Arnon Rotem-Gal-Oz

Subscribe to Arnon Rotem-Gal-Oz: eMailAlertsEmail Alerts
Get Arnon Rotem-Gal-Oz: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: SOA & WOA Magazine

SOA & WOA: Article

SOA Patterns: Basic Structural Patterns – Part 3

The Workflodize and Edge Component Patterns

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

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 ( scheduled to print February 2009. This article is courtesy of Manning Publications ( The ebook is available and sold exclusively through Manning Publications.

More Stories By Arnon Rotem-Gal-Oz

For the past 10 years Arnon Rotem-Gal-Oz has been an architecture and system designer of large distributed systems including C4ISR systems, IP customer care and billing systems, and BI engines. He has experience with a variety of technologies (.Net, J2EE, CORBA, COM+, X-Windows) on diverse platforms (Unix, Windows, Dos, AS/400). He currently works for Rafael as the Biometric line development manager.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.