IIS 6.0 is Microsoft’s newest web server environment and ships as a native part of the Windows 2003 Server operating system. IIS 6.0 takes the essence of the ASP.NET innovations and rearchitects them in a wider and more general context. Specific features of ASP.NET (i.e., page output caching and process recycling) become features of the whole web server infrastructure. With IIS 6.0, those features are available to all web applications including, but not limited to, ASP.NET applications. In particular, ASP.NET 1.1 is designed to detect the current version of IIS and adjust its way of working.
The way in which ASP.NET works with respect to the host environment is said to be the ASP.NET Process Model. It comprises a sequence of actions—the process model—that altogether define how a request is serviced. As of ASP.NET 1.1, there are two possible models—the default model and the IIS6 model.
The default model (sometimes referred to as the IIS5 model) is the only one supported by ASP.NET 1.0 and the only that is conceivable when the web server is not IIS 6.0. When the ASP.NET 1.1 framework is installed under IIS 6.0, you can choose between the two. The default model enabled under IIS 6.0 is still the “old” IIS5 process model. You must explicitly enable the new model in the IIS configuration metabase. Let’s briefly review the main differences between the IIS5 and IIS6 process models.
In the default process model, the request is caught by the aspnet_isapi module and passed along to the worker process—the aspnet_wp.exe unmanaged executable. The worker process hosts the CLR and passes any information it holds about the request to the HTTP pipeline. The HTTP pipeline is a pipeline of managed objects that transform the request from an HTTP payload to HTML text for the browser. The aspnet_isapi module and the worker process implement advanced features such as process recycling, page output caching, memory monitoring, and thread pooling that are key to the health of the web server environment. The worker process and the ISAPI module communicate through named pipes and a single instance of the worker process serve all web applications. Each web application is run in a distinct AppDomain within the worker process. By default, the worker process runs under a weak account named “ASPNET.”
IIS 6.0 implements its HTTP listener as a kernel-level module. As a result, all incoming requests, including ASPX requests, are first managed by such a driver (http.sys) in kernel mode. The http.sys driver listens for requests and posts them to the request queue of the appropriate application pool. An application pool is a blanket term that identifies a worker process and a virtual directory. A module, called the “Web Administration Service” (WAS), reads from the IIS metabase and instructs the http.sys driver to create as many request queues as there are application pools registered in the metabase.
Each application pool is managed by a distinct instance of the same worker process-w3wp.exe. As a result, you can have ASP and ASPX applications managed by the same worker process. Sound weird? Well, not really.
The worker process looks up the URL of the request and loads a specific ISAPI extension. For example, asp.dll for ASP applications and aspnet_isapi.dll for ASP.NET applications. When working under the IIS6 process model, the aspnet_isapi is responsible for loading the CLR itself and starting the HTTP pipeline. All the settings in the <processModel> section of the machine.config file are ignored and the same settings are imported in the IIS metabase and read from there. (All the other settings are, instead, regularly read from the .config file.) The w3wp.exe worker process runs under a weak account, functionally similar to ASPNET but named "NetworkService.
For a time, Microsoft developed IIS 6.0 and ASP.NET side by side. Then, ASP.NET had to ship before the newest version of IIS and some of the ideas commonly developed have been coded in a specific worker process. In light of this, it's neither coincidental nor surprising that IIS 6.0 and ASP.NET share several concepts and architectural features.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant based in Rome, Italy. Dino is a contributing editor to Windows Developer Network and MSDN Magazine, and the author of several books for Microsoft Press including Building Web Solutions with ASP.NET and ADO.NET and Applied XML Programming for .NET. Contact Dino at [email protected].
