Self-Hosting Your Service

The most flexible and easiest way to host WCF services is by self-hosting. To be able to self-host your services, you have to meet two requirements. First, you need the WCF runtime; second, you need a managed .NET application in which you can host ServiceHost. It is your own responsibility to write the code that starts and stops the host.

The following are the advantages of self-hosting:

Is easy to use

With only a few lines of code you have your service running.

Is flexible

You can easily control the lifetime of your services through the Open() and Close() methods of ServiceHost<T>.

Is easy to debug

Debugging WCF services that are hosted in a self-hosted environment provides a familiar way of debugging, without having to attach to separate applications that activate your service.

Is easy to deploy

In general, deploying simple Windows applications is as easy as xcopy. You don't need any complex deployment scenarios on server farms, and the like, to deploy a simple Windows application that serves as a WCF ServiceHost.

Supports all bindings and transports

Self-hosting doesn't limit you to out-of-the-box bindings and transports whatsoever. On Windows XP and Windows Server 2003, IIS limits you to HTTP only.

The following are the disadvantages of self-hosting:

Limited availability

The service is reachable only when the application is running.

Limited features

Self-hosted applications have limited support for high availability, easy manageability, robustness, recoverability, versioning, and deployment scenarios. At least, out-of-the-box WCF doesn't provide these, so in a self-hosted scenario you have to implement these features yourself; IIS, for example, comes with several of these features by default.

In other words, you shouldn't consider self-hosting for enterprise scenarios. Self-hosting is suitable during the development or demonstration phases of your enterprise project. Another suitable example where you would self-host your services is when you want applications on a user desktop to communicate with each other or in a peer-to-peer scenario, as described in Chapter 12.

You saw several examples of self-hosting scenarios in Chapter 3. These examples all used simple console applications. To illustrate this better in a real-life scenario, this chapter presents a WinForms application that hosts a service that tracks published quotes for the Market Makers actors in the QuickReturns Ltd. case study.

For this scenario, you have two distinct WinForms applications. One is the Market Makers Manager application that Market Makers can use to publish quotes and trade their securities. The other is a separate WinForms application that tracks published quotes. It does that by exposing a service that implements the ITradeTrackingService contract, as described in Listing 5-1. The Market Makers Manager application calls this service when it successfully publishes a quote through the TradeService.

Example. ServiceContract for the Trade-Tracking Service

using System.ServiceModel;
using QuickReturns.StockTrading.ExchangeService.DataContracts;

namespace QuickReturns.StockTrading.TradeTrackingService.Contracts
{
    [ServiceContract()]
    interface ITradeTrackingService
    {
        [OperationContract()]
        void PublishQuote(Quote quote);
    }
}