Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Hosting WCF Services in Windows Activation Service

You're probably used to hosting WCF services with IIS, but Vista and IIS 7 provide a much more powerful and lighter-weight option that supports additional protocols besides HTTP.

indows Activation Service (WAS), introduced with Windows Vista, is the new process activation mechanism that ships with IIS 7.0. WAS builds on the existing IIS 6.0 process and hosting models, but is much more powerful because it provides support for other protocols besides HTTP, such as TCP and Named Pipes.

By hosting the Windows Communication Foundation (WCF) services in WAS, you can take advantage of WAS features such as process recycling, rapid failover protection, and the common configuration system, all of which were previously available only to HTTP-based applications. This article explores the steps involved in using WAS to host and consume WCF services.

Hosting Options for WCF
When hosting WCF services, you now have three choices:

  1. Windows Activation Service (WAS) hosting environment
  2. Executable (.exe) applications (including Console and Windows Forms applications)
  3. Windows Services
The WAS hosting environment is a broad concept that extends the ASP.NET HTTP pipeline hosting concept primarily used for ASMX web services. WAS is implemented as a Windows service in Windows Vista. As a standalone Windows component it's completely separate from the legacy IIS host and does not carry all the overhead associated with IIS while still providing a flexible and stable hosting environment for WCF services. In addition, by providing a protocol-agnostic activation mechanism (meaning you aren't limited to HTTP), WAS allows you to choose the most appropriate protocol for your needs

A WCF service hosted in WAS works similarly to an ASMX Service. For the HTTP protocol, it relies on the ASP.NET HTTP pipeline to transfer data. For non-HTTP protocols such as TCP and Named Pipes, WAS leverages the extensibility points of ASP.NET to transfer data. These extensibility hooks are implemented in the form of protocol handlers that manage communication between the worker process and the Windows service that receives incoming message. There are two types of protocol handlers: Process Protocol Handler (PPH) and App Domain Protocol Handler (ADPH). When the WAS activates a worker process instance, it first loads the required process protocol process handlers and then the the app domain protocol handlers.

What You Need
  • Visual Studio 2005 Professional RTM
  • Microsoft Windows Vista
  • Microsoft Windows Vista SDK

Setting up WAS
Before getting into the steps involved in setting up WAS, create a new WCF Service project named WASHostedService through Visual Studio 2005. I've used C# for the examples here, but you can easily translate them to VB.NET.

Figure 1. WAS Hosting for Non-HTTP Protocols: To make your WCF services available for remote invocation through TCP, Named Pipe and MSMQ protocol bindings, turn on the WCF Non-HTTP Activation feature through the Windows Features dialog box.
In Windows Vista, you need to perform two steps to host WCF services in WAS. First, install the WCF Non-HTTP activation components. To do that, go to the Start menu —> Control Panel —> Programs and Features, and then click "Turn Windows Components On or Off" in the left pane. Expand the Microsoft .NET Framework 3.0 node and ensure that the "Windows Communication Foundation Non-HTTP Activation" feature is checked as shown in Figure 1.

Second, to use a non-HTTP protocol such as TCP or Named Pipes, you need to add the site binding to the WAS configuration. As an example, here's how you'd bind the default web site to the TCP protocol. Go to the Start menu —> Programs —>Accessories. Right click on the "Command Prompt" item, and select "Run as administrator" from the context menu. You'll see a command prompt that has the requested elevated administrator permissions so you can execute administrator commands. Execute the following command:

<DriveName>\Windows\system32\inetsrv\appcmd.exe set site "Default Web Site" -- +bindings.[protocol='net.tcp',bindingInformation='808:*']

That command adds the net.tcp site binding to the default web site by modifying the applicationHost.config file located in the <DriveName>\Windows\system32\inetsrv\config directory.

After binding the default web site to the appropriate protocol, you need to enable the individual web applications to support the same protocol. To enable net.tcp for the WASHostedService site, run the following command from an administrator-level command prompt:

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

Now that you have set up the web site and application, you are ready to create a service and host it in WAS.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.