Chapter 16: ATL Server

ATL Server is a set of classes that are part of Microsoft's Visual Studio .NET offering and a mechanism for using them in an Internet-related context. The classes are used in developing C++ application projects for the web. When Microsoft decided to produce ASP.NET, it started with ATL Server. Many of the features that ASP.NET Web Forms and Web Services provide are truncated forms of functionality found within the ATL Server classes. In addition to all of the classes that are afforded in a web service, ATL Server offers the developer classes that control memory utilization, session management, resource caching, and thread management of IIS and Hypertext Transfer Protocol (HTTP) requests. ATL Server also offers many new classes that are devoted to file management-classes that were previously unavailable to ISAPI (Internet Server Application Program Interface) developers. ATL Server gives a developer a great deal of command and control in producing web-based solutions, and it provides the ease and convenience of access to many classes oriented toward the production of web-based solutions.

ATL Server could also be viewed as a nice enhancement for ISAPI. In the same way that the Active Template Library (ATL) was produced to help developers interact with the Microsoft Foundation Classes (MFC) and the Windows application programming interface (API), ATL Server was produced to aid the programmer in working with the IIS API or ISAPI. ATL Server allows developers to produce web solutions that are either managed via the .NET framework or unmanaged. ATL Server also provides many intricate options for controlling interactions with IIS that are not available in the managed languages such as Visual C# and Visual Basic. ATL Server is also a great alternative to using ISAPI directly, because many of the classes provided in ATL Server would likely be classes that developers would have to produce themselves if they were working with ISAPI.

ATL Server Architecture Overview

ATL Server associates classes and functions stored in dynamic link libraries (DLLs) with tags placed in text files in such a way that requests to IIS can call the functions within the DLLs and return to the requesting client the text file contents along with the results from the function calls. ATL Server uses ISAPI to establish the calling mechanism between the text files, IIS, and the DLLs using a tag style command system that is enabled by the .NET Framework. The simplest ATL Server solution comprises the following:

• ISAPI extension DLL

• Web Application DLL or Request Handler DLL

• Server Response File (SRF)

• Internet Information Services (IIS)

As requests are sent to IIS for a resource that happens to be an ATL Server source, IIS will associate the call to the ISAPI extension DLL. After IIS hands the request to the ISAPI extension DLL, the requested web application DLL or server response file is opened by the ISAPI extension DLL and processed. If the requested resource is a server response file, the replacement tag indicating a function located in the web application DLL is called and the results are pasted into the server response file at the location of the replacement tag. The combination of the results of the calls placed to the web application DLL and the contents of the server response file are returned to the requester. If the web application DLL is requested directly, the ISAPI DLL makes the appropriate call(s) and returns the result to the browser.

Figure 16-1 provides an architecture overview of ATL Server.

Figure 16-1: Architecture overview of ATL Server

Because an ISAPI extension DLL could reside on the host server in a file location other than within the web root, IIS has to know what to do with the ISAPI extension file and the files associated with the ISAPI extension DLL, such as the server response files and the web application DLL. To illustrate the situation with a common web solution that requires the use of text files to be processed by an ISAPI extension, Active Server Pages (ASP) will be used to contrast the mechanism by which IIS associates files and ISAPI extensions. IIS knows how to process ASP files because all filenames ending with the extension .asp are processed using an ISAPI extension named ASP.DLL. The code within ASP.DLL opens the associated ASP file and interprets the code in the ASP tags. Web forms and web services using the .aspx and .asmx files, respectively, use the same mechanism, except they use the .NET Framework instead of using ASP.DLL to interpret code and tags within the respective files.

ATL Server uses the ISAPI extension DLLs to interpret code embedded in server response file tags and call functions identified with replacement tags in the web application DLL. When a developer is building a web application using ASP files, they would never consider recompiling the ASP.DLL so that it would contain code only useful for processing the ASP functions that they used in their ASP files. The ASP.DLL does not change from ASP application to ASP application-in essence, providing a one size fits all interpreting ISAPI extension DLL. In contrast, however, ATL Server makes a customized interpreter for the solution being built that is optimized for the solution. The customized interpreter is the ISAPI extension DLL that is part of the ATL server project. The developer has the luxury of changing it to meet the needs of their application rather then accepting the default configuration.

To make IIS use the ISAPI extension DLL, the server response files and the application DLL files must be mapped to the respective ISAPI extension DLL. Just as filenames ending in .asp are mapped to the ASP.DLL ISAPI extension DLL or filenames ending in .aspx are mapped to the .NET Framework interpreter named aspnet_isapi.dll, so must the filename extension .srf for server response files and .dll for web application DLLs be mapped to their respective ISAPI extension DLL.

Here's how to map filename extensions to ISAPI extensions:

1. Open the Microsoft Management Console (MMC) snap-in for IIS.

2. Click the Web Site folder icon in the tree to expand the list of web server instances on the server, and then click the web site instance that should be configured to expand the contents within the instance.

3. Open the Properties window for any given web instance, or virtual directory (by right-clicking the web instance or directory), and click the Configuration button found on the Home Directory tab, or the Virtual Directory tab, respectively. The Application Configuration applet shown in Figure 16-2 will open.

4. Associate the file and path location of the desired path location of the ISAPI extension DLL on the host. Once this effort is complete, the instance of IIS should be restarted.

   
   Figure 16-2: Application Configuration applet for mapping files to extensions

The location of the web application DLL used by the server response file is identified in the server response file itself. The web application DLL must reside within the virtual directory root. The server response file contains a handler tag that identifies the relative location of the web application DLL. (See the section 'Server Response Files' for more on handler tags.) When an HTTP request is sent to IIS for the server response files or the web application DLL, IIS will know from the file mapping where to find the ISAPI extension DLL to process and interpret the request.

Because none of the DLLs involved are Component Object Model (COM) DLLs, the mechanism used by IIS and the parts of ATL Server to find the proper DLLs consists of physically locating the DLLs on the host, based on actual file locations. As many of you may recall, a COM object's location on a host is known by associating a unique identification number (CLSID) with the file path of the DLL. This information is stored in the Windows registry where any software requesting the use of the COM object DLL would be able to use the functionality it offered. Although accessing a DLL by physically locating it and loading it may be viewed as somewhat antiquated when contrasted to the post-COM architecture, this solution offers some benefits from a maintenance perspective. The file mappings in IIS are based on filename extensions. The web application DLL is specified using a relative path. Moving files to another server would disrupt a file mapping for IIS to the ISAPI extension DLL, but the other files could be moved as though they were static content, as long as their locations relative to one another are maintained.