Using ISAPI to Access SQL Server

3 4

ISAPI is a set of function calls that are designed to provide Internet application developers with a powerful method of extending the functionality of IIS. ISAPI applications offer outstanding performance and low-level control. In fact, ISAPI applications can outperform other Web applications available for IIS. Also, through ISAPI, the developer has access to the entire array of Win32 API functions.

ISAPI applications are implemented as dynamic-link libraries (DLLs) that come in two flavors: extensions and filters. Because DLLs are typically natively compiled code, they execute much faster than any interpreted code or scripting language. If fast performance and scalability are important features in your Internet application, at the expense of ease of programming and modification, an ISAPI extension or filter is the best option. The next two sections describe ISAPI extensions and filters in detail, and the section that follows explains the limitations of programming and using ISAPI applications.

ISAPI Extensions

ISAPI extensions are implemented as DLLs and are loaded into either the IIS process space or a separate process space. You have this option for each ISAPI extension you install on your Web server. If application stability is an issue, extensions should be loaded into a separate process space to prevent a faulty ISAPI extension from crashing the entire Web server. This is a possibility with experimental or untested ISAPI extensions.

An ISAPI extension is referenced by using the virtual location of the .dll file in the URL. Here is an example: http://www.mydomain.com/SampleISAPI.dll.

When referenced this way, the ISAPI extension is loaded into memory if it has not already been loaded, and the extension handles the entire request, with IIS acting as a simple intermediary to transfer data to and from the client browser. One possible use for this approach would be implementing a custom search engine for an Internet site.

ISAPI Filters

ISAPI filters are also implemented as DLLs, but they are loaded into the IIS process space when the Web server is started and stay in memory until it is shut down. ISAPI filters can be configured to receive any number of filter event notifications, which occur for every Hypertext Transfer Protocol (HTTP) request that IIS processes and for every HTTP response that IIS generates. When an ISAPI filter is loaded, the filter communicates with IIS—via a special structure it passes—which types of events the filter should be notified of. Each time an such an event happens, an event notification is posted to each ISAPI filter that registered interest in that event.

ISAPI filters are quite powerful and can be used to implement compression or encryption, custom authentication, Web traffic logging and analysis, and even server-side scripting engines. You can create an ISAPI filter that examines each Web page set to be delivered to a client, looks for special markup tags, and acts in accordance with those instructions, much like an Active Server Pages (ASP) page does.

The ability to examine and modify every incoming and outgoing data stream makes ISAPI filters highly powerful and flexible. However, if ISAPI filters are used too much, overall site performance and scalability will be drastically diminished. For example, if every single input and output page is filtered, this filter activity may be too great a load for the system to handle, since it does incur overhead. Great care must be taken to ensure work performed by ISAPI filters is minimized. For example, in a custom encryption scheme, the filter should perform encryption, while IIS should read data from and write data to the client. This reduces the number of tasks that the ISAPI filter must carry out.

Limitations of ISAPI

The ISAPI technology can provide the best performance available, but it has a few disadvantages. Developing ISAPI extensions and filters requires more time than developing scripted pages because ISAPI extensions and filters are generally written in C or C++, and for the same reason maintenance difficulties increase as well. A change to an ISAPI extension or filter requires a recompile of the entire application, not just the replacement of a file. And even though ISAPI extensions and filters generally run faster than do their server-side scripting counterparts, they offer no absolute guarantee of perfect scalability. Finally, certain programming abstractions that most server-side scripting developers take for granted, most notably the session object, are surprisingly absent in ISAPI programming. ISAPI programming is performed at a significantly lower level than server-side scripting.