What the hack is .NET Remoting?

If you have ever worked with DCOM or CORBA, then you have an understanding of how to work with Remote Objects and how to deal with application communications across boundaries. .NET Remoting is Microsoft’s new infrastructure that provides a rich set of classes that allow developers to ignore most of the complexities of deploying and managing remote objects. In .NET Remoting, calling methods on remote objects is nearly identical to calling local methods. Here, I give a very brief introduction about .NET Remoting. Remoting is a framework built into the common language runtime (CLR) that can be used to build sophisticated distributed applications and network services. When a client creates an instance of a remote object, it receives a Proxy to the class instance on the server. All methods called on the Proxy will automatically be forwarded to the remote class and any results will be returned to the client. From the client's perspective, this process is no different than making a local call. To use .NET remoting to build an application in which two components communicate directly across an application domain boundary, you need to build only the following: A remotable object. A host application domain to listen for requests for that object. A client application domain that makes requests for that object. Even in a complex, multiclient/multiserver application, .NET remoting can be thought of in this way. The host and the client application must also be configured with the remoting infrastructure and you must understand the lifetime and activation issues that the remoting infrastructure introduces. Proxy objects. When a client creates an instance of a remote object, it receives a proxy to the class instance on the server. All methods called on the proxy will automatically be forwarded to the remote class and any results will be returned to the client. From the client's perspective, this process is no different than making a local call. Any exceptions thrown by the remote object will automatically be returned to the client. This enables the client to use normal try and catch blocks around sections of the code to trap and deal with exceptions.

Object passing. All objects created remotely are returned by reference and have to derive from MarshallByRefObject. Objects passed as parameters to a remote method call can be forwarded by value or by reference. The default behavior is pass by value provided the object in question is marked by the custom attribute [serializable]. Additionally, the object could implement the ISerializable interface, which provides flexibility in how the object should be serialized and deserialized. Objects that are not marshal by reference or marshal by value are not remotable.

Activation models. Remote objects can easily be created from a client by calling new. The framework contains enough "intelligence" to realize you are dealing with a remote object and will ensure an instance of the object gets created in the relevant remote application. Creating instances of remote objects is not limited to default constructors; you can even do this using a constructor that requires one or more parameters. The Activator class contains two methods, CreateInstance and GetObject, that can also be used to create an instance of remote objects. The former can be used in place of new to create an object instance while the latter is normally used to connect to an object at a specified URL.

Stateless and Stateful objects. The framework makes a provision for creating remote objects as stateless. When an object is configured as SingleCall, it will be created when a method is called on that object. The object processes the call, returns an optional result, and is then collected by the garbage collector. This way the client is always connected to a fresh object with each call. Configuring an object as a Singleton ensures that all clients will be connected to the same object whenever a call is made to that object. ClientActivated objects allow the client to pass parameters to the constructor of a remote object when it gets created. Each activation request for a client activated object (Activator.CreateInstance or new in combination with entries in the configuration file) on the client results in a new object on the server.

Channels and Serialization. When a client calls a method on a remote object, the remoting framework automatically serializes any data associated with the request and transports the data to the remote object using a channel. Some of the more popular channels supported are HTTP, TCP, and SMTP. In the case of HTTP, the framework uses the SOAP protocol to transport data in XML format from the client to the server and back. The default serialization formatter for HTTP is a SOAP formatter. Since programmers can create custom formatters for use with any channel, the remoting framework can be configured to work with any external .NET Framework on other platforms. The TCP channel uses plain sockets and Binary Serialization by default and can be used to communicate with any object on a remote server. Of course, .NET remoting is in itself a full 500 pages book, this is just a starter and can be used generate interest for development. Share your thoughts.