The Distributed Component Object Modeling Approach. Microsoft's COM is a technology for component software development. It is a binary standard which is not language dependent. DCOM is a distributed extension of COM. Reference counting is memory management technique used to count how many times an object has a pointer referring to it. The first time it is created, the reference count is set to one. When the last reference to the object is nulled, the reference count is set to zero and the object is deleted. Care must be exercised to prevent a context switch from changing the reference count at the time of deletion. In the methods that follow, the syntax is shorten to keep the scope of the discussion manageable and brief. All interfaces are classes derived from the base class IUnknown. The system registry is a hierarchical database which stores information (the class id) about the objects registered in the computer. It is these class id's which provide a unique Unicode identification of the object. Object-oriented programming as described by Booch and implemented in C++, give rise to long chains of inheritances which complicate large system development. COM is an implementation of Rumbahl's object-oriented paradyne based on a few assumptions. The fundamental one is that every object supports at least one interface, the unknown interface called IUnknown. Each interface supports methods which allow the user to access data and perform operations. For example, IUnknown supports three methods, AddRef, Release(), and QueryInterface(). Suppose pUnk is a pointer to an IUnknown. pUnk->AddRef() increments the reference count. pUnk->Release() decrements the reference count and deletes the object when the reference count reaches zero, and pUnk->QueryInterface( IDesired, pDesired) check to see if the current interface (IUnknown) supports another interface, IDesired, creates an instance (via a call to CoCreateInstance()) of the object if the reference count is zero (the object does not yet exist), and then calls pDesired->AddRef() (where pDesired is a pointer to IDesired) and returns the pointer to the caller. The outer COM object reuse an inner's object through containment or aggregation. When an outer object contains an inner object, it merely passes on the QueryInterface to the inner object and treats the inner's methods as if they were the outer's without exposing the inner's interface. When an outer object aggregates an inner object it exposes the inner object's interface as thought it belonged to the outer object. The program control in this is done is handled by the logic inside the QueryInterface() method. DCOM differs from COM in that allows for creating objects distributed across a network, a protocol for invoking that object's methods, and secure access to the object. DCOM provides a wrapper around COM, hence is a backwards compatible extension. DCOM uses Remote Procedural Calls (RPC) using another standard, i.e. Open Software Foundation's Distributed Computing Environment. These RPC are implemented over TCP/IP and named pipes. The protocol which is actually being used is registered just prior to use, as opposed to an initialization time. The reason for this is that if a protocol is not being used, it will not be verified. In order to inform an object that the client is still alive, periodic pinging is used. Hence when the client has died, and no ping has been received (to refresh it) before the expiration time, the server object will perform some clean up tasks (including decrementing its reference count). Since RPC across a network are typically slow (compared to processes residing on the same machine), DCOM sends multiple requests in the same call. For example, in COM, the program performs a QueryInterface, one interface at a time. In DCOM, multiple QueryInterfaces are all clustered into one call. This clustering optimization trick is also used when creating and serialing an object. Since these two operations usually occur together, DCOM allows one method which will perform both operations in one call without waiting for an acknowledgement from the first task before performing the second one. The client has the control to set the computer which will be responsible for the lifetime of the object. That is to say, these object are not created just somewhere where the system resources and access privileges allow for it. Call security is implemented in all four ways, authentication (to prevent false clients from impersonating the true client), authorization (to insure that a client only does what it is authorized to do), data integrity (to insure that data was not tampered with during transit) and data privacy (to insure that only designated sources can read it). The security issues are handled as they are on operating systems. The client gives the server various access privileges to access memory or disk space. References: [Bro96] Brown, N. and Kindel, C., Distributed Component Object Model Protocol -- DCOM/1.0, (work in progress). Microsoft Co., Nov. 1996. [Bro95] Brockschmidt , K., Inside OLE, 2nd ed., Microsoft Press, 1995 [Cha96] Chappell, D., Understanding ActiveX and OLE, Microsoft Press. 1996. [Mic96a] DCOM Technical Overview. Professional Developers Conference Nov. 96, Microsoft Co. 1996. [Mic96b] DCOM, The Distributed Component Object Model. Professional Developers Conference Nov. 96, Microsoft Co. 1996. -- Walter Heger