Distributed Computing Using .NET Remoting

Distributed computing has become the identity of present generation software applications. In past, developers used technologies like DCOM (Distributed Component Object Model) by Microsoft, CORBA (Common Object Request Broker Architecture) by OMG and Java RMI (Remote Method Invocation) by SUN for the same purpose.

Microsoft .Net Remoting is an extensible framework provided by Microsoft .Net Framework, which enables communication across Application Domains (AppDomain).

AppDomain is an isolated environment for executing Managed code. Objects within same AppDomain are considered as local whereas object in a different AppDomain is called Remote object. Microsoft .Net Remoting comes into picture when an application requires communication between different AppDomains.

How Remoting Works?

Just like other distribute computing technologies, in .Net Remoting also, client object doesn't make a direct call to the remote object, rather it creates a proxy object of the remoting object and then uses the proxy object to invoke methods of remote object. When the client object calls a method of remote object via proxy, the call is formatted by a formatting object (SOAP, Binary or any Custom formatter). After formatting the call is transferred to the remote object via proper channel (TCP Channel, HTTP Channel or any Custom channel) where the method is executed. Now the entire process is reversed to return appropriate result to the client object.

Figure 1: .Net remoting Architecture

Remote Object

Remote object (Located at server side) is derived from System.MarshalByRefObject class which provides required functionality for communicating with an object in different AppDomain. Any object that needs to be transferred across appDomains has to be passed by value and should implement ISerializable interface. An object which doesn't implement ISerializable interface can't be transmitted across appDomains.

Example:

using System;
namespace Employee
{
public class Employee: MarshalByRefObject
{
//Constructor
public Employee
{
// Implementation details
}
//Other functions will come here
}
}

Proxy Object

This is created when a client object activates a remote object.

We can have two types of remoting objects i.e. Client Activated Object or Server Activated Object.

Client Activated Object: Client Activated Remote object is one whose life is controlled by client object. Here one single instance of remote object will exist per client object. Client Activated Object is created using new keyword. Client Activated object can store state information for a specific client.

Server Activated Object: Contrary to Client Activated Remote objects, life time for Server Activated Object is controlled by Server. These objects are created when client object calls a method on the proxy object. There are two types of Server Activated Objects i.e. SingleCall and Singleton.

SingleCall: They serve only one client request. Once the client request is over, they are subjected to garbage collection. They don't store any state information.

Singleton: They serve multiple clients, thereby allowing information sharing between requests. They are stateful objects unlike SingleCall, which is stateless.

//Creating a new instance of a remote object using new.
Employee Emp = new Employee();
//Creating a new instance of a remote object using CreateInstance.
Employee Emp = (Employee)Activator.CreateInstance(...);

Note: Above method creates an instance of the remote object based on the parameter passed. For a complete listing of the same, please refer MSDN.

//Retrieving an Existing Instance.
Employee Emp = (Employee)Activator.GetObject( typeof(Employee), HTTP://[Path]);

All the calls to the remote object (at server side) are routed through proxy object. To make things little complicated, there are two types of proxy objects involved in the process i.e. Transparent proxy and Real proxy. Transparent proxy provides the implementation of all public method to Client object which means that client object always talks to Transparent proxy which in turn makes call to Real proxy. Real proxy passes the message to channel object. Developers can customize the Real proxy to include additional functionalities if required.

Formatters

They encode and decode the message between client application and Remote object. .Net Framework provides SOAP and Binary formatter. It also supports custom formatters (IRemotingFormatter) developed by programmers.

Binary Formatter: System.Runtime.Serialization.Formatters.Binary
SOAP Formatter: System.Runtime.Serialization.Formatters.Soap

Channels

They are responsible for transmitting the message over the network. .Net Framework provides HTTPChannel and TCPChannel. It also supports custom channels (IChannel) developed by programmers.

HTTPChannel: System.Runtime.remoting.Channels.Http
TCPChannel: System.Runtime.remoting.Channels.Tcp

By default HTTP Channel uses SOAP Formatter and TCP Channel uses Binary Formatter.

Channels need to be registered with the remoting service as shown below.

//Registering a channel
ChannelServices.RegisterChannel();

Hosting a Remoting Application

Remoting Host is a runtime environment for the remote object i.e. Microsoft IIS Server.

Step By Step: Let's see the entire step once again.

1. Client object registers a channel.
2. Creation of Proxy object (Client activated or Server Activated)
3. Calling the method of remote object via proxy.
4. Client side formatter formats the message and transmits via appropriate channel.
5. Server side formatter reformats the message.
6. The specified function on remote object is executed and the result is returned.
7. Above process of formatting and reformatting is reversed and the result is returned to client object.

Above article explains the basic terms and technology involved in .Net Remoting. It's possible to create complex distributed applications using .Net Remoting. Developers can create their own custom channels and formatters depending on business needs. There is no built in security provided by .Net Remoting framework. The security features need to be provided by the hosting environment.