Remoting

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