Hosting WCF in IIS5/ II6

IIS 5/6 Hosting 

The main advantage of hosting service in IIS is that, it will automatically launch the host process when it gets the first client request. It uses the features of IIS such as process recycling, idle shutdown, process health monitoring and message based activation. The main disadvantage of using IIS is that, it will support only HTTP protocol.

Let as do some hands on, to create service and host in IIS

Step 1:Start the Visual Studio 2008 and click File->New->Web Site. Select the 'WCF Service' and Location as http. This will directly host the service in IIS and click OK.

Step 2: I have created sample HelloWorld service, which will accept name as input and return with 'Hello' and name. Interface and implementation of the Service is shown below.

IMyService.cs

[ServiceContract]
public interface IMyService
{
    [OperationContract]
    string HelloWorld(string name);    

}

MyService.cs

public class MyService : IMyService
{

    #region IMyService Members

    public string HelloWorld(string name)
    {
        return "Hello " + name;
    }

    #endregion
}

Step 3: Service file (.svc) contains name of the service and code behind file name. This file is used to know about the service.

MyService.svc

<%@ ServiceHost Language="C#" Debug="true" 
Service="MyService" CodeBehind="~/App_Code/MyService.cs" %>

Step 4: Server side configurations are mentioned in the config file. Here I have mention only one end point which is configured to 'wsHttpBinding', we can also have multiple end point with differnet binding. Since we are going to hosted in IIS. We have to use only http binding. We will come to know more on endpoints and its configuration in later tutorial. Web.Config

<system.serviceModel>
  <services>
   <service behaviorConfiguration="ServiceBehavior" name="MyService">
 <endpoint address="http://localhost/IISHostedService/MyService.svc" 
 binding="wsHttpBinding" contract="IMyService">
 <identity>
 <dns value="localhost"/>
 </identity>
 </endpoint>
 <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
   </service>
 </services>
 <behaviors>
  <serviceBehaviors>
    <behavior name="ServiceBehavior">
 <!-- To avoid disclosing metadata information, 
 set the value below to false and remove the 
 metadata endpoint above before deployment -->
      <serviceMetadata httpGetEnabled="true"/>
 <!-- To receive exception details in faults for 
 debugging purposes, set the value below to true.  
 Set to false before deployment to avoid disclosing exception information -->
 <serviceDebug includeExceptionDetailInFaults="false"/>
 </behavior>
   </serviceBehaviors>
  </behaviors>
</system.serviceModel>

Note:

You need to mention the service file name, along with the Address mention in the config file. IIS Screen shot

This screen will appear when we run the application.

Step 5: Now we successfully hosted the service in IIS. Next we have to consume this service in client application. Before creating the client application, we need to create the proxy for the service. This proxy is used by the client application, to interact with service. To create the proxy, run the Visual Studio 2008 command prompt. Using service utility we can create the proxy class and its configuration information.

svcutil  http://localhost/IISHostedService/MyService.svc

After executing this command we will find two file generated in the default location.

• MyService.cs - Proxy class for the WCF service
• output.config - Configuration information about the service.

Step 6: Now we will start creating the Console application using Visual Studio 2008(Client application).

Step 7: Add the reference 'System.ServiceModel'; this is the core dll for WCF.

Step 8: Create the object for the proxy class and call the HelloWorld method.

static void Main(string[] args)
        {
            //Creating Proxy for the MyService 
             MyServiceClient client = new MyServiceClient();
             Console.WriteLine("Client calling the service...");
             Console.WriteLine(client.HelloWorld("Ram"));
             Console.Read();

        }

Step 9: If we run the application we will find the output as shown below.

I hope you have enjoyed the Service hosted in IIS. Now let start the look on the self hosted service.

WCF Hosting

In this part of the tutorial we are going to see the four different way of hosting the WCF service. WCF service cannot exist on its own; it has to be hosted in windows process called as host process. Single host process can host multiple servers and same service type can be hosted in multiple host process. As we discussed there are mainly four different way of hosting the WCF service.

