Observing the User Experience: A Practitioners Guide to User Research

The question that now arises is what services make sense for the ISAPI DLL. The answer is any service that stores some form of global state and is unlikely to change its functionality often. One good question to ask yourself is Do I need to access/update this information over multiple requests ? If the answer is yes, then an ISAPI service may be the right solution for you.

Good examples of services that meet the criteria for exposing an ISAPI service include the following:

• Caches: Data in a Web application is usually cached based on global information. For example, you may want to cache the pages of your application that are hit most often, the most often used data source connections, or a commonly requested image or file. The information that determines, for example, what file is commonly requested relies on building up information over multiple requests. The file in question must also be returned to the user on various different requests.

• Session state: Session state is typically used to create state information over HTTP (a stateless protocol). You do this by finding a way to uniquely identify a given user (usually via cookies) and then accessing information specific to that user on each of the users requests. Information such as what city the user lives in can be gathered on a single request, but it requires access on every request the user makes after that. Each of these requests can be handled by a different thread requiring a central storage mechanism.

• Logging/Perfmon counters: Usually youll use Perfmon to track information that occurs over your applications lifetime. Similarly, logging is something youll likely do based on information over time, as opposed to a specific request. Examples include counting how many purchases have been made on your site or logging what times of the day your application receives the most requests (and from what countries ). You could even create a mechanism to log application errors and failures (e.g., failures to connect to the database).

Because the ISAPI DLL runs on a single thread, doesnt often get reset, and handles all incoming requests, its capable of meeting all the requirements that these types of services demand. It also makes sense because these services are unlikely to change regularly. Session state is an example of a service thats designed into the application. Caching and logging are good examples of services that are honed during the develop-test cycle and therefore see little change once the application goes into production.

These are also all good reasons for why your ISAPI services should be some of the most carefully scrutinized code in your entire application. Services should be well designed so they provide the functionality required today and so they can be modified with minimal effort to extend that functionality in the future. Regularly called services are likely to be a bottleneck in your application, especially if theyre processor intensive . You should examine the code carefully for security and reliability issues.

Code in your ISAPI DLL also falls into the category of being some of the only code in a Web application that needs to be thread-safe. Because you have multiple worker threads running, and all these threads are capable of calling your service at any time, you need to ensure that locking is carefully used on update commands and that information returned to callers is valid.