General Navigation Buttons - Home | Search | Contact Us | Site Map | Whats New
products graphic
white space
Software Technology Roadmap
What's New
Background & Overview
Technology Descriptions
Defining Software Technology
Technology Categories
Template for Technology Descriptions
Glossary & Indexes
Feedback & Participation
Software Engineering Information Repository (SEIR)
white space
About SEI|Mgt|Eng|Acq|Collaboration|Prod.& Services|Pubs
Rollover Popup Hints for Topic Navigation Buttons above
Component Object Model (COM), DCOM, and Related Capabilities




We recommend Object Request Broker, Remote Procedure Call, and Component-Based Software Development/COTS Integration, as prerequisite readings for this technology description.

Purpose and Origin

COM [COM 95] refers to both a specification and implementation developed by Microsoft Corporation which provides a framework for integrating components. This framework supports interoperability and reusability of distributed objects by allowing developers to build systems by assembling reusable components from different vendors which communicate via COM. By applying COM to build systems of preexisting components, developers hope to reap benefits of maintainability and adaptability.

COM defines an application programming interface (API) to allow for the creation of components for use in integrating custom applications or to allow diverse components to interact. However, in order to interact, components must adhere to a binary structure specified by Microsoft. As long as components adhere to this binary structure, components written in different languages can interoperate.

Distributed COM [DCOM 97] is an extension to COM that allows network-based component interaction. While COM processes can run on the same machine but in different address spaces, the DCOM extension allows processes to be spread across a network. With DCOM, components operating on a variety of platforms can interact, as long as DCOM is available within the environment.

It is best to consider COM and DCOM as a single technology that provides a range of services for component interaction, from services promoting component integration on a single platform, to component interaction across heterogeneous networks. In fact, COM and its DCOM extensions are merged into a single runtime. This single runtime provides both local and remote access.

While COM and DCOM represent "low-level" technology that allows components to interact, OLE [Brockschmidt 95], ActiveX [Active 97] and MTS [Harmon 99] represent higher-level application services that are built on top of COM and DCOM. OLE builds on COM to provide services such as object "linking" and "embedding" that are used in the creation of compound documents (documents generated from multiple tool sources). ActiveX extends the basic capabilities to allow components to be embedded in Web sites. MTS expands COM capabilities with enterprise services such as transaction and security to allow Enterprise Information Systems (EIS) to be built using COM components. COM+ is the evolution of COM.

COM+ integrates MTS services and message queuing into COM, and makes COM programming easier through a closer integration with Microsoft languages as Visual Basic, Visual C++, and J++. COM+ will not only add MTS-like quality of service into every COM+ object, but it will hide some of the complexities in COM coding.

The distinctions among various Microsoft technologies and products are sometimes blurred. Thus, one might read about "OLE technologies" which encompass COM, or "Active Platform" as a full web solution. In this technology description, we focus on the underlying technology represented by COM, DCOM, and COM+.

Technical Detail

COM is a binary compatibility specification and associated implementation that allows clients to invoke services provided by COM-compliant components (COM objects). As shown in Figure 5, services implemented by COM objects are exposed through a set of interfaces that represent the only point of contact between clients and the object.

Figure 5: Client Using COM Object Through an Interface Pointer [COM 95]

COM defines a binary structure for the interface between the client and the object. This binary structure provides the basis for interoperability between software components written in arbitrary languages. As long as a compiler can reduce language structures down to this binary representation, the implementation language for clients and COM objects does not matter - the point of contact is the run-time binary representation. Thus, COM objects and clients can be coded in any language that supports Microsoft's COM binary structure.

A COM object can support any number of interfaces. An interface provides a grouped collection of related methods. For example, Figure 6 depicts a COM object that emulates a clock. IClock, IAlarm and ITimer are the interfaces of the clock object. The IClock interface can provide the appropriate methods (not shown) to allow setting and reading the current time. The IAlarm and ITimer interfaces can supply alarm and stopwatch methods.

