.NET Remoting Architecture | The .NET and COM Interoperability Handbook (Integrated .Net)


Team-Fly

	.NET and COM Interoperability Handbook, The By Alan Gordon
	Table of Contents

	Chapter Eleven. .NET Remoting

.NET Remoting Architecture

The overall process of making a method call across process (or app domain) boundaries is, at a conceptual level, no different in .NET remoting than it is in DCOM or CORBA or even the Java programming language RMI for that matter. The key to making cross-process method calls is marshaling. The idea is that you have a piece of software called a proxy that runs in the client process and a piece of software, which is usually called a stub, that runs in the server process as shown in Figure 11-1.

Figure 11-1. Making a distributed method call.

graphics/11fig01.gif

When you instantiate a remote object, the operating system runtime will return a transparent proxy to the client. This proxy looks exactly like the object that the client requested from the server. When the client calls methods on the proxy, the proxy will take the method call and turn it into a stream of bytes. Encoded in this stream of bytes is an identifier for the object that the client is making the method call on, the name of the method that the client wishes to call, and the parameters it is passing to the method. The networking infrastructure provided by the operating system will then send this stream across the network (using some network protocol) to a stub or dispatcher that runs on the server. This stub will interpret the message, dispatch the call to the requested method, and send the return value and output parameters back to the client.

.NET remoting is simply one implementation of this basic concept. Figure 11-2 shows a high level view of the .NET remoting architecture. The figure shows how method calls are made from a client to a marshal by reference object in a different app domain using .NET remoting.

Figure 11-2. The .NET remoting architecture.

graphics/11fig02.gif

Note

Marshal by value objects behave differently. I discuss those later in this chapter.

When you instantiate a marshal by reference object, the CLR will return a proxy to the client. Although at a high level you can think of the proxy as a single object, with .NET remoting, it is actually composed of two objects: a transparent proxy, which is an instance of an undocumented class called System.Runtime.Remoting.Proxies.__TransparentProxy , and a real proxy, which is an instance of a documented class called System.Runtime.Remoting.Proxies.RealProxy . The client talks directly to the transparent proxy. The transparent proxy looks and behaves exactly like the remote object. It will have the same methods, properties, interfaces, and events. The transparent proxy contains a member variable with the name _rp, which contains the real proxy. The real proxy does most of the heavy lifting in making the cross-process app domain method call. When you make a call on the transparent proxy, it takes the method call and turns it into a call on the real proxy.

The proxy uses a formatter to turn the method call into a network transportable stream. The .NET Framework ships with two formatters: A SOAP formatter, which serializes the method call in SOAP 1.1 format, and a binary formatter, which serializes the method call in a compact binary format. You can also create your own formatters by implementing the System.Run-time.Remoting.Messaging.IRemotingFormatter.IRemotingFormatter and System.Runtime.Serialization.IFormatter interfaces. The proxy then sends the serialized method call to the server object using a channel. Channels are objects that transport messages between applications across remoting boundaries. The .NET Framework comes with two channels: an HTTP channel, which uses HTTP (see the System.Runtime.Remoting.Channels.Http. HttpChannel class), and a TCP channel, which uses a lower-level TCP-based protocol (see the System.Runtime.Remoting.Channels.Tcp.TcpChannel class). You can also create your own channels by implementing the IChannel, IChannelReceiver, and IChannelSender interfaces from the System.Runtime.Remoting.Channels namespace. A channel actually has two halves : a sender channel, which runs on the client, and a receiver, which runs on the server (hence the two interfaces, IChannelSender and IChannelReceiver). You can create separate classes to do the sending and receiving, but the HTTP and TCP channels provided by the .NET Framework implement both interfaces. By default, the HTTP channel uses the SOAP formatter, and the TCP channel users the binary for matter. However, you can change this and use the HTTP channel with the binary formatter or the TCP channel with the SOAP formatter. The message is received by the server side of the channel, which reverses the process and passes the message to the formatter on the server, which decodes the method call and then sends the method call to a dispatcher, which calls the actual object. Any return values or output parameters are sent back to the client in the same manner.


Team-Fly

Top