Tasks required for COM Servers

The relationship of COM servers, class factories, COM objects, and interfaces can be viewed as a containment relationship. A server contains one class factory for each COM class (i.e., type of COM object) that it implements. Each instance of a COM object contains one or more COM interfaces. And each COM interface contains three or more COM methods (i.e., IUnknown plus other methods). The following diagram depicts these relationships.

The Component Services Explorer gives you visual feedback when a server applicat ion is running: the application icon and the active components will be spinning. Library applications will have no visual feedback when they are running in a client process, even if that process is another COM+ server application. Expand the COM+ Applications folder and select the Status View on the Component Services Explorer toolbar (the button at the far right end of the toolbar;) .
The Component Services Explorer will display the process ID of the running server applications. Record the process ID for the Hello COM+ application. Next, bring up Windows Task Manager and locate the process with a matching ID. Its image name will be dllhost .exe.
The first CoCreateInstance( ) request for a component in a server application creates a new dllhost process, to host components from that application only. Subsequent CoCreateInstance( ) calls to objects from the same application create new objects in the existing dllhost instance. Unlike classic COM, there is no way to create each object in its own process. No COM+ equivalent to the COM call you make to

CoRegisterClassObject (...REGCLS_SINGLEUSE...) 

exists.

All COM servers must:

1. Register all COM classes in the system registry (i.e., register the CLSID andInProcServer32 under
   HKEY_CLASSES_ROOT\clsid\{clsid-xxx }_.
2. Unregister all of its COM classes.
3. Create class objects, usually as class factories, and provide a pointer to the class object's object creation interface, usually IClassFactory, to the COM runtime system.
4. Keep track of reference counts on instances of its COM objects and server lock counts. A server's execution can be terminated if none of its COM objects are in use and the lock counts are 0.

How COM servers perform required tasks depends on the type of COM server. COM supports several different types of servers: in-process, local, remote, NT-service based, and surrogate DLL servers.
An in-process COM server resides in a dynamic link library (DLL). In-process servers have all the properties of Win32 DLLs. They are run in the same address space as the COM client. A local server resides in its own executable (i.e. *.exe file). It runs in a different process than the COM client. A remote server runs on a different machine than the client.
An NT-service-based server runs as an NT service. A surrogate DLL server is an in-process server that is loaded and run by a "surrogate" process. From the client's perspective, it appears to be a local or remote server.
This course will focus on in-process servers. The following lessons will discuss how an in-process server registers and unregisters its COM objects, creates and manages class factories, and supports unloading.