Distributed Computing Using .NET Remoting

Distributed computing has become the identity of present-generation software applications. In the 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 on the server side) is derived from the System.MarshalByRefObject class which provides the required functionality for communicating with an object in different AppDomain. Any object that needs to be transferred across app domains has to be passed by value and should implement the ISerializable interface. An object that doesn't implement an ISerializable interface can't be transmitted across app domains.

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 the 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(typeof(Employee));

Note. The 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 (on the 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. The 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 format. 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. The 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. The client-side formatter formats the message and transmits it via the appropriate channel.
5. The 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.

The 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.