The Role of .NET Remoting in a Distributed System

Modern operating systems such as Microsoft Windows isolate applications and the memory they use from one another. This protection ensures that a flawed or maliciously designed program can't affect another running application. The cost of this protection is that interprocess communication is possible only through controlled channels, such as sockets or named pipes, and is slower and more complex.

.NET Remoting is a mechanism through which a .NET client application can interact with a .NET component that's part of another application domain (and often hosted on a different computer). Think of .NET Remoting as the key to full-blown distributed architecture. It enables you to split up entire portions of an application into separate physical locations. Other .NET technologies just aren't as ambitious. In Chapter 5, for example, you'll learn about XML Web services, which enable you to execute snippets of code on the Web server. By no stretch of the imagination can you consider an XML Web service a full-blown object. It can't raise events, provide a server-side user interface, or live longer than a single method call.

.NET Remoting imposes very few rules on application architecture. Unlike with XML Web services, you can even use .NET Remoting to design peer-to-peer applications in which individual clients communicate back and forth and there is no central server. In a typical enterprise application, however, you'll host utility components (the service providers) on separate computers and make these components available to clients through .NET Remoting. This approach allows database connections and other resources to be pooled among large numbers of clients and offloads some of the work from the client.

The actual remote component can be hosted in one of several different types of applications. It can be hosted in a Windows Forms or console application (which can be useful if you want to display running status information or an interface for configuring the component), in a dedicated Windows service (which allows automatic startup and provides good transparency), or even through Microsoft Internet Information Services (IIS) and the ASP.NET runtime (somewhat like an XML Web service). We'll consider all these possibilities throughout the book; we'll focus on the first, simplest approach in this chapter.

Note

We'll return to the difference between .NET Remoting and XML Web services in the next chapter. However, it's not too early to start considering one of the most important distinctions: .NET Remoting can use stateful objects, but XML Web services are always stateless helper classes. In other words, an XML Web service is created at the start of each client request and is destroyed after the response has been returned. XML Web services can serialize information to some type of storage between method calls, creating the illusion that they retain state, but they are never alive and active between client requests. Objects exposed through .NET Remoting have a much higher degree of independence. Even after the client has received a response, the remote object can continue executing.