ATL Server and ASP.net

Asp.net|server Download the code for this article: ASPColumn0311.exe (534KB)
*
Content of this page
What the hell is asp.net? What the hell is asp.net?
How is ATL Server different? How is ATL Server different?
ATL Server and ASP. NET ATL Server and ASP.
aspx file with SRF aspx file and SRF
Intrinsic object "intrinsic" object
Manage UI elements Manage UI elements
Session State Session State
Summary Summary

The task of the WEB server is to accept incoming HTTP requests and return some information that is useful to callers (whether the caller is a person or a Web service machine). Windows contains mature structure-iis that handle requests and their associated extensions. However, it is tedious and error-prone to design IIS from scratch. A better way to manage HTTP requests is to manage them using a framework located at the top of IIS. This month I'll compare two major techniques for creating a Windows Web application: asp.net and ATL Server. Each of these frameworks has some specific advantages and disadvantages. In this section, I'll focus on how to manage the web-based UI with asp.net. Next time I'll focus on how to use these two frameworks to build Web services and other features.
What the hell is asp.net?

asp.net is a class library designed to handle HTTP requests. In addition to the class library, ASP.net also contains several IIS components that manage requests. These components include the name Aspnet_isapi. The ISAPI DLL for the DLL and the name aspnet_wp. EXE's worker process. asp.net also installs new mappings in IIS to redirect file requests for ASPX, ASCX, ASHX, and ASMX to Aspnet_isapi. Dll. So far, Aspnet_isapi. The DLL directs the request to aspnet_wp. EXE, in which asp.net loads the required classes to service the request.

Centered on a managed class named HttpContext, ASP.net has a convenient object model. If you have ever written a standard ISAPI DLL, you must understand the information contained in EXTENSION_CONTROL_BLOCK and passed to the ISAPI DLL's HttpExtensionProc. When managing requests, the ISAPI DLL checks the structure for information such as environment IDs, query strings, and functions that read and write to clients. asp.net wraps all of this information in the HttpContext class. ASP.net also includes the basic class structure for managing web-based UIs (through System.Web.UI.Page classes) and managing Web services through System.Web.Services.WebService classes and [WebMethod] properties.

ASP.net is Object oriented. Each request passed through the ASP.net application is handled by a class named IHttpHandler, which implements the interface. This creates a highly scalable architecture. You can choose to take advantage of the ASP.net page architecture or WEB service architecture, or you can write processing logic from scratch. Figure 1 shows the path taken by the ASP.net request.
Miissues0311aspcolumnfig01

Figure 1 The life cycle of the asp.net request

The ASP.net ui-processing architecture is centered on the Web.UI.Page class (represented by an ASPX file). ASPX files can include neat HTML code and server-side controls. When ASP.net encounters a server-side control (through the "Runat=server" property), it instantiates a class that represents the control (for example, a Button and a ListBox control). Essentially, the ASP.net page acts as a tree of these server-side controls (the text and markup on the page are packaged as LiteralControl classes)-The rest are server-side controls. When the page itself is requested to be rendered, the page simply traverses the control tree, and each node on the "tell" tree renders itself. ATL Server operates in a somewhat different way.
Back to top of page return page
How is ATL Server different?

ATL Server is a C + + Template Library that is used to create ISAPI DLLs. When IIS is first created, the developer must write the ISAPI extension from scratch or as a starting point from MFC's ISAPI DLL classes. Generating an ISAPI DLL from the original C + + or MFC code requires human-written extension code. For example, the MFC ISAPI does not provide a form-based architecture for developers. Any HTML markup that ends at the client must be sent manually.

ATL Server combines a form-based approach with running speed and the flexibility of C + +. The Web site built with ATL server consists of three basic components: the server response file (SRF), the application DLL, and the required ISAPI extensions. SRF is a new type of file that ATL Server installs in IIS. The SRF map points IIS to the application's ISAPI DLL, which in turn handles points to one or more application DLLs. SRF includes a special new markup syntax that essentially calls an entry point in an application DLL. Figure 2 shows the path that is used when the request is passed through the system based on ATL Server.
Miissues0311aspcolumnfig02

Figure 2 Path to the request based on ATL Server

ATL Server applications consist of many DLLs (ISAPI extensions and application extensions) and HTML build templates called SRF (previously mentioned). This architecture clearly separates application representations from application logic. The representation of a Web page is defined by a SRF that contains HTML and special tags. These tags invoke the ATL Server application DLL.

Because the target platform for most WEB applications is Windows, the ATL Server application is built on top of the ISAPI DLL. The ATL Server project contains a single ISAPI extension DLL that can handle rough requests. The ATL Server application also contains one or more application DLLs for a variety of precise request processing. The class that processes the request is derived from CRequestHandlerT and also contains your own code that handles the markup in SRF.

These handler classes contain dictionaries that associate the request handler class with the request handler DLL and associate the substitution method with the SRF tag. In addition to the substitution of dictionaries, CRequestHandlerT includes methods and member variables that access standard WEB application elements, such as form variables, cookies, request flows, and response flows.

When the browser finds the. SRF URL through HTTP, IIS knows to open the site with the ISAPI DLL for the ATL Server application. The ATL Server application then opens the SRF and loads the application's DLLs if they have not yet been loaded. The application then passes the request to the default request handler class, which analyzes the SRF to find tags with special markings. Each time a token occurs in SRF, the application invokes an alternate method that exists in one of the handler classes in an application DLL. This workaround dynamically generates the output of the browser. Figure 2 shows the path of the request through the ATL Server application.
Back to top of page return page
ATL Server and ASP. NET

Although both ATL Server and ASP.net are based on the ISAPI architecture, they are significantly different from processing requests. To illustrate these differences, let's look at an example of an application that collects personal names and his or her development preferences. I'll explain how to develop the user interface and how to use session state. In the next installment of this column, I'll look at some of the other features, such as caching and browser capabilities, and how WEB services work on each of these frameworks. Figure 3 compares some of the features of the two frameworks.
Back to top of page return page
ASPX files and SRF

asp.net and ATL Server introduced a new file name extension for the ISAPI architecture. The file types introduced by asp.net are ASPX, ASMX, ASCX, and ASHX, as well as some other types. In the ASP.net framework, each of these file types has a corresponding managed class. For an ASPX file, such a class is System.Web.UI.Page. The page class is responsible for rendering a UI-based Web page. Figure 4 shows a simple ASPX file.

The main thing to note about ASPX files is the inheritance directives near the top of the page and the "Runat=server" property of buttons, labels, and drop-down list tags. These tokens represent the corresponding classes in the code-behind files in Visual Studio for server-side controls.

By contrast, SRF contains the most standard and common HTML tags. ATL server does not have a server-side component architecture. However, it does introduce the concept of a server response tag. These special tags are represented by double curly braces ({{}}). When the ATL server request architecture encounters a server response token, it expects to find a corresponding handler function in the application Dllöð. Figure 5 shows a simple SRF that shows a user interface that is roughly the same as the user interface in the Figure 4 ASPX example.

The most important thing to note in this document is a special tag enclosed in double braces. For example, near the top of the SRF, you see the handler token for the specified application's default handler ({{handler.}}). This tells the ATL Server application which DLL to load to find the function that is called by the response token. Other response tokens indicate the entry point in the application DLL.
Back to top of page return page
"Intrinsic" object

Both asp.net and ATL servers contain similar intrinsic request and response objects, which are represented by the HttpRequest and HttpResponse classes in the asp.net of the typical aspò»ñù¡£. In ATL Server, they are represented by CHttpRequest and CHttpResponse classes. In each framework, they are used in the same way. The request object encapsulates items such as request parameters and request URLs. The response object contains the ability to output text to the client. For example, to insert "Hello world" into an output stream that is based on an asp.net request, you only need to call Response.Write, as follows:

protected void HelloWorld ()
{
Response.Write ("Hello World");
}

To output "Hello world" to clients based on an ATL Server application, use the CHttpResponse object as follows:

[Tag_name (name= "Hello")]
Http_code OnHello (void) {
m_HttpResponse << "Hello world!";
return http_success;
}

Note how you can invoke the OnHello function by using the server response tag in Figure 5. (This tag looks like this: Hello.) ）
Back to top of page return page
Managing UI Elements

Each framework takes a different approach to managing UI elements. As previously mentioned, UI support in ASP.net revolves around the server-side control model. The Representation code (ASPX file) declares a server-side element on a Web page using the "Runat=server" attribute. It is easy to programmatically access a control as long as the corresponding class is declared in the code-behind class. For example, the code in Figure 4 illustrates several server-side control elements (for example, submit buttons, text box elements, and Drop-down lists). Code-behind pages declare Button, TextBox, and DropDownList classes as members of the page so that they can be programmed to use. To find the data in the Textboxname element, you only need to access the Text property, as follows:

String s = this. Textboxname.text;

asp.net server-side controls also have the advantage of automatically tracking view state. UI elements, such as Drop-down list boxes and radio buttons, maintain a consistent state when the browser is accessing the server in a round trip. For example, the last item selected in the Drop-down list box is the item that is displayed. There is no need to write any special code to ensure that the control behaves correctly.

ATL Server does not have such a control model. The UI can only be managed through the server response tag. To populate the Drop-down list, the ATL server example uses a server response function to populate it (see the {{showfeatureselection}} tag in Figure 5). Figure 6 illustrates how the server response function inserts items into the Drop-down list.

ATL Server differs from the ASP.net method in that it does not track the state of the view. To keep the Drop-down list consistent, you need the code shown in Figure 6. The code examines the parameters passed in the query string and finds out which item was selected. The rendering code ensures that the item selected by the user contains the selected attribute in the option tag.
Back to top of page return page
Session state

It is convenient to manage session state in ASP.net. The ASP.net worker process handles low-level detail issues. When a new client initiates a session, ASP.net automatically assigns a newly-addressed object-A dictionary that contains name-value pairs. The System.Web.UI.Page class contains a reference to the current customer session information. Access to the client's state requires only the indexer to access the session dictionary. Figure 7 shows the code needed to create a new session variable and use ASP.net to access them later.

Managing session state is slightly more complex in ATL Server. Although using the ATL Server Wizard to build an ISAPI DLL includes a session manager, you still need to write code to create and Access session objects. The code in Figure 8 shows how to create and access session variables in ATL Server.

The ATL Server Wizard generates the ValidateAndExchange function. This method is called at the beginning of each request, just as the Init as contained in the ASP.net Page class is the same as the Load event. ValidateAndExchange gets an interface (via QueryService) for the session manager of the ISAPI DLL. If there is no session cookie in the header, the method creates a new session and adds a conversation cookie to the response. If this is the continuation of an existing session, the code uses session information to populate the name and age variables. Note that the session variable is represented by a COM variable.
Back to top of page return page
Summary

This month, I quickly scanned the asp.net and ATL servers. These frameworks represent the most advanced methods currently used to handle HTTP requests on Windows platforms. Each framework is built on a well-tested ISAPI architecture that has emerged almost a decade ago. asp.net and ATL Server map their file name extensions to specific DLLs. The ASP.net DLL is aspnet_isapi. Dll. The ATL Server DLL is generated by ATL Server, but for the most part it is a repeatable code. One of the advantages of ATL Server In this context is that it can actually refer to (and change) the original ISAPI request processing code for a particular application.

Although you can use any of these frameworks to write broadly equivalent applications, there is a tradeoff between standard issues. Typically, using a managed language and asp.net framework to develop asp.net applications is straightforward. However, you are subject to the framework (although ASP.net has eased flexibility with its scalability). On the other hand, as long as the ATL Server application passes the test of IIS, it contains a high performance recommendation for most dllµ÷óã-. ATL Server applications are written in C + +, so you have a lot of control and the necessary responsibilities.

Next time I'll compare asp.net with the other features of ATL Server, including buffering status, security, and Web services.
Figure 3 to Figure 8 Link: http://www.msdn.microsoft.com/msdnmag/issues/03/11/ASPColumn/default.aspx?fig=true#fig3

George Shepherd specializes in the development of. NET Framework software. He is the author of programming with Microsoft Visual C++.net (Microsoft Press, 2002), and is also co-author of Applied. NET (addison-wesley,2001). He taught developmentor at the seminar, and he was an architect who contributed to the syncfusion. NET tools.