The hosting options for WCF services are based on the activation model that you want your services to use. You can use the self-hosted approach, or you can host your service in IIS. If you elect to use the self-hosted approach, you have to manually activate the service. If you decide to host the service in IIS, it will be automatically activated the first time it is called.

Self-Hosted vs. IIS-Hosted

Services can be hosted using any number of .NET 2.0 code execution types. A service can be hosted within a console, a Windows forms, or a Windows service application. In these types of hosts, the code to activate and run the service has to be written within your own custom code. This is what classifies this approach as self-hosted. One advantage you have when self-hosting your WCF service is that you have more control as you are explicitly launching the host when you want to. Another advantage is that you have the flexibility to use transports other than HTTP with service development today.

The more popular option for hosting services is within IIS. IIS gives you automatic activation of your WCF service code. There are also a number of other benefits to using IIS for hosting service code. You will get periodic app domain recycling which helps with the stability of the service. IIS also recognizes changes in configuration files; these changes will trigger another app domain refresh, which will pick up those changes. IIS-hosted services can also be tested easily through a standard Web browser.

One point of clarification is that self-hosted services are the only way to use any transports other than HTTP. This is true today but will be remedied in the future. As soon as Windows Activation Services (WAS) is made available as part of the operating system, other transports will be available for invoking IIS hosted-services. The plan, as I understand it, is to deliver WAS with IIS 7 and Windows Vista.