Figure 6: Clock COM object

COM objects and interfaces are specified using Microsoft Interface Definition Language (IDL), an extension of the DCE Interface Definition Language standard (see Distributed Computing Environment). To avoid name collisions, each object and interface must have a unique identifier.

Interfaces are considered logically immutable. Once an interface is defined, it should not be changed-new methods should not be added and existing methods should not be modified. This restriction on the interfaces is not enforced, but it is a rule that component developers should follow. Adhering to this restriction removes the potential for version incompatibility-if an interface never changes, then clients depending on the interface can rely on a consistent set of services. If new functionality has to be added to a component, it can be exposed through a different interface. For our clock example, we can design an enhanced clock COM object supporting the IClock2 interface that inherits from IClock. IClock2 may expose new functionality.

Every COM object runs inside of a server. A single server can support multiple COM objects. As shown in Figure 7, there are three ways in which a client can access COM objects provided by a server:


  1. In-process server: The client can link directly to a library containing the server. The client and server execute in the same process. Communication is accomplished through function calls.
  2. Local Object Proxy: The client can access a server running in a different process but on the same machine through an inter-process communication mechanism. This mechanism is actually a lightweight Remote Procedure Call (RPC).
  3. Remote Object Proxy: The client can access a remote server running on another machine. The network communication between client and server is accomplished through DCE RPC. The mechanism supporting access to remote servers is called DCOM.

Figure 7: Three Methods for Accessing COM Objects [COM 95]

If the client and server are in the same process, the sharing of data between the two is simple. However, when the server process is separate from the client process, as in a local server or remote server, COM must format and bundle the data in order to share it. This process of preparing the data is called marshalling. Marshalling is accomplished through a "proxy" object and a "stub" object that handle the cross-process communication details for any particular interface (depicted in Figure 8). COM creates the "stub" in the object's server process and has the stub manage the real interface pointer. COM then creates the "proxy" in the client's process, and connects it to the stub. The proxy then supplies the interface pointer to the client.

The client calls the interfaces of the server through the proxy, which marshals the parameters and passes them to the server stub. The stub unmarshals the parameters and makes the actual call inside the server object. When the call completes, the stub marshals return values and passes them to the proxy, which in turn returns them to the client. The same proxy/stub mechanism is used when the client and server are on different machines. However, the internal implementation of marshalling and unmarshalling differs depending on whether the client and server operate on the same machine (COM) or on different machines (DCOM). Given an IDL file, the Microsoft IDL compiler can create default proxy and stub code that performs all necessary marshalling and unmarshalling.

Figure 8: Cross-process communication in COM [COM 95]

All COM objects are registered with a component database. As shown in Figure 9, when a client wishes to create and use a COM object:

  1. It invokes the COM API to instantiate a new COM object.
  2. COM locates the object implementation and initiates a server process for the object.
  3. The server process creates the object, and returns an interface pointer at the object.
  4. The client can then interact with the newly instantiated COM object through the interface pointer.

An important aspect in COM is that objects have no identity, i.e. a client can ask for a COM object of some type, but not for a particular object. Every time that COM is asked for a COM object, a new instance is returned. The main advantage of this policy is that COM implementations can pool COM objects and return these pooled objects to requesting clients. Whenever a client has finished using an object the instance is returned to the pool. However, there are mechanisms to simulate identity in COM such as monikers (reviewed later).

Figure 9: Creating a COM object pointer [COM 95]

COM includes interfaces and API functions that expose operating system services, as well as other mechanisms necessary for a distributed environment (naming, events, etc.). These are sometimes referred to as COM technologies (or services), and are shown in Table 3.

Table 3: COM Technologies




Some clients need runtime access to type information about COM objects. This type information is generated by the Microsoft IDL compiler and is stored in a type library. COM provides interfaces to navigate the type library.

Storage and Persistence

COM objects need a way to store their data when they are not running. The process of saving data for an object is called making an object persistent. COM supports object persistence through "Structured Storage", which creates an analog of a file system within a file. Individual COM objects can store data within the file, thus providing persistence.


Clients often require a way to allow them to connect to the exact same object instance with the exact same state at a later point in time. This support is provided via "monikers". A moniker is a COM object that knows how to create and initialize the content of a single COM object instance. A moniker can be asked to bind to the COM object it represents, such as a COM object residing on specific machine on the network, or a group of cells inside a spreadsheet.

Uniform Data Transfer

COM objects often need to pass data amongst themselves. Uniform Data Transfer provides for data transfers and notifications of data changes between a source called the data object, and something that uses the data, called the consumer object.

Connectable Objects

Some objects require a way to notify clients that an event that has occurred. COM allows such objects to define outgoing interfaces to clients as well as incoming interfaces. The object defines an interface it would like to use (e.g., a notification interface) and the client implements the interface. This enables two-way communication between the client and the component.

COM has enjoyed great industrial support with thousands of ISVs developing COM components and applications. However, COM suffers from some weaknesses that have been recognized by Microsoft and addressed in Component Object Model+, which is the ongoing upgrade of COM.

  1. COM is hard to use. Reference counting, Microsoft IDL, Global Unique Identifiers (GUID), etc. require deep knowledge of COM specification from developers.
  2. COM is not robust enough for enterprise deployments. Services such as security, transactions, reliable communications, and load balancing are not integrated in COM.

Both issues were partially mitigated by add-ons of COM, complexity by integrated development environments and robustness by MTS. However, to further address those problems, the company is working to turn COM+ and the MTS (Microsoft Transaction Server) into one programming model that will simplifying the lives of developers building distributed, enterprise-wide COM applications. COM+ integrates seamlessly with all COM-aware languages (basically Microsoft languages). Users write components in their favorite language. The tool chosen and the COM+ runtime take care of turning these classes into COM components [Kirtland 97].

Usage Considerations

A number of issues must be evaluated when considering COM, DCOM, and COM+. They include


  • Platform support. COM and DCOM are best supported on Windows 95 and NT platforms. However, Microsoft has released a version of COM/DCOM for MacOS that supports OLE-style compound documents and the creation of ActiveX controls. Software AG, a Microsoft partner, has released DCOM for some UNIX operating systems, concretely OS/390, HP-UX 11.0, SUN Solaris, AIX 4.2, 4.3, Tru64 Unix 4.0 and Linux. However, DCOM over non-Windows platforms has few supporters. Until DCOM for alternate platforms has solidified, the technology is best applied in environments that are primarily Windows-based.
  • Platform specificity of COM/DCOM components. Because COM and DCOM are based on a native binary format, components written to these specifications are not platform independent. Thus, either they must be recompiled for a specific platform, or an interpreter for the binary format must become available. Depending on your perspective, the use of a binary format may be either an advantage (faster execution, better use of native platform capabilities) or a disadvantage (ActiveX controls, unlike Java applets, are NOT machine independent). See Java for more information.
  • Security. Because COM/DCOM components have access to a version of the Microsoft Windows API, "bad actors" can potentially damage the user's computing environment. In order to address this problem, Microsoft employs "Authenticode" [Microsoft 96] which uses public key encryption to digitally sign components. Independent certification authorities such as VeriSign issue digital certificates to verify the identity of the source of the component [VeriSign 97]. However, even certified code can contain instructions that accidentally, or even maliciously, compromise the user's environment.
  • Support for distributed objects. COM/DCOM provides basic support for distributed objects. There is currently no support for situations requiring real time processing, high reliability, or other such specialized component interaction.
  • Stability of APIs. In October of 1996 Microsoft turned over COM/DCOM, parts of OLE, and ActiveX to the Open Group (a merger of Open Software Foundation and X/Open). The Open Group has formed the Active Group to oversee the transformation of the technology into an open standard. The aim of the Active Group is to promote the technology's compatibility across systems (Windows, UNIX, and MacOS) and to oversee future extension by creating working groups dedicated to specific functions. However, it is unclear how much control Microsoft will relinquish over the direction of the technology. Certainly, as the inventor and primary advocate of COM and DCOM, Microsoft is expected to have strong influence on the overall direction of the technology and underlying APIs.
  • Long-term system maintainability. Microsoft is actively supporting COM and DCOM technology and pushing it in distributed and Web-based directions. Microsoft is also trying to preserve existing investments in COM technology while introducing incremental changes. Microsoft, for example, has ensured backward compatibility of COM+. Although this affirmation is in general true, COM objects that access local information in the registry or in system folders may require modification. In general, the PC community has not been faced with the concern of very long-lived systems, and vendors often provide support only for recent releases.


COM has its roots in OLE version 1, which was created in 1991 and was a proprietary document integration and management framework for the Microsoft Office suite. Microsoft later realized that document integration is just a special case of component integration. OLE version 2, released in 1995 was a major enhancement over its predecessor. The foundation of OLE version 2, now called COM, provided a general-purpose mechanism for component integration on Windows platforms [Brockschmidt 95]. While this early version of COM included some notions of distributed components, more complete support for distribution became available with the DCOM specifications and implementations for Windows95 and Windows NT released in 1996. Beta versions of DCOM for Mac, Solaris and other operating systems followed shortly after.

There are many PC-based applications that take advantage of COM and DCOM technology. The basic approach has proven sound, and as previously mentioned, a large component industry has sprung up to take advantage of opportunities created by the Microsoft technology. On the other hand, DCOM has just arrived on non-Windows platforms, and there is little experience with it. DCOM for non-Windows platforms is mainly used to communicate COM based programs with legacy applications in Mainframes and Unix workstations.

COM+ is much younger than COM, it was announced in Sept. 23, 1997 and shipped with windows 2000 (a.k.a. Windows NT 5.0). COM+ can be considered the next release of COM. We are unaware of any large-scale distributed applications relying on COM+ support.

The computing paradigm for distributed applications is in flux, due to the relative immaturity of the technology and recent advances in web-based computing. The Web-centered computing industry has begun to align itself into two technology camps-with one camp centered around Microsoft's COM/DCOM/COM+, Internet Explorer, and ActiveX capabilities, and the other camp championing Netscape, CORBA, and Java/J2EE solutions. Both sides argue vociferously about the relative merits of their approach, but at this time there is no clear technology winner. Fortunately, both camps are working on mechanisms to support interplay between the technology bases. Thus, a COM/DCOM to CORBA mapping is supported by CORBA vendors [Foody 96], and Microsoft has incorporated Java into an Internet strategy. However, work on interconnection between the competing approaches is not complete, and each camp would shed few tears if the other side folded.

Costs and Limitations

Low cost development tools from Microsoft (such as Visual C++ or Visual Basic), as well as tools from other vendors provide the ability to build and access COM components for Windows platforms. Construction of clients and servers is straightforward on these platforms. In addition, the initial purchase price for COM and DCOM is low on Windows platforms. For other platforms the prices are considerably more expensive. DCOM for mainframes, for example, costs around two hundred thousand dollars by December 1999.

Beyond basic costs to procure the technology, any serious software development using COM/DCOM/COM+ requires substantial programmer expertise-the complexities of building distributed applications are not eliminated. It would be a serious mistake to assume that the advent of distributed object technologies like COM/DCOM/COM+ reduces the need for expertise in areas like distributed systems design, multi-threaded applications, and networking.

However, Microsoft has a strong support organization to assist individuals developing COM/DCOM clients and objects: many sample components, books and guides on the subject of COM/DCOM development are available. Unfortunately, information on COM+ is limited at this time.


Dependencies include Remote Procedure Call and Distributed Computing Environment.


