Microsoft designs a middleware for OSes and distributed apps

According to chairman Bill Gates, Microsoft's Component Object Model will reduce the
complexity of building distributed applications by putting the middleware into the
operating system.

When Windows NT 5.0 comes out next year, it will bundle the Microsoft Transaction
Server and Microsoft Message Queue Server. Applications written for the Transaction Server
must conform to COM.

COM defines a way for one piece of software to provide services to another, regardless
of the languages involved. A COM object lets a client access its methods through
interfaces, each of which has one or more methods. Client software using this COM object
can acquire individual pointers to each interface and invoke that interface's methods.

COM underlies Object Linking and Embedding, ActiveX and future versions of Windows. It
is language-independent: COM objects can be developed in Java, C++, Visual Basic and other

The Distributed Component Object Model extends COM to objects running on other machines
and across networks. I think of DCOM as COM with a longer wire. When client and component
reside on different machines, DCOM simply replaces the local interprocess communication
with a network protocol. Neither the client nor the component is aware that the wire
between them has just gotten a little longer.

In a DCOM architecture, a COM run-time program provides object-oriented services to
clients and components. It uses remote procedure calls to generate network packets that
conform to DCOM.

Windows NT 4.0 has built-in COM for many of its internal functions. NT 5.0 will expand
that dependence on COM.

A client that needs to communicate with a component in another process can't call it
directly but must instead use interprocess communication through the operating system. COM
does this by intercepting calls from the client and forwarding them to the component.

COM, which has the support of Microsoft, Hewlett-Packard Co., Digital Equipment Corp.
and Cisco Systems Inc., competes with the Common Object Request Broker Architecture
(CORBA) advanced by Netscape Communications Corp., IBM Corp. and Novell Inc.

COM and DCOM are no longer proprietary to Microsoft but are managed by the Open Group's
ActiveX Consortium. CORBA is the more cross-platform choice at this point, although
Digital and HP plan to support COM on the HP-UX, Digital Unix and OpenVMS operating
systems soon.

Meanwhile, Microsoft will make DCOM available for the Apple Macintosh and leading Unix
platforms this year, including a reference implementation in source code form.

Distributed platforms need a security framework to safely distinguish different clients
that are trying to do things to a component. DCOM uses the extensible security framework
of NT, which supports multiple identification and authentication mechanisms, from
trusted-domain security models to noncentralized public key.

The heart of the security framework is a user directory with credentials. Most DCOM
implementations on non-NT platforms have a similar extensibility mechanism to use whatever
security providers are available. Unix implementations of DCOM will have an NT-compatible
security provider.

Here are some NT security providers:

These security providers use standard Internet protocols. NTLM and the Kerberos
provider that will replace it in NT 5.0 are private-key protocols, extremely secure in
centrally administered environments or in NT Server domains with mutual or unilateral
trust relationships. Commercial implementations of NTLM security providers are available
for leading Unix platforms.

Charles S. Kelly is a computer systems analyst at the National Science Foundation.
You can e-mail him on the Internet at
This column expresses his personal views, not the official views of NSF.

Stay Connected

Sign up for our newsletter.

I agree to this site's Privacy Policy.