1. IIS hosting
2. Self hosting
3. Windows Activation Service
4. Windows Service

Multiple hosting and protocols supported by WCF.Microsoft has introduced the WCF concept in order to make distributed application development and deployment simple.

Hosting Environment	Supported protocol
Windows console and form application	HTTP,net.tcp,net.pipe,net.msmq
Windows service application (formerly known as NT services)	HTTP,net.tcp,net.pipe,net.msmq
Web server IIS6	http, wshttp
Web server IIS7 - Windows Process Activation Service (WAS)	HTTP,net.tcp,net.pipe,net.msmq

A summary of hosting options and supported features.

Feature	Self-Hosting	IIS Hosting	WAS Hosting
Executable Process/ App Domain	Yes	Yes	Yes
Configuration	App.config	Web.config	Web.config
Activation	Manual at startup	Message-based	Message-based
Idle-Time Management	No	Yes	Yes
Health Monitoring	No	Yes	Yes
Process Recycling	No	Yes	Yes
Management Tools	No	Yes	Yes

WCF Architecture

The following figure illustrates the major components of WCF.

Figure 1: WCF Architecture

Contracts

Contracts layer are next to that of Application layer. Developer will directly use this contract to develop the service. We are also going to do the same now. Let us see briefly what these contracts will do for us and we will also know that WCF is working on message system.

Service contracts

- Describe about the operation that service can provide. Example, Service provided to know the temperature of the city based on the zip code, this service we call as Service contract. It will be created using Service and Operational Contract attribute.

Data contract

- It describes the custom data type which is exposed to the client. This defines the data types, are passed to and from service. Data types like int, string are identified by the client because it is already mention in XML schema definition language document, but custom created class or datatype cannot be identified by the client e.g. Employee data type. By using DataContract we can make client aware that we are using Employee data type for returning or passing parameter to the method.

Message Contract

- Default SOAP message format is provided by the WCF runtime for communication between Client and service. If it is not meeting your requirements then we can create our own message format. This can be achieved by using Message Contract attribute.

Policies and Binding

- Specify conditions required to communicate with a service e.g security requirement to communicate with service, protocol and encoding used for binding.

Service Runtime

- It contains the behaviors that occur during runtime of service.

• Throttling Behavior- Controls how many messages are processed.
• Error Behavior - Specifies what occurs, when internal error occurs on the service.
• Metadata Behavior - Tells how and whether metadata is available to outside world.
• Instance Behavior - Specifies how many instance of the service has to be created while running.
• Transaction Behavior - Enables the rollback of transacted operations if a failure occurs.
• Dispatch Behavior - Controls how a message is processed by the WCF Infrastructure.

Messaging

- Messaging layer is composed of channels. A channel is a component that processes a message in some way, for example, by authenticating a message. A set of channels is also known as a channel stack. Channels are the core abstraction for sending message to and receiving message from an Endpoint. Broadly we can categories channels as

• Transport Channels
  Handles sending and receiving message from network. Protocols like HTTP, TCP, name pipes and MSMQ.
• Protocol Channels
  Implements SOAP based protocol by processing and possibly modifying message. E.g. WS-Security and WS-Reliability.

Activation and Hosting

- Services can be hosted or executed, so that it will be available to everyone accessing from the client. WCF service can be hosted by following mechanism

• IIS
  Internet information Service provides number of advantages if a Service uses Http as protocol. It does not require Host code to activate the service, it automatically activates service code.
• Windows Activation Service
  (WAS) is the new process activation mechanism that ships with IIS 7.0. In addition to HTTP based communication, WCF can also use WAS to provide message-based activation over other protocols, such as TCP and named pipes.
• Self-Hosting
  WCF service can be self hosted as console application, Win Forms or WPF application with graphical UI.
• Windows Service
  WCF can also be hosted as a Windows Service, so that it is under control of the Service Control Manager (SCM).
  
  
  
  
  references:http://wcftutorial.net/WCF-Architecture.aspx

IIS

IIS

