Hosting WCF Services

Windows Communication Foundation (WCF) Services can be hosted with Internet Information Services (IIS); with the new Windows Activation Service (WAS) installed with IIS 7.0; or with any managed application process including console, Windows Forms, Windows Presentation Foundation (WPF), or managed Windows service applications. Selecting the right hosting environment for your services is a choice driven largely by deployment requirements related to transport protocol and operating platform.

WCF is part of the .NET Framework 3.0 stack and thus is supported on the following operating platforms: Windows XP/SP2, Windows Vista, Windows Server 2003, and Windows “Longhorn” Server. Regardless of platform, you can access WCF services over many protocols including HTTP, TCP, IPC and MSMQ. Unfortunately, not all hosting environments are available to each platform, nor does every host support the entire suite of protocols-limiting your options at times.

Beyond operating platform and choice of protocol, other features available to the hosting environment also influence deployment decisions and choice of host. In this article, I’ll describe the desired features of a hosting environment; provide you with an overview of WCF hosting options and their availability; and explain how to implement scenarios applicable to each environment.

Features of a Great Host

Hosting environments make it possible to expose your services to client applications. They facilitate request processing to service operations, but they can also play a critical role in the availability and scalability of your services. A great hosting environment should provide these important features:

• Executable Process/Application Domain: You can use any managed process to host WCF services, which implies the existence of an application domain (“app domain”).
• Configuration: A mechanism for external configuration should be available to support deployment and manageability. For managed hosts this is supplied by the application configuration file (app.config or web.config).
• Activation: Ultimately the service model instantiates the appropriate service type to handle incoming requests, but the host process must initialize the channel stack that receives incoming messages. You can do this activation at host startup but it is preferably done through message-based activation.
• Idle-Time Management: To conserve server resources during idle time, hosts can release unused resources. Hosts that support this feature usually provide a configurable timeout. Idle-time management relies on the activation capabilities of the host to instantiate resources as needed.
• Health Monitoring: To ensure availability a host process must always be running to service requests. Some hosting environments can proactively monitor their processes to ensure a new host process is started when existing processes are unable to service requests.
• Process Recycling: To avoid problems associated with memory leaks or faulty code, some hosting environments support configurable process recycling to “freshen up” running host processes.
• Management Tools: Sophisticated hosting environments also provide tools for configuring hosting features for greater control and manageability. This toolset sometimes contains tools for monitoring the health and status of running host processes.

There are three types of hosting environments for WCF services: IIS, WAS, and self-hosting. The term “self-hosting” refers to any application that provides its own code to initialize the hosting environment. This includes console, Windows Forms, WPF, and managed Windows services. Table 1 provides a summary of these three hosting environments and the features they support.

At a minimum, all WCF hosts provide an executable process and application domain in which services are loaded. They also provide support for external configuration. The remaining hosting features discussed here are built into IIS and WAS, but not provided by self-hosting environments. Despite this fact, self-hosting does have its value under the right circumstances.

In the sections to follow, I’ll discuss how the service model exposes WCF services, and then I’ll describe scenarios for self-hosting, IIS, and WAS.

ServiceHost

Regardless of the hosting environment, all WCF services must be associated with a ServiceHost instance to be accessible at run time. ServiceHost is part of the System.ServiceModel namespace, and is the centerpiece of the hosting story. A ServiceHost instance is initialized with information about the service type, one or more service endpoints, optional base addresses, and behaviors that govern how the service model processes requests to the service.

Initializing the ServiceHost

Listing 1 illustrates a simple example of a console host application initializing the ServiceHost programmatically. In fact, this listing is the entire listing for the host application. The application constructs a ServiceHost instance on startup, supplying the service type: HelloIndigo.HelloIndigoService. A single endpoint is created exposing its HelloIndigo.IHelloIndigoService contract over NetTcpBinding. In this example, the endpoint is initialized with a complete URI, removing the need for any base addresses.

After calling the Open() method the ServiceHost begins listening for messages. While the Console.ReadLine() statement blocks the console application to keep the process alive, the application processes incoming requests on their own thread taken from the thread pool. After closing the console, the using statement disposes of the ServiceHost instance calling its Close() method. At this point new requests are rejected while currently processing requests complete gracefully.

In this example, the console host only exposes one service. To expose multiple services, you can open multiple ServiceHost instances within the same host process.

By: Michele Leroux Bustamante

Michèle Leroux Bustamante is a Principal Architect with IDesign Inc., a Microsoft Regional Director, and an internationally known speaker and author. At IDesign Michèle focuses on designing scalable and secure architecture, Web services tools and technologies, and best practices for hosting 24x7 operations and services. Michèle is a member of the INETA (International .NET Association) Speakers Bureau and is .NET MVP for XML Web services. With her experience in Java technologies, Michèle also serves as a BEA Technical Director, advises the Web services track of SD, and is Program Advisor to the Web services program at UCSD Extension. Reach her at www.idesign.net or www.dotnetdashbaord.net.