Hosting and using WCF services

Brief introduction

If an enterprise relies on a service-oriented architecture, it must ensure that the service is running normally and reliably. The most important driver behind application reliability is where to host the service and how to host the service. When considering managed services, you must consider several issues in advance: what are the availability requirements for the service? How do I manage and deploy services? Do you need to provide support for older versions of the service?

Understanding how to meet these business requirements is critical to developing successful services. In the 3rd chapter you will learn that you have to provide your hosts to host services. Instead of hosting, Windows Communication Foundation (WCF) provides a class called ServiceHost that allows you to host WCF services in your own applications. You do not have to consider any network transport details to ensure that the service can be accessed. Simply configure the endpoint of the service programmatically or declaratively, and then call the ServiceHost open method. ServiceHostBase and ServiceHost integrate all the general features of bindings, channels, schedulers, and listeners that are covered in chapter 3rd. This means that the load of the application that is used to host the service (the application running ServiceHost) will be much lower than you expected.

This chapter discusses what types of applications can provide a hosting environment for ServiceHost. In addition, you will have an understanding of the differences that exist when using services hosted in different applications.

After reading this chapter, you will learn the following knowledge:

A variety of different hosting scenarios for your application

What are the advantages and disadvantages of each hosting scenario

Choose the guidance of the hosting plan according to the specific situation

Guidance on how Microsoft implements different hosting scenarios and how each scenario is extensible in terms of the architecture

Research on the carrying programme

On the Microsoft. NET platform, you can use Microsoft Visual Studio.NET to create several different types of managed Windows applications:

WinForms applications

Console Application

Windows Services

Web applications hosted in Internet Information Services (IIS) (asp.net)

WCF services provided in IIS 7.0, and was in Windows Vista or Windows Server 2007

If you take a closer look at the project templates that come with Microsoft Visual Studio 2005, you will find that there are other options available for you to use. Obviously, we think that no other template can be used as a viable solution in the service world. It is worth noting, however, that as long as WCF is able to provide a. NET application domain, you can run the service in any other type of application. (If you do not understand the rationale for. NET application domains, refer to the section on "Understanding. NET application Domains" below.) In fact, it all depends on your requirements for the host. Summarizing these alternatives, we focus on three common types of WCF service hosts:

Self-hosted in a managed. NET Application

Hosting in Windows Services

Hosting in different versions of IIS

As you can imagine, all of these hosts have associated project templates in Visual Studio and have their own characteristics, as mentioned earlier in this section. To better understand which host is the best choice in each case, you must understand the host's usual requirements and capabilities. Understanding this, we will detail each of the hosting scenarios.

Understanding. NET Application Domains

If you understand the role of the Windows process and how to interact with them through managed code, you will certainly have an understanding of the concepts of. NET application domains. To run managed. NET code in a process, you need to create an assembly. These assemblies are not directly hosted in the Windows process. Instead, the common language runtime (CLR) creates separate logical partitions, called application domains, in the process to isolate managed code. A single process may contain multiple application domains, each hosting different snippets of code encapsulated within the assembly. This partitioning of traditional Windows processes can provide several benefits through the. NET Framework.

The main benefits are as follows:

Because the concept of an executable file or library is not involved, the application domain determines the operating system-independent nature of the. NET platform.

You can control, unload, and load application domains according to your needs.

Application domains play a role of isolation in the process of symbiosis between applications or multiple application domains. application domains in a process are independent of one another, although a domain fails, but other domains are still functional.

Characteristics of the bearing environment

. NET applications require a Windows process that is hosted. You can host multiple. NET application domains within this Windows process. Application domains are a means by which the. NET CLR isolates managed code from Windows. The CLR initializes in each worker process and automatically creates a default application domain. The default application domain runs on a process and will not unload until the process is finished. The shutdown of the default application domain is controlled by the CLR. In most hosts, no code is running inside the default application domain. Instead, the host (or "process") creates a new application domain so that the application domain can be shut down independently of the process. In many applications, the ideal scenario is for client code and server-side code to be executed in different application domains, respectively. This requirement is usually considered for reasons of security and isolation.

The relationship between process and application domains is similar to the relationship between application and application domains and SERVICEHOSTWCF. As shown in Figure 5-1, each process has at least one application domain, and each application domain can host 0 or more WCF ServiceHost instances. WCF requires a minimum of one application domain to be hosted within a Windows process.

Figure 5-1: Process, application domain, and WCF servicehost relationships

Note: While multiple ServiceHost instances can be instantiated, it is easier to keep a ServiceHost instance in each application domain. You can expose multiple service interfaces with multiple endpoints within a single host. More advanced hosts (for example, IIS and was) can indeed instantiate multiple ServiceHost instances to provide isolation and a different security context.

Therefore, the primary task of the host is to provide the Windows worker process and application domain to WCF ServiceHost. In addition, WCF relies on the security and configuration features provided by the application domain. The Windows process always runs with the default identity, and the WCF service can use this out-of-the-box identity at any time. However, WCF provides several levels of analog user functionality (see Chapter 7th of this book). If you do not use these features, the Windows process running the service provides a security context. As mentioned in the previous chapters, WCF relies on the configuration features in the. NET framework by default, which you can access through application domains.

Some hosts also have other features that manage the applications that are running. Most notably, IIS also features automatic process recycling, resource throttling, logging, health indicators, and more. You can learn more about these topics through the entire chapter. (Different versions of IIS have different manageability features supported by WCF.) Most obviously, IIS 5.1 in Windows XP has some limitations in managing the user interface. ）