The COM Client/Server Model
Chapter 1 mentioned how COM supports a model of client/server interaction between a user of an object's services, the client, and the implementor of that object and its services, the server. To be more precise, the client is any piece of code (not necessarily an application) that somehow obtains a pointer through which it can access the services of an object and then invokes those services when necessary. The server is some piece of code that implements the object and structures in such a way that the COM Library can match that implementation to a class identifier, or CLSID. The involvement of a class identifier is what differentiates a server from a more general object implementor.
The COM Library uses the CLSID to provide implementation locator services to clients. A client need only tell COM the CLSID it wants and the type of server—in-process, local, or remote—that it allows COM to load or launch. COM, in turn, locates the implementation of that class and establishes a connection between it and the client. This relationship between client, COM, and server is illustrated in Figure 2-2.
Chapter 1 also introduced the idea of location transparency, where clients and servers never need to know how far apart they actually are, that is, whether they are in the same process, different processes, or different computers.
This section now takes a closer look at the mechanisms in COM that make this transparency work as well as the responsibilities of client and server applications.
Figure 2-2. Clients locate and access objects through implementation locator services in COM. COM then connects the client to the object in a server. Compare this with Figure 1-2 in Chapter 1.
COM Objects and Class Identifiers
A COM class is a particular implementation of certain interfaces; the implementation consists of machine code that is executed whenever you interact with an instance of the COM class. COM is designed to allow a class to be used by different applications, including applications written without knowledge of that particular class's existence. Therefore class code exists either in a dynamic linked library (.DLL) or in another application (.EXE). COM specifies a mechanism by which the class code can be used by many different applications.
A COM object is an object that is identified by a unique 128-bit CLSID that associates an object class with a particular .DLL or .EXE in the file system. A CLSID is a GUID itself (like an interface identifier), so no other class, no matter which vendor writes it, has a duplicate CLSID. Servers implementors generally obtain CLSIDs through the CoCreateGUID function in COM, or through a COM-enabled tool that internally calls this function.
The use of unique CLSIDs avoids the possibility of name collisions among classes because CLSIDs are in no way connected to the names used in the underlying implementation. So, for example, two different vendors can write classes which they call StackClass, but each will have a unique CLSID and therefore avoid any possibility of a collision.
Further, no central authoritative and bureaucratic body is needed to allocate or assign CLSIDs. Thus, server implementors across the world can independently develop and deploy their software without fear of accidental collision with software written by others.
On its host system, COM maintains a registration database (or registry) of all the CLSIDs for the servers installed on the system, that is, a mapping between each CLSID and the location of the .DLL or .EXE that houses the server for that CLSID. COM consults this database whenever a client wants to create an instance of a COM class and use its services. That client, however, only needs to know the CLSID which keeps it independent of the specific location of the .DLL or EXE on the particular computer.
If a requested CLSID is not found in the local registration database, various other administratively-controlled algorithms are available by which the implementation is attempted to be located on the network to which the local computer may be attached; these are explained in more detail below.
Given a CLSID, COM invokes a part of itself called the Service Control Manager (SCM4.) which is the system element that locates the code for that CLSID. The code may exist as a .DLL or .EXE on the same computer or on another computer: the SCM isolates most of COM, as well as all applications, from the specific actions necessary to locate code. We'll return a discussion of the SCM in a moment after examining the roles of the client and server applications.