IIS 7.0 and WAS Hosting
In the Vista timeframe, on Windows "Longhorn" Server machines, you can host your WCF services with the Windows Activation Service (WAS). 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. Like IIS 6.0, WAS also provides features for idle-time management, health monitoring, process recycling, and management tools for configuring application pools among other things.

In this section I'll explain how WAS hosting works, show you how the hosting architecture compares to IIS 6.0 hosting, and provide you with some tips for getting started with WAS.

WAS Hosting Architecture
IIS 7.0 introduces some architectural changes necessary to expand support for named pipes, TCP, and MSMQ protocols. The new architecture relies on protocol listeners, listener adapters, and protocol handlers to process requests.

Figure 5: How listener adapters and protocol handlers process requests with WAS hosting.

• Protocol Listeners: A protocol listener is responsible for receiving requests for a particular protocol. There is a protocol listener provided for HTTP, named pipes, TCP, and MSMQ. For HTTP, the HTTP listener is http.sys (same as in IIS 6.0). Listeners for other protocols are provided by their respective listener adapter service.
• Listener Adapters: A listener adapter is responsible for bridging requests between WAS and the worker process for a particular protocol. There is a listener adapter for HTTP, named pipes, TCP, and MSMQ. WWW Service provides the HTTP listener adapter. IIS provides Windows services for each of the other protocols, supplying a protocol listener and listener adapter pair (see Figure 5).
• Protocol Handlers: A protocol handler channels requests through the service model for a particular protocol. WCF provides managed protocol handlers for HTTP, named pipes, TCP, and MSMQ.

As each protocol listener receives requests, WAS checks for the existence of a worker process to service the request (according to application pool configuration). The listener adapter's job is then to pull requests from the application pool queue and forward to the appropriate protocol handler for processing. Figure 5 illustrates this architecture and flow.

To support this new architecture there are two services:

• Windows Activation Service (WAS): This service handles configuration, application pooling, and process activation for all protocols.
• WWW Service: This service provides the listener adapter for the HTTP listener, http.sys.

Table 2 shows these and other services that support the architecture shown in Figure 5. Ultimately, it's the protocol handler provided by WCF that ensures the ServiceHost instance has been created before requests can be processed.

Table 2: Services supporting WCF hosting with the WAS.

Process	Service	Description
smsvchost.exe	Net.Tcp Port Sharing Service (itcppss)	Enables multiple listeners on the same port.
smsvchost.exe	Net.Tcp Listener Adapter Service (itcpas)	Processes TCP requests.
smsvchost.exe	Net.Pipe Listener Adapter Service (inpas)	Processes named pipe requests.
smsvchost.exe	Net.Msmq Listener Adapter Service (imsmqas)	Processes MSMQ requests.
	HTTP Listener (http.sys)	Forwards HTTP requests to the WAS.
svchost.exe	WWW Service (w3svc) - includes the HTTP Listener Adapter	Processes HTTP requests.
svchost.exe	Windows Activation Service (WAS)	Provides configuration for protocol listeners and listener adapters, handles process activation for requests, provides health monitoring and other hosting features.

Regardless of protocol, the service model handles all requests in a consistent manner, but WAS provides a message-based activation mechanism like IIS 6.0 to increase the overall reliability and scalability for requests over any protocol.

Enabling WAS
You'll need to perform a few steps to configure IIS 7.0 and WAS before you can successfully host WCF services over any protocol. As you would with IIS 6.0, you'll first have to make sure the machine has IIS 7.0 and WAS installed. With these Windows components installed you can configure WAS for the protocols you want to support for each Web site.

IIS provides a new command-line utility to configure Web sites: appcmd.exe. HTTP protocol is supported by default, but with this utility you can enable support for named pipes, TCP, or MSMQ for any Web site or application directory. The following illustrates enabling named pipes, TCP, and MSMQ support for the default Web site:

 %windir%\system32\inetsrv\appcmd.exe set site
"Default Web Site" -+bindings.[protocol=
'net.pipe',bindingInformation='*']
%windir%\system32\inetsrv\appcmd.exe set site
"Default Web Site" -+bindings.[protocol=
'net.tcp',bindingInformation='*']
%windir%\system32\inetsrv\appcmd.exe set site
"Default Web Site" -+bindings.[protocol=
'net.msmq',bindingInformation='*']

After executing these commands, IIS updates the configuration file for WAS, applicationHost.config, with new <binding> entries for the Web site. IIS nests site configuration inside the <system.applicationHost> section as shown here:

 <system.applicationHost>
<sites>
<site name="Default Web Site" id="1">
<bindings>
<binding protocol="http"
bindingInformation="*:80:" />
<binding protocol="net.pipe"
bindingInformation="*" />
<binding protocol="net.tcp"
bindingInformation="*" />
<binding protocol="net.msmq"
bindingInformation="*" />
</bindings>
</site>
</sites>
</system.applicationHost>

This section governs what protocols the Web site and WCF services can support. Put another way, services can only expose endpoints that use service model bindings matching the supported protocols for the application.

Choosing the Right Hosting Environment
As I mentioned at the beginning of this article, choosing a hosting environment for your services is something that is largely driven by your operating platform and choice of protocol. Now that you've had a chance to explore the different hosting environments, you can probably guess that the best possible hosting environment would be WAS for its rich set of features and protocol support. Unfortunately, WAS is only available on Windows Vista or Windows "Longhorn" Server machines.

Table 3 summarizes the hosting options available to you on each operating platform, including client and server platforms.

Table 3: A summary of hosting options based on operating platform and communication protocol.

Operating Platform	Protocol	Hosting Options
Windows XP/SP2	HTTP	IIS 5.1 or self-host
	Named Pipes, TCP, MSMQ	Self-host
Windows Vista	HTTP, Named Pipes, TCP, MSMQ	WAS or self-host
Windows Server 2003	HTTP	IIS 6.0
	Named Pipes, TCP, MSMQ	Self-host
Windows "Longhorn" Server	HTTP, Named Pipes, TCP, MSMQ	IIS 7.0/WAS or self-host

Based on this summary, you will likely make one of these choices for your production services on each server platform:

• For Windows "Longhorn" Server machines you'll use IIS 7.0 and WAS.
• For Windows Server 2003 machines you'll use IIS 6.0 for HTTP and Windows services for other protocols.

For client systems the choice is a little bit more complex. In-process services introduce the least configuration overhead for clients, thus you'll be using Windows Forms or WPF clients as your self-hosting environment. If the system is a complex, distributed system where you have significant control over setup, you may install Windows services to provide services for Windows XP machines. For Windows Vista machines your choice of self-hosting with Windows services or enabling WAS may be governed by client preferences.