Distributed Component Object Model (DCOM)
Distributed Component Object Model (DCOM) is a proprietary Microsoft technology that allows Component Object Model (COM) software to communicate across a network. DCOM is enhanced with COM applications to facilitate RPC and a Distributed Computing Environment (DCE) dedicated to Windows application and platform support.
Traditional COM components can only perform interprocess communication across process boundaries on the same machine. DCOM uses the RPC mechanism to transparently send and receive information between COM components (i.e., clients and servers) on the same network. DCOM was first made available in 1995 with the initial release of Windows NT 4. DCOM serves the same purpose as IBM's DSOM protocol, which is the most popular implementation of CORBA. Unlike CORBA, which runs on many operating systems, DCOM is currently implemented only for Windows.
DCOM is a Microsoft protocol for distributed computing that is based on RPC. DCOM is the mechanism Microsoft suggests that developers use for all client-server computing on Microsoft platforms, and most applications that are listed as using Microsoft RPC are actually using DCOM. DCOM can use either TCP or UDP; under Windows NT 4, it defaults to using UDP, while most other DCOM implementations default to using TCP. If the default version of RPC does not work, servers will use the other. Although DCOM is based on RPC, it adds a number of features with important implications for firewalls. On the positive side, DCOM adds a security layer to RPC; applications can choose to have integrity protection, confidentiality protection, or both. On the negative side, DCOM transactions are more complicated to support through firewalls than straightforward RPC transactions. DCOM transactions include IP addresses, so DCOM cannot be straightforwardly used with firewall mechanisms that obscure the IP address of the protected machines (for instance, proxying or network address translation). DCOM servers also may use callbacks, where the server initiates connections to clients, so for some services, it may be insufficient to allow only client-to-server connections. Microsoft has produced various ways to run DCOM over HTTP. These methods allow you to pass DCOM through a firewall without the problems associated with opening all the ports used by Microsoft RPC. On the other hand, if you use these methods to provide incoming DCOM access, you are making all your DCOM servers available to the Internet. DCOM services are not written to be Internet access and should not be opened this way. You can control DCOM security configuration and the ports used by DCOM with the dcomcnfg application. The Endpoints tab in dcomcnfg will let you set the port range used for dynamically assigned ports, and if you edit the configuration for a particular DCOM service, the Endpoints tab will allow you to choose a static port for it. This is safer than editing the registry directly, but you should still be careful about the port number you choose; if port numbers conflict, services will not work correctly. Do not statically assign services to port numbers that are low in the port range (these will frequently be dynamically assigned) or to port numbers that are statically assigned to other services.
How DCOM Works
DCOM is a client/server protocol that provides distributed network services to COM, allowing DCOM-enabled software components to communicate over a network in a similar fashion to the method by which COM components communicate among themselves on a single machine. DCOM client objects make requests for services from DCOM server objects on different machines on the network using a standard set of interfaces.
The client object cannot call the server object directly. Instead, the operating system intercepts the DCOM request and uses interprocess communication mechanisms such as remote procedure calls (RPCs) to provide a transparent communication mechanism between the client and server objects. The COM run time provides the necessary object-oriented services to the client and server objects. The COM run time also uses the security provider and RPCs to create network frames that conform to the DCOM standard. In Microsoft Windows NT and Windows 2000, DCOM requests are sent using RPCs. Windows NT and Windows 2000 use security features such as permissions to enable software components to securely and reliably communicate over the network. DCOM was formerly known as “Network OLE.”
- Language Independence: DCOM technology is language neutral. COM and thus DCOM achieve this capability by being a binary specification. You could build or access components through DCOM by using, Java, C++, MS Visual Basic, Delphi, PowerBuilder, etc. On top of that, any number of different tools that use these languages would be capable of interacting with DCOM. One of the biggest benefits of language independence is that it allows a developer to choose the language and tool that he/she is most familiar with.
- Protocol Independence: When writing DCOM applications developers are free to build their applications without worrying about the underlying protocol used on their network. DCOM can use many transport protocols. An application is free to use TCP/IP, UDP, IPX/SPX, or NetBIOS as its underlying network protocol. This provides a big benefit in cases where a large network might be using a number of different protocols. A DCOM component would require no recompile or rebuild of an
- Referrals: A powerful feature of the DCOM/COM programming model is its capability in passing object references from one component to another component (where that component can be on another machine). COM can marshal an object reference across the thread, process, and machine boundaries. Marshaling of object references is handled transparently by the COM run-time environment.
- Re-usability: Re-using existing code has long been a goal of any application environment. DCOM provides the ability to reuse existing COM components within a distributed environment seamlessly. Through the use of location transparency and surrogate capabilities COM components can become DCOM components without any change to the client or component code.
- Location Transparency: DCOM hides the location of a component. No matter where a component resides a client connects and calls components identically. This is fundamental to the DCOM protocol and allows for ease of re-use of existing components. By changing the configuration of a COM component within the registry and registering the component on the remote machine it now becomes a DCOM component. On the client machine, you will need to add the following values to the registry. These changes provide the location of the new DCOM component. Depending upon the type of component either EXE or DLL different registry settings are needed on the remote machine.
- Surrogates: Many of the COM components that exist today are located in in-process DLLs. A DLL cannot run by itself it needs a process to host its code. In order for an in-process DLL to become remote it needs the help of a surrogate process on the remote machine. With the introduction of Windows NT 4.0 service pack 2 Microsoft introduced a default surrogate process that could be used to host in-process DLLs. Custom surrogates can also be written based on a protocol for surrogates. Using surrogates can offer a tremendous amount of re-use of existing components while allowing these components to become remote. What was previously an in-process component running on the client can be moved to a server where there might be more processing power or closer access to data stores. A "thick" client could be easily modified to distribute some of its load to a server. Take the example of a component that required a number of enhancements or bug fixes. Being able to move the component to the server remove the need for software distribution. The enhanced component would simply be updated on the server.
- Garbage Collection: One of the best things about DCOM is the services it provides automatically. Automatic garbage collection is something that you usually think is only supported by a language like Java. DCOM garbage collection isn't related to a programming language but is related to the network. DCOM components aren't useful if they are no longer connected to their client. So DCOM provides automatic garbage collection when the connection between a client and a DCOM server is broken. DCOM provides automatic garbage collection for components by ensuring that a client is still live. DCOM uses a pinging protocol to detect if clients are live. A client machine periodically sends a ping message to the DCOM server. If the ping message is NOT received by the DCOM server 3 times in a row then the client is assumed to be dead. DCOM assumes that the connection is broken with the client. DCOM automatically decrements the reference count of the component used by the dead client.
DCOM Features 
DCOM gives developers two main benefits: location transparency, the ability to distribute client applications without ties to local objects, and packaging transparency, the ability to implement in-process objects in DLLs or local or remote objects in executables (EXEs) or as Win32 services. Despite being behind the scenes, DCOM provides some powerful features. Built on the Component Object Model (COM), an object-based programming model, DCOM adds several important extensions.
- Free-Threaded Objects: DCOM enhances COM's threading support to include completely multithreaded (free-threaded) objects. This support is in addition to DCOM's support for apartment-threaded and nonthreaded objects. Be aware that free-threaded objects support simultaneous calls by multiple clients, which is a key feature for developers creating scalable server-side applications.
- Activation/Launch Security: Using NT's access control lists (ACLs), you can specify which users can start specific object servers. Object servers instantiate (create) in-process, local, and remote objects. By default, DCOM lets only machine administrators launch object servers from remote clients, but you can change or override this default for individual object servers. Launch security also applies to local (same machine) launch requests, which is important for Win32 services that typically run under the System Account. With DCOM, if you have object servers that a remote client launches, you can configure them to run under a specific domain user account.
- Call/Access Security: In addition to launch security, you can specify which users can connect to the object servers. As with launch security, you can configure this feature as a machine default or on a per-server basis. This security feature also applies to local access requests. You can use access security with launch security to let a remote user access an object that the server must launch.
- Call-Level Security: DCOM supports putting security on specific properties or methods of an object server. For example, each interface can have its own remote procedure call (RPC) authentication, impersonation, or authorization parameters.
Overview of the DCOM Architecture
The DCOM architecture is designed around promoting software interoperability. The architecture supports a `software bus' on which reusable software components can be used and integrated with one another seamlessly. This makes the architecture robust in its design and provides a basis on which developers can modularise their applications. In order to provide support for these reusable software components the entire object model is based on an object based programming model as opposed to an object-oriented model. This object model was selected because of its inability to provide inheritance. This means that the architecture is capable of avoiding the fragile base class syndrome which exists in other models. The fragile base class syndrome appears when one class inherits the members and behavior of another class. The class which provides the behavior and member functions is known as the base class while the other class is known as the derived class. If the members and/or functionality of the base class change then the behavior and member functions of the derived class change. Changes like this result in having to modify the base class which in turns requires the recompilation of all dependent classes. Apart from this programming model supporting the concept of reusable components, the model was also selected on the basis that it makes use of pointers and hence is capable of providing a reasonable amount of performance. Like other component models, an overhead from which DCOM suers, is when a connection is required between a component and a client. This results in the COM architecture having to be responsible for negotiating a protocol between the client and the component. In the case of a in-process DLL call once the negotiations are complete the COM overhead is removed while the DLL makes in-process calls. The DCOM architecture possesses a unique infrastructure as it provides support for persistent storage. It is capable of doing this through the use of interfaces which components can implement from in order to save its persistent state. When saved, the data is structured in a specific order known as Structured Storage as is mentioned in Brockschmidt (1994). This ordering of the data makes it easier for other applications and components to browse through the component and extract data which is relevant. In addition to DCOM being able to store the data it also provides the capability of assigning a \smart-name", known as a "Moniker" to a particular instantiation of a component. This name can then be used by the component at a later stage to reconnect to the exact same component again. This component contains the exact same values of all the data members. This form of technology provides a level of indirection in the DCOM architecture allowing a component to be changed in the background without affecting the current links to it. In order to provide this service the DCOM architecture makes use of `Monikers' which are smart names and which can be associated with an instantiation of an object. These identifiers are capable of matching up the internal reference of an object with the identifier that the developer gave. It is through this software bus that the capability of persistent storage is possible. A Moniker is used to match the identifier that the developer gave to the internal reference that was assigned to the component at instantiation time. The infrastructure in DCOM also provides a set of standard interfaces known as the `Uniform Data Transfer'. This interface provides a way for the client and the component to communicate with one another using strict data and type definitions. These interfaces are commonly used by the client to pass information to the component informing the object the data that it is looking at has changed. This can be very useful if one party needs to be informed of an event that has happened to the other party. The structure of the data which flows through these interfaces is strongly defined with regard to type and layout so as to facilitate the exchange of data between the client and the object.
DCOM - Alternative Versions and Implementations
- COMsource: Its source code is available, along with full and complete documentation, sufficient to use and also implement an interoperable version of DCOM. According to that documentation, COMsource comes directly from the Windows NT 4.0 source code, and even includes the source code for a Windows NT Registry Service.
- The Wine Team is also implementing DCOM for binary interoperability purposes; they are not currently interested in the networking side of DCOM, which is provided by MSRPC. They are restricted to implementing NDR (Network Data Representation) through Microsoft's API but are committed to making it as compatible as possible with MSRPC.
- TangramCOM is a separate project from Wine, focusing on implementing DCOM on Linux-based smartphones.
- The Samba Team is also implementing DCOM for over-the-wire interoperability purposes: unlike the Wine Team, they are not currently interested in binary interoperability, as the Samba MSRPC implementation is far from binary-interoperable with Microsoft's MSRPC.
Advantages of Using DCOM
DCOM is a preferred method for developers to use in writing client/server applications for Windows 2000. With DCOM, interfaces to software objects can be added or upgraded, so applications aren't forced to upgrade each time the software object changes. Objects are software entities that perform specific functions. These functions are implemented as dynamic-link libraries so that changes in the functions, including new interfaces or the way the function works, can be made without rewriting and recompiling the applications that call them. Windows 2000 supports DCOM by making the implementation of application pointers transparent to the application and the object. Only the operating system needs to know if the function called is handled in the same process or across the network. This frees the application from concerns with local or remote procedure calls. Administrators can choose to run DCOM applications on local or remote computers and can change the configuration for efficient load balancing. Your application might support its own set of DCOM features. For more information about configuring your application to use DCOM, see your application's documentation. DCOM builds upon remote procedure call (RPC) technology by providing an easy-to-use mechanism for integrating distributed applications on a network. A distributed application consists of multiple processes that cooperate to accomplish a single task. Unlike other interprocess communication (IPC) mechanisms, DCOM gives you a high degree of control over security features, such as permissions and domain authentication. It can also be used to start applications on other computers or to integrate Web browser applications that run on the Microsoft® ActiveX® platform.
- Definition - What does Distributed Component Object Model (DCOM) mean?
- What is Distributed Component Object Model (DCOM)?
- Explaining Distributed Component Object Model (DCOM)
- How DCOM Works?
- Using DCOM
- What are the features of Distributed Component Object Model (DCOM)?
- Overview of the DCOM Architecture
- DCOM - Alternative Versions and Implementations
- Advantages of Using DCOM