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 the same AppDomain are considered as local whereas object in a different AppDomain is called Remote object. Microsoft .Net Remoting comes into the picture when an application requires communication between different AppDomains.

 

How Remoting Works?

 

Just like other distributed computing technologies, in .Net Remoting also, the 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 the remote object. When the client object calls a method of a 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 a proper channel (TCP Channel, HTTP Channel, or any Custom channel) where the method is executed. Now the entire process is reversed to return the 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 the 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 the ISerializable interface. An object which doesn't implement an 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 the client object. Here one single instance of the remote object will exist per client object. Client Activated Object is created using the new keyword. Client Activated object can store state information for a specific client.

 

Server Activated Object: Contrary to Client Activated Remote objects, a lifetime for Server Activated Object is controlled by Server. These objects are created when a 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 to 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 the proxy object. To make things a 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 methods to the Client object which means that the client object always talks to the Transparent proxy which in turn makes calls to the Real proxy. Real proxy passes the message to the channel object. Developers can customize the Real proxy to include additional functionalities if required.

 

Formatters

 

They encode and decode the message between the client application and the 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 a remote object via proxy.
4. Client-side formatter formats the message and transmits it via the appropriate channel.
5. Server-side formatter reformats the message.
6. The specified function on a remote object is executed and the result is returned.
7. Above the process of formatting and reformatting is reversed and the result is returned to the 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 the .Net Remoting framework. The security features need to be provided by the hosting environment.