What is IIS?
IIS Manager is a graphical interface for configuring your application pools or your Web, FTP, SMTP,
or NNTP sites. With IIS Manager, you can configure IIS security, performance, and reliability features.
You can add or delete sites; start, stop, and pause sites; back up and restore server configurations;
and create virtual directories for better content management, to name only a few of the administrative
capabilities. In previous releases of IIS, this tool was called the Internet Service Manager.
What is the full form of IIS?
Internet Information Server.
What is a Web service extension and how do I use the Web Service Extensions folder? (IIS 6.0)
The Web Service Extensions folder is the user interface for the new IIS 6.0 lockdown feature. This
feature is a manifest of ISAPI extensions and CGIs with user-specified permissions, meaning,
administrators must set the permissions to allow specific ISAPIs and CGIs to run on your server.
Administrators can also specify the names of ISAPIs or CGIs that are forbidden to run on your server.
Before loading an ISAPI extension .dll file or CGI .exe file, IIS checks this manifest for the permissions
on the file. If the file is permitted to run, then the request proceeds normally. If the file is not permitted
to run, then IIS returns a 404.2 error response to the client machine. The HTML page for a 404.2 error
looks like a standard 404 error page, so the client machine processes the request as though the file did
not exist. IIS logs the 404.2 error, which administrators can view to assess problems or potential threats
against the server.
How do I publish documents or Web pages? (IIS 6.0)
1.Move your files to the \Inetpub\Wwwroot directory.
2.Type http://servername/filename in the address bar of your Internet browser to see your published files.
How do I create a virtual directory on a Web or FTP site? (IIS 6.0)
You can use IIS Manager to create virtual directories on your Web site.
How do I create a Web site?
When you install IIS on a computer running a member of the Windows Server 2003 family, a default
Web site is set up for you. You can publish your content here immediately.
How do I create multiple Web sites?
To create multiple Web sites, you must first ensure that each site has unique identification. To
accomplish this, you need to contact your network administrator to either obtain multiple IP addresses or
to assign multiple host header names.
How do I stop and restart Internet services?
By using the "IISRESET" command
Can I change the name of my Web site and also redirect requests for the old site name to the new
one?
You can configure your Web site to respond to both the old name and the new name, provided your
network correctly routes both requests to your computer. This way, visitors can still reach your site by
using the old name, and will be informed of the new name.
How can I confirm that a server certificate is attached to a Web site?
1.In IIS Manager, right-click the Web site, and click Properties.
2.Click the Directory Security tab.
3.Under Secure communications, if the View Certificate button is activated, there is a certificate attached
to the Web site. If the button is not activated, you must attach a server certificate to the site to use the
Secure Sockets Layer (SSL) features.
Can I attach more than one server certificate to a Web site?
No. Each Web site can have only one server certificate attached to it.
Can I attach the same server certificate to more than one site?
Yes. A server certificate can be attached to as many Web sites as needed.

