.

NET Remoting

Before going into the discussion of .Net Remoting let us talk some important objects involved in
.Net remoting.
1. The process of Packaging and unpacking and sending the method calls across the different
application domains via serialization and deserialization is called as Marshalling.
2. Marshalling is done by the object called Sink. Sink is an object that allows custom
processing of messages during remote invocation.
3. Channels are objects used to transport the messages through the network or across
different application domains
4. Application Domain is the Logical construct of the CLR that is the unit of Isolation for an
application which guarantees, Each Application can be Independently stopped, An
application can not directly access code or resource of the other application, a fault in one
application will not effect the other application CLR allows multiple applications in a single
Process by Implementing Application Domains.

.Net Remoting enables objects in different application domains to talk to each other. The real
strength of remoting is in enabling the communication between objects when their application
domains are separated across the network. The .Net Remoting Framework provides number of
services like Activation, Lifetime control, Communication Channels for transporting messages to
and from remote application. Formatters are used for encoding and decoding the messages before
the channel transmits them. Applications can use binary Formatter where Performance is critical
and XML where Interoperability is Critical.

There are really 7 steps that are mainly involved in understanding the .Net Remoting
1. When a Client object wants to create an instance of the server object (to access the
remote object) the remoting System Framework will create a proxy (Transparent Proxy) of
the server object on the Client side, that contains list of all classes, as well as interface
methods of the remote object. The TransparentProxy class gets registered with the CLR.
2. The Proxy object behaves just like the remote object, this leaves the client with the
impression that the server object is in the client's process
3. When a Client object calls a method on the server object, the proxy passes the call
information to the remoting Framework on the client. This remoting System (Remoting
Framework) in turn sends the call over the channel to the remoting System on the server
4. The Remoting system on the server receives the call information and on the basis of it, it
invokes the method on the actual object on the server creating object if necessary
5. Then the remoting system on the server collects all the results of the invocation and
passes through the channel to the remoting System on the client.
 6. The remoting System on the client receives the response of the server and passes the
results to the client object through the proxy
7. The process of Packaging and unpacking and sending the method calls across the different
application domains via serialization and deserialization is called as Marshalling.

Note: Remotable objects are the objects that can be marshaled across different platforms. All
other are object are nonremotable.

They are basically two types of remotable objects

1. Marshall-By-Value (MBV): Objects are copied and passed over the server application
domain to the client application domain
2. Marshall-By-Reference (MBR): Objects are accessed on the client side by using a proxy.
Client just holds the reference of this object which in on server-side.

Marshall-By-Value objects reside on the server. However when the client invokes a method of
the MBV object, the MBV object is serialized, (by the Remoting Framework) and transferred over
the network (using the channels & sinks) and restored on the client as an exact copy of the
server-side object. The Method is then invoked directly on the Client. When this happens, the
MBV object is no longer a remote object. Any method calls to the object do not require any proxy
object or marshalling because the object is locally available.
So the MBV objects provide faster Performance by reducing the number of network round trips,
but in the case of large objects the time taken to transfer the serialized object from the server to
the client can be very significant. Further, MBV objects don’t allow you the flexibility to run the
remote object on the server environment (That is you have to bring it to the client side)
A MBV object can be created by declaring a class with serializable attribute:
[Serializable()]
Public class MyMBVObject
{
// …
}

If a class needs to control its own serialization, it can do so by implementing the ISerializable
interface as follows:

using System.Runtime.Serialization;

[Serializable()]
public class MyMBVObject : ISerializable
{
// …
//Implement custom serialization here
public void GetObjectData(SerializationInfo info, StreamingContext context)
{
//...
}
//...
}

Marshall-By-Reference objects are remote objects they always reside on the server and all the
methods invoked on these objects are executed at the server side. The Client Communicates with
the MBR objects on the server using the Local proxy object that holds reference to the MBR
object.
Although the use of MBR object increases the network round trips, they are good choice when the
objects are prohibitively very large or when the functionality of the object is only available on the
sever environment on which it is created.
MBR object can be created by deriving from the Namespace System.MarshalByRefObject class

Public class MyMBRObject:MarshalByRefObject

{
// …
}

Remote Object Activation:

We have two types of remote objects MBV and MBR among these two only MBR objects can be
activated remotely. No remote activation is needed in the case of MBV because the object itself is
transferred to the client as explained earlier.

Remotable Members:
An MBR object can remote the following types of members
1. Non-Static public methods
2. Non-Static public properties
3. Non-Static public fields.
There are two types of activation modes an MBR object is classified to
1. Server Activated objects
2. Client Activated objects

Server Activated Objects (SAO)

