Introduction

The object remoting is an integral part of the .Net Framework. It allows to call
an object located on the Enterprise network using the same programming techniques
like access to object located within the application domain. The remoting is a peer-to-peer
communication mechanism between the remote object (server) and its consumer on the
client side. The objects can be hosted in different application domains such as
Web Server, Web Service, COM+ Service, etc. The remoting call is processing
in a synchronously manner with the option of the asynchronously end notification
on the client side. This design pattern is knew as a BeginInvoke/EndInvoke technique.
The client will receive a notification of the end remoting with the return value
of the called method. Note that the client has no state of the remote method during
this remoting process. (only finally as a returned value). This article will describe
a mechanism of the remoting callback which can be used to notify client about the
remote method state. This solution is suitable for any cases where "real-time"
processing is required. In my simple sample I will demonstrate how to make a Windows
Form more sensitive and pre-emptive during the remoting time using the Remote
Callbacks.

Concept and Design

The concept of the remoting call-back is based on the remoting delegate, where
a callback object is delegated to the remote object within the invoked method.
The following picture shows the remoting callback "plumbing" mechanism:

The remoting part is sitting between the client and server objects. From the application
point of view it represents by the proxy/stub of the remoting object, communication channel
and message format protocol. The client/server connectivity is started at
the remote object with publishing its metadata (url object) and registering the
stub object in the specified listener such as tcp or http channel and port. This
process can be done either programmatically or administratively using a config file.
The client side needs to know where the remote object metadata located and which
channel and port is dedicated for this connectivity (listener channel). Based on this information,
the client will create a proxy object of the remote object within its application domain.
Also like a server side, this process can be completed by either the hard-coding or using the config
file. Using config files to establish a "wiring" between the client/server is more
flexible solution than hard-coding.

The above picture shows two remoting objects between the client and sever
side:

Remote object - is calling by the client
(Windows Form) to invoke any public member of the remote object. The object
can be setup for any mode such as Singleton, SingleCall or Client Activated.
Note that remoting callback mechanism doesn't need to keep an object state
(for instance: event class), it's a stateless - loosely coupled design
pattern. The connectivity are setup explicitly and transparently (the remote
object has to be published).

Callback object
- is calling by the remote
object within the method scope. Here is a situation little bit different. The
remote callback is a private client-server contract and it is configured implicitly.
The major different is that the client creating the callback proxy and then it is
delegated to the remote object as a method argument. The callback object is
running in the Singleton mode with unlimited lease time.

Based on the physical connectivity with the remoting objects, the client can
create one common callback object for the same channel and formatter for
different remote objects. This sample using
a common callback object, where Windows Form calls concurrently three different
remote objects and passing delegate of the same callback proxy. Note that each
remote object will create own remote callback proxy based on the delegate metadata and
using the Reflection design pattern.

The following picture shows a situation on the client side using multiple
remoting objects:

This is a generic model for any number of the remoting callback objects. The
callback object is receiving a state from the remote object and passing it to the
thread pool in the "fire&forget" fashion. The worker thread then dispatching a
call to the Windows Control handler based on the cookie and senderId value.

Note that every object is serialized/de-serialized between the proxy/stub,
therefore it has to be derived from the ISerializable (or attributed).

Let's look at closely for some issues which are related with the design
implementation:

Remoting
Interface

Interface is a contract between the object and its consumer. The interfaces
allow to publish an object based on their abstract definitions. This
encapsulation is giving a more flexibility in the design implementation. The
major advantage using interfaces (or abstract class) is their loosely design pattern,
which it may play an important role in the remoting issue. It is a good design
technique to put all common abstract definitions into one assembly. In my
sample I created separate project called a ContractObject
for that issue.

The following is an abstract definition of the remote object contract:

There are three parts of the metadata in its assembly: delegator, interface
and callback's EventArg class. They can be modified based on needs of the
application. Note that interface has been attributed by Guid value to keep its
ID the same (The .Net Service will be accepted this Guid each time when object is going to
be re-registered into the COM+ catalog)

