In IIS 7.0, two modes are available for an application pool:
Integrated mode and Classic mode. When you configure an application pool
with Integrated mode, IIS 7.0 processes ASP.NET requests using the
integrated IIS and ASP.NET request processing pipeline. When you
configure an application pool with Classic mode, IIS 7.0 processes
ASP.NET requests using the separate IIS and ASP.NET request processing
pipelines, as in IIS 6.0.
Application pools configured with
different modes can run on the same server machine. You can specify the
mode for an application pool by configuring the Managed Pipeline Mode
setting in IIS Manager.
To use IIS Manager to configure the ASP.NET processing mode for an application pool, perform the following steps:
-
In IIS Manager, expand the server node and select the Application Pools node in the Connections pane. -
On the Application Pools page, select the application pool you’d like to configure. -
In the Actions pane, under Edit Application Pool, select Basic Settings. -
In the Edit Application Pool dialog
box, in the Managed Pipeline Mode drop-down list, choose the desired
mode (Integrated or Classic) and click OK.
Classic mode in IIS 7.0 provides
backward compatibility with IIS 6.0. When an application pool is in
Classic mode, IIS 7.0 processes ASP.NET requests using two separate IIS
and ASP.NET request processing pipelines, as in IIS 6.0. To understand
Classic mode in IIS 7.0, let’s first look into how ASP.NET requests are
processed in IIS 6.0.
Figure 1
shows ASP.NET request processing in IIS 6.0. In IIS releases up to
version 6.0, ASP.NET connects to the Web server as a stand-alone
application framework. In these releases, ASP.NET is implemented as an
IIS Internet Server Application Programming Interface (ISAPI) extension.
In
IIS 6.0, the ASP.NET ISAPI extension (aspnet_isapi.dll) is responsible
for processing the content types that are registered to it, such as ASPX
and ASMX. For those requests, it offers powerful features, for example,
Forms Authentication and Response Output Caching. However, only content
types registered to ASP.NET can benefit from these services. Other
content types—including ASP pages, static files, images, and Common
Gateway Interface (CGI) applications—have no access to these features at
all.
A request to an ASP.NET content type is
first processed by IIS and then forwarded to aspnet_isapi.dll that
hosts the ASP.NET application and request processing model. This
effectively exposes two separate server pipelines, one for native ISAPI
filters and extension components, and another for managed application
components. ASP.NET components execute entirely inside the ASP.NET ISAPI
extension and only for requests mapped to ASP.NET in the IIS script map
configuration. Requests to non-ASP.NET content, such as ASP pages or
static files, are processed by IIS or other ISAPI extensions and are not
visible to ASP.NET.
In addition, even for ASP.NET resources,
certain functionalities are not available to ASP.NET because of run-time
limitations. For example, it is not possible to modify the set of
outgoing HTTP response headers before they are sent to the client
because this occurs after the ASP.NET execution path.
In IIS 7.0 in Classic mode, ASP.NET requests are also processed using the ASP.NET ISAPI extension, as shown in Figure 2. The core Web server in IIS 7.0 is fully componentized, whereas
in IIS 6.0, it is monolithic. However, the ASP.NET requests in Classic
mode are processed by asnet_isapi.dll in the same way as in IIS 6.0.
After the request has been processed by asnet_isapi.dll, it is routed
back through IIS to send the response.
Classic mode in IIS 7.0 has the same
major limitations as ASP.NET processing in the IIS 6.0. In summary,
these limitations are as follows:
-
Services provided by ASP.NET modules are not available to non-ASP.NET requests. -
Some processing steps are duplicated, such as authentication. -
Some settings must be managed in two locations, such as authorization, tracing, and output caching. -
ASP.NET applications are unable to affect
certain parts of IIS request processing that occur before and after the
ASP.NET execution path due to the placement of the ASP.NET ISAPI
extension in the server pipeline.
Classic mode is provided only for backward
compatibility with IIS 6.0. Simply put, you should add an application
to an application pool in Classic mode only if the application fails to
work in Integrated mode.
When an application pool is configured with
.NET Integrated mode, you can take advantage of the integrated request
processing architecture of IIS 7.0 and ASP.NET.
In IIS 7.0, ASP.NET run time is
integrated with the core Web server. The IIS and ASP.NET request
pipelines are combined, providing a unified (that is, integrated)
request processing pipeline that is exposed to both native and managed
modules.
The IIS 7.0 request processing pipeline is
implemented by the core Web server engine. It enables multiple
independent modules to provide services for the same request. All of the
Web server features are implemented as stand-alone modules. There are
over 40 separate native and managed modules. Each module implements a
particular Web server feature or functionality, such as logging or
output caching.
Native modules are implemented as dynamic-link
libraries (DLLs) based on public IIS 7.0 C++ extensibility APIs.
Managed modules are implemented as managed .NET Framework classes based
on the ASP.NET integration model in IIS 7.0. (IIS 7.0 has integrated the
existing IHttpModule API for ASP.NET.) Both of these APIs enable
modules to participate in the IIS 7.0 request processing pipeline and
access all events for all requests.
An IIS 7.0 integrated request processing pipeline is shown in Figure 3.
A pipeline is an ordered list consisting of native and managed modules
that perform specific tasks in response to requests. When a worker
process in an application pool receives a request from HTTP.sys, the
request passes through an ordered list of stages. As a result of
processing, the response is generated and sent back to HTTP.sys.
Each stage in the pipeline raises an event.
Native and managed modules subscribe to events in the stages of the
pipeline that are relevant to them. When the event is raised, the native
and managed modules that subscribe to that event are notified and do
their work to process the request. The pipeline event model enables
multiple modules to execute during request processing.
Most
of the pipeline events are intended for a specific type of task, such
as authentication, authorization, caching, and logging. The following
list describes stages and corresponding events in the request processing
pipeline:
-
Begin Request stage. This stage starts request processing. The BeginRequest event is raised. -
Authenticate Request stage. This stage authenticates the requesting user. The AuthenticateRequest event is raised. -
Authorize Request stage. At this stage, the AuthorizeRequest
event is raised. This stage checks access to the requested resource for
the authenticated user. If access is denied, the request is rejected. -
Resolve Cache stage. At this stage, ResolveRequestCache event is raised. This stage checks to see if the response to the request can be retrieved from a cache. -
Map Handler stage. At this stage, the MapRequestHandler event is raised. This stage determines the handler for the request. -
Acquire State stage. At this stage, the AcquireRequestState event is raised. This stage retrieves the required state for the request. -
Pre-execute Handler stage. At this stage, the PreExecuteRequestHandler event is raised. This stage signals that the handler is about to be executed and performs the preprocessing tasks if needed. -
Execute Handler stage. At this stage, the ExecuteRequestHandler event is raised. The handler executes and generates the response. -
Release State stage. At this stage, the ReleaseRequestState event is raised. This stage releases the request state. -
Update Cache stage. This stage updates the cache. The UpdateRequestCache event is raised. -
Log Request stage. At this stage, the request is logged. The LogRequest event is raised. -
End Request stage. At this stage, the EndRequest event is raised, which signals that the request processing is about to complete.
Modules that subscribe to an event provide specific services appropriate for the relevant stage in the pipeline. For example, Figure 4 shows several native and managed modules that subscribe to the AuthenticateRequest
event at the Authenticate Request stage, such as the Basic
Authentication module, the Windows Authentication module, the ASP.NET
Forms Authentication module, and the Anonymous Authentication module.
Basic, Windows, and Anonymous Authentication modules are native modules,
whereas Forms Authentication is a managed module.
.NET integrated pipeline provides several key advantages over previous versions of IIS, as follows:
-
Allowing services provided by both native and managed modules to apply to all requests.
All file types can use features that in IIS
6.0 are available only to managed code. For example, you can now use
ASP.NET Forms authentication and Uniform Resource Locator (URL)
authorization for static files, ASP files, CGI, static files, and all
other file types in your sites and applications. -
Eliminating the duplication of several features in IIS and ASP.NET.
For example, when a client requests a
managed file, the server calls the appropriate authentication module in
the integrated pipeline to authenticate the client. In previous versions
of IIS, this same request goes through an authentication process in
both the IIS pipeline and the ASP.NET pipeline. Other unified IIS and
ASP.NET functionality includes URL authorization, tracing, custom
errors, and output caching. -
Managing all of the modules in one location, thus simplifying site and application administration on the server.
Instead of managing some features in IIS
and some in the ASP.NET configuration, there is a single place to
implement, configure, monitor, and support server features. For example,
because of the run-time integration, IIS and ASP.NET can use the same
configuration for enabling and ordering server modules, as well as
configuring handler mappings. -
Extending IIS with ASP.NET managed modules.
IIS 7.0 enables ASP.NET modules to plug
directly into the server pipeline, in the same way as modules developed
with the native C++ IIS API. ASP.NET modules can execute in all
run-time stages of the request processing pipeline and can be executed
in any order with respect to native modules. The ASP.NET API has also
been expanded to allow for more control over request processing than was
previously possible.
How ASP.NET Integration Is Implemented
Though
native and managed modules implement the same logical module concept,
they use two different APIs. To enable an integrated pipeline model for
both native and managed modules, IIS 7.0 provides a special native
module called Managed Engine. The Managed Engine module in effect
provides an integration wrapper for ASP.NET modules that enables these
managed modules to act as if they were native IIS modules and handlers.
It acts as a proxy for event notifications and propagates a required
request state to the managed modules. Together with the ASP.NET engine,
it sets up the integrated pipeline and is also responsible for reading
the managed modules and handlers configuration.
When a request requires a managed
module, the Managed Engine module creates an AppDomain where that
managed module can perform the necessary processing, such as
authenticating a user with Forms authentication. Figure 5 shows the Managed Engine module, with the managed Forms Authentication module executing within an AppDomain.
All managed modules are dependent on the
Managed Engine module, and they cannot execute without it. For the
integrated pipeline and ASP.NET applications to work, the Managed Engine
module must be installed and enabled in IIS 7.0.
In Windows Server 2008, the Managed Engine
module is installed as a part of the Role Service component and .NET
Extensibility Component. In Windows Vista, it is installed as a part of
the .NET Extensibility component.
Modules can be installed and enabled on
different levels. Modules that are enabled on the server level provide a
default feature set for all applications on the server. The IIS global
configuration store, applicationHost.config, provides the unified list
of both native and managed modules. Each time WAS activates a worker
process, it gets the configuration from the configuration store, and the
worker process loads all globally listed modules.
Native modules can be installed only at
the server level. They cannot be installed at the application level. At
the application level, the global native modules that are enabled at the
server level can be removed, or those that are installed but not
enabled globally can be enabled for that application.
Managed modules can be added at the server,
site, and application levels. Application-specific modules are loaded
upon the first request to the application. Application managed modules
can be xcopy-deployed together with other application files.
You can manage both native and managed modules using the Modules feature in IIS Manager.
The pipeline model ensures that the typical
Web server processing tasks are performed in the correct order. For
example, authentication must happen before authorization: authenticating
the user associated with a request at the Authenticate Request stage
has to happen before checking that user’s access to the requested
resource at the Authorize Request stage.
The server uses the sequence of modules list
in the <modules> configuration section to order module execution
within each request processing stage. By executing during the relevant
stage, the majority of modules automatically avoid ordering problems.
However, multiple modules that execute within the same stage may have
ordering dependencies. For example, the built-in authentication modules
that run at the Authenticate Request stage should be executed in the
strongest to weakest order so that the request is authenticated with the
strongest credentials available.
To manage ordering dependencies, the
administrator can control the ordering of modules by changing the order
in which they are listed in the <modules> section. This can be
done, for example, using the Modules feature in IIS Manager.
To view, and optionally change, the ordered list of modules for a server, perform the following steps:
-
In IIS Manager, in the Connections pane, select the server node. -
In the server’s home page, open the Modules feature. -
In the Actions pane, click View Ordered List. -
You can change a position of a module in the
processing sequence by selecting the module and then using Move Up and
Move Down options in the Action pane to move it to the desired position
in the list.
|
