Overview of Remoting

Remoting is the system within the .NET Framework that enables developers to create distributed applications quickly and easily. Remoting provides a layer of abstraction that allows the developer to worry more about the content and design of a distributed system than about the mechanism by which the components communicate. The choice of transport layer (such as TCP/IP, Inter-Process Communication, and so on) has no significant impact on the use of the remoting classes. This means that remoting applications can communicate over TCP/IP or any other means without having to make significant changes to the application.

There are three aspects to any remoting system:

1. A remotable object Any .NET object that will be transmitted between remoting endpoints

2. A remoting host An application domain that has been configured to respond to requests for the object indicated in item #1

3. A remoting client An application domain that initiates a request for the object indicated in item #1

Remoting works in an extremely simple way. A host application domain informs the remoting infrastructure that it is hosting an object on a specific URL using a specific channel (you'll see more on channels later in the chapter). A remoting client then requests that object by supplying the object's URL to the remoting infrastructure.

The remoting client then works with a proxy, much the same way COM interoperability works. Rather than your code communicating directly with the remote object, your code instead works with a proxy that exposes properties and methods with the same names and types as the remote object. Each member then forwards the request over the channel to a proxy on the other end. Figure 41.1 illustrates how the proxies fit in between the real objects involved.

Figure 41.1. Remoting at a glance.

Data transfer between application domains is at the core of remoting's functionality. The management of remote object instances and the method of transferring data between application domains both warrant detailed discussion.

Introduction to the MarshalByRefObject Class

In Chapter 1, there is a discussion about the difference between value types and reference types. A value type is one in which the data is stored directly on the stack, whereas a reference type only maintains a pointer on the stack and the real data is contained within the managed heap.

A similar difference exists for objects transmitted via remoting. When you pass an object as a parameter to a remote method, that object can either be passed as a serialized copy, or it can be passed as a reference to the original. If your code passes an object by reference over remoting, the code on the other end of the channel can make changes to the object. Those changes will take place on the original object.

If you pass a standard object to a remoting host, that object will be serialized and a new copy of the object will be created by deserializing the object data. To pass an object reference without creating additional copies, you can use an object that is derived from the MarshalByRefObject class. When you use objects that derive from MarshalByRefObject, a proxy is created, like the one shown in Figure 41.1, that essentially forwards calls to the original object. This feature gives remoting quite a bit of power and flexibility.

You don't have to do anything special to make your class a MarshalByRefObject other than inheriting from it, as shown in the following code:

public class MyRemotableObject: MarshalByRefObject {    // class implementation } 

To ensure that your object is copied rather than used as a reference, simply ensure that it is serializable:

[Serializable()] public class MyObjectToCopy {     // class implementation } 

Single Call Versus Singleton Objects

When using remoting, the client code requests an instance of a remote object using the remoting infrastructure. The instance that the client is using is not the same as the instance on the remote host.

When using remote objects, sometimes you want the object to be created long enough to perform a single task and then be disposed, and sometimes you want objects to remain, state intact, between method calls from a client.

The first type of object is called a single call object. Single call objects are instantiated at the request of a client and belong to only that client. After the client is done with the object's single call, the object is disposed of. This means that with a single remoting host, each client gets its own unique, temporary copy of that object, as shown in Figure 41.2.

Figure 41.2. Single call objects in a remoting infrastructure.

Conversely, a singleton object is an object that is shared among all clients. After the object has been created, possibly by a client, it will then be shared by all clients by being retrieved as a reference. In this situation, when client A makes a change to data on the remote object, client B will see that change, as illustrated in Figure 41.3.

Figure 41.3. Singleton objects in a remoting infrastructure.

If you want to obtain a remote object instance that belongs solely to the client requesting it, a single call object is the right choice. However, if you want multiple clients to have access to the same remote object and its shared state, use a singleton object.