Can I attach a server certificate to an FTP site?
No. FTP sites do not support Secure Sockets Layer (SSL) features.
Should I create a backup copy of my server certificate?
Yes. Your server certificate is a valuable investment, and is the key to your server's Secure Sockets
Layer features. To create a backup copy of your server certificate, copy the entire certificate on to a
floppy disk and store it in a safe place.
Does ASP debugging work in IIS 6.0 worker process isolation mode?
Yes, when you configure Launch and Access permissions to enable ASP debugging in worker process
isolation mode for Script Debugger and Visual InterDev.
What are the new features in IIS7?
1. Simple, Configurable Command Line Setup · Install only the IIS components needed to run your site
Example: start /w pkgmgr /l:log.etw /iu:IIS-WebServerRole;IIS-WebServer;IIS-
CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-
HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-
ASP;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-
HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-Security;IIS-
ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-
RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-
HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementConsole;IIS-
ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-
Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;WAS-
WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI 2.
Great Compatibility Story · Most (99%+) ASP and ASP.NET applications just worked.
ü One application encountered breaking change ü Handful of applications required config migration to
run in Integrated (We have about 260 applications running on www.microsoft.com as defined by IIS,
there are thousands of pages of code that could have broken but didn’t.) · Integrated Pipeline is the new
unified request processing pipeline. Benefits include: ü Allowing services provided by both native and
managed modules to apply to all requests, regardless of handler. For example, managed Forms
Authentication can be used for all content, including ASP pages, CGIs, and static files. ü Empowering
ASP.NET components to provide functionality that was previously unavailable to them due to their
placement in the server pipeline. For example, a managed module providing request rewriting
functionality can rewrite the request prior to any server processing, including authentication, takes place.
ü A single place to implement, configure, monitor and support server features. For example, single
module and handler mapping configuration, single custom errors configuration, single url authorization
configuration. · Classic ASP mode allows for easy app migration ü ASP.NET Setup provides a
“Classic .NET AppPool” ü For more information on check out the article ASP.Net Integration With IIS7
· Use AppCmd to migrate apps to Integrated mode ü %windir%\system32\inetsrv\APPCMD.EXE
migrate config <application path> ü For more information about AppCmd.exe see Getting Started With
AppCmd.exe · IIS 6.0 Metabase compatibility layer ü Allows you the run old ADSI scripts ü IIS6.0
Metabase Compatibility module must be installed
3. No More Metabase! · Clean clear-text schema · IIS settings stored in XML configuration file
(applicationHost.config) ü Metabase exists for SMTP/NNTP/FTP only · Site-wide changes made easily
ü Update central applicationHost.config and copy to all web servers ü Replaces our bulky ADSI based
script solution for metabase changes · Microsoft.com considerations ü Careful copying to production
servers under load: (Know Thy Environment! When you push out a new applicationHost.config those
affected worker process need to reload the new configuration. It comes down to the scope of the change.
For example, if you are making a global change that that affectes all the worker processes, and you are
heavily dependent on caching then you could cause some grief in your environment as those new
configurations are reloaded by the worker processes.)
4. Centralized Configuration · applicationHost.config stored on UNC share · Allows us to copy to two
(maybe four) servers rather than 80 ü Potential gotcha - managing password changes for account used to

connect to config store (This is because that currently you cannot use the UNC share that is running
under the Network service, which we use heavily. It currently requires a domain account, which our
security policy mandates a periodic password change.)
5. Delegated Configuration · Admin can now delegate IIS settings to application owner · Settings
defined in web.config file in application directory · Example of setting to delegate include: ü
System.webServer section of applicationHost.config ü Caching, defaultDocument, httpErrors, security
6. AppCmd and Other New Management Options · Managing via the UI ü New modular, task-based
look and feel ü Moving away from the right-click/properties paradigm · Managing via the Command
Line ü AppCmd § Command line utility which replaces adsutil.vbs, iisapp.vbs, and others § Allows
command line management of sites, applications, vdirs, apppools, modules, tracing, and more ü
Powershell § IIS community creating IIS-specific Powershell cmdlets · MSCOM Considerations ü
AppCmd limitations – no remote ü No IIS provider for Powershell
7. Failed Request Tracing · Buffers the trace events for requests and flushes them to disk if they meet
your failure criteria · Captures trace data while you’re sleeping · Very little perf impact when targeting
failing requests · Quick test: Enabling tracing for all file extensions and errors results in approx 5%
fewer requests/sec at full stress load (please don’t do this in production) · View Currently Executing
Requests via AppCmd ü appcmd list requests (for all request) ü appcmd list requests /
apppool.name:DefaultAppPool REQUEST "3e00000080012675" (url:GET /casestudies/casestudy.aspx?
casestudyid=201269, time:2954 msec, client:127.0.0.1) · New Task Scheduler ü Trigger tasks on events
8. Request Filtering · No more URLScan · settings in applicationHost.config · Gotcha for
Microsoft.com: If filename includes “+” then allowDoubleEscaping must be set to “true” ü · Allow or
disallow specific file extensions and verbs ü · DenyURLSequences ü ü · RequestLimits ü
maxAllowedContentLength="1000000“ ü maxUrl="260“ ü maxQueryString="2048" 9. UNC Content ·
Simplified content synchronization · Reduced H/W footprint (potentially less cost) ü Common industry
pain point 10. Output Caching of Dynamic Content · Fewer off-box calls to backend dependencies ·
Significant performance gains · Simple WCAT (Web Capacity Analysis Tool) Stress Test against
www.microsoft.com/en/us/default.aspx Not appropriate for all applications (e.g. not effective for those
with very personalized output)

ASP.NET Internals – IIS and the Process Model

Introduction

Microsoft Active Server Pages, also known as ASP, since its first release in late 1996 provided web developers with a rich and complex framework for building web applications. As years passed its infrastructure evolved and improved so much that what is now known as ASP.NET is no longer something which resembles its predecessor. ASP.NET is a framework for building web applications, that is, applications that run over the web, where the client-server paradigm is represented mostly by a browser forwarding requests for resources of different kinds to a web server. Before the advent of dynamic server-side resource generation techniques like CGI, PHP, JSP and ASP, all web servers had to do was accept client’s requests for static resources and forward them to the requestor. When dynamic technologies started to grow up web servers became invested of greater responsibility, since they had to find a way to generate those dynamic resources on their side and return the result to the client, a task they were not formerly built for.

From a bird’s eye view, the interaction between client and server is very simple. Communications over the web occur via HTTP (Hyper Text Transfer Protocol), an application level protocol which relies on TCP and IP to transmit data between two nodes connected to the heterogeneous network known as World Wide Web.

Each dynamic server-side technology essentially leans on a particular web server implementation, and ASP.NET is tightly coupled with Microsoft’s Internet Information Server, akaIIS.

Different servers chose different ways to generate and serve dynamic resources and what we’re going to examine is how IIS does that, together with the path a request follows once on the server and back to the client.

IIS and ISAPI Extensions

As mentioned, static resources needn’t to be processed by the server; once a request for such a resource arrives, the server just retrieves its contents from the file system and sends it back to the client as a stream of byte flowing on the HTTP protocol. Static resources can be images, Javascript files, css style sheets or plain old html pages. It’s clear that the server needs to know how to distinguish between static and dynamic resource, whereas the second need to be processed somehow and not just sent back to the client. That’s where ISAPI extensions appear, where ISAPI stands for Internet Server Application Programming Interface. ISAPI extensions are modules implemented as plain old Win32 .dll, on which IIS relies to process specific resources. Mappings between ISAPI extensions and files are configured via the IIS snap-in and stored in the IIS metabase, where each file extension can be associated with a particular ISAPI extension, that is, when a request for such a file arrives, IIS handles it to the corresponding ISAPI extension, confident that it will be able to handle it.

Figure 1: Configuring ISAPI extensions mappings on IIS 5.0

ISAPI extensions obviously need to respect a common interface through which they can be called by IIS and provided the necessary data to elaborate the request and generate a response.

As Figure 1 illustrates, the .asp extension is mapped to the asp.dll ISAPI extension; at the time of ASP this component was in charge of performing all the tasks required to generate a response, that is, collecting information about the request, made available into the ASP page via the Request, Response and other common ASP intrinsic objects, parsing and executing the ASP page and returning the resulting HTML.

Actually, that was a big improvement compared to a technology like CGI, but ASP.NET takes this approach much further and introduces abstractions which totally shield the developers from having to care about what happens at this stage.

When installed, ASP.NET configures IIS to redirect requests for ASP.NET specific files to a new ISAPI extension called aspnet_isapi.dll. What this extension does is somewhat different then the former asp.dll extension, which was essentially responsible just for parsing and executing the requested ASP page. The steps taken by a generic ISAPI module to process a request are totally hidden from IIS, therefore ISAPI extension may follow different paradigms in order to process requests.

Table 1: IIS Application Mappings for aspnet_isapi.dll

Extension	Resource Type
.asax	ASP.NET application files. Usually global.asax.
.ascx	ASP.NET user control files.
.ashx	HTTP handlers, the managed counterpart of ISAPI extensions.
.asmx	ASP.NET web services.
.aspx	ASP.NET web pages.
.axd	ASP.NET internal HTTP handlers.

