Learning WCF

IIS 7.0 and Windows Activation Service

On Windows Vista and Windows Server 2008 machines you can host your WCF services with 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. Although supported by Windows Vista, hosting in the WAS is not incredibly useful for client deployments.

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 the 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.

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 listener is http.sys (same as 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 the WAS and the ASP.NET worker process for a particular protocol. There is a listener adapter for HTTP, named pipes, TCP, and MSMQ. The HTTP listener adapter is provided by the WWW service (w3svc). Each of the other protocols has a Windows service that supplies a protocol listener and listener adapter pair.

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.

Figure 4-16 illustrates how protocol listeners, listener adapters, and protocol handlers participate in request processing. As each protocol listener receives requests, the WAS checks for the existence of a worker process to handle the request (according to application pool configuration). The listener adapter’s job is then to pull requests from the application pool’s queue and forward to the appropriate protocol handler for processing.

To support this new architecture there are two core 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.

These and other services supporting the architecture in Figure 4-16 are listed in Table 4-3. Ultimately, it’s the protocol handler provided by WCF that ensures the ServiceHost instance has been created before requests can be processed.

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.

Figure 4-16. IIS 7.0 and WAS architecture for processing requests to WCF services

Table 4-3. 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 pipes 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.

Installing IIS 7.0, WAS, and WCF Communications

Before you can successfully host WCF services on a Windows Vista or Windows Server 2008 machine, you must enable IIS 7.0, WAS, and WCF communications. On a Windows Vista machine, you can do this through the Control Panel. From classic view, select “Programs and Features,” and from the task pane select “Turn Windows features on or off.” In the Windows Features dialog, you should do the following:

• Enable IIS, including the management tools checked in Figure 4-17. Installing IIS 6 compatibility is optional, but it can be helpful if you have existing .vbs scripts.

• Enable WWW Services, accepting the defaults in addition to the common HTTP features checked in Figure 4-18. In particular, you should make sure ASP.NET is enabled.

• Enable WAS, labeled Windows Process Activation Service in Figure 4-19. In this case, enable all features.

• Enable WCF communication protocols for .NET 3.0 as shown in Figure 4-20. You should enable both HTTP and non-HTTP support if you plan to host services over all protocols in WAS.

  

  Figure 4-17. Enabling IIS features

  

  Figure 4-18. Enabling WWW features

  

  Figure 4-19. Enabling WAS

  

  Figure 4-20. Enabling WCF communication

Configuring IIS 7.0 and WAS

Once IIS 7.0, WAS, and WCF communication features are installed, you can configure activation over named pipes, TCP, and MSMQ; by default, HTTP protocol is supported. IIS provides a new command-line utility to configure IIS applications, appcmd.exe, located in the C:\Windows\System32\inetsrv directory. With this utility, you can enable support for named pipes, TCP, or MSMQ for any web site or application directory.

In order to support non-HTTP protocols for any of your applications, you must first enable that protocol support for the web site it belongs to. The following set of commands shows how to enable named pipes and TCP 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='9200:*']

Tip

A batch file named enablewasnonhttp.bat is located in the <YourLearningWCFPath>\Samples\Hosting\WASHosting directory with these commands. Execute this batch file to enable non-HTTP support for the default web site on your machine.

IIS 7.0 configuration is stored in the applicationHost.config file, located in the c:\Windows\System32\inetsrv\config directory (or, your equivalent System32 path). After executing these commands the configuration file is updated with new <binding> entries for the default web site. Site configuration is nested inside the <system.applicationHost> section, as shown in Example 4-22.

Example 4-22. Supported binding protocols for the default web site

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

Warning

When you enable support for the TCP protocol, you must specify a port number as part of the bindingInformation setting. For the WAS hosting samples provided with this book, port 9200 is used for WAS hosting.

This section of the applicationHost.config file governs what protocols the web site can support, as well as WCF services hosted within that web site. Once the web site supports a protocol, individual applications can be configured to support that protocol. In fact, you must specifically enable non-HTTP protocols for each application on the machine, once again using the appcmd.exe utility. Service endpoints can use only bindings that match the supported protocols for the application.

To enable support for HTTP, TCP, and named pipes for a particular application you can issue a command like the following:

%windir%\system32\inetsrv\appcmd.exe set app "Default Web Site/[application
directory]" /enabledProtocols:http,net.tcp,net.pipe

The placeholder application directory should be replaced with the name of the specific application to be configured. This IIS setting is not inheritable, so you must repeat this for each application that requires additional protocol support.

This command also updates configuration settings for the application directory in the applicationHost.config file. The <site> section contains a list of application directories in individual <application> sections as shown in Example 4-23. Each application has a comma-delimited list of enabled protocols. This is the setting modified by the previous command.

Example 4-23. Supported protocols for a particular application directory in IIS

<sites>
  <site name="Default Web Site" id="1" serverAutoStart="true">
    <application path="/WASHost"enabledProtocols="http,net.tcp,net.pipe,net.msmq">
      <virtualDirectory path="/" physicalPath="C:\inetpub\wwwroot\WASHost" />

    </application>

    <!-- more applications -->

    <bindings>...</bindings>
  </site>
</sites>

Once you’ve enabled the appropriate protocol support in IIS, you can begin hosting WCF services over those protocols using WAS.

Hosting WCF Services with WAS

On machines where IIS 7.0 and WAS are enabled, you can host WCF service endpoints over any protocol without self-hosting in a Windows service. From a development perspective, you still create an ASP.NET web site project, optionally using the WCF Service template. The only restriction is that the web site can’t be file-based—it must be an IIS application.

The following steps summarize how you would go about creating a new web site with WCF services that can be hosted over HTTP, named pipes, and TCP. MSMQ is covered in Chapter 6.

1. Create a new ASP.NET HTTP-based web site using the WCF Service template.

2. Use the appcmd.exe utility to enable named pipes and TCP support as discussed in the previous section. For example, if the web site is located at http://localhost/WASHost, you would execute the following command:

   %windir%\system32\inetsrv\appcmd.exe set app "Default Web Site/WASHost" /
   enabledProtocols:http,net.tcp,net.pipe

   You can verify that the correct protocols are supported for the application in the IIS administrative console (see Figure 4-21).

3. Now you can configure the ServiceHost as you would for any IIS-hosted application, with the exception that you can now specify endpoints that support HTTP, named pipes, or TCP protocol (see Example 4-24). Like with other IIS-hosted applications, a base address is not required for each protocol—this is provided by the application.

4. To generate a proxy for your WAS-hosted services, you must enable metadata exchange as with any other IIS or self-hosted service. The .svc endpoint is the address provided for metadata exchange.

   

   Figure 4-21. Protocol support is indicated for an application directory under Browse Application actions

Tip

See the following code sample for a complete implementation of a WAS-hosted service: <YourLearningWCFPath>\Samples\ Hosting\WASHosting.

Example 4-24. ServiceHost configuration for a WAShosted service

<service name="HelloIndigo.HelloIndigoService" >
  <endpoint address="netPipe" contract="HelloIndigo.IHelloIndigoService"
binding="netNamedPipeBinding"/>
  <endpoint address="netTcp" contract="HelloIndigo.IHelloIndigoService"
binding="netTcpBinding"/>
  <endpoint address="basicHttp" contract="HelloIndigo.IHelloIndigoService"
binding="basicHttpBinding"/>
  <endpoint address="wsHttp" contract="HelloIndigo.IHelloIndigoService"
binding="wsHttpBinding"/>
</service>