Conclusion

The ISAPI services provide a way of sharing data and functionality between different request handlers. The data preserved in these services will be available for the lifetime of the Web application or until the service is removed (for dynamic services).

If some simple stateless functionality is to be shared between request handlers, a global ISAPI service is the easiest design choice. If data has to be shared between request handlers, a global ISAPI service should again be the design of choice, but the access to data has to be synchronized using NT synchronization primitives, like Interlocked functions, or critical section or mutex objects. ATL provides handy wrappers for most of the synchronization objects.

If some functionality that relies on state information has to be shared by multiple request handlers (as long as data is not to be shared), then a per-thread service design will meet the requirements. This is a useful choice also for functionalities that can benefit (usually in performance) from removing the thread synchronization code. They wont be thread-safe, but they dont need to be as theyll be visible only from the current thread.

Plug-in kind of functionalities can be exposed as dynamic ISAPI services. This design choice provides a reliable mechanism for swapping objects that implement the same interface (the service interface) without worrying about the lifetime of the objects, as the ISAPI framework takes care of this.

A major task that every development team must face is debugging its Web application. In the next chapter we take a closer look at debugging ATL Server applications and present some useful tips and tricks.