IDevResource.com COM channel

The Developer's Resource & Community Site

COM	XML	ASP	Java & Misc.	NEW: VS.NET
International	This Week	Forums	Author Central	Find a Job

ATL Server

Author: Richard Grimes
Date Submitted: May 9 2000

Introduction

ATL Server is a set of services that you can use to develop ISAPI DLLs. ATL Server will be available in Visual Studio 7.0 which will be 'released sometime next year'. The following is a description of ATL Server taken from a talk given by Lon Fisher and Walter Sullivan at VCDC, in Santa Clara, Ca (17-19 April 2000) and a keynote given by Craig Symonds and Tony Goodhew also at VCDC.

The need for ATL Server

Currently there are three main ways to develop web applications: CGI, ISAPI and ASP. CGI is based on spawning new executables on the web server machine whereby the input to the CGI program comes via the standard input and the standard output provides the HTML for the web page; environment variables are used to provide access to various HTTP headers sent from the client to allow the CGI executable to adjust its processing. CGI is a solid, if rather dated technology and suffers from the overhead of starting a new executable for each request.

To get around this problem, Microsoft developed ISAPI. These are DLLs that are loaded into Microsoft's IIS (Internet Information Server) to serve page requests. Microsoft provides an API to give access to the request input parameters and HTTP headers, and it also gives access to an output stream that is used to generate the web page. ISAPI DLLs are a high performance, resource-lean alternative to CGI, but suffer in that they are a raw API (with no support for commonly used tasks required by web developers) and they are firmly a C++ technology.

Next, Microsoft developed ASP (Active Server Pages). From an immediate perspective, ASP is simply an ISAPI based scripting engine. The ASP pages can be written in any scripting language that you have installed on your web server machine, but because ASP supports VBScript as a scripting language it brought many hundreds of thousands of VB developers into web application development. Writing a feature rich web application became as simple as writing a few VB scripts. Furthermore, the scripts could use server-side COM components and Microsoft supplied several of these to perform frequently required tasks. Perhaps the most important aspect of ASP is that it was integrated with MTS which meant that threading issues and transactions were automatically handled.

However, ASP had its problems. The most serious of which is that ASP relies on scripting, which means that scripts are parsed at runtime; it is universally recognised that a compiled solution is far better than a scripted version (look at VB, this has produced compiled code since version 4). Furthermore, because it is seen as a simple solution to web development it means that most of the difficult facilities (like thread pooling) have been implemented with a 'one size fits all' solution.

Thus what is required is a compiled solution that comes with a library of facilities. C++ is clearly an excellent choice as the language, but why did Microsoft choose to use ATL? The reason is that ATL is a framework based on C++ templates and this flexible architecture allows developers to extend the library with little effort; the developer can derive new classes at the bottom of the class hierarchy, and through template parameters they can even replace classes midway in the hierarchy. This makes ATL extremely flexible and feature rich.

ATL Server Applications

ATL Server is used to create ISAPI based applications. The architecture is shown in the following picture

The ATL Server Wizard provides the code for the ISAPI DLL and your application's DLL. The ISAPI DLL takes the requests from forms on web pages and dispatches them to code in your application DLL. The SRF files (Service Request File) is essentially a template for the response, it contains placeholders indicated with double braces ({{ and }}) , the names in these placeholders represent sections of code in the application DLL that will be called to return HTML for the response page.

Since you have access to the entire code used in your application - both the ISAPI and your application DLL - it means that you have the ability to take this code and extend it. So if you are not happy with the parser used to process the server-side SRF files, you are perfectly free to extend it, or replace it with your own version.

Handling Requests

ATL Server provides many classes to process requests from a client HTML page. The data comes into the ISAPI as an encoded URL, which is cracked by ATL Server to obtain the data. ATL Server maintains a pool of threads to perform request processing. These are maintained via an NT I/O Completion Port, which queues requests to perform work until a pool thread becomes available. The reason why Microsoft chose this route rather than creating a thread for every request is that unconstrained threading inevitably leads to threads contending for shared resources. This results in all but one of these threads being suspended or waiting on a kernel object. Queuing work via an I/O Completion Port requires fewer threads and less chance of contention. Furthermore, this asynchronous way of handling requests allows the IIS request handler threads to merely handle the request and queue them for processing.

