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.

Service-oriented architecture (SOA) has become the leading solution for complex, connected business systems. While it's easy to grasp the theory of SOA, implementing well-designed, practical SOA systems can be a difficult challenge. SOA Patterns provides detailed, technology-neutral solutions to the challenges by providing architectural guidance through patterns and anti-patterns. Part 1 of this excerpt focuses on two patterns that address matters of services. These are the patterns you are most likely to use even if your service has modest requirements. The patterns in this excerpt are relevant to implementing the Services (see Figure 1).

There are five patterns in this chapter; Table 1 lists all of them along with the problems they address. In this excerpt we will cover two of them: ServiceHost and Active Service.

Table 1: List of patterns

ServiceHost
The first pattern we will talk about is one of the most basic patterns if not the most basic one. The ServiceHost Pattern deals with the environment that runs the services instances and handles some of the rote tasks associated with that.

The Problem
Pick a service, any service (don't tell me what it is :). You have some code that sets up listeners for incoming messages or requests. You have some code to wire up components, and you have some code that initializes and activates the service. You probably also have some code to configure your service Well? How did I do? Chances are you have most of if not all these pieces of code somewhere in your service.

There are quite a few tasks that are repetitive and common. Maybe there is something we can do about it.

How can you make your services adaptable to different configurations easily and save yourself the repetitive and mundane tasks of setting listeners, wiring components, etc.

The first option, or actually non-option, is to rewrite the wiring and the rest of the repetitive code for each and every service. Obviously, this is not a good option - for one you are likely to introduce bugs as you write something again and again. The multiple copies of the same code problem are even worse when we consider maintaining this code. During maintenance you not only need to make bug fixes and changes for each service, but also make sure that you didn't miss any of them and all the services are up to date.