Chapter 10: .NET Remoting

Marks! I ha’ marks o’ more than burns—-deep in my soul an’ black,
An’ times like this, when things go smooth, my wickudness comes back.
The sins o’ four and forty years, all up an’ down the seas,
Clack an’ repeat like valves half-fed.... Forgie’s our trespasses.

—Rudyard Kipling, writing on failing to learn from mistakes made in
previous versions. “McAndrew’s Hymn,” 1894.

Problem Background

The .NET Framework XML Web service architecture that I discussed in Chapter 4 was designed to solve the problem of communicating in a heterogeneous environment, which it accomplished through the time-honored method of falling back on the lowest common denominator. People writing or speaking about .NET make a lot of noise about it, and it’s wonderful for the ever-increasing class of applications that want, say, a non-Microsoft palmtop to call functions on a Microsoft server. However, to get its wide reach, the designers of .NET had to make tradeoffs that sacrificed performance and ease of programming in a homogeneous environment. For example, Web service objects can’t retain object state from one call to another unless you go out of your way to write code that makes them do so.

XML Web services were designed for wide reach, not good performance.

Handling communication between tightly coupled, homogeneous systems doesn’t get as much promotion as XML Web Services, probably because it’s been around longer and is seen as old hat and unsexy. Making function calls across process or machine boundaries among Microsoft systems is the problem that COM, and later DCOM and COM+, were originally designed to solve. We’ve left COM behind and moved to .NET for reasons that I discussed in Chapter 2. But we still need to solve this problem. For example, a cluster of servers that use XML Web services to communicate with their heterogeneous clients would like a more efficient way to talk to each other. For another example, we’d really like an efficient way for two separate processes on the same machine to communicate with each other. Web services can’t apply intimate knowledge of the Microsoft environment because they’re designed specifically to handle the case where one of the parties doesn’t have access to it. In the case where both do, it’s silly to pay the cost of working under constraints that don’t apply.

We still need to make function calls across process or machine boundaries in homogeneous, Microsoft-only distributed applications.

We need a way of efficient communication across process and machine boundaries in a Microsoft-only environment, taking advantage of the sophistication of the operating system, instead of having to settle for the lowest common denominator. We want it to be easy to write clients and their servers using the same .NET techniques that we’ve already learned. We want a choice of how our objects are created, of how they maintain their state during use, and of how their lifetime is managed. We want a choice of the communication protocol to use between client and server. And we’d like the internals of this architecture to be public and flexible so that we can modify and extend it where we need to.

We need a way of efficient communication across process and machine boundaries in a Microsoft- only environment.