As well as the file extensions listed in Table 1, the ASP.NET ISAPI extension manages other file extensions which are usually not served to web browsers, like Visual Studio project files, source code files and config files, for example.

The ASP.NET Process Model

So far we’ve seen that when a request for an ASP.NET file is picked up by IIS, it is passed to the aspnet_isapi.dll, which is the main entry point for ASP.NET related processing. Actually, what the ISAPI extension does depends sensibly on the version of IIS available on the system, and thus the process model, which is the sequence of operations performed by the ASP.NET runtime to process the request and generate a response, may vary quite a bit.

When running under IIS 5.X, all ASP.NET-related requests are dispatched by the ISAPI extension to an external worker process called aspnet_wp.exe. The ASP.NET ISAPI extension, hosted in the IIS process inetinfo.exe, passes the control to aspnet_wp.exe, along with all the information concerning the incoming request. The communication between the two is performed via named pipes, a well known mechanism for IPC (Inter Process Communication). The ASP.NET worker process performs a considerable number of tasks, together with the ISAPI extension. They are the main authors of all the stuff that happens under the hoods of an ASP.NET request. To introduce a topic which will be discussed later, take note of the fact that each web application, corresponding to a different virtual directory hosted on IIS, is executed in the context of the same process, the ASP.NET worker process. To provide isolation and abstraction from the execution context the ASP.NET model introduces the concept of Application Domains, in brief AppDomains. They can be considered as lightweight processes. More on this later.

If running under IIS 6, on the other side, the aspnet_wp.exe process is not used, in favour of another process called w3wp.exe. Furthermore, inetinfo.exe is no longer used to forward HTTP requests to ISAPI extensions, although it keeps running for serving other protocols requests. A lot of other details change compared to the process model used by previous versions of IIS, although IIS 6 is capable of running in compatibility mode and emulate the behavior of its predecessor. A big step forward, compared to the process model used when running on top of IIS 5, is that incoming requests are in the former handled at a lower – Kernel – level and then forwarded to the correct ISAPI extension, thereby avoiding inter process communication techniques which may represent an expensive operation under a performance and resource consumption point of view. We’ll delve deeper into this topic in the following paragraphs.

IIS 5.0 Process Model

This is the default process model available on Windows 2000 and XP machines. As mentioned it consists in the IIS inetinfo.exe process listening by default on the TCP port 80 for incoming HTTP requests and queuing them into a single queue, waiting to be processed. If the request is specific to ASP.NET, the processing is delegated to the ASP.NET ISAPIextension, aspnet_isapi.dll. This, in turn, communicates with the ASP.NET worker process, aspnet_wp.exe via named pipes and finally is the worker process which takes care of delivering the request to the ASP.NET HTTP runtime environment. This process is graphically represented in Figure 2.

Figure 2: The IIS 5.0 Process Model

In Figure 2 is represented an additional element we didn’t mention yet, the ASP.NET HTTP Runtime Environment. It’s not topic of this article and will eventually be explained in a follow up article, but for the sake of this discussion the HTTP Runtime Environment can be considered as a black box where all the ASP.NET specific processing takes place, all the managed code lives and developers can actually put their hands on, from the HttpRuntime straight to the HttpHandler who will finally process the request and generate the response. This is even referred to as the ASP.NET Pipeline or HTTP Runtime pipeline.

One of the interesting points of this process model is that all the requests, once handled by the ISAPI extension, are passed to the ASP.NET worker process. Only one instance of this process is active at a time, with one exception, discussed later. Therefore all ASP.NET web applications hosted on IIS are actually hosted inside the worker process, too. However, this doesn’t mean that all the applications are run under the same context and share all their data. As mentioned, ASP.NET introduces the concept of AppDomain, which is essentially a sort of managed lightweight process which provides isolation and security boundaries. Each IIS virtual directory is executed in a single AppDomain, which is loaded automatically into the worker process whenever a resource belonging to that application is requested for the first time. Once the AppDomain is loaded – that is, all the assemblies required to satisfy that request are loaded into the AppDomain – the control is actually passed to the ASP.NET pipeline for the actual processing. Multiple AppDomains can thus run under the same process, while requests for the same AppDomain can be served by multiple threads. However, a thread doesn’t belong to an AppDomain and can serve requests for different AppDomains, but at a given time a thread belongs to a single AppDomain.

