A more plausible option is to create a library of common tasks and have each service work with the library's API. This helps a bit, but you are still left with coding the wiring that is needed to utilize all of the library's functionality.

Another option is using inheritance to create a superclass that implements the common functionality and have each service inherit from that class. Using inheritance is also problematic since the service functionality usually won't fit within a single class, due to the granularity of what a service is. In addition, different services handle completely different business areas - otherwise they would be the same service, so it usually doesn't make sense to make them a single class hierarchy.

Using inheritance almost solves our problem as we write the code once and the customization only occurs where the services differ - if we want to get the same behavior without using inheritance we need to use a framework.

The Solution
Create a common ServiceHost component that acts as a container or a framework for services. The container is configurable and performs the wiring and setup of services (see Figure 2).

The ServiceHost acts as a mini-framework that can have several responsibilities. The first responsibility is to instantiate the right components or classes that the service consists of. The ServiceHost is also responsible for reading configuration information, for instance, the ServiceHost can read the port that consumers can use to contact the service. Another responsibility is to set up the service's environment, for example, setting up listeners on the endpoint. Last, the ServiceHost can be responsible for wiring the components - binding a protocol to the listener to an endpoint or setting up a connection to the database. The common denominator of these responsibilities is that they are all related to instantiating and initializing services and, as we've seen in the problem introduction, you are likely to encounter them in more than one service. As mentioned earlier, the ServiceHost is a framework, which is a little different from the library concept mentioned in option two. Basically it's a collection of utility classes/methods your code can call on to get some functionality. Frameworks, on the other hand, contain some functionality or flow and call your code to extend or make the flow a specific one. The principle of frameworks calling your code is known as "Inversion of Control." It is in wide use in object-oriented frameworks such as Spring or Spring.NET, picocontainers, and the like.

The ServiceHost pattern has several benefits compared with the other options. One benefit was already mentioned - as a framework the ServiceHost performs the work and only calls your code to fine-tune the behavior rather than leaving this orchestration to you. Another benefit is that it better addresses the Open Closed Principle (OCP). OCP states that a class should be open to extension but closed for modification, which is exactly what we get when we use the framework concept.

A ServiceHost may host more than one service - though this is probably not very common. There was one system I built where we had to scale a solution down to run on a single computer and this was handy. The more likely situation is that a service would span more than one computer and then you would have several ServiceHost instances, each hosting parts of the service rather than the complete service

The ServiceHost pattern is commonly used by technology vendors - we can see that in the technology mapping section.

Technology Mapping
This section takes a brief look at what it means to implement the pattern using existing technologies and mentions where technologies implement the pattern.

The ServiceHost is a fundamental SOA structural pattern and as such it is supported by most available technologies. Both JAX-WS and Windows Communication Foundation let you configure your services in markup (XML) and have the web server, i.e., the servlet engine or IIS, do most of the wiring for you.

Windows Communication Foundation also has a class called ServiceHost. Microsoft's documentation describes the ServiceHost as follows: "Use the ServiceHost class to configure and expose a service for use by client applications when you are not using Internet Information Services (IIS) or Windows Activation Services (WAS) to expose a service. Both IIS and WAS interact with a ServiceHost object on your behalf." Basically the built-in WCF implementation of a ServiceHost is very much in line with the pattern described here.

If you are implementing the ServiceHost pattern by yourself, perhaps on top of the technology one, you can take a look at a lightweight container like Sprint (or Spring.NET), picocontainers, etc., to help you out with wiring and instantiation. There aren't many other technological implications as the ServiceHost pattern is a relatively simple pattern.

Lightweight Containers and Dependency Injection
Spring and a few other frameworks are known as "lightweight containers." The nice thing about these "Lightweight containers" is that they allow you to increase loose coupling and the testability of your solutions. They perform this magic through the use of the Dependency Injection Pattern, which is a non-SOA pattern. Dependency Injection, as the name implies, happens when a class lets a third party that acts as an "assembler" provide the interfaces it depends on. Using Dependency Injection, a class no longer has to depend on a specific implementation but rather it depends only on the interface or abstract class. This helps increase testability as you can now supply stubs or mocks for the class to simulate its environment. It also helps flexibility as you can easily change the implementation of the dependencies as long as they keep their contract.

As we've seen, the ServiceHost Pattern is simple but effective and is widely used. You can take a look at the Further Reading section at the end for links to resources that expand on the technologies mentioned in this section.

Quality Attribute Scenarios
The quality attribute scenarios section talks about the architectural benefits of utilizing patterns from the requirements perspective. Most of the architectural requirements are described from the perspective of quality attributes (scalability, flexibility, performance, etc.) through the use of scenarios where these attributes are manifested. The scenarios can also be used as a reference for situations where the pattern is applicable.

The main reason to use the ServiceHost pattern is reusability. Reusability is increased by the fact that common tasks that are needed by many services are written only once. A nice side-effect of reusability is also increased reliability as you also only need to debug once. The other quality attribute the ServiceHost Pattern provides is portability. Portability is enhanced by the separation of concern effect of the pattern, as was demonstrated in the scale-down example I mentioned earlier. Another facet of portability comes from the ability to configure the service context in markup.

•   •   •

This article is based on the book SOA Patterns (http://www.manning.com/rotem) scheduled to print February 2009. This article is courtesy of Manning Publications (http://www.manning.com). The ebook is available and sold exclusively through Manning Publications.