Hosting and Consuming WCF Services

When your business relies on a service-oriented architecture, you need to make sure your services are robust. The most important driver behind the robustness of your application is where/how you host your service. You need to ask yourself several questions when thinking about hosting services: What are the availability requirements of my services? How am I going to manage and deploy my services? Do I need to support older versions of my services?

Learning how to cover these business requirements is essential to developing successful services. As you learned in Chapter 3, you have to host services on your own host. WCF doesn't come with its own host but instead comes with a class called ServiceHost that allows you to host WCF services in your own application easily. You don't have to think about any of the network transport specifics to be able to make sure your services are reachable. It's a matter of configuring your services' endpoints either programmatically or declaratively and calling the Open method of ServiceHost. All the generic functionality regarding bindings, channels, dispatchers, and listeners you learned about in Chapter 3 is baked into ServiceHostBase and ServiceHost. This means the responsibility of the application you use to host your service, the application where ServiceHost is running, is significantly less than you would expect up front.

This chapter is about which types of applications you can use to host ServiceHost. In addition, you will learn about the differences when you want to consume these services hosted in different applications.

After completing this chapter, you will have the following knowledge:

• The different hosting options available to you

• The advantages and disadvantages of each hosting option

• Guidance on when to choose each hosting option

• Architectural guidance on how Microsoft implemented the different hosting options and the extensibility points each option has