The requests are handled through 'stencil processing', which is the ATL Server term for the code that processes SRF files. These files contain HTML tags and can also include other SRF or HTML files. The sections of the HTML that can have variable data is tagged with the {{}} placeholders which indicates the code that will provide replacement HTML. These placeholders can have parameters derived from the request. The code behind each placeholder is a method in a class implemented in your application DLL.

ATL server uses attributes to associate the code in your C++ files that will be used to provide the HTML for the placeholders in the SRF files. Attributes appear in the C++ files enclosed in square brackets ([ ]) and look a bit like pragmas in that they appear in cpp files seemingly disconnected with the code. Like pragmas, attributes give directions to the compiler, however, unlike pragmas attributes inject code into the final compiled code. In the case of stencil processing these are used to indicate the class that is associated with a particular SRF file and the method that is called to replace the SRF's placeholders.

For example this SRF file:


{{handler MyDll.dll/default}}
<html><body>
Hello {{GetName}}
</body></html>

indicates that the application DLL called MyDll.dll is used to process the SRF file; it has just one placeholder called GetName. The following code represents a class implemented in MyDll.dll:


// MyDll.cpp
[request_handler("default")]
class CMyHandler
{
public:
[tag_name("GetName")]
   DWORD CodeForGetName(IWriteStream* pStm)
   {
      // code in here to return placeholder HTML
   }
};

The SRF file indicates that the default handler should be used in MyDll.dll, which is the CMyHandler class since it is tagged with "default" using the request_handler() attribute. Within CMyHandler is a method that has the tag_name() attribute and so the stencil processor will call this method and pass an IWriteStream pointer that represents the output stream.

As an optimisation, ATL Server allows server-side caching of pages. In typical ATL fashion you are given a variety of caching schemes based on various criteria (size, expiry date etc), in addition you can cache a file, a database source or a blob of data. ATL server also provides session services, that is, it can maintain state for a particular user across HTTP requests. Since HTTP is connectionless this means that a user is given an identifying cookie, which is used by ATL Server to obtain its state. This state can be saved in memory or in a database, you chose which is appropriate for your application.

Utilities

One particularly cool aspect of ATL Server is called 'web proxies'. Essentially, Visual Studio will be provided with a tool that parses a web page and generates a C++ class based on the tags on the site. Thus, if you have a web page with a table of data the parser will allow this data to be accessed by a C++ application. The extra data transfer occurs as XML via SOAP.

In addition ATL Server provides classes to wrap the crypto API so that you can perform secure processing. In addition, it has remote management facilities that will also run over SOAP. To enable you to tune your application ATL Server has classes and attributes that allow you to integrate it with PerfMon (the amount of code that this saves you from writing, should convince you that ATL Server is the only library for web development). Finally, it also has a regular expression handling and classes for CGI and SMTP Mail.

Summary

ATL Server is integrated with Visual Studio 7.0 and allows you to develop fast, efficient web applications. Microsoft claims that this ISAPI based solution, based on ATL, produces code that is only 8% slower than a raw ISAPI solution. But what you gain is significant - you have the flexibility and ease of use of ATL and a whole gamut of facilities that allows you to optimise your application from changing the stencil processing to changing the caching policy. In addition, ATL Server has code for all the common tasks that you will want to do when developing a web application.

Although there is a steeper learning curve associated with ATL than there is with ASP, the benefits are clear. Any effort that you invest in ATL now will pay large dividends when ATL server is released, and I for one will revel in the prospect of a new generation of ATL developers. (And when prompted, will issue a recommendation or two about suitable books to use to learn ATL!)

Links

Further details about ATL Server can be found at:

Details about Web Services can be found at: