“To be or not to be”, that’s the question many enterprise customers ask themselves recently. Having decided to use Microsoft’s solution for distributed computing, large (“whale-like” in Microsoft terms) customers now have the additional burden to select the exact technology they want to develop their components on. Should one go with the tried and tested Distributed Component Object Model (DCOM) or use DCOM’s successor, state-of-the-art .NET Remoting? This article may serve as a starting point in answering such questions.

This article assumes that the customer is deciding on what to use for the transport between the clients and the server in her high performance, real-time, client-server communication. I take it for granted that she requires at least the following in her application:

• Client to Server Method Invocation (up to a certain number of method invocations per time unit)
• Server to Client Event Notification (up to a certain number of events per time unit with near real-time notification)
• Security, Scalability, and Performance
• Support for Conventional Platforms (Windows 2000, Windows XP, and/or Windows Server 2003)
• Easy Deployment (simple installation and configuration)

Distributed Component Object Model (DCOM)
DCOM is a protocol that enables software components to talk over a network in a reliable, secure, and efficient manner. It provides the basic architectural support necessary to design and deploy robust and sophisticated software systems. (Read Inside Distributed COM by Guy & Henry Eddon ISBN: 1-57231-849-X to get the complete picture.)

Over the years, DCOM has matured as a solid distributed computing framework. The feature set is complete, stable, and tested. How does DCOM fare in each of the 5 requirements above? “Fairly well,” I’d say. The points 1, 2, and 4 above are obvious and need no further explanation. DCOM has more than acceptable results in scalability and performance tests. It also has a built-in security mechanism that leverages Windows NT security. With configurable deployment options (install scripts for registry settings, DCOMCNFG application, or DCOMPERM sample in MSDN to name a few) for mass rollout of servers and clients takes the nightmares of application deployment away from you.

The predictability of the framework is unparallel that all you need to avoid nasty surprises is to follow the “rules of DCOM”. The vast pool of resources—both tools and programmers—make DCOM an obvious choice for rapid software development (RSD). Every aspect of the technology and framework is “live” in many thousands of user applications, in websites that have thousands and thousands of hits per day, and in mission-critical applications deployed by various military establishments and space research organizations. There are a number of public forums that discuss DCOM-related topics including Microsoft portal for COM technologies and free support for DCOM is available via Microsoft’s official newsgroup for the technology at http://msdn.microsoft.com/newsgroups/ (look for win32.programmer.ole newsgroup in COM under Component Development). If you hit a (rare) bug with DCOM, chances are that Microsoft already has a fix for the issue, or will work with you to fix it. Best of all, contrary to some believe, DCOM is not dying anytime soon; and Microsoft is certainly not planning to stop supporting DCOM in the foreseeable future.

As you can see, saying good-bye to DCOM can prove to be a painful experience if you have been an ardent believer and follower of the technology.

When you have all these, why in the world do you want to consider another technology for distributed computing? The only possible reason I can think of is that your company believes in cutting edge technology and all the new development is done only using the .NET Framework (“managed world”) in mind. Even though interoperability techniques available for COM object to seamlessly talk with .NET objects, you may want to avoid such mix for reasons such as performance and maintainability. (See Microsoft .NET/COM Migration and Interoperability and Adam Nathan’s brilliant book .NET and COM: The Complete Interoperability Guide ISBN: 0-67232-170-X).

.NET Remoting
.NET Remoting (“Remoting” in short) is designed to be the “managed” equivalent of DCOM. The attempt to relate Remoting to DCOM sent a wrong and undesired signal to developing community that Remoting is replacing DCOM altogether. Remoting is the Microsoft preferred distributed application development platform for .NET Framework.
Remoting is built on managed code. As with DCOM, points 1, 2, and 4 above are “standard features” in Remoting as well. A big question mark on security arises when you talk about Remoting. Remoting does not provide built-in security (as yet). Security modules have to be coded in by the developers. (See samples in MSDN: Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication and .NET Remoting Security Solution). However, this is a moot point when the next major release of Web Services comes in (Indigo) as Indigo has built-in security just like DCOM, and the migration to Indigo will be “trivial”.

Unlike DCOM, the learning curve for Remoting is not steep. It doesn’t require a lot of manual serialization (or “marshalling” as we fondly call it in the DCOM world) or stack building. Within the short period of its existence, .NET Remoting gained the reputation as a common man’s tool to creating and extending distributed applications while DCOM still is an expert’s technology. Remoting being a “pluggable architecture” can quickly build (and therefore swap, if needed) subsystems of a huge application. Remoting interoperability capabilities go beyond the expected Microsoft-based solutions. It can interoperate with Java RMI, CORBA because Remoting is based on open standards such as XML and SOAP.

Unlike COM, Remoting uses a common type system. This means that a string in C#, C++, or VB will be treated the same way by the Remoting architecture. In the COM world, C++ uses code type descriptions while VB uses binary type descriptions (IDL versus Type-library). Another definite cause of worry in the COM world is its lifetime management of objects. Reference counting woes continue to haunt even the best of DCOM experts. Remoting has a lease-based lifetime management with built-in garbage collector that makes the life of an average developer easier.

Web Services, MSMQ & System.Messaging
Until Indigo comes out Web Services remain a subset of Remoting. Since my attempt is to compare DCOM and .NET Remoting, I am not going to be elaborate more on these technologies. Even though these can be used in lightweight solutions (and in certain cases there are distinct advantages in using a light-weight solution), they come with a number of disadvantages. Web Services until now does not support events. Web Services can only be hosted in IIS (at least for now). MSMQ, as its name indicates, may not be suitable for real-time applications. The migration path from these technologies to the next generation Indigo remains questionable.

Conclusion
With the pace with which Microsoft and other software vendors are rapidly embracing managed technologies and frameworks for distributed computing, .NET Remoting seems to be the de-facto standard for distributed application development. However, the time and energy invested in DCOM is not going be in vain anytime soon. Microsoft is not undermining DCOM as a proven technology for distributed computing; it is just pointing out that your options as a software developer are not limited. As someone who has witnessed issues regarding hard-core software development with DCOM, and someone who is witnessing the range of problems that come up with software in the managed world, I can’t pick one over the other as my favorite. However, the limitless possibilities that the managed world offers never fail to fascinate me.

Read my published works:
Are You A Better Software Engineer?
Enterprise Computing with Microsoft’s .NET Framework
Bill Gates has Become Rich, But My Windows Crashed Again!
The Good Doctor Prescribes You a Tablet