Performance Consulting: A Practical Guide for HR and Learning Professionals

.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 a part of a remote application. If the assembly is part of the remote application then 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 sub-process 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. For applications to communicate with each other, cross-process communication is needed. With .NET, the application domain is the new safety boundary inside a process, because the MSIL code is type-safe and verifiable . As we discussed in Chapter 8, 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 in order to access objects in a different application domain.

Before we look into the internal functionality of .NET Remoting, let's have a look at the major elements of the 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 differentiate 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. With the .NET Framework, we get two channel types that communicate via TCP or HTTP. We can also create a custom channel that communicates using a different protocol.

• Messages are sent into the channel. Messages 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. With the .NET Framework, we have 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 possibility to create a custom formatter.

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

• The client calls methods on a proxy instead of the remote object. There are two types of proxies: the transparent proxy and the real proxy . To 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 just a sink, is an interceptor object. We have such interceptors on both the client and on 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 it 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.

To get a better insight into the functionality, let's look at a conceptual picture of how these pieces fit together:

When the client calls methods on a remote object, it actually calls methods 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. The real proxy is pluggable; we can replace it with a custom implementation. 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. How the messages are sent over the wire depends on the formatter. As previously stated, we have SOAP and binary formatters. 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; we just have to implement the code to do what's necessary to transfer the data to the other side:

Let's continue with the server side.

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

.NET Remoting is extremely customizable: we can replace the real proxy, add sink objects, or replace the formatter and channel. Of course, we can also use all what's already provided.

If you're wondering about the overhead when going through these layers , there's not much overhead if nothing is happening in there. If you add your own functionality, the overhead will depend on that.