Channels ▼
RSS

.NET

The IIS7 Integrated Pipeline



All Web servers do essentially the same thing: They get requests and ensure a proper response is returned to the caller. Producing the response is not necessarily a task that servers can accomplish internally. For Web servers, an extensible architecture is a must -- and it is also one of the points that differentiate one Web server from another. IIS -- the Microsoft's Web server -- is no exception.

When the request for a resource arrives, IIS first verifies the type of the resource. Static resources -- images, text files, HTML pages, and script-less ASP pages -- are typically resolved directly by IIS without the involvement of any external modules. IIS accesses the file on the local Web server machine and flushes its contents to the output console so that the requesting browser can get it.

Resources that require server-side elaboration are passed on to any tailor-made modules that registered to handle those resources. Requested resources are mapped to registered modules based on their extension.

The details of how a request is being processed depend on the "process model" in use within IIS, and ultimately on the internal architecture of the Web server. The internal architecture of IIS changed significantly in the past decade to stay in sync with the progress of ASP.NET.

Originally, ASP.NET was envisioned to work in a way that revolutionized the internal architecture of the IIS of the time -- IIS 4. For about a decade new versions of ASP.NET and IIS followed one another, each reducing the gap between the design of each run time environment. In the beginning, ASP.NET was just an embedded shell within IIS 5. With the release of Windows Server 2008 and IIS 7, the circle closes and, at least when IIS 7 is configured to work in Integrated Pipeline mode, a single runtime environment exists for all incoming requests and all incoming requests go through a pipeline that is nearly identical to the classic ASP.NET runtime pipeline.

In an integrated pipeline, an ASP.NET request is like any other requests except that, at some point, it yields to a sort of simplified ASP.NET runtime environment that now just prepares the HTTP context, maps the HTTP handler, and generates the response.

When the application pool that contains an ASP.NET application running in Integrated Pipeline mode is initialized, it hosts ASP.NET runtime classes in the worker process and gives them a chance to register a set of built-in HTTP modules and handlers for the IIS pipeline events. This guarantees, for example, that Forms authentication, session state, and output caching work as expected in ASP.NET. At the same time, the ASP.NET runtime also subscribes to receive notification of when an ASP.NET request needs processing.

In IIS 7 running in Integrated Pipeline mode every request goes through a sequence of events for which both managed and unmanaged handlers can be defined. ASP.NET itself registers its own handlers for system events to capture and handle its own specific requests. Handlers of pipeline events are HTTP modules.

The big difference with classic ASP.NET and earlier versions of IIS is that any managed HTTP modules registered to handle early stages of the request can execute without first routing the request to the managed runtime of ASP.NET. A managed HTTP module can be added through the IIS manager and can operate on both managed and native requests. Similarly, a managed HTTP handler can be mapped to any resource types directly from the IIS manager or via the web.config file of the ASP.NET application. IIS doesn't serve ASP.NET requests itself though. In between the PreRequestHandlerExecute and PostRequestHandlerExecute events, IIS 7 hands an ASP.NET request on to the ASP.NET ISAPI component for actual processing.

IIS 7 supports two working modes: Classic and Integrated Pipeline. You select the working mode the application pool your application belongs to. All applications in the same pool share the same working mode. The Integrated Pipeline mode is the default mode and it makes it faster for a request to be served and gives more programming power to ASP.NET developers as it let them to control more carefully more types of resources.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video