Network Computingwww.networkcomputing.com

Microsoft has virtually complete control over its specification and implementations, as opposed to either Sun or the OMG. This tends to make DCOM a fairly coherent model in actual use, but also one that's limited to running in Microsoft environments. For instance, one of the most critical pieces of a distributed object model for enterprise use is robust transaction processing. In the DCOM world, that's accomplished via MTS, which runs on NT. Period. On the other hand, eliminating cross-platform interoperability avoids a host of problems.

Microsoft's control of the OS means that, at least on Windows NT servers, OS integration with DCOM is excellent. And in fact, in Windows 2000, COM+, the evolutionary successor to the current COM model, will both add some new services and subsume what had previously been discrete (though bundled) products, such as MTS. Furthermore, the DCOM infrastructure and MTS-COM+ services are distributed at no additional cost over the base OS, unlike products that use CORBA or EJB. David Chappell, an industry analyst and principal at Chappell and Associates, puts it bluntly: "The decision about which component model to use is based on which OS you want to build your server-side business logic. If a Microsoft OS is your choice across the board, use DCOM and MTS. If you don't want to use NT, you can't use MTS and DCOM."

Some NT shops won't find the choice so cut and dried; there will always be reasons to purchase or develop enterprise-level products that use CORBA and/or EJB, such as the need for extremely robust failover and dynamic load-balancing services across LANs and WANs--services that NT by itself either lacks or provides in only a limited capacity. The point about OS choice, however, is an excellent one: DCOM is based upon the assumption that all of a business' new development and business logic will be on NT, probably using MTS. And while Microsoft may be hoping for a future where that's true, most shops still support multiple OSes and platforms, not only for "legacy" data and applications, but for new applications as well, and will continue to do so for the foreseeable future. Microsoft has made a good effort to port COM to various other platforms--namely, Digital Equipment's OpenVMS, IBM Corp.'s MVS, and Unix for Hewlett-Packard Co., Digital, Silicon Graphics and Sun boxes. But this is primarily to ensure access to COM-wrappered "legacy" data sources; there are no plans to port the critical MTS piece to anything but NT, and COM+ is also intended to be a Windows-only offering.

The trade-offs to using DCOM and MTS are familiar ones: You gain a solid, consistent environment, mature development tools, and a distributed component model supported by a huge installed base. On the downside, you lock yourself into a relationship with a single vendor, Microsoft. Despite the company's recent support for "COM on Unix," you can rest assured that support for Unix will always be minimal to induce companies to migrate to Windows-based servers. Microsoft representatives have repeatedly stated that they have no interest in making Unix a stronger platform.

The subject of development tools is laced with pros and cons. Microsoft has spent considerable effort integrating its tool offerings (Visual Studio 6, for example) to make easy use of the COM/DCOM model, and to make it a straightforward proposition to create COM objects in several languages (primarily C++, Java, COBOL and Visual Basic), rather than having to write or wrapper everything in Java with EJB. But that still assumes you're using Microsoft's development tools; you're unlikely to see a Visual Basic IDE from another vendor, for instance, so you definitely hitch your wagon firmly to Microsoft by using its object model. Another double-edged sword is the ease with which COM objects are created. When a developer merely checks a box to create an object or make it transactional, it's easy to lose sight of what's going on under the hood--and what effect that may have on network traffic--and create swiftly written but poorly designed, inefficient systems.

What does the future hold for DCOM? Like Sun and the OMG, Microsoft doesn't want to make radical changes to anything in its object model. Microsoft claims that COM objects built when the specification was released in 1993 will work today. The emphasis, according to Microsoft, will be on stability and performance. Going from COM to COM+ involves folding formerly separate products, such as MTS, into the base OS, and adding some new services, such as dynamic load-balancing, in-memory database, a publish-and-subscribe events service, and a queued-components service. Unless Microsoft changes its mind, however, COM+ will be a reality for the Windows 2000 OS only.