Message-Based Activation
One of the most important features IIS provides your WCF services is message-based activation. ServiceHost instances need not be open prior to processing requests for a given endpoint. Instead, the World Wide Web Publishing Service (WWW Service) is responsible for ensuring a worker process is present to handle requests. Then, when IIS forwards requests for a particular .svc endpoint to the worker process, the service model initializes the corresponding ServiceHost (if necessary), before dispatching the request through the channel stack.

There are many participants in this activation process:

• Microsoft introduced the HTTP Protocol Stack (http.sys) in IIS 6.0. It is a kernel-mode message processing service that can receive messages even while worker processes are dormant. All requests arrive and return through this service.

Figure 4: Services, processes, and core types involved in processing messages for WCF services.

• The WWW Service is responsible for launching worker processes on demand to handle requests. It also determines the correct request queue (application pool) for http.sys to send messages for processing. WWW Service is a Windows service that must be running for http.sys to successfully forward requests.
• Ultimately, IIS forwards requests for .svc endpoints to an ASP.NET worker process, which looks to its HTTP handler configuration (<httpHandlers> section) to determine the correct runtime type to process requests. In the case of .svc endpoints, the HttpHandler type from the System.ServiceModel.Activation namespace handles requests.

Figure 4 illustrates how the IIS 6.0 architecture processes messages for WCF services. In fact, up to the point when the service model's HttpHandler takes over, the ASP.NET ISAPI extension (aspnet_isapi.dll) handles the process much like any other HTTP request. What the service model's HttpHandler does is initialize ServiceHost instances as needed to process requests.

This message-based activation process allows IIS to balance the number of worker processes required to service request loads, releasing unused resources where appropriate. IIS also monitors the health of each worker process and will launch a new, healthy worker process to service requests as needed. In addition, you can configure IIS to periodically recycle worker processes to reduce the risk of resource and memory leaks. These features improve the overall reliability and availability of your WCF services.

ASP.NET Compatibility Mode
Once you activate the ServiceHost, hosting a WCF service with IIS operates much the same as self-hosted services. That is, the service model has a consistent way of processing requests. The ASP.NET processing model is only involved as far as passing the request to the correct HTTP handler, the service model's HttpHandler type.

In fact, the service model has two modes for hosting WCF services:

• Mixed Transports Mode: This is the default hosting mode. In this mode the ASP.NET pipeline does not process service requests. This makes it possible to expose endpoints for multiple transports in a consistent manner.
• ASP.NET Compatibility Mode: This hosting mode restricts an application to HTTP services. When you enable this mode, the features supplied by HTTP modules such as file and URL authorization, session state, caching, and profile are available to the service. In addition, the hosting mode initializes HttpContext.Current to provide access to ASP.NET-specific context.

In most cases, access to ASP.NET features and the HttpContext should not be necessary. The service model provides a much richer set of authentication and authorization features that are more appropriate for services. The service model also supplies a global OperationContext object with access to contextual information for the request including the security context, the request message and related headers, and information about the hosting environment.

If you are porting existing ASP.NET Web services (ASMX), you may have existing code that relies on the HttpContext or other ASP.NET features. For example, you may want to access the ASP.NET Session, Cache, or Profile objects to provide a consistent run-time experience as you would have with ASMX. You can enable ASP.NET compatibility by setting the aspNetCompabitilityEnabled property to true in the <serviceHostingEnvironment> section:

"The WAS is a process activation service installed with IIS 7.0 that decouples the activation architecture from IIS in order to support non-HTTP protocols such as named pipes, TCP, and MSMQ."

   <system.serviceModel>
     <serviceHostingEnvironment 
       aspNetCompatibilityEnabled="true"/>
   <system.serviceModel>

This makes it possible for your service code, or its downstream objects, to interact with these aforementioned ASP.NET features. For example, you can write code that relies on the ASP.NET Profile. Consider this <profile> section in the web.config:

   <profile enabled="true" 
     automaticSaveEnabled="true">
     <properties>
       <add name="Culture" allowAnonymous="true" 
         defaultValue=""/>
     </properties>
   </profile>

Your service code could access it as follows, using the current HttpContext:

   // set the culture preference
   string culture = HttpContext.Current.Profile["Culture"];
   
   // get the culture preference
   HttpContext.Current.Profile["Culture"] = culture;

Services can also require a hosting environment that supports ASP.NET compatibility by applying the AspNetCompatibilityRequirementsAttribute from the System.ServiceModel.Activation namespace.

   [AspNetCompatibilityRequirements(RequirementsMode=
      AspNetCompatibilityRequirementsMode.Required)]
   public class ProfileService : IProfileService

Other than porting ASMX services, you will most likely avoid using this feature in order to provide a consistent hosting model for your services over multiple protocols.