For performance purposes the worker process can be recycled according to some criteria which can be specified declaratively in the machine.config file placed in the directory C:\windows\microsoft.net\Framework\[framework version]\CONFIG. These criteria are the age of the process, number of requests served and queued, time spent idle and consumed memory. Once one of the threshold value of these parameters is reached, the ISAPI extension creates a new instance of the worker process, which will we used from then on to serve the requests. This is the only time when multiple copies of the process can be running concurrently. In fact, the old instance of the process isn’t killed, but it is allowed to terminate serving the pending requests.

IIS 6.0 Process Model

The IIS 6 process model is the default model on machines running Windows 2003 Server operating system. It introduces several changes and improvements over the IIS 5 process model. One of the biggest changes is the concept of application pools. On IIS 5.X all web applications, that is, all AppDomains, were hosted by the ASP.NET worker process. To achieve a finer granularity over security boundaries and personalization, the IIS 6 process model allows applications to run inside different copies of a new worker process, w3wp.exe. Each application pool can contain multiple AppDomains and is hosted in a single copy of the worker process. In other words, the shift is from a single process hosting all applications to multiple processes hosting each an application pool. This model is also called the worker process isolation mode.

Another big change from the previous model is the way IIS listens for incoming requests. With the IIS 5 model, it was the IIS process, inetinfo.exe, who was listening on a specific TCP port for HTTP requests. In the IIS 6 architecture, incoming requests are handled and queued at kernel level instead of user mode via a kernel driver called http.sys; this approach has several advantages over the old model and is called kernel-level request queuing.

Figure 3: The IIS 6.0 process model

Figure 3 illustrates the principal components taking part in the request processing when using the II 6 model. Once a request arrives the kernel level device driver http.sys routes it to the right application pool queue. Each queue belongs to a specific application pool, and thus to a specific copy of the worker process, which next receives the request from the queue. This approach highly reduces the overhead introduced by named pipes used in IIS 5 model since no inter process communication is taking place, but the requests are headed to the worker process directly from the kernel level driver. This has many advantages concerning reliability, too. Since running in kernel mode, the request dispatching isn’t influenced by crashes and malfunctions happing at user level, that is, in the worker processes. Thereby, even if a worker process crashes, the system is still capable of accepting incoming requests and eventually restarts the crashed process.

It’s the worker process who is in charge of loading the ASP.NET ISAPI extension, which, in turn, loads the CRL and delegates all the work to the HTTP Runtime.

The w3wp.exe worker process, differently from the aspnet_wp.exe process used in IIS 5 model, isn’t ASP.NET specific, and is used to handle any kind of requests. The specific worker process then decides which ISAPI modules to load according to the type of resources it needs to serve.

A detail not underlined in Figure 3 for simplicity reasons is that incoming requests are forwarded from the application pool queue to the right worker process via a module loaded inIIS 6 called Web Administration Service (WAS). This module is responsible for reading worker process – web application bindings from the IIS metabase and forwarding the request to the right worker process.

References

Simone Busoli - ASP.NET Internals - The bridge between ISAPI and Application Domains

BrainBell.com – ASP.NET Application Fundamentals

Dino Esposito – Programming Microsoft ASP.NET 2.0 Core Reference

Dino Esposito – Programming Microsoft ASP.NET 2.0 Applications Advanced Topics

George Shepherd – IIS 6.0: New Features Improve Your Web Server's Performance, Reliability, and Scalability

Fritz Onion – ASP.NET Pipeline: Use Threads and Build Asynchronous Handlers in Your Server-Side Web Code

Tim Ewald and Keith Brown – HTTP Pipelines: Securely Implement Request Processing, Filtering, and Content Redirection with HTTP Pipelines in ASP.NET