Overview of the ATL Server - XML

The ATL Server is a library of C++ classes that you can also use to develop Web applications and Web services through compiled code. The ATL library was originally developed to provide classes to create light weight and fast COM components. Microsoft has based the ATL Server on the ATL library.

Advantages of the ATL Server

As discussed earlier, ATL Servers can be used to create high-performance Web applications and Web services. In addition, ATL Servers provide other advantages, as discussed in the following list:

  • Allows reusability of code. The ATL Server allows you to create applications by reusing the existing code. This is because the source code of the ATL Server applications is easily available to all users. Therefore, you can create a Web service or Web application by customizing the existing code according to your needs.
  • Allows creation of applications in Visual Studio .NET. Microsoft has based the ATL Server on the .NET platform. Therefore, while you're creating ATL Server applications, you can benefit from the features of the .NET platform, such as CLR, managed code, debugging tools, and so on. In addition, Visual Studio .NET provides you with a template for creating ATL Server applications, as shown in Figure.

    The Template for ATL Server Applications

    The Template for ATL Server Applications

  • Allows use of conditional constructs. While you're creating applications by using the ATL Server, you can use constructs, such as if-else or while to perform conditional execution of code. Doing this helps a block of code be executed based on the value returned by a condition. The syntax for the if-else and while loops is as follows:
  • Allows monitoring performance of applications. You can monitor the performance of ATL Server applications by accessing Windows 2000 Performance Monitor. In addition, the ATL Server library contains classes and attributes that allow you to add performance counters to ATL Server applications. You can then use these counters to monitor the performance of the application.
  • Allows access of the Crypto API library. The Crypto API library is a collection of classes that enables Visual C++ and Visual Basic programmers to include cryptography functionality in their applications. ATL Server applications can access the Crypto API library.
  • Allows data access by using OLE-DB.ATL Server applications can use OLE-DB to access data from a data source. OLE-DB is a specification that allows you to access data by using several data providers. The Visual Studio .NET IDE provides wizards that allow simple access to various data sources.
  • Allows support for storing and retrieving of session state data. ATL Server applications can store cookie values and session state data in a database that ATL provides.

Features of ATL Server Applications

The features of ATL Server applications are discussed in the following list:

  • ATL Servers are used to create dynamic Web pages, which in turn contain the business logic used to display the output to the user in the form of an HTML page. Coding these dynamic pages includes creating the programming logic and the HTML code. In an ATL Server application, the programming logic and the HTML code are stored in different files.
  • ATL Servers are capable of handling multiple client requests simultaneously. To do this, ATL Servers implement internal thread-pools. This implies that when an ATL Server receives a request from a client, it allocates a thread to handle the client request. Therefore, when a client sends in a request, a thread processes the request. The client application is not required to wait until the server is finished processing another request.
  • ATL Server applications can process a client request. Therefore, when a client sends a request to a Web server, the server forwards the request to the ATL Server. The ATL Server then allocates threads and resources to process the request.

Architecture of ATL Server Applications

An ATL Server application consists of the following components:

  • ISAPI extension DLL
  • Web application DLL
  • Server Response File (SRF)

In addition to the previous list, the architecture includes a Web server (which is not a component of the ATL Server application) that receives the request sent by a client application. We will discuss these components in detail now.

Web Server

In ATL Server applications' architecture, the Web server forwards the request that a client application sends to an ATL Server. The ATL Server processes the request. The Web server that can be used in ATL Server applications' architecture is IIS.

ISAPI Extension DLL

The ISAPI extension DLLs contain the desired functionality of a Web service. The ISAPI extension DLLs are of two types:

  • ISAPI filters. When a Web server forwards a request that a client sends to an ATL Server, the ISAPI filters process the request. However, a client application can never explicitly invoke an ISAPI filter.
  • ISAPI applications. ISAPI applications are similar to CGI applications because you can invoke an ISAPI application by using a URL. In addition, ISAPI applications provide the same functionality as CGI applications. However, ISAPI applications provide better performance than CGI applications.

Web Application DLL

When the ATL Server processes a request, the SRF needs to call the Web methods. These Web methods are contained in the classes within the Web application DLLs. In addition, to process a request, the ISAPI application DLL interacts with the Web application DLL. You will learn about SRFs in the following section.


As you know, the ATL Servers create dynamic Web pages. However, the Web pages that you create might also contain some static text. The code for the static text is stored in the Simple Text Files (STFs). In addition, these files contain tags to invoke the request-handling methods from the Web application DLLs. You will learn about the request-handling methods in the section "Default Class."

To understand the content of an SRF, refer to the following sample code:

As you can see, the SRF is an HTML file; therefore, it begins with the <html> tag. Next, the code specifies the name of the Web application DLL, which the SRF calls. In this case, the Web application DLL is application.dll. The name of the Web application DLL is included in the handler tag, which defines the class that contains the request-handling methods that the SRF invokes. Using the Default keyword indicates that the request handling methods are contained in the class marked with the default attribute.

The previous SRF calls request-handling methods from just one Web application DLL. However, you can modify the code to call request-handling methods from multiple Web application DLLs, as shown here:

In the preceding code, CalculatorObj calls the request-handling methods of the Math class in Calculator.dll. To do so, the id property is assigned a value CalculatorObj.

Next, the file contains the head and body elements. Inside the body element, you need to specify the request-handling method that the SRF invokes. The name of the requesthandling method is enclosed in the {{Hello}} placeholder. Therefore, the output of the request-handling method replaces the placeholder at runtime. The ATL Server keeps track of the placeholders and their corresponding request-handling methods. This information is stored within a file called the ATL Server map.

The architecture of ATL Server applications is depicted in Figure.

The Architecture of ATL Server Applications

The Architecture of ATL Server Applications

Default Class

As discussed earlier, to process a request, the SRFs call the request-handling methods that are contained in the classes of a Web application DLL. These classes are derived from a base class, CrequestHandlerT. Data in the ATL Server application architecture is exchanged by using the HTTP protocol. The CrequestHandlerT class contains methods to access the request and response messages that are transferred using HTTP.

A class in a Web application DLL might contain one or more request-handling methods. In addition, each Web application DLL contains a default class. If you do not explicitly relate a request-handling method to an SRF, the file invokes the request-handling methods of the default class. A default class is marked with the Default keyword, as shown in the following code snippet:

After a class is declared as default, the entry for the class is created in the ATL Server map. However, to do this, you first need to create an ATL Server map. You can create an ATL Server map by using the MFC-style macros, as shown in the following code:

Alternatively, you can create ATL Server maps by using the attributes provided by the ATL Server Project Wizard. The following code creates an ATL Server map by using the attributes provided by the ATL Server Project Wizard:

The default class in any Web application DLL contains two methods. These methods are discussed in the following list:

  • OnHello() method. At runtime, the placeholder {{Hello}} is replaced by a request handler method in the Web application DLL. To replace this placeholder, the application calls the OnHello() method. You can add user-defined placeholders to an SRF. Therefore, you need to create methods similar to the OnHello() method that are used to replace these placeholders with the corresponding request-handler methods.
  • ValidateAndExchange()method. When a client application sends a request, ATL Server processes the request and returns the result to the calling application. However, before the result is displayed, the ValidateAndExchange() method is called implicitly to declare the state variables.

Processing of the ATL Server Applications

You have looked at the architecture of the ATL Server applications. Now you will learn about the processing of these applications based on their architecture. The processing of the ATL Server applications primarily involves the interaction between a client application and an ATL Server application. These interactions are explained in the following list:

  1. The interactions between the client application and the ATL Server application start when a client application sends a request to the Web server.
  2. The request that the client application sends can be for an SRF If this is the case, the Web server forwards the request to the ISAPI extension DLLs. When the request is forwarded to the ISAPI extension DLLs, the Web server is free to receive other client requests.
  3. The ISAPI extension DLLs assign a thread from their thread pool to the client request.
  4. The thread processes the client application by loading the Web application DLL mentioned in the SRF.
  5. Note:An ISAPI extension DLL maintains a cache for the SRFs and Web application DLLs. Therefore, when the SRF is processed, the ISAPI extension DLL looks for the required Web application DLL in the DLL cache. If the required DLL is not present, the DLL is loaded from its actual location.

  6. The request-handling methods, as specified in the SRF, are called from the Web application DLL.
  7. The values that the methods return then replace the placeholders in the SRFs.
  8. The processed result is sent back to the requesting application.

The processing of the ATL Server applications is shown in Figure.

The Processing of the ATL Server Applications

The Processing of the ATL Server Applications

Until now, you have learned about the ATL Server. You will now create a sample ATL Server application by using the knowledge you have gained in the previous sections

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

XML Topics