Distributed Component Object Model (DCOM)

Researched by Eric Klodnick

Index


What is DCOM?

DCOM is an extension of Microsoft's Component Object Model (COM) across the network.   It allows a transparent implementation of COM between two or more computers.   Fundamentally DCOM specifies a network protocol for making this transparency work   When a client and component resided on the same computer they would communicate via local procedure calls.  When a client and a component reside on different computers, DCOM inserts itself into the mix by using remote procedure calls to access the components across the network. 

COM Component (1 machine)

com.jpg (5671 bytes)

DCOM Component (across machines)

dcom.jpg (6604 bytes)

To the client and component the distributed calls is totally seamless.   The client never has to change how it calls the component.  To the component it doesn't even know that it's client is on another machine. 

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 thread, process, and machine boundaries.  Marshaling of object references is handled transparently by the COM run-time environment. 

For example, take an environment consisting of three machines, say A, B, and C.   DCOM components are registered on all three machines, let's call them component A, B, and C respectively.  Component A creates component B.  Component B in turns creates component C. 

refer.jpg (6272 bytes)

Now component A wants a reference to component C.   Component A calls a method on component B called GetComponentC.  GetComponentC returns the interface pointer to component C.  Component A can now call component C directly without any interaction with component B.  If component B is released by component A, component A still maintains its connection with component C.

refer1.jpg (11660 bytes)

Re-usability

Re-using existing code has long been a goal of any application environment.  DCOM provides the ability to re-use 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. 

[HKEY_CLASSES_ROOT\APPID\{<appid-guid>}]
"RemoteServerName"=<DNS name>

[HKEY_CLASSES_ROOT\CLSID\{<clsid-guid>}]
"AppId"="<appid-guid>"

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 upon 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 are still live.  DCOM uses a pinging protocol to detect if client 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 and NT Security

