Learning WCF

Self-Hosting

Self-hosting is the simplest way to host your services, but it is also the approach that yields the least number of hosting features. As the label implies, self-hosting requires you to write the code necessary to initialize the ServiceHost and manage its lifetime. At a minimum, you provide a managed process, instantiate a ServiceHost for each service, and then initialize them with endpoints and binding configurations that define the communication channel for each endpoint for incoming messages.

Typically, you’ll keep ServiceHost instances alive for the lifetime of the application in which they are hosted. The ServiceHost is normally constructed on the application thread, but the service model allocates worker threads for incoming requests to its service endpoints. Your job is to keep that application thread and the ServiceHost alive as long as you want to process requests. Any managed process will suffice for this purpose including console, Windows Forms, WPF, and Windows services, as I discussed earlier.

Console Applications

Console applications are a popular hosting environment for developing and testing services. As I discussed earlier, you need only create and open the ServiceHost instance and keep the console process alive to receive and process requests. Example 4-2 illustrates how a typical console application achieves this, using Console.ReadLine( ) to keep the thread alive.

Console applications are ultimately impractical for deploying production services for a two reasons:

1. They require a user be logged in to the machine to start the process.

2. The console can be easily closed, taking the communication channel along with it.

Still, you can expect to use console hosts to verify basic service functionality in unit tests and in early prototypes.

Windows Applications

Both Windows Forms and WPF applications can be useful for hosting WCF services associated with a user interface (UI). In this case, the UI thread keeps the application alive, thus any ServiceHost instances can receive requests for the duration of the application lifetime, unless it is explicitly closed.

Here are a few possible scenarios for Windows application hosts:

• Chat applications that participate in a peer mesh will expose services to receive broadcast messages and likely provide a UI.

• Windows client applications may host services in-process to consume local services without crossing a process boundary. For example, a smart client application may use local services when operating offline, and remote services while online. Another example could be when two applications on the client must share functionality hosted in another process.

• Services deployed to client (less likely on server machines) may have an associated UI if the service presents an activity log or provides some administrative controls for service activation and deactivation.

Hosting services inside a Windows application does, however, have some drawbacks. For one, they require a user to be logged in to start the application, which limits their usefulness in server deployments since server machines are generally unattended. More importantly, when UI threads are involved, you must understand which thread the service will be hosted on, and deal with possible concurrency implications. Hosting on the UI thread will be explored shortly.

Windows Services

Unlike console and Windows applications, Windows services do not require a user to be logged in to the machine to start the service. In fact, Windows services are traditionally configured to start automatically on unattended server machines and do not require user interaction.

As with console and Windows applications, any ServiceHost instances must be kept alive for the lifetime of the Windows service. Due to the server-side nature of this hosting environment, concurrency is still a concern, though it may not specifically be related to a UI thread since most Windows services do not have an associated interface (and should not on a server machine). Windows services will usually allow multiple concurrent requests to increase throughput, making it necessary to protect any other shared resources used by hosted services.

Later in this chapter, I’ll explain how to host services in a managed Windows service.