Remoting Architecture

Now that this chapter has established the two different logical styles of remoting that are available from the .NET Framework, it will move to a discussion of how remoting allows for such distinctly different modes of operation. Figure 13.1 shows a broad overview of the remoting architecture.

Starting from the left side of the figure, the client is presented with a transparent proxy. The client cannot easily tell that it is working with a proxy rather than a real object because all of the methods and properties are exposed through the transparent proxy in the same manner as a real object. Because it is required that an assembly that represents the real object be present when building the client, it is possible that you might not really be talking to a remoted object. To remedy this, you can make a call to IsTransparentProxy to make sure that you are indeed connected to a remote object. This call would take on the following form:

if (true == RemotingServices.IsTransparentProxy(timeService))
{
    Debug.WriteLine("TimeObject activated on server");
    . . .
}

The transparent proxy calls a real proxy, which in turn turns the calling stack frame of your method call with its arguments into an IMessage. IMessage is then passed through a chain of channel sinks. The proxy contains a reference to the first IMessageSink object in the chain so that it can start the call cycle. The first channel sink must implement IMessageSink, but typically, the first channel sink implements either IClientFormatterSink or IServerFormatterSink and is known as a formatter sink because it turns a message into a series of bytes.

Currently, the .NET Framework implements two formatter sinks as BinaryClientFormatterSink and SoapClientFormatterSink. The formatter sink turns a message into a byte stream. The binary sink provides a high-speed method to transfer all .NET objects from one AppDomain to another. The SOAP sink turns a message into a stream of bytes that is SOAP 1.1 compliant.

Message sinks and channel sinks provide a mechanism whereby remoting can be extended. Message sinks can forward a message, log a message, transform a message, or generate a new message. By inserting a class that implements IMessageSink, IClientChannelSink, or IServerChannelSink, you can modify the message (which is the method call and its arguments) as it flows from one sink to another.

Each sink in the chain receives the message object, performs a specific operation, and calls the next sink in the chain. Each sink provides some kind of service such as security and synchronization.

Notice that two methods must be implemented for every IMessageSink object: AsyncProcessMessage and SyncProcessMessage. When an asynchronous call is made on a remoted object, each sink provides a reply sink to be called by the next sink when the reply is on its way back.

Figure 13.1 shows a single block that is labeled “channel.” Logically, this is probably true, but there is much more to a channel than that. Look at Figure 13.2 for a more accurate picture of what a channel is composed of.

Logically, a channel's main task is to transport a byte stream from the client to the server or vice versa if it is carrying a reply message. Figure 13.2 shows that as only one component of the channel—the transport sink. A channel is composed of a chain of channel sinks, each one implementing at least an IClientChannelSink or an IServerChannelSink interface.

The .NET Framework includes two channels as part of the shipped product: an HTTP and a TCP channel. As you can guess, the HTTP channel implements the HTTP protocol and is good to use when it is necessary to cross firewalls and HTTP proxy servers. The TCP channel implements a high-speed socket that is good for a more direct peer-to-peer communication. Of course, it is possible to create your own channel. A TimeLog sample illustrates how to hook into the list of channel sinks to provide a log of the traffic that occurs within the channel. In addition, a TimeFilter sample shows how to implement some rudimentary security checks in a sink by rejecting calls from certain IP addresses.

On the server side, the remaining code to transfer a message to the server primarily does what the client side did in reverse. It reads in the message from the transport sink, runs the message through the server side chain of channel sinks, converts the serialized data to a message, constructs a call stack from the message, and invokes the appropriate method on the object.