DCOM Objects

The only major vendor to not adopt CORBA as its distributed object model is Microsoft. The Microsoft answer to CORBA is its Distributed Component Object Model, or DCOM. While DCOM has many similarities to CORBA, it has some very basic differences. This section does not attempt to provide a complete description of DCOM. Rather, it compares and contrasts DCOM and CORBA using CORBA terminology.

There has been much inter-mixing of the terms COM, DCOM, and ActiveX in computer literature. Here is a quick summary of the differences between these terms. The technological infrastructure, or foundation, for DCOM is Microsoft's Component Object Model (COM). DCOM is COM with distribution support. ActiveX objects are simply self registering COM components . For purposes of this section, we will focus on the term DCOM.

Like CORBA, DCOM separates the object interface from its implementation. All DCOM interfaces are declared using an Interface Definition Language. Unfortunately, the Microsoft IDL is not compatible with CORBA IDL. Another major difference between the two is that DCOM does not support IDL-specified multiple inheritance. DCOM does, however, support multiple interfaces. DCOM reuse can thus be achieved by encapsulating the interfaces of inner components and representing them to a client.

Hard- core object-oriented programmers will claim that DCOM's lack of multiple inheritance disqualifies it as a true object-oriented model. Furthermore, DCOM interfaces do not have any state and cannot be instantiated to create a unique object with a unique object reference. A DCOM interface is thus really just a group of related functions. While DCOM clients are given a pointer to access the functions in an interface, this pointer is not related to state information. Therefore a DCOM client cannot reconnect to exactly the same object instance with the same state at a later time. It can only reconnect to an interface pointer of the same class. This means that DCOM is not well suited to implementing applications requiring stateful connections. Stateful connections are often desirable when communicating over noisy or error-prone channels such as the Internet.

To compensate for its lack of persistent objects, DCOM implements "Monikers." A DCOM moniker allows a transient, stateless, DCOM object to be associated with a persistent alias name for another object. Monikers can thus provide aliases for such objects as distributed filenames, database queries, or a paragraph in a document. A moniker is really a patch for DCOM's lack of support for object identifiers. Like many of DCOM's drawbacks, the need for monikers is due to DCOM's origins in COM, which was not originally a distributed object model.

DCOM implements local/remote transparency of server locations through its Service Control Manager. Unlike CORBA, in which server location is totally transparent, DCOM defines three different types of servers: in-process, local, or remote. An in-process server executes in the same address space as the client. In Microsoft Windows this is implemented as a dynamic link library (DLL). Local servers execute in a separate address space from the client but are local to the same machine. Microsoft Windows implements local servers in their own executable (.exe) file. DCOM uses a Lightweight RPC (LRPC) mechanism to communicate between clients and local servers. Finally, remote servers execute on a remote machine. DCOM clients use a remote procedure call-like mechanism to communicate between clients and remote servers.

On top of its other limitations, DCOM is primarily a Microsoft-only solution. At least one, third party non-Windows implementation of DCOM has been completed, but one would be hard pressed to find any widespread DCOM implementation outside of a Microsoft platform. With all its limitations, why would one consider using DCOM? Basically, because Microsoft uses DCOM for everything it is doing today with objects. DCOM is included with Windows NT 4.0 and Windows 98 and can be installed on Windows 95. DCOM is the foundation for Microsoft's Internet component strategy, often referred to as ActiveX. Microsoft has also based its Microsoft Transaction Server (MTS), also known as Viper, on DCOM as the component coordinator for transactional services. Microsoft's Visual J++ development tool for Java includes Java language bindings for DCOM and tightly integrates the two. If you are developing for a pure Microsoft client environment, are not concerned with high-end server scalability beyond that offered by Windows NT, and are not concerned with Internet standards and cross-platform interoperability, then DCOM is indeed a very attractive solution.