Callback Custom Attribute

For setup a config of the Remote Callback object on the client side is
suitable to use a custom attribute technique. It will allow to hide and reuse
all implementation for this private remoting object. I created a separate project
- RemoteCallbackLib to handle this solution.
There is a RemoteCallbackAttribute to config
any attributed object (of course derived from the
MarshalByRefObject class) for the Remoting purpose.

Remoting Method

The method
signature of the Remoting object which wants to use the Remoting Callback
mechanism includes less two additional arguments such as the ticketId and objwire
as it is shown in the following snippet:

RemoteWindowsForm.exe.config - the config info for Remoting objects using
by this client

RemoteCallbackLib

The following code snippet shows the implementation of the RemoteCallbackAttribute. Its design is based on the Refection of the "parent"
assembly, where located all metadata of the Callback object. The
RemoteCallbackLib is built into the separate assembly which it can be reused by another remoting clients.

RemoteObject (A , X and WS)

The design pattern of the Remoting methods is the same for any of these
remoting objects. The following code snippet shows the RemoteObjectA class derived from the
MarshalByRefObject
class and IRmObject interface.

There are implementation of two methods of the
IRmObject interface in the object. The first one -
Echo has a test purpose, the other one -
GiveMeCallback simulated some time consuming work with notification of
the
method state using the Remoting Callback mechanism. The method state is wrapped
and serialized by the CallbackEventArgs object.

Now I will show you only differencies in the following remote objects:

RemoteObjectX

This is a .Net Service - transactional and poolable object register into the
COM+ catalog and config as a remoting object. There are attributes for assembly
and class necessary for this object configuration in the COM+ catalog. The other
change, the remote class is
derived from the ServicedComponent. This is a standard stuff for the .Net Service
configuration.

Note that this project has to be unzip and move it into the localhost\RemoteObjectWS
directory in prior of opening the solution.

HostServer

This is a server program to host
a remote object. It's a very simply console program to perform a configuration
of the remote object(s). There are two kinds of options for this configuration
as I mentioned earlier. The option 1 is commented.

HostServer.exe.config

This is
a configuration file to config the Remoting ObjectA and ObjectX on the Tcp
channel port# 12345. Both objects have been choose for server activatation
running as a wellknown object in the SingleCall mode. This config file can be modified during the
deploying process to match an application environment.

RemoteWindowsForm

This is a
client side - consumer of the Remoting objects. The Remoting client can be any
object on the Enterprise Network. This sample is using a Windows Form to
demonstrate an asynchronously invoking remote objects with callbacks to the
Windows Controls.

There are 3 major parts on the client side related to
the remoting callbacks:

Initialization

The Initialization part has the following responsibility for the remoting
process and connectivity:

subscribing (config) a callback object as a remoting object

creating proxy objects of the requested remote objects based on the configuration
file

Callback object

The callback object is the remoting object for the client's remoting objects,
that's why it is derived from the MarshalByRefObject class. The callback object
has been initiated for infinity lease time (actually its life time is depended
from the client's life time). There is one callback method - Progress with the
arguments (state) passed from the remote object. Based on this state, the DispatchEvent helper calls a particular Windows Control. Note that callback
method is running in the "fire&forget" fashion to isolated processes and
minimize its respond time. The callback object holding a state of the
progressing and passing back to the remote object which it will allow to abort
the remoting call. This a a great feature of the remoting callbacks to make the
remote call pre-emptive.

The design implementation is the same for any remoting object. It's starting
to create a callback delegator - RemoteCallback for
the specified callback method (Progress). Secondly, the
AsyncCallBack is initiated for the particular handler function (for
instance; asyncCallBackA). This function is going
to be called at the end of the remoting call. Next step is to create a delegator
of the Remoting method for the asynchronous call. As a last step is invoking a
delegator method using the BeginInvoke function.

Note that all calls are processing without any blocking, so the Windows
Control thread can be yielded and be ready to process any event such as callbacks,
user interface, asyncCallBacks, etc. When the remoting is done, the post-call
function (handler) is called to finish and resulting the remoting method.

RemoteWindowsForm.exe.config

This is a client configuration file. As you can see it's a different from the
server side and also from the standard one. There is no section for the
system.runtime.remoting. I created a custom section
Client\urlAddress where located an objecturi address of the remote
object which client wants to talk.

Test

Testing of the Remoting Callbacks solution needs to install properly Web Service
and .Net Service projects. The package has included a batch files to make their
installation easy. Please, look at them an change their pathname related to your
setup environment if it's necessary. After that, launch the client program (RemoteWindowsForm)
and you should see the following form:

The Echo Message has been nested trough all of three remote objects. This is
an indication that your connectivity with the remote objects are valid. Now
click the button Run to process the remoting callbacks.

As you can see, each remote object will notify its control on the Window Form
such as the progress bar, text and button colors. Pressing the button Abort the
remoting process will be aborted on the all remoting objects. After these simple
test, lunch more clients (for instance five) and repeat the above test
simultaneously for all of them. I hope everything is working well like on my
machine.

Conclusion

Using the Remoting Callback in the .Net Application
enhancing its event driven model, making more pre-emptive and realistic. As
typically example is downloading a large file or query database. In this article
I described the capability of the .Net Remoting and Reflexion which they play
very significant role in the .Net Enterprise Solutions.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

Comments and Discussions

thanks for a very helpfull article. I do have a question though. I have a similar architecture in our n-tier app. Instaed of a delegate I am using an interface based callback method. The interface is passed by the client to the remoting server. and when the server is done processing it calls the dataready function on the interface. Which then invokes the dataready function on the client side. My question is, when the dataready function executes on the client side what thread it is executed on, a threadpool thread or an iocompletion thread?

I found that when RemoteWindowsForm invoke remoteObject's GiveMeCallback,
system will invoke AsyncCallBack delegate successfully but remoteObjecte's method doesn't work!
Does anything about security issue need to be concerned or setup something else?

My development eviornment is VS2003 and I modified some code in RemoteCallbackSubscriber,thus the test program works.

hello ,
I was planning on using .NET remoting for IPC between .NET Apps on the same box. Is anybody aware of any security issues that maybe posed because of opening of ports when a TCP channel is used?
I would appreciate any links for the above.
Also does socket commumication on the same box open up the box to hackers.
Sumit

Hello, sorry for me posting this here, I hope it is in the right spot.

I have an issue with remoting where I am finding it a little hard to make it usefull.

Here is my issue. it seems that all demo programs that I can find have a host and a client. The client side is very simple.

It is the server side that I am having issues. What I want to do is be able to from the client access verables that the host is running. I'll give you an example.

The host application will load, It will creat gloabl DV that will hold my information. the application its self will constantly be updating and changing this data. This application Will also load the remoting services.

This is where the problem comes in, the dll loaded objects that form the objects that the clients conect to are unable to access objects outside of there DLL meaning that I can't get them to inract with the host aplication.

Not to sure what you mean by that. Not fully up to speed with the yet.

The host is a windows aplication.

There is a publicaly declared DV that is done in the Form1 script. the application is efectivly a single form application. It will colect information and re serve it to clients that request it.

So to answer your question the processes that will be running will be driven from a timmer. they will handel the colection and calculation of data. the other process will be the one that handles the request for information from the client.

Is there any way to host remote object without using of IIS, Windows services or custom executables?
I heard that it is possible to implement remote objects as COM+ components and host them in dllhost.exe. Is it true?

when i tried to execute the sample application given (try to start the form application) , it gives a message saying "Could not create System.Configuration.NameValueSectionHandler,System" after executing the line NameValueCollection uriAddr = (NameValueCollection)ConfigurationSettings.GetConfig("Client/urlAddress"); in Form1.cs. What cud be the reason?

I can run and compile the project (after associating the objectA & objectX dlls with the hostserver project under references), but I get "Exception from HRESULT: 0x8013151A." in the GUI textbox when the client runs.