The advantage of workflows is that it gives you a tool that makes you think in building blocks called activities and lets you rearrange them into processes in a flexible and easy way. Modeling the processes as a flow of activities means it would be easier to identify the stable ones and reuse them as the change requests arrive. Since the activities can be tested by themselves, reusing an activity means you don't have to retest it as heavily as you would otherwise. The flexibility for rearranging the activities means you can quickly respond to changing business needs.

One question that the inviting option to easily change the service behavior (via workflow) raises is: Should the contract version be updated every time the behavior changes? The answer is, of course, it depends. My guiding rule is that if the Liskov's Substitution Principle is kept in regard to the way the contract behaves, then there's no reason to add a new version.

When to Change Contract Versions - Liskov's Substitution Principle for Services
Liskov's Substitution Principle, which is also known as design by contract, is an object-oriented principle. Barbara Liskov originally published it as follows: "If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T." In plain English this means that a subclass is a class that can be usable instead of its parent class without breaking the behavior of any user of the base class. Applied to SOA this means that when changing the internal behavior of a service, you don't need to create a new version of the contract if, for each operation defined in the contract, the preconditions are the same or weaker and the post-conditions (i.e., the outcome of the request) are the same or stronger. In other words, in order to keep the same contract version, the new version of the service should meet the expectations that consumers of the service have come to expect from the old service version's observable behavior.

Let's Workflodize the example scenarios and see how adding a workflow can help us. To recap, the scenario talks about introducing new usage plans quickly for a mobile operator. When a new plan is introduced, the back-end systems are usually not ready - it takes a few days or weeks to change, test, and deploy them. One thing we can use the workflow for is to route requests for new plans that don't have back-end implementations for human intervention. For example, we can let some customer service register the change in the CRM and then notify technicians to configure the network, etc. Later when the back-end systems are ready, we can reroute the flow to them. Furthermore, there are many steps in the flow that are stable, as I already mentioned, getting the customer's demographics (name, address, etc.), offering add-on and accessories for phones, etc. These steps can be reusable activities or steps in the flow that most, if not all, selling processes reuse. Adding a workflow in this scenario greatly enhanced the business's ability to react and remain agile. When one of the competitors launches a new plan that is all the rage, this mobile operator is able to react and launch a competing plan within a day or less. This is a real and tangible business value.

The ability to handle long-running processes is another advantage of workflow engine. Visualizing the complete processes that involve multi-message interaction makes it easier to understand the big picture and how the process unfolds and thus debug the process from the business perspective.

Workflodize can, of course, be combined with other patterns, for example, it's easy to use job scheduling (which most if not all workflow engines support) to implement the Active Service Pattern.

A pattern closely related to Workflodize is Orchestrated Choreography; both patterns use the same underlying technology of using a workflow engine. Nevertheless, even though the technology used is the same, there are different architectural considerations that warrant a different pattern, for example, one easily observable difference is that Workflodize is constrained to stay within the boundaries of a single service and the Orchestrated Choreography has to do with adding workflow coordination between services.

Technology Mapping
The technology mapping section takes a brief look at what it means to implement the pattern using existing technologies as well as mention places technologies implement the pattern.

The natural technology mapping for the Workflodize Pattern is, of course, workflow engines. There are many workflow engines in the market. Microsoft released Windows Workflow Foundation as part of.NET 3.0, which I guess will make it a popular choice in the .NET world - though there are several other companies that provide .NET workflow solutions like Skelta or K2. Java, as usual, has more options from the usual suspects such as IBM and JBoss as well as companies that specialize in workflows such as Flux. Oracle even has a workflow package for its database (WF_Engine) and a supporting Java API.

Most workflow engines have a built-in visual designer for modeling the workflows themselves. Figure 10 shows a modeling of the Active Service Pattern for report generation using the visual designer of Flux.

While using a visual editor such as the one in Figure 10 is usually the preferred option for modeling flows, you can usually also use XML to define the workflows. Several tools, such as the open source (BSD license) OpenWFE, don't have a visual editor at all and rely solely on XML for configuring their workflows. Listing 1 shows an example of a flow modeled in OpenWFE.

Choosing a Workflow Engine - The Flexibility Perspective
There are a few simple building blocks for modeling workflows such as activities, exclusive choice (one of possible execution paths), and parallel split. You should be aware that sometimes there are more complex scenarios. For example, how to merge many execution paths without synchronizing them, but still execute the subsequent activity only once. Another example is how to handle multiple instances of an activity (what if they need synchronization, what if the number of activities is not known in advance, and so on) and quite a few other such problems. Solutions to these problems are defined as Workflow Patterns (many of them are described in "The Workflow Patterns page," which can be found at http://is.tm.tue.nl/research/patterns/patterns.htm).

I suggest that you also take a look at how many of the workflow patterns the engine supports to ensure you will have the flexibility and not hit a brick wall later in the game. Flexibility, of course, is not the only selection criteria (you still need to consider performance, availability, security, etc.) but I think it is an important one for a tool whose main premise is to introduce flexibility.

Some of the workflow engines such as Microsoft Biztalk or WebSphere MQ Workflow are better suited for orchestrating inter-service interaction and not as internal workflows due to their costs.

•   •   •

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.