What is a Distributed Component Object Model (DCOM)?

DCOM is an extension of the Component Object Model (COM). Component Object Model explains how components and their clients interact. This interaction is the way the client and the component can connect without the need of any intermediary system component.

Suppose when client and component are present on different machines, DCOM replaces the local Inter-process communication with a network protocol.

Neither the client nor the components are aware that the wire that connects them has just become a little longer.

The COM run-time provides object-oriented services to clients and components and uses RPC and the security provider to generate standard network packets that conform to the DCOM wire-protocol standard.

The above architecture supports a software bus.

In order to support this reusable software component, the complete object model is based totally on an object-based programming model.

The object model is used to select due to its incapability to provide inheritance which means that the above architecture is successful in keeping off fragile base class syndrome which exists in different models.

The fragile base class syndrome seems when one class inherits members and behavior of any other class.

The Class that offers the behavior and member functions which is recognized as base class will be recognized as derived class. As the member and functionality of base class modifications occur then behavior and member functions of derived class will change.

Finally the end results in having to alter the base class which in turn requires compilation of all dependent classes.

Working of DCOM

If the DCOM has to work, first the COM object should be configured correctly on both computers and you have to uninstall and reinstall the objects several times to get them to work.

The Windows contains the DCOM configuration data in three identifiers −

  • CLSID − The Class Identifier (CLSID) is called a Global Unique Identifier (GUID) where the windows store a CLSID for every installed class in a program. Suppose if you want to run a class, we have to correct CLSID, the Windows will know where to find the program.

  • PROGID − The Programmatic Identifier (PROGID) is one of the optional identifiers where the programmer can substitute for the more complicated and strict CLSID. PROGIDs are easier to read and understand. +

  • APPID − The Application Identifier (APPID) identifies and requires permissions to access it and all the classes that are part of the same executable. Suppose if APPID is not correct the DCOM will not work. We need to get permissions errors trying to create the remote object, in my experience.

DCOM Transaction

Generally the DCOM transaction is as follows −

  • First the client system requests the remote computer to create an object by using its CLSID or PROGID. Suppose if the client passes the APPID, the remote computer looks up the CLSID using the PROGID.

  • Then the remote machine checks for the APPID and verifies that the client has given permissions to create the object.

  • DCOMLaunch.exe or DLLHOST.exe will create an instance of the class the client computer requested.

  • Communication is successful!

The Client can now access all functions in the class on the remote computer.

If the client does not have the correct permissions, or the CLSID is pointing to an old version of the exe or the APPID is not configured correctly, or any other number of issues, we will get a "Can’t Create Object" message.

Updated on: 21-Mar-2022

1K+ Views

Kickstart Your Career

Get certified by completing the course

Get Started