Pro Visual C++ 2005 for C# Developers

.NET Remoting can be used for accessing objects in another application domain. .NET Remoting can always be used whether the two objects live inside a single process, in separate processes, or on separate systems.

Remote assemblies can be configured to work locally in the application domain or as part of a remote application. If the assembly is part of the remote application, the client receives a proxy to talk to instead of the real object. The proxy is a representative of the remote object in the client process, used by the client application to call methods. When the client calls a method in the proxy, the proxy sends a message into the channel that is passed on to the remote object.

.NET applications work within an application domain. An application domain can be seen as a subprocess within a process. Traditionally, processes were used as an isolation boundary. An application running in one process cannot access and destroy memory in another process. Cross-process communication is needed for applications to communicate with each other. With .NET, the application domain is the new safety boundary inside a process, because the MSIL code is type-safe and verifiable. As discussed in Chapter 15, different applications can run inside the same process but within different application domains. Objects inside the same application domain can interact directly; a proxy is needed to access objects in a different application domain.

The following list provides an overview of the key elements of this architecture:

• A remote object is an object that's running on the server. The client doesn't call methods on this object directly, but uses a proxy instead. With .NET it's easy to distinguish remote objects from local objects: every class that's derived from MarshalByRefObject never leaves its application domain. The client can call methods of the remote object via a proxy.

• A channel is used for communication between the client and the server. There are client and server parts of the channel. .NET Framework 2.0 offers channel types that communicate via TCP, HTTP, or IPC. You can also create a custom channel that communicates by using a different protocol.

• Messages are sent into the channel; they are created for communication between the client and the server. These messages hold the information about the remote object, the method name called, and all of the arguments.

• The formatter defines how messages are transferred into the channel. .NET 2.0 has SOAP and binary formatters. The SOAP formatter can be used to communicate with Web services that are not based on the .NET Framework. Binary formatters are much faster and can be used efficiently in an intranet environment. Of course, you also have the option to create a custom formatter.

• A formatter provider is used to associate a formatter with a channel. By creating a channel, you can specify the formatter provider to be used, and this in turn defines the formatter that is used to transfer the data into the channel.

• The client calls methods on a proxy instead of the remote object. Two types of proxies exist: the transparent proxy and the real proxy. For the client, the transparent proxy looks like the remote object. On the transparent proxy, the client can call the methods implemented by the remote objects. In turn, the transparent proxy calls the Invoke() method on the real proxy. The Invoke() method uses the message sink to pass the message to the channel.

• A message sink, or sink for short, is an interceptor object. Interceptors are used on both the client and the server. A sink is associated with the channel. The real proxy uses the message sink to pass the message into the channel, so the sink can do some interception before the message goes into the channel. Depending on where the sink is used, it is known as an envoy sink, a server context sink, an object context sink, and so on.

• The client can use an activator to create a remote object on the server or to get a proxy of a server-activated object.

• RemotingConfiguration is a utility class to configure remote servers and clients. This class can be used either to read configuration files or to configure remote objects dynamically.

• ChannelServices is a utility class to register channels and then to dispatch messages to them.

Figure 29-1 shows a conceptual picture of how these pieces fit together.

Figure 29-1

When the client calls methods on a remote object, it actually calls them on a transparent proxy instead. The transparent proxy looks like the real object — it implements the public methods of the real object. The transparent proxy knows about the public methods of the real object by using the reflection mechanism to read the metadata from the assembly.

In turn, the transparent proxy calls the real proxy. The real proxy is responsible for sending the message to the channel. This proxy is pluggable: it can be replaced with a custom implementation. Such a custom implementation can be used to write a log, or to use another way to find a channel, and so on. The default implementation of the real proxy locates the collection (or chain) of envoy sinks and passes the message to the first envoy sink. An envoy sink can intercept and change the message. Examples of such sinks are debugging sinks, security sinks, and synchronization sinks.

The last envoy sink sends the message into the channel. The formatter defines how the messages are sent over the wire. As previously stated, SOAP and binary formatters are available with .NET Framework 2.0. The formatter, however, is also pluggable. The channel is responsible for either connecting to a listening socket on the server or sending the formatted data. With a custom channel you can do something different; you just have to implement the code and to do what's necessary to transfer the data to the other side.

Let's continue with the server side as shown in Figure 29-2:

Figure 29-2

• The channel receives the formatted messages from the client and uses the formatter to unmarshal the SOAP or binary data into messages. Then the channel calls server-context sinks.

• The server-context sinks are a chain of sinks, where the last sink in the chain continues the call to the chain of object-context sinks.

• The last object-context sink then calls the method in the remote object.

Note that the object context sinks are confined to the object context, and the server context sinks are confined to the server context. A single server-context sink can be used to access a number of object sinks.

Going through these layers you may be wondering about the overhead, but there's not much overhead left if nothing is happening in there. If you add your own functionality, the overhead will depend on that.