SAO’s are those remote objects whose lifetime is directly controlled by the server. When a client
requests an instance of a server-activated object, a proxy to the remote object is created in the
clients. The remote application domain object is only instantiated (or activated) on the server side
when the client calls a method in the proxy object.
Server activated object provide limited flexibility because they are only be instantiated using their
default constructors (Parameter-less).
There are two possible activation modes for server activated objects
1. Single-call activation mode
2. Singleton activation mode

Single call activation Mode:

In the single call activation mode an object is instantiated for the sole purpose of responding to
just one client request. After the request is fulfilled, the .Net remoting Framework deletes the
object and reclaims the memory. Objects activated in single-call mode are also known as stateless
because the objects are created and destroyed with each client requests, therefore they do not
maintain state across requests.

Singleton Activation Mode:

In the Singleton activation mode at most (Minimum) there will be one instance of the remote
object regardless of the no. of clients accessing it. A singleton mode object can maintain state
information across method calls. For this reason such objects, are also sometimes known as
stateful objects. The state maintained by the singleton-mode object is globally shared by all its
clients.

Client Activate objects (CAO):

CAO are those remote objects whose Lifetime is directly controlled by the client. This is in direct
contrast to SAO. Here the server and not the client have complete control over the lifetime of the
objects. Client activated objects are instantiated on the server as soon as the client request the
object to be created. Unlike as SAO a CAO doesn’t delay the object creation until the first method
is called on the object. (In SAO the object is instantiated when the client calls the method on the
object)

REVIEW BREAK
• .NET remoting enables objects in different application domains to talk to each other even
when they are separated by applications, computers, or the network.
• The process of packaging and sending method calls among the objects across the
application boundaries via serialization and deserialization is called marshaling.
 • Marshal-by-value (MBV) and Marshal-by-reference (MBR) are the two types of remotable
objects. MBV objects are copied to the client application domain from the server
application domain, whereas only a reference to the MBR objects is maintained in the
client application domain. A proxy object is created at the client side to interact with the
MBR objects.
• A channel is an object that transports messages across remoting boundaries such as
application domains, processes, and computers. The .NET Framework provides
implementations for HTTP and TCP channels to allow communication of messages over the
HTTP and TCPs, respectively.
• A channel has two end points. A channel at the receiving end, the server, listens for
messages at a specified port number from a specific protocol, and a channel object at the
sending end, the client, sends messages through the specified protocol at the specified
port number.
• Formatters are the objects that are used to serialize and deserialize data into messages
before they are transmitted over a channel. You can format the messages in SOAP or the
binary format with the help of SoapFormatter and BinaryFormatter classes in the FCL.
• The default formatter for transporting messages to and from the remote objects for the
HTTP channel is the SOAP formatter and for the TCP channel is the binary formatter.

Example:
Step 1: Creating the Server Server.cs on Machine1
using System;
using System.IO;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
namespace Server
{
public class ServiceClass : MarshalByRefObject
{
public void AddMessage (String msg)
{
Console.WriteLine (msg);
}
}
public class ServerClass
{
public static void Main ()
{
HttpChannel c = new HttpChannel (1095);
ChannelServices.RegisterChannel (c);
RemotingConfiguration.RegisterWellKnownServiceType(typeof(ServiceClass),
"ServiceClass",WellKnownObjectMode.Singleton);
Console.WriteLine ("Server ON at 1095");
Console.WriteLine ("Press enter to stop the server...");
Console.ReadLine ();
}
}
}

Save this file as Server.cs. Compile this file using

csc /r:system.runtime.remoting.dll /r:system.dll Server.cs

This will generate a executable Server.exe , run this file and on the console u should see
Server ON at 1095
Press enter to stop the server...
To check whether the HTTP channel is bonded to the port open the browser and type
http://localhost:1095/ServiceClass?WSDL
You should see a XML file describing the Service.

Step 2: Creating Client Proxy and Code on Machine2

Creating a client proxy requires to use a tool provided by Microsoft called soapsuds.exe
This utility ready the XML description and generates a proxy assembly used to access the server.
Go to a different machine and type in
soapsuds -url:http://<Machine Name >:1095/ServiceClass?WSDL -oa:Server.dll

This will create a proxy called Server.dll which will be used to access the remote object

Client Code TheClient.cs

using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Http;
using Server;
public class TheClient
{
public static void Main (string[] args)
{
HttpChannel c = new HttpChannel (1077);
ChannelServices.RegisterChannel (c);
ServiceClass sc = (ServiceClass) Activator.GetObject (typeof (ServiceClass),
"http://<Machine where Service is Running >:1095/ServiceClass");
sc.AddMessage ("Hello From Client");
}
}

Save this file as TheClient.cs. Compile it using

csc /r:system.runtime.remoting.dll /r:system.dll /r:Server.dll TheClient.cs

The output will be TheClient.exe, run it and check the server console on Machine 1, you will see
"Hello From Client".

This example used HTTP Channel to transport messages to remote components; likewise TCP
channel can also be used to achieve the same result.