Next

DCOM is the extensions of COM for multi computer programming. This allow for example to have a very fast computer for computing NC toolpath on surface and to call this computation from any computer on the network without specific programming.

DCOM components

Administration of remote objects. Remote objects must be registered on the server and client computer. On the client side the component can be bind to specific computer using DCOMCFG. The software running on the client side may also precise which computer is going to do the job. This is an extra parameter to CoCreateInstanceEx().

Transfer of calls and Arguments. When a remote object is called it is actually a small object with the same interface which is called. This object is in the same process space as the caller so there is no problem for data transfer. This small object take care to put all arguments in a form suitable for network communication. The same occur on the server computer. Eventually the server program will process the call. Outgoing arguments are moved back to the calling machine. This process of putting arguments in a form suitable for network and heterogeneous communication is called marshalling.

Objects as services. On a computer process are either applications running with interaction of the desktop or services. Desktop application will run with all permissions related to the user currently logged in. Services are background tasks. They have no relation with the desktop and they run with a user account given once for all. Services can be started a boot time or on request. In the DCOM environment it is natural to consider objects as services.

Security, Pinging, Asynchronous calls, Many issues are still in discussion. Is DCOM enough security proof ? The fact the user logged on the client machine don't need to have an account on the server machine let us imagine that in some cases some user may have access to features they are not allowed to have by the way of the remote object. Pinging is relative to all the questions about keeping object pointers valid if a computer or the network goes down. Inside DCOM there is a mechanism to check if objects are still alive. This is done through a kind of ping from one computer to the other asking whether all objects referenced are still alive. Asynchronous calls are an issue when there is a server object firing event on his customers. When the server will send the event it will call the first object, wait for the answer, then call the second etc .. If one of them is slow to answer all the others are affected. This is for us a major drawback of this new technology, but it is going to be reduced in the future.

Remark. To prepare your interfaces for DCOM they should all have an HRESULT as result. This is because all errors due to bad network communication or a server going down are returned as specific error code in a HRESULT.

This feature is enabled on windows NT 4.0 It is also available for windows 95 but you have to download it from microsoft web . It is still a release candidate so you might experience problems.

DCOM White paper

COM COM is available across computers boundary.