Chapter 4. .NET Remoting: A More Durable DCOM

Microsoft .NET Remoting is, at its simplest, a new way for components to communicate, even as they run in different processes or on different computers. To a degree, .NET Remoting can be considered a replacement for DCOM, the technology that allows COM components to talk across a network. Like DCOM, .NET Remoting is an ideal solution for use over internal networks and enables the application programmer to follow essentially the same programming model used to interact with local objects. Unlike DCOM, .NET Remoting is simple to configure and easy to scale. It also uses a "pluggable" architecture that makes it far more flexible than any previous standard. For that reason, you can use .NET Remoting in situations where DCOM rarely works, such as across a firewall or between computers on different platforms. In such cases, your remote components don't require any coding changes you just adjust your .NET Remoting configuration files to specify a different message format or protocol for communication.

For developers who have toiled with DCOM, .NET Remoting will come as a welcome relief. However, some of the same problems that affect DCOM come into play with .NET Remoting. Namely, communicating with a component that is hosted in another process or on another computer is inherently slower than communicating with a locally instantiated component. .NET Remoting is therefore not always the best solution. Used wisely, it can be a fundamental building block for a scalable distributed system. Used recklessly and Microsoft architects comment frequently that they see .NET Remoting being used in places where it isn't required it can introduce new performance bottlenecks.

Even for experienced .NET developers, .NET Remoting is often a foreign subject. Because of its complexity, it hasn't received the same degree of attention as other innovations, such as .NET XML Web services. This chapter introduces .NET Remoting from the ground up, considers where it should and shouldn't be used, and highlights some of the common headaches that developers experience when starting out with it. It paves the way for later chapters and case studies in which we'll explore how remote components can interact with XML Web services in advanced distributed systems.