SOA Patterns: Basic Structural Patterns - Part 1
Solving some of the more common issues related to services
Oct. 2, 2008 05:00 PM
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.
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 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.
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week