Solution Architecture

.NET Remoting is a technique that allows our code to make function calls to .NET applications in other processes and on other machines. The key to understanding remoting is to understand marshaling objects by reference instead of by value. In the Web service examples in Chapter 4 and Chapter 5, a client made a call on a Web service and received an object in return. The Web service infrastructure on the server took the object returned from the Web service method, serialized it (essentially dehydrated it; see Chapter 7) into XML, and transmitted the XML across the wire to the client. The client then deserialized the XML (reconstituted the original object; think of it as adding water to powdered soup) on the client’s machine. Subsequent calls to the returned object, for example, to read elements out of the data set, took place solely on the client. This process, called marshaling by value because the complete value of all the object’s data is copied from the server to the client, is shown in Figure 10-1.

.NET Remoting allows us to make function calls to other .NET processes and machines.

Figure 10-1: Marshaling by value.

.NET Remoting is different. When a client creates a remoting object, the object is not transferred to the client’s machine as it was in the previous case. Instead, the object stays in its original location on the server. The client gets a reference to the object, as shown in Figure 10-2. The reference runs through a proxy on the client side, through a communication channel, to a stub on the server side. The proxy appears to the client exactly as if it were a local object. But when the client makes calls on it, the proxy takes the function call parameters and squirts them through the channel to the server. The server end of the channel passes the call to a server-side stub, which makes the call into the object on the server. The results are marshaled back to the client in a similar manner.

NET Remoting performs marshaling by reference.

Figure 10-2: Marshaling by reference.

If you think this looks like COM, you’re right on a certain conceptual level. The proxy-channel-stub architecture isn’t new. (It wasn’t invented for COM, either. The first use of it I ever saw was in 1991 for OSF DCE RPC [abbreviated ODR, a saturated CCT]; see Chapter 4.) However, remoting is implemented completely in the .NET Framework, without any use of COM. And there are important differences as well—for example, the remoting object server must be running at the time of the request; it can’t be launched on demand as a COM server could. The first example in this chapter demonstrates the simplest instance of remoting.

Although .NET Remoting resembles COM somewhat, the resemblance is primarily coincidental.

.NET Remoting is highly flexible. You can control remoting with a configuration file, so you don’t have to hard-code all your design choices into your applications. The second example in this chapter demonstrates this. Remoting allows several choices as to when objects are created and how they handle their state between calls. The third example in this chapter demonstrates these choices. Managing the lifetime of remoting objects is somewhat tricky, but it’s always under your control, as the fourth example will show. You have several options for the host program that provides your remoting objects to the world, as the fifth example shows. Finally I discuss security and performance considerations in remoting.

.NET Remoting is highly flexible.

As are most of the topics covered in this book, remoting is a deep subject and this chapter only scratches the surface. If you want to probe further, I’d suggest the books Advanced .NET Remoting by Ingo Rammer (APress, 2002, available in both C# and Microsoft Visual Basic versions), and Microsoft .NET Remoting by Scott Maclean, James Naftel, and Kim Williams (Microsoft Press, 2003).

Tips from the Trenches

If remoting is so great, why haven’t you heard much about it until now? It appears to be a marketing decision, with Microsoft wanting to spend their limited amount of limelight on Web services. They felt that a solution to the new problem of heterogeneous communication would gain more market share than a new (albeit better) solution to the old problem of communication in a homogeneous environment.