Single Call objects service one and only one request coming in. Single Call objects are useful in scenarios where the objects are required to do a finite amount of work. Single Call objects are usually not required to store state information, and they cannot hold state information between method calls. However, Single Call objects can be configured in a load-balanced fashion.

Singleton objects are those objects that service multiple clients and hence share data by storing state information between client invocations. They are useful in cases in which data needs to be shared explicitly between clients and also in which the overhead of creating and maintaining objects is substantial.

For example, the following code snippet depicts a server-activated (wellknown) type with activation mode set to SingleCall.

 When a client creates an instance of a remote object, it receives a proxy to the class instance on the server. All methods called on the proxy will automatically be forwarded to the remote class and any results will be returned to the client. From the client's perspective, this process is no different than making a local call.

 The .Net Framework makes a provision for creating remote objects as stateless. When an object is configured as SingleCall, it will be created when a method is called on that object. The object processes the call, returns an optional result, and is then collected by the garbage collector. This way the client is always connected to a fresh object with each call.

Configuring an object as a Singleton ensures that all clients will be connected to the same object whenever a call is made to that object.

The lifetime of remote objects is controlled by a leasing mechanism. When an object is first created, it is given a lease time. When the lease time of the object reaches zero, the object will be disconnected from the Remoting infrastructure and when all references to the object has been freed within the AppDomain, it will be collected by the garbage collector. A number of mechanisms are provided that allow the client to extend the lease on the object, thereby sustaining its life.

As with any normal .Net class, event handlers can be attached to remoting objects so that a client can hook methods to serve the declared events. Whenever the event gets fired in the remote object, the event handler method is executed in the client. However delegates require that the receiving object be able to obtain the type information for the class whose function is being wrapped by the delegate. In the case of the remoting, it means that he client assembly be available to the server. If the client assembly is not available to the server, that type information cannot be loaded.

To make remoted delegates work, an abstract class (MustInherit in Visual Basic .NET, abstract in C#) that contains the callback function must be defined in a common assembly that both client and server have access to. The client can then derive a custom class from this abstract class to implement the logic in the callback. The abstract class needs to have a specific structure. The function to be used for callbacks must be a public function that cannot be overriden. This function must forward all calls to a protected abstract function that is overridden in the derived client classes. The reason for this architecture is that the delegate needs to be able to bind to a concrete implementation of the callback function, and this implementation must not be overridable.

Remoted delegates are implemented in the ‘Message and File Transfer Application’ (explained in section 6). You can refer the source code attached.

The solution architecture is shown in the diagram below. There is class the object of which (the remote object) is hosted on a remote server by using a console application. Loading of this application can be configured using a windows service. As with any client-server application, it is must that the server application should be up running before the clients can access it. This object is a singleton object. The client application is a Winform which has reference to a local copy of the remote component. Using the local reference, the client application creates a proxy object. This proxy object then gets a reference of the remote object so that whenever the clients access the proxy object, it in turn accesses the remote object. Since the remote object is a singleton object, all the clients connecting to a single server is accessing the same instance of the remote class. This facilitates the communication among different clients.

The remote object exposes certain event handlers such as OnLogin, OnLogout, OnMessagePublish etc.. The client application can hook methods to these event handlers. So, whenever these events happen, all the clients get notified about it.

Whenever a user sends some message to another user, the ‘OnMessagePublish’ event is raised. The sender acts as a publisher. All the clients, who have registered (added) a method to the ‘OnMessagePublish’ event handler act as listeners. This is how ‘Publisher-Listener’ design pattern is being implemented in this design.