Dynamically Adding Services to the ISAPI Application

So far, we ve discussed services that are built into the Web application ”that is, services that are known by the ISAPI extension class at compile time. This is necessary for the QueryService implementation, which has to know how to map a service GUID to an existing object.

In this section we describe a more flexible way of adding services at runtime, meaning after the Web application (and, most important, the ISAPI DLL) has been loaded and is already receiving requests . We cover a set of functions, namely AddService and RemoveService , that are part of the IIsapiExtension interface, an interface implemented by all the CIsapiExtension derivatives and therefore by all the ISAPI extension classes in ATL Server.

The functions are defined as follows :

 HRESULT AddService(     REFGUID  guidService  ,     REFIID  riid  ,     IUnknown*  punk  ,     HINSTANCE  hInstance  );  HRESULT RemoveService(     REFGUID  guidService  ,     REFIID  riid  ); 

AddService makes a service available through the IServiceProvider:: QueryService method of the CIsapiExtension class. That is, once AddService was invoked for a given service (let s call it DynamicService ), any request handler can use that service through the regular mechanism described in the first section of this chapter (i.e., the QueryService method).

AddService takes as parameters a service GUID (the guidService parameter) and an interface GUID (the riid parameter). These parameters are enough to identify a given service inside the QueryService implementation. The IUnknown pointer is the actual implementation of the service to be returned by QueryService to any request for this specific service.

The last parameter, hInstance , although not used in the QueryService architecture, plays an important role. It s the instance handle of the DLL containing the dynamically added service, and passing it to AddService ensures that the DLL will be kept loaded as long as the service might be in use.

Once a service is no longer in use, it can be unloaded through a call to RemoveService . RemoveService takes as parameters the GUIDs of the service and the interface. A call to RemoveService will make the service unavailable through QueryService and also will decrement the reference count for the instance handle of the DLL containing the service. If this reference count reaches zero, the DLL will soon be unloaded (as soon as the DLL cache maintenance thread gets a chance to do this). As a consequence, you can safely invoke RemoveService from a request handler different from the one that actually added the service ”even from a different application DLL, or from the ISAPI DLL itself.

The Services\DynamicServices sample proves the dynamically added services concept. It assumes (a rather simplistic approach, but good enough for a sample s sake) that all the DLLs in the virtual directory, except the RequestHandler DLL and the ISAPI DLL, are DLLs containing dynamic services. Furthermore, it assumes that sending a simple HTTP request to those DLLs will register the service they contain.

The Web application invokes various arithmetical operations that take two double parameters and then display the result. The actual arithmetical operation code is implemented in a dynamic service. For instance, you would have to load the service contained in the Add.dll to sum two numbers .