How ATL Server Compares with Traditional Solutions

There are three main traditional solutions for creating Web applications. We discuss these solutions in the following sections, as well as ATL Server.

CGI

Common Gateway Interface (CGI) provided one of the first ways to create Web applications, and its still extremely popular, especially for developers on UNIX systems. CGI was designed to work on the UNIX systems that originally powered the Internet, and it creates one process for each request received. Unfortunately, this is very inefficient on Windows systems, as process creation is very expensive. As a result, CGI isnt an ideal solution for Windows systems.

ASP

Active Server Pages (ASP) is a more recent innovation designed to simplify Web application development on Windows. ASP is very popular for many of todays Web applications because it offers fast application development. Unfortunately, with ASP it can be difficult to separate Web logic and Web page design. Also, because ASP was designed to greatly simplify Web development, it suffers from some problems related to performance, control, and flexibility.

ISAPI

ISAPI is the underlying application programming interface (API) for Web development on Windows. Its therefore very powerful and controllable, and it has excellent performance characteristics. The problem with targeting ISAPI directly is that it doesnt provide any functionality for creating real Web applications, so developers end up spending a lot of time trying to get useful access to information such as cookies or form/query data, not to mention the framework code required to get an application running efficiently (thread pool, cache, and so on).

Other Solutions

More recently, JavaServer Pages (JSP) and ASP.NET were developed to help developers in the ASP segment who are looking for better performance, more control, and better application architecture than ASP provides. These solutions, however, lack the benefits of raw ISAPI. They still take away control and flexibility from the developer and suffer from many performance problems, much like their predecessor.

Another issue that arises with these solutions is their reliance on script. This reliance can create Internet Protocol (IP) issues for developers. For example, if a third-party site is running your application and some of your application logic is in script, then your IP is not as well protected as it is in a compiled image. Outside of IP issues, a reliance on scripting languages generally leads to a maintenance nightmare for all but one-off projects.

ATL Server

ATL Server provides a lot of common Web application functionality on top of ISAPI, without hiding the underlying ISAPI model and without costing the developer performance, control, or flexibility.

Among the functionality provided is an I/O completion portbased asynchronous thread pool. The thread pool provided in IIS is static (not strictly true, but you can't rely on it to grow and shrink to handle the application's requirements). When all the threads become busy, your Web server will stop accepting HTTP requests. To your customers (and in many ways to you), this is the same as your Web server going down. Therefore the IIS team recommends that developers create their own thread pool. This thread pool should take requests off the fixed- sized IIS thread pool to ensure that the IIS thread pool never becomes full.

Another piece of functionality is caching, which gets turned on by default and is used to make your application more efficient out of the box. Other examples of functionality that ATL Server provides are output page caching (for pages that have already been rendered), session state (with custom backing or built-in support for memory and database backup), and PerfMon counters.

The ATL ideal of lightweight, separate classes means that you can easily add ATL Server use to an existing ISAPI application or revert parts of an ATL Server application to straight ISAPI without requiring rewriting of any part of the application that isnt being converted. Therefore, if you dont like the ATL Server thread pool, caching, or session state, you can easily implement your own and slot it right in.

The ATL goal of flexibility in design is also very important. The classes are all stand-alone in functionality, and for the most part they arent application specific. This means that you can use the caches in a general application (e.g., the memory cache for holding a lookup table) or you can use the thread pool to handle DirectPlay events (as some of the ATL Server developers did). Good use of templates means that it becomes easy to use classes in flexible ways. For example, with ATL Server Web services you can templatize on one of the HTTP stacks provided (WinINet, Custom, or MSXML) or create your own. Another great example of flexibility is the ability to use transports other than HTTP for your XML Web services you can easily change to using TCP/IP or MSMQ as your transport mechanism.

The ATL goal of high performance is also very critical in the design of ATL Server. By designing for performance and testing performance (at both a class level and an application level), from the very start the library is well designed for handling the most demanding performance requirements.