Advanced
We recommend Object
Request Broker, Remote Procedure
Call, and Component-Based
Software Development/COTS Integration, as prerequisite
readings for this technology description.
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+.
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:
- 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.
- 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).
- 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:
- It invokes the COM API to instantiate a new COM object.
- COM locates the object implementation and initiates a server
process for the object.
- The server process creates the object, and returns an
interface pointer at the object.
- 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
|
Service
|
Explanation
|
|
Type
Information
|
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.
|
|
Structured
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.
|
|
Monikers
|
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.
- COM is hard to use. Reference counting, Microsoft IDL, Global
Unique Identifiers (GUID), etc. require deep knowledge of COM
specification from developers.
- 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].
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.
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:
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.
This technology is classified under the following categories.
Select a category for a list of related topics.
