ASP.Net Application - Application Boundaries
(Page 4 of 8 )
In ASP.NET, as in classic ASP, the boundary of an application is determined primarily by the site or virtual directory defined for that application in IIS. Requests for ASP.NET pages or web services that reside within that site or virtual directory and its subdirectories are treated as part of the application and have access to application-specific items such as the Application and Session intrinsic objects (provided, respectively, by the HttpApplicationState and HttpSessionState classes). They also share resources with other requests to the application.
Request Lifecycle and Handling
When a request comes in from a client for a file within the purview of IIS (i.e., an HTTP request for a file within one of the sites or virtual directories set up in IIS), IIS checks the file extension of the file being requested and then checks its mapping of file types to handler programs to determine which program should be used to process the request. In the case of a classic ASP application, a request for a file with the .asp extension is handled by the asp.dll ISAPI application. The App Mappings tab of the Application Configuration dialog for IIS, shown in Figure 2-4, allows you to view and modify the mappings of file extensions to the executables used to handle those extensions, as well as to determine the HTTP verbs (GET, POST, etc.) that qualify the mapping.
Figure 2-4. The IIS Application Configuration dialog
Requests for files with the .aspx and .asmx extensions and for other ASP.NET-related files are handled by the aspnet_wp.dll ISAPI application. This application, in turn, hands the requests off to the aspnet_wp.exe worker process. Once the request is handed off to the ASP.NET worker process, it handles the rest of the processing by:
- JIT (just in time)-compiling the code in the page (and in any code-behind page identified with thesrcattribute) if no cached compiled version of the requested resource exists.
- Executing the compiled assembly associated with the page or web service, including refreshing any control or page state from a previous request, handling events raised by the request, and rendering the appropriate output to the client.
- Releasing used resources and discarding any transient state information (information not stored in either the Application or Session state collections).
With the exception of the Application state collection, which is available to all clients within a given ASP.NET application, and the Session state collection, which is associated with a specific client by a value either stored in an HTTP cookie on the client or munged into the URL for the application, each individual request to the application is independent from any other, even for that client.
The practical effect is that each request must contain sufficient information to successfully process the request—whether that information comes from form fields passed from the client, information stored in the Application or Session collections, or even information from cookies or a database.
 This chapter is from ASP.NET in a Nutshell, by G. Andrew Duthie. (O'Reilly, 2003, ISBN: 0596005202). Check it out at your favorite bookstore today. Buy this book now.
|
/ 33 
