When to use .Net Remoting over Web services

.Net Remoting provides distributed solution for a corporate use. So, if you need distributed environment to be implemented for internal use, .Net remoting is the best choice. If you require a faster distributed solution, .Net Remoting with TCP protocal using binary format is faster than Web services. .Net Remoting is better solution when large transfer of data is required.

How does .Net Remoting works?

Remoting.Net allows components to interact across application domains, processes, and machine boundaries, thus allows applications to access remote resources in a networked environment. The interaction of components is made possible through proxy in remoting architecture. When a client calls the remote method, it’s the proxy that receives the call. The proxy then encodes the message using formatter. The messages are then sent over the channel to the server process where listening channel receives the call and passes it to the remoting system. The requested method is then invoked and results are returned back to the client.

.Net Remoting provides an infrastructure where objects of different AppDomains can interact. A client interacts with server object using .Net Remoting architecture. An object interacts with other objects outside AppDomains using proxy since the objects can't access directly anything outside AppDomain.

Point to be noted.
A remote object is implemented by inheriting MarshalByRefObject class.
A client has to obtain proxy activating a remote object by calling CreateInstance, GetObject, or new.
Local objects can be passed as parameters when making remote calls. Local objects are passed by value in a remote call.
The object passed as parameter in a remote call must be serialized.

Activation Model
You need to activate remote object before use. There are two activation modes in .Net Remoting
Server Activation
In this mode, objects are created automatically when a client attempts to access the object. The object doesn't get created when you use new keyword to create instance of the server class.
Client Activation
In this mode, objects are created when you use new keyword to create instance of the server class.

A server object is created and deployed on the network that serves client requests. The server objects have to be registered with the CLR before it can be accessed by client. The details that have to be provided to the CLR are

Name of the assembly that should be loaded to activate the object
The namespace and type name of the object
The name of the endpoint where the object can be accessed
The channels to be used by client to communicate have to be registered.
The registered channels then start listening for clients to connect.

Once a remote object has been deployed, clients can connect and invoke methods on the server object.

In order to access remote object, the client first activates the object by calling new, GetObject, or CreateInstance. On activation request, a proxy is created to represent the remote object. The client message in the serialized form is transported to the server. The type of serialization depends on the channel. For example, when the HTTP channel is used, all messages are serialized to XML and transported over SOAP. On the other hand, TCP uses binary serialization.

On the server side, the requested method is then invoked and results are packaged in a message and returned back by to the client. If the target object is of type SingleCall, it will automatically be garbage collected after the call completes.

Approaches to access server objects in Remoting.Net

First one to have copy of server object on the client machine and accessing local copy of object to call method. This method is good suited when the object is not very big not having too many methods. Copying big object is wastage of client resources which includes network resources and processing time.

The second approach is to create a proxy object that returns reference of all the methods and properties of server object in the client domain. The proxy acts as local object, fake server object on the client machine. Any method call from the client will be served by proxy which in turn access server domain to get response from server object. This approach is good when the object is big with many methods.

Remotable and Nonremotable objects

You have two categories of objects in distributed applications: Remotable and Nonremotable objects.

Nonremotable object can’t be accessed outside its own application domain. This kind of object doesn't allow its methods or properties to be used by remoting system. Remotable objects can be accessed outside its own application domain. The remoting system can use methods and properties of this kind of object.

There are two types of remotable objects

Marshal-by-value-objects - When client calls a method on marshal-by-value-object, the remoting system creates a copy of this object and passes the copy to the client application domain. The copy hence received can handle any method call in client domain. Using Marshal-by-value-object reduces resource consuming trip across network.

Marshal-by-reference-object - When client calls a method on Marshal by reference object, the remoting system create proxy object in the caller application that contains the reference of all method and properties of the object.