Jump to content

Distributed Component Object Model: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
bit about comsource. also, DCOM would be NOTTTHHIING without dce/rpc: it would just be COM.
re-added (better phrased i hope) sections indicating quite how critical DCE/RPC is to DCOM's viability.
Line 6: Line 6:
*[[Marshalling]] - serializing and deserializing the arguments and return values of method calls "over the wire".
*[[Marshalling]] - serializing and deserializing the arguments and return values of method calls "over the wire".
*Distributed [[Garbage collection (computer science)|Garbage Collection]] - ensuring that references held by clients of interfaces are released when, for example, the client process crashed, or the network connection was lost.
*Distributed [[Garbage collection (computer science)|Garbage Collection]] - ensuring that references held by clients of interfaces are released when, for example, the client process crashed, or the network connection was lost.

One of the key factors in solving these problems is the use of [[DCE/RPC]] as the underlying RPC mechanism behind DCOM. [[DCE/RPC]] has strictly defined rules regarding marshalling and who is responsible for freeing memory.


DCOM was a major competitor to [[CORBA]]. Proponents of both of these technologies saw them as one day becoming the model for code and service-reuse over the [[Internet]].
DCOM was a major competitor to [[CORBA]]. Proponents of both of these technologies saw them as one day becoming the model for code and service-reuse over the [[Internet]].

Revision as of 21:49, 13 September 2005

Distributed Component Object Model (DCOM) is a Microsoft proprietary technology for software components distributed across several networked computers to communicate with each other. It extends Microsoft's COM, and provides the communication substrate under Microsoft's COM+ application server infrastructure. It has been deprecated in favor of Microsoft .NET.

The addition of the "D" in DCOM was due to extensive use of DCE/RPC - more specifically Microsoft's enhanced version, known as MSRPC.

In terms of the extensions it added to COM, DCOM had to solve the problems of

  • Marshalling - serializing and deserializing the arguments and return values of method calls "over the wire".
  • Distributed Garbage Collection - ensuring that references held by clients of interfaces are released when, for example, the client process crashed, or the network connection was lost.

One of the key factors in solving these problems is the use of DCE/RPC as the underlying RPC mechanism behind DCOM. DCE/RPC has strictly defined rules regarding marshalling and who is responsible for freeing memory.

DCOM was a major competitor to CORBA. Proponents of both of these technologies saw them as one day becoming the model for code and service-reuse over the Internet.

Ironically, however, the difficulties involved in getting either of these technologies to work over Internet firewalls, and on unknown and insecure machines, meant that normal http requests in combination with web browsers won out over both of them. This despite Microsoft's attempts to add an extra transport - Network Computing Architecture, Connection-based, over HTTP aka ncacn_http - to DCE/RPC, which was made available seamlessly to DCOM services.

There exists an implementation of DCOM from The Open Group called COMsource - see http://opengroup.org/comsource. The source code is available for COMsource, and it comes directly from the Windows NT 4.0 source code.