When creating DCOM applications DCOM and NT Security become an issue by default (even if you didn't want it to).  Even though you might not want to secure your DCOM server the application will pick up the default settings of the machine it runs on.  DCOM settings can be viewed through the Dcomcnfg application.  DCOM security can be customized to fit your application needs.  Customization of DCOM security can be done using Dcomcnfg or it can be changed programmatically.

DCOM security allows applications to control who (i.e. what user) may access or launch DCOM application.  DCOM security allows DCOM servers to determine who the client is making the call and allows servers to impersonate that client on the local machine. NT security provides authentication mechanisms for identifying and validating clients.  In other words DCOM security allows you to control different types of access to applications and servers by using NT security.

Access to DCOM applications can be controlled at two levels.  The first level defines an overall strategy for how your DCOM application will control access, this is the Authentication Level.  The second level defines the NT user(s) or group(s) (an Access Control List) that you want to allow access to your DCOM application.  Another part of the DCOM access security has to deal with launch access.  DCOM security allows you to control who may launch (i.e. start) your DCOM application.  Launch access is also implemented using ACL's.   It's important to remember that access to a DCOM application is different from launch access.

The second part of DCOM security is the Impersonation Level of a DCOM server.  Impersonation allows DCOM servers to customize the NT security account of a call made by a client.  That is, when a call is made to a DCOM server that call runs under a NT security account.  By setting the Impersonation level a DCOM server could set the call to run under the clients NT security token, the NT security token the DCOM server is running under, etc..  Essentially the Impersonation level controls the NT security token of a call in the DCOM server.

Authentication Level

The following table describes the different levels of Authentication.  It can also be found on the Microsoft web site.

Level Description
Default Not available until WinNT 5.0.  Under WinNT 4.0 this defaults to Connect.
None No authentication is performed on the client by the server.
Connect Authenticates the client when a connection is made to the server.
Call Authenticates the client for every call made to the server.
Packet Authenticates that all data packets received is from the expected client.
Packet Integrity Authenticates and verifies that none of the data transferred between client and server has been modified.
Packet Privacy Authenticates all previous levels and encrypts the argument value of each remote procedure call.


Impersonation Level

The following table describes the different levels of Impersonation.  t can also be found on the Microsoft web site.

Level Description
Default Not available until WinNT 5.0
Anonymous The client is anonymous to the server.  There is no NT security token for the client on the server.
Identity The server can obtain the client's identity. The server can impersonate the client for ACL checking, but cannot access system objects as the client.
Impersonation The server process can impersonate the client's security token while acting on behalf of the client. This level of impersonation can be used to access local resources such as files. When impersonating at this level, the impersonation token can only be passed across one machine boundary.
Delegate Not available until WinNT 5.0

 

NOTE: Under WinNT 4.0 a users NT security token can only pass from one machine to another machine.  Any process of the machine receiving the NT security token can NOT pass the same NT security token to another machine for use.  
For example: Take a process on client machine A and a DCOM server on machine B. 

When client A makes a DCOM call to machine B the clients NT security token is authenticated on machine B.  That is, machine B makes sure that the client has access to the DCOM server on B.  Once the DCOM server receives the NT security token it can only use that token on machine B.  The DCOM server can use that NT security token to open a file,  or access any other local resources for that call.   If the DCOM server attempts to call a third machine C the NT security token is lost for that call to another machine.  The call to machine C is made under a NULL NT security token (non-existent user).

Now assume client A and the DCOM server are both on machine A.

When client A makes a DCOM call to the DCOM server the NT security token is authenticated on machine A.  At this point the NT security token has not been passed to another machine.  If the DCOM server makes a call to a second machine B the NT security token can be passed to the DCOM server on machine B.  This works because the call from A to B is the first time the NT security token has been passed from one machine to another.

Programmatically Setting Authentication and Impersonation Levels

You can set DCOM security settings programmatically with the function CoInitializeSecurity.   CoInitializeSecurity will override the default settings in Dcomcnfg for any application that calls CoInitializeSecurity.  CoInitializeSecurity can only be called once per process so you can't use CoInitializeSecurity to change the way security is set on a currently running process.   Also the COM system will call CoInitializeSecurity by default the first time it makes a cross Apartment call within a process.  It's advised that you make the call to CoInitializeSecurity immediately after the call to CoIntialize or CoInitializeEx within your process.  It is not recommended that you call CoInitializeSecurity from a DLL.  

A process can supply CoInitializeSecurity with an Access Control List (ACL) as one of its parameters. The ACL supplied in the security descriptor controls which users have access to the components implemented by a DCOM server.  You can also set the Authentication, and Impersonation level of a DCOM server through CoInitializeSecurity.    For the complete description of CoInitializeSecurity see the Microsoft documentation for more information.

The following call to CoInitializeSecurity demonstrates how to allow everyone access to your DCOM application.

HRESULT hr = CoInitializeSecurity( NULL,
-1,
NULL,
NULL,
RPC_C_AUTHN_LEVEL_NONE,
RPC_C_IMP_LEVEL_IDENTIFY,
NULL,
EOAC_NONE,
NULL);

 

For more information on DCOM Security view the following Microsoft Knowledge Base article    http://support.microsoft.com/support/kb/articles/Q158/5/08.asp.

For the complete lowdown on DCOM Security see Keith Brown's article in the MSJ.

The Future

One of the fundamental issues companies face today is how to re-use existing systems while providing a web interface for their information. To allow companies to achieve both goals Microsoft is working towards providing a bridge to Unix, mainframe, and other operating systems from the Windows platform. 

Microsoft is working with third party vendors to port COM to a number of different operating systems (In the future COM will be available on different flavors of Unix, on AIX, Sun Solaris, etc.).  In order to access your legacy data you would create COM wrappers that provide access to the legacy systems.  Using MTS or straight DCOM running on a Windows NT Server you would create the remote component on the Unix, AIX machine and then access the data through DCOM.   

Microsoft is hoping that their web technology becomes the web development platform of choice.  Once a company has decided Windows NT is the best platform for developing a web presence they will need a bridge to legacy systems.  Once a company brings the legacy data closer to web they can concentrate on how to port their legacy data to Windows NT.  The movement of an application from old legacy systems to a modern operating system and user interface becomes a gradual process.  Companies can smoothly transition out their old systems and move to the new environment.

COMTI is Microsofts solution for providing mainframe access from Windows NT.   COMTI provides the necessary protocol and messaging capabilities to communicate with IBM's IMS or CICS mainframe management systems.  Using SNA Server a COM/MTS component can send messages to the mainframe.  COMTI provides the translation mechanism for converting a COM/MTS component transaction into a mainframe message.   COMTI will also provide the reverse translation, taking mainframe data and translating into something a COM component can interpret. 

An article appeared in the 1998 December issue of the Microsoft Systems Journal that describes Microsoft's vision of how DCOM/COM will become cross platform compatible.  But check other less favorable articles to get the both sides of the story on cross platform COM.