Windows Process Activation Service in IIS 7.0

In this excerpt from Introducing Windows Server 2008, read about WPAS, which manages application pool configuration and worker processes.

Introducing Windows Server 2008
By Mitch Tulloch

Get a jump on evaluating Windows Server 2008 -- with technical insights from Windows Server team. This practical introduction delivers real-world implementation scenarios and pragmatic advice for administering Windows Server in the enterprise.

To get an idea of how "minimal" IIS 7.0 is out of the box, when you add the Web Server (IIS) role using the defaults already selected for this role, only the following role services and the specified subcomponents (modules) actually get installed:

  • Common HTTP
    • Static Content
    • Default Document
    • Directory Browsing
    • HTTP Errors
  • Health and Diagnostics
    • HTTP Logging
    • Request Monitor
  • Security
    • Request Filtering
  • Performance
    • Static Content Compression
  • Management Tools
    • IIS Management Console

Look under the Security role service in the preceding list -- no Basic authentication, right? Remember that for later.

Windows Process Activation Service

When you add the Web Server (IIS) role to your Windows Server 2008 server, you're also required to install a feature called Windows Process Activation Service (WPAS), together with its three subfeatures: Process Model, .NET Environment and Configuration APIs. WPAS manages application pools and worker processes running on your machine for both HTTP and non-HTTP requests. For example, when a protocol listener picks up a client request, WPAS determines whether a worker process that can service the request is already running within the application pool. If this is the case, the listener adapter passes the request to the worker process for processing. If there isn't a worker process running in the pool, WPAS starts a new worker process and the listener adapter passes the request to it for processing.

Windows Server 2008 security extras

Modular architecture in IIS 7.0 aids Web server security

Windows Server 2008 (Longhorn) preview: Important new features

WPAS also functions as a configuration manager that reads and maintains configuration information for sites, applications and application pools running on IIS, as well as for the global configuration, which includes HTTP central logging and so on. In addition, WPAS maintains the life cycle of worker processes by starting them (for example, when requests come in), stopping them (when they idle out), monitoring their health, and recycling them when needed.

What new functionality does WPAS provide that wasn't there in previous IIS platforms? Let's hear from one of our experts:

From the Experts: Windows Process Activation Service (WPAS)

Windows Process Activation Service, also referred to as WPAS, is a new component in IIS 7.0 that manages application pool configuration and worker processes instead of the WWW process. This enables the same configuration for both HTTP and non-HTTP sites to be used. Thanks to this separation (and in combination with the new modular architecture of IIS 7.0), you can even host non-HTTP sites without the WWW Service even being installed in the first place.

What scenarios does this enable? Because WPAS is not specific to HTTP sites, you can use WPAS to host non-HTTP sites as well. But what do we mean by "non-HTTP sites"? Well, simply put, WPAS can be used to host sites built on technologies such as Windows Communication Foundation, for example. If you are using WCF with WPAS, are you limited to listening over HTTP? Not at all. In fact, that is the beauty and power of WPAS. You can be hosting a WCF service within WPAS that is using netTcpBinding, netMsmqBinding, and so on. As an extension to this, because WPAS supports both HTTP and non-HTTP sites, you can be hosting a service that exposes itself over both HTTP and NET.TCP as well.
Jason Olson - Technical Evangelist, Windows Server 2008 Developer & Platform Evangelism

Request processing pipeline

The modular architecture of IIS 7.0 is also important to the way requests are processed by IIS 7.0. By way of comparison, on the previous platform (IIS 6.0), you basically had a monolithic request-processing pipeline that could have its functionality extended through ISAPI. In IIS 7.0, however, you have all these different modules that can be plugged into your generic request pipeline to modify how requests are processed by your server. In addition, you have a public module API that you can use to extend your pipeline by adding your own custom modules.

Another way of comparing the new IIS 7.0 architecture with the old one in IIS 6.0 is by comparing how ASP.NET is integrated with IIS on these two platforms. In IIS 6.0, you basically have IIS and ASP.NET and never the twain shall meet -- unless it happens via ISAPI. For example, suppose a request comes in that needs to be processed by ASP.NET. IIS hands it off to ASP.NET via the ISAPI extension aspnet_isapi.dll, which processes the request and returns it to IIS. This mechanism involves feature duplication and is not very efficient. By contrast, IIS 7.0 offers two modes of handling such requests. First, you can use the "classic" mode, where ASP.NET runs as ISAPI just like in IIS 6.0, which is useful for compatibility reasons. And, second, you can use the new "integrated" mode, where ASP.NET and IIS are part of the same request-processing pipeline -- that is, your .NET modules and handlers plug directly into the generic request-processing pipeline, which is much more efficient than the old model (and provides a far easier extensibility point to program to -- ISAPI is so '90s).

Excerpted from "Introducing Windows Server 2008" by Mitch Tulloch with the Microsoft Windows Server Team . Reprinted by permission of Microsoft Press. All rights reserved. For more information, go to http://www.microsoft.com/MSPress/books/11163.aspx.


Dig Deeper on Windows systems and network management