COM/DCOM/COM+ represents one of a number of alternate technologies that support distributed computing. Some technologies, such as remote procedure call, offer "low level" distribution support. Other technologies, such as message oriented middleware and transaction processing monitors, offer distribution support paradigms outside the realm of objects. The Common Object Request Broker Architecture (CORBA) and Java 2 Enterprise Edition (J2EE) can be considered direct competitors to COM/DCOM. Information about technologies supporting distributed computing is available in the following places:

Complementary Technologies

One commonly hears of COM and DCOM in conjunction with OLE, ActiveX, MTS and COM+. Indeed, these and other technologies constitute Microsoft's distributed and web-oriented strategy. This strategy is globally referred as Distributed interNet Architecture(tm) (DNA) and it comprises a full set of products and specifications to implement net-centric applications.

Technologies championed by other vendors can also be used in conjunction with COM. For example, COM objects can be created and manipulated from Java code. Tools are provided to create Java classes from COM type library information-these classes can be included in Java code. Using Internet Explorer, Java programs can also expose functionality as COM services. In general, Microsoft's approach for Java support involves tying it very closely to its existing Internet strategy (Internet Explorer, COM/DCOM, ActiveX); i.e., to provide a mechanism for interfacing to the wide range of components that already adhere to Microsoft's strategy and specifications.

COM+ is a good candidate to implement the middle layer of multitier architectures. The distribution support and quality of service provided by COM+ can help to overcome some of the complexities involved in these architectures.

Index Categories

This technology is classified under the following categories. Select a category for a list of related topics.

Name of technology

Component Object Model (COM), DCOM, and Related Capabilities

Application category

Software Architecture Models (AP.2.1.1)
Client/Server (AP.
Client/Server Communications (AP.2.2.1)

Quality measures category

Maintainability (QM.3.1)
Interoperability (QM.4.1)
Reusability (QM.4.4)

Computing reviews category

Distributed Systems (C.2.4)
Object-Oriented Programming (D.1.5)

References and Information Sources

[Active 97]

Active Group home page [online]. Available WWW
<URL:> (1997).

[Brockschmidt 95]

Brockschmidt, Kraig. Inside OLE, 2nd edition, Microsoft Press, 1995

[Chappell 96]

Chappell, David. DCE and Objects [online]. Available WWW
<URL:> (1996).

[COM 95]

Microsoft Corporation. The Component Object Model Specification, Version 0.9, October 24, 1995 [online]. Available WWW

[DCOM 97]

Microsoft Corporation. Distributed Component Object Model Protocol-DCOM/1.0, draft, November 1996 [online]. Available WWW
<URL:> (1996).

[Foody 96]

Foody, M.A. "OLE and COM vs. CORBA." UNIX Review 14, 4. (April 1996): 43-45.

[Harmon 99]

Harmon, Paul. Microsoft transaction Server. Component development Strategies Vol IX No 3. Available WWW <URL: > 1999

[Kirtland 97]

Kirtland, Mary. "The COM+ Programming Model Makes it Easy to Write Components in Any Language". Microsoft System Journal. Dec, 1997.

[Microsoft 96]

Microsoft Corporation. Microsoft Authenticode Technology [online]. Available WWW
<URL:> (1996).

[MSCOM 97]

Microsoft home page [online]. The site provides information about COM, DCOM and OLE. Available WWW
<URL:> (1997).

[OMG 97]

Object Management Group home page [online]. The site provides information comparing DCOM (ActiveX) to CORBA. Available WWW
<URL:> (1997).

[VeriSign 97]

Verisign home page [online]. Available WWW
<URL:> (1997).

Current Author/Maintainer

Santiago Comella-Dorda, SEI

External Reviewers


13 Mar 2001: Update with new developments of COM
23 June 1997: Total replacement text
10 Jan 1997: Original

The Software Engineering Institute (SEI) is a federally funded research and development center sponsored by the U.S. Department of Defense and operated by Carnegie Mellon University.

Copyright 2007 by Carnegie Mellon University
Terms of Use
Last Modified: 11 January 2007