How can an Active Service Pattern help us solve the problems mentioned earlier? As Pat Morita playing Mr. Miyagi said in "Karate Kid" - "Best defense: no be there." If you want to avoid waiting for another service, your best defense is not to get to that situation in the first place; you can actively, periodically, go and fetch data from other services to refresh your caches. You can also save other services the trouble and proactively publish your own state changes. Caching data locally can seem to induce a data duplication problem but it doesn't (see callout for details).

Caching and the Data Duplication Problem
I am sure that several of you, especially those of you with a database background, who read the suggestion to actively go and fetch and cache data from remote services, jumped out of your seats and questioned my sanity for promoting data duplication. However, the way I see it, this is not really the same data. The data that is cached in a service is that service view of the data. It can be aggregated, processed, or otherwise altered to fit the service needs. Naturally, one caveat you must keep in mind is that the service that caches the data is not the master of the data.

A thread with a timer can take care of most of the other temporal events (you can have a timer per event if you have few events or wake up every known interval, see what events needs to be handled, and process them if you have a lot of possible events).

A thread in the Edge Component(s) is a good way to deal with contract-related temporal issues (e.g., make sure we publish state on time, timeouts, etc.), while a thread on the service takes care of purely business-related concerns such as sending monthly bills or handling incoming message queues.

Let's look at how the situation shown in Figure 3 can be redesigned using the Active Service Pattern. To recap, Figure 3 shows a flow for a proposals service that needs to get external data from an internal customer service and an external publisher service to produce a pro-forma for a customer (see Figure 5). Now the Proposals service actively goes to fetch discounts on a regular basis and caches the results, thus when a request to produce a pro-forma arrives, the proposal service can immediately calculate the discount and return a reply more quickly, plus it doesn't depend on the external services to be there when the request for producing the pro-forma arrives. Using Active Service, the coupling between the proposals service and the other services are decoupled in time.

The Active Service Pattern is mostly a mindset pattern and doesn't have a lot of technological implications.

Technology Mapping
The technology mapping section usually talks about how the pattern is implemented using SOA-related technology; however, since there aren't real technological challenges in implementing the Active Service Pattern this section will be brief.

The technological idea behind the Active Service Pattern is simply to have an active thread on the service and/or the Edge Component that will provide some specific functionality that you will have to code. Basically, the Active Service Pattern relies on threading technologies that are available in any language you may want to use. The real trick is to decide what you want to do with this thread. The previous section showed some ideas for that such as caching data from other services and handling recurring reports.

The next question is when do you want to use the Active Service Pattern? Let's look at few scenarios that may make us consider this pattern.

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 the scenarios where these attributes are manifested. The scenarios can also be used as a reference for situations where the pattern is applicable.

Active Service is the prerequisite for few other patterns such as decoupled invocation and blogjecting watchdog mentioned earlier, and those patterns help handle many quality attributes such as reliability and availability. Nevertheless, even applied alone the Active Service Pattern helps satisfy several quality attributes.

Active Service helps satisfy latency aspects by allowing data to already be available for the service to consume. It helps with deadlines by making sure that the service will perform its tasks when needed in order to meet deadlines (such as producing monthly bills on time). Another quality attribute that benefits from the Active Service Pattern is availability, since polling other services and caching their data means the service's availability is less dependent on other services availability.

Table 3 lists a few sample scenarios where the Active Service Pattern can help.

The architectural scenarios that can make us consider using the Active Service pattern.

This excerpt dealt with few of the basic structuring patterns for building services: ServiceHost, which makes a common wrapper to host service instances and reuse across services, and ActiveService, which has at least one independent thread in the service so it can initiate

Resources

• Liskov, B. Data Abstraction and Hierarch [Conference] // Proc. of OOPSLA conference.1988.
• Anderson, R.W., and Ciruli, D. Scaling SOA with Distributed Computing [Journal] // Dr. Dobb's Journal. - 2006.

•   •   •

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.