The Distributed Component Object Modeling Approach. Abstract: This paper starts with a short explanation of COM and some of the fundamental techniques. DCOM is an extension of COM over a network. The way in which DCOM enhances COM is covered. 1. COM fundamentals Microsoft's COM is a technology for component software development. It is a binary standard which is language independent. DCOM is a distributed extension of COM. Reference counting is a 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 shortened to keep the scope of the discussion brief and manageable. The system registry is a hierarchical database which stores information (the class id) about the objects registered in the computer. It is these class ids which provide a unique identification of the object. Object-oriented programming as described by Booch and implemented in C++ gives rise to long chains of inheritance which complicate large system development. COM is an implementation of Rumbahl's object-oriented paradigm based on a few assumptions. The fundamental assumption is that every object supports at least one interface, the IUnknown interface. All interfaces are classes derived from the base class IUnknown. Each interface supports methods access data and perform operations transparently to the programmer. For example, IUnknown supports three methods, AddRef, Release(), and QueryInterface(). Suppose that pUnk is a pointer to an IUnknown. pUnk->AddRef() increments the reference count. pUnk->Release() decrements the reference count, deleting the object when the reference count reaches zero. pUnk->QueryInterface( IDesired, pDesired) checks 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() to increment the reference count (where pDesired is a pointer to IDesired) and returns the pointer to the caller. An outer object is one that a client sees and holds the interface. An inner object is one that the client does not see and does not have access to its Unknown interface. The inner object is one whose interface is stored in an outer object. The outer COM object reuse an inner 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 object'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 though it belonged to the outer object. The program control in this is handled by the logic inside the QueryInterface() method. In multithreaded applications, the programmer must be careful when using reference counts and delete operations during a context switch . It is possible that one thread holds onto a non-zero reference count on a COM object which has been deleted by another thread. The contemporary way to deal with this problem is to put the AddRef, Release, and QueryInterface methods inside a critical section. 2. DCOM fundamentals DCOM differs from COM in that it 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 it is a backwards compatible extension. DCOM uses Remote Procedural Calls (RPC) using another standard, Open Software Foundation's Distributed Computing Environment. See fig. 1. Fig. 1 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 being registered at initialization time. The reason for this is that if a protocol is not being used, it will not be loaded. 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 an instance of the object and serializing it with data. Since these two operations usually occur together, DCOM allows one method which will perform both operations in one call without waiting for an acknowledgment from the first task before performing the second one. Similarly, when a client pings its server object, he can do it in one call. Moreover, if there are multiple clients sending pings to multiple servers, an optimization is made where the multiple pings going to the same object are consolidated into just one ping. This is to cut down on the use of precious bandwidth used only for pinging. The client has the control to set the computer which will be responsible for the lifetime of the object. That is to say, these objects 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. 3. Conclusion With the strong growth of Microsoft's COM and the network, DCOM provides a binary standard as a solution for working on distributed objects. 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 page 1