Service Control Manager
The Service Control Manager (SCM) is the component of the COM Library responsible for locating class implementations and running them. The SCM ensures that when a client request is made, the appropriate server is connected and ready to receive the request. The SCM keeps a database of class information based on the system registry that the client caches locally through the COM library.
Computers in a COM environment which support the ability to instantiate objects on behalf of a remote client offer SCM services remotely via an ORPC interface.16. To ensure connectivity, such SCM services reside at the same well-known endpoints as the COM Object Exporter17. on each computer. Note that unlike the Object Exporter service, which is required for a computer to expose COM objects remotely, the exposed SCM service is in fact optional and some computers may not offer it. Clients may receive references to existing objects on such a computer or cause objects to be instantiated on that computer through means besides the services offered by the SCM, such as a through a moniker binding mechanism.
These capabilities are the basis for COM's implementation locator services as outlined in Figure 15-1.
Figure 15-1: COM delegates responsibility of loading and launching servers to the SCM.
When a client makes a request to create an object of a CLSID, the COM Library contacts the local SCM (the one on the same computer) and requests that the appropriate server be located or launched, and a class factory returned to the COM Library. After that, the COM Library, or the client, can ask the class factory to create an object.
The actions taken by the local SCM depend on the type of object server that is registered for the CLSID:
- In-Process The SCM returns the file path of the .DLL containing the object server implementation. The COM library then loads the .DLL and asks it for its class factory interface pointer.
- Local The SCM starts the local executable which registers a class factory on startup. That pointer is then available to COM.
- Remote The local SCM contacts the SCM running on the appropriate remote computer and forwards the request to the remote SCM. The remote SCM launches the server which registers a class factory like the local server with COM on that remote computer. The remote SCM then maintains a connection to that class factory and returns an RPC connection to the local SCM which corresponds to that remote class factory. The local SCM then returns that connection to COM which creates a class factory proxy which will internally forward requests to the remote SCM via the RPC connection and thus on to the remote server.
Note that if the remote SCM determines that the remote server is actually an in-process server, it launches a "surrogate" server that then loads that in-process server. The surrogate does nothing more than pass all requests on through to the loaded .DLL.
ISCMSCM interface is defined as follows (SCMSCM.IDL):
//+-------------------------------------------------------------------------
//
// Microsoft Windows
// Copyright (C) Microsoft Corporation, 1992 - 1995.
//
// File: scmscm.idl
//
// Synopsis: Interface for SCM to SCM communication.
//
// This is the interface that needs to be supported by hosts that allow
// activation of objects. Only one instance of this interface can be exported
// by the host.
//
//--------------------------------------------------------------------------
[
uuid(00000137-0000-0000-C000-000000000046),
version(1.0),
pointer_default(unique)
]
interface ISCMtoSCM
{
HRESULT ActivationRequest(
[in] handle_t hRpc,
[in] ORPCTHIS * orpcthis,
[out] ORPCTHAT * orpcthat,
[in] const GUID * rclsid,
[in, string, unique] WCHAR * pwszObjectName,
[in] DWORD clsctx,
[in] DWORD grfMode,
[in] DWORD dwCount,
[in,unique,size_is(Interfaces)] IID * pIIDs,
[out,size_is(Interfaces)] OBJREF ** ppInterfaces,
[out,size_is(Interfaces)] HRESULT * pResults
);
}