2.2 Application Structure and Boundaries

Although it is convenient, for the sake of discussing application types, to divide ASP.NET applications into web applications and web services, the truth is that from a practical standpoint, ASP.NET applications can be comprised of both types; an ASP.NET Web Application may contain .asmx files that implement web services, and a web service application may contain .aspx files that implement user interfaces for web services or functionality contained in .NET assemblies. Thus, from the standpoint of application structure, ASP.NET Web Applications and ASP.NET Web Services are quite similar.

2.2.1 Application Structure

The structure of an ASP.NET application consists of a site or virtual directory in IIS and at least one ASP.NET page or web service. Optionally, each ASP.NET application may have:

• A single global.asax file, located in the root of the application.

• One or more web.config files. There can be only one web.config file per directory or subdirectory in the application.

• One or more User Control files bearing the .ascx extension.

• One or more class files, either for ASP.NET code-behinds or for assemblies used in your application.

• A /bin directory containing .NET assemblies you wish to use in your application. Assemblies in the /bin directory are automatically made available to your application.

• ASP.NET Web Applications created in Visual Studio .NET contain Solution and Project-related files (.sln, .suo, .vbproj, and .csproj, for example), and an optional default cascading style sheets file (.css). These applications may also optionally contain resource files (.resx), dataset and/or XML schema definitions (.xsd), and other file types.

• Any other type of file (.htm, .asp, images, etc.) that you'd expect a classic web application to contain. Note, however, that .asp pages within an ASP.NET application will not share an Application and Session state with the ASP.NET application.

Figure 2-3 provides a visual explanation of how an ASP.NET application is structured.

Figure 2-3. Structure of an ASP.NET application

2.2.2 Application Boundaries

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.

2.2.3 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 the src attribute) 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.