Columns

DCOM is Dead — Long Live .NET Remoting
David Chappell - November 20 , 2001

Allowing communication across a network is the sine qua non of distributed computing. In Windows DNA, a COM object can be accessed from another process or another machine using Distributed COM (DCOM). In the .NET Framework, a managed object can be accessed by a remote client using .NET Remoting. Although the word "remoting" may seem to imply communication between different machines, it's used a bit more broadly in the .NET Framework. Here, remoting refers to any communication between objects in different application domains, a process-like abstraction managed by the Common Language Runtime (CLR). More commonly called just app domains, they may be on the same machine or on machines connected by a network. Wherever they exist, communication between code in different app domains can make use of .NET Remoting.

When a client calls a method in an object in another app domain, that call is first handled by a proxy object running in the client's app domain. The proxy acts as a stand-in for the remote object in the client's app domain, allowing the client to behave as if that object were running locally. The proxy eventually hands a call's information to a channel object. The channel object is responsible for using some appropriate mechanism to convey the client's request to the remote app domain. Once the request arrives in that app domain, a channel object running there locates the object for which this call is destined, perhaps creating it if the object isn't already running. The call is then passed to the object, which executes it and passes any results back through the same path.

Two standard channels are provided, called the TCP channel and the HTTP channel. The TCP channel by default serializes and deserializes a call's parameters into an efficient binary format and then sends that information directly in TCP packets. The second option, the HTTP channel, by default serializes a call's parameters into a Simple Object Access Protocol (SOAP) message, representing those parameters in XML. This information is then sent embedded in HTTP.

Deciding which channel to use depends on your goals. If the communication will remain entirely within an organization's intranet—if no firewalls will be traversed—use the fast and simple TCP channel. If the communication must go through firewalls, however, as do most packets sent on the Internet, use the HTTP channel. Although it's a bit less efficient, riding on HTTP allows passing through port 80, the only port that virtually all firewalls leave open. Also, if the goal is to provide a standard Web service whose clients might not be based on the .NET Framework, the HTTP channel is the only .NET Remoting option you can use (although using the support for Web services provided by ASP.NET is probably a better idea in this case).

At a high level, anyway, .NET Remoting isn't very complicated. Yet until the arrival of .NET, Microsoft's primary protocol for intelligent communication between systems was DCOM. DCOM has certainly had some success, so why replace it? How is .NET Remoting better?

First of all, DCOM assumes that both sides of the communication are implemented as COM objects. Because COM is no longer the fundamental technology on which applications are built in the .NET world, it's not surprising that DCOM has also been relegated to legacy status. Just as important, though, the world has changed since DCOM was designed. Intranets, DCOM's forte, are still important, but so is access across the Internet, an area where DCOM has severe problems.

At a more technical level, there are many differences between DCOM and .NET Remoting. For example, DCOM includes a way to launch a new server process automatically on the first request from a client, whereas .NET Remoting allows this only with IIS-based applications using the HTTP channel. DCOM relies on frequent pinging of clients to manage the lifetime of remote objects, an artifact of COM's reference counting mechanism. .NET Remoting uses a simpler and more efficient leasing scheme. Also, for people who delight in building their own infrastructure, .NET Remoting allows adding custom channels, custom serialization mechanisms, and other low-level modifications. DCOM is much more of a closed system, offering little in the way of extensibility.

Finally, one of the biggest differences in the two technologies is the approach each takes to distributed security. DCOM is a very secure technology. In fact, its strong emphasis on security is perhaps the most challenging thing about using it because configuring DCOM correctly is not simple. If DCOM is at one end of the security scale, however, .NET Remoting is at the other. The HTTP channel allows access to IIS-based security, but the TCP channel has no built-in security services whatsoever. Given that this channel is designed for use on intranets, where the Kerberos-based services of a Windows domain are readily available, this omission is surprising. (In fact, I'd be surprised if Kerberos support isn't added to the TCP channel in the next release of the .NET Framework.)

DCOM was a reasonably effective (although often complex to use) technology for the problem it addressed. But the problems we're interested in change, and so the technologies we use to address them must change, too. DCOM had its day, but for the most part, that day is over. Going forward, distributed computing in the Microsoft world will depend on .NET Remoting.