Table 2 shows a couple of sample scenarios that can point you to consider the ServiceHost pattern.

Once you have a service up and running you need to decide whether the service should be passive and only wake up when a request arrives or if the service should be active and perform some chores such as publish its state and handle timeouts without waiting for its consumers to activate it. As its name implies, the Active Service Pattern allows a service to be active rather than passive.

Active Service
It's important for services to be Autonomous. Autonomy increases the loose coupling between services and spells greater flexibility for the overall solution. But what does autonomous services actually mean? One explanation I've heard was that autonomous means the teams working on different services can be autonomous. This definition means that there are few dependencies between the services as they only know each other by contract. This means that different teams can work independently, each focusing on its own service without stepping on each other's toes. While this is a nice "feature" to have, a much more valuable (as in "business value") definition is that the services are as self-sufficient as possible. Let's explain this using an example.

The Problem
Imagine a journal subscription agency such as Ebsco or Blackwell that needs to create a proposal for a client. The proposal service needs, among other things, to produce a "pro forma" invoice. To produce the pro forma, the service must get both the discount the business gives the customer as well as the discounts the business gets from the different publishers so that, for example, we can check if the proposal is profitable. Figure 3 shows a simple example for such a flow.

In the sample scenario the proposal service has to wait for two other services. While the customer service is internal and part of the same system, the publisher's discount service is most probably an external once - what will happen to our proposal service if the publisher's system is not online? The proposal service would be unavailable. Oops, even if we spent a gazillion dollars on making sure the proposal service was fault-tolerant, we now encounter a situation where it is unavailable. The reason is that the proposal service is coupled in time to the publisher service, which is external. The proposal service is not really autonomous.

How can I increase service autonomy and handle temporal concerns?

As the example above demonstrated, a passive service that only works upon request is problematic since the service might not be able to fulfill its contract (or its SLA) depending on how other external services behave.

One option is for the service to cache previous results, but this will provide a partial solution as it doesn't take care of data freshness and occasionally you'd have a cache miss and will need to contact other services anyway. Another problem with this approach is that when you have a lot of incoming requests and are "busy waiting" on the thread that handled the request on your service, you can get into a resources problem, as each of these requests is now waiting for external input.

Even if we manage to solve the caching problem mentioned earlier, we still need to be able to solve other temporal events. Temporal events are recurring or one-time events that are tied to time. For instance, producing monthly bills or publishing stock figures or any other recurring reports are all temporal events. One option to solve this is to choreograph the service from the outside. The problem with this approach is that you are externalizing business logic that is really the service responsibility. Remember that encapsulating business aspects are one of the reasons to go with SOA in the first place. We need to have another way to achieve this.

The Solution
Make the Service an Active Service by implementing at least one active class, either on the edge, the service, or both. Let the active class take care of temporal concerns and autonomy issues

The Active Service Pattern basically means implementing the "Active Class" concept on the service level (see Figure 4). "Active Class" as defined in the Official UML specification means "An object that may execute its own behavior without requiring method invocation." The same can be applied to services. This means that the service would have independent threads that are used to handle cyclic events such as monthly billing or publishing status. An Active Service can also monitor its own health, handle timeouts, and can even be used to handle requests.

•   •   •

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.