This print for content only-size & color not accurate 7" X 9-1/4" / casebound / malloy

The Role of DCOM 

Prior to the release of the .NET platform, Distributed Component Object Model (DCOM) was the

remoting API of choice for Microsoft-centric development endeavors. Using DCOM, it was possible

to build distributed systems using COM objects, the system registry, and a good amount of elbow

grease. One benefit of DCOM was that it allowed for 

location transparency of components. Simply

put, this allowed client software to be programmed in such a way that the physical locations of the

remote objects were not hard-coded. Regardless of whether the remote object was on the same

machine or a secondary networked machine, the code base could remain neutral, as the actual

location was recorded externally in the system registry.

While DCOM did enjoy some degree of success, for all practical purposes it was a Windows-

centric API. Even though DCOM was ported to a few other operating systems, DCOM alone did not

provide a fabric to build comprehensive solutions involving multiple operating systems (Windows,

Unix, Mac) or promote sharing of data between diverse architectures (COM, J2EE, CORBA, etc.).