Using the Remoting Callbacks in .Net Applications

Contents

Introduction
Concept and Design
      Remoting Interface
      Callback Custom Attribute
      Remoting Method
Implementation
      RemoteCallbackLib
      RemoteObject (A , X and WS)
      RemoteObjectX
      RemoteObjectWS
      HostServer
      HostServer.exe.config
      RemoteWindowsForm
            Initialization
            Callback object
            Invoking the Remote Method
      RemoteWindowsForm.exe.config
Test
Conclusion


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 demostrate 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: