Programming Microsoft ASP.NET 4 - Dino Esposito [17]
Let’s step back and review the key changes in the IIS architecture and the architecture’s interaction with ASP.NET applications.
The Standalone ASP.NET Worker Process
Originally, the ASP.NET and IIS teams started together, but at some point the respective deadlines and needs created a fork in the road. So ASP.NET 1.0 couldn’t rely on the planned support from IIS and had to ship its own worker process. Figure 2-1 shows the runtime architecture as of Windows 2000 and IIS 5.0.
Figure 2-1. ASP.NET requests processed by a separate worker process outside IIS.
Captured by the IIS executable listening on port 80, an HTTP request was mapped to an IIS extension (named aspnet_isapi.dll) and then forwarded by this component to the ASP.NET worker process via a named pipe. As a result, the request had to go through a double-stage pipeline: the IIS pipeline first and the ASP.NET runtime pipeline next. The ASP.NET developer had little control over preliminary steps (including authentication) performed at the IIS gate and could gain control over the request only after the request had been assigned to the ASP.NET worker process. The ASP.NET worker process was responsible for loading an instance of the Common Language Runtime (CLR) in process and triggering the familiar request life cycle, including application startup, forms authentication, state management, output caching, page compilation, and so forth.
The IIS Native Worker Process
With Windows Server 2003 and IIS 6.0, Microsoft redesigned the architecture of the Web server to achieve more isolation between applications. IIS 6.0 comes with a predefined executable that serves as the worker process for a bunch of installed applications sharing the same application pool. Application pools are an abstraction you use to group multiple Web applications under the same instance of an IIS native worker process, named w3wp.exe.
IIS 6.0 incorporates a new HTTP protocol stack (http.sys) running in kernel mode that captures HTTP requests and forwards them to the worker process. The worker processes use the protocol stack to receive requests and send responses. (See Figure 2-2.)
Figure 2-2. The worker process isolation mode of IIS 6.0.
An ad hoc service—the WWW publishing service—connects client requests with hosted sites and applications. The WWW service knows how to deal with static requests (for example, images and HTML pages), as well as ASP and ASP.NET requests. For ASP.NET requests, the WWW service forwards the request to the worker process handling the application pool where the target application is hosted.
The IIS worker process loads the aspnet_isapi.dll—a classic IIS extension module—and lets it deal with the CLR and the default ASP.NET request life cycle.
A Shared Pipeline of Components
Before IIS 7, you had essentially two distinct runtime environments: one within the IIS process and one within the application pool of any hosted ASP.NET application. The two runtime environments had different capabilities and programming models. Only resources mapped to the ASP.NET ISAPI extension were subjected to the ASP.NET runtime environment; all the others were processed within the simpler IIS machinery.
With IIS 7, instead, you get a new IIS runtime environment nearly identical to that of ASP.NET. When this runtime environment is enabled, ASP.NET requests are authenticated and preprocessed at the IIS level and use the classic managed ASP.NET runtime environment (the environment centered on the managed HttpRuntime object) only to produce the response. Figure 2-3 shows the model that basically takes the ASP.NET pipeline out of the CLR closed environment and expands it at the IIS level.
Figure 2-3. The unified architecture of IIS 7 that offers an integrated pipeline for processing HTTP requests.
An incoming request is still captured by the kernel-level HTTP stack and queued to the target application pool via the WWW service. The difference now