SOA Patterns: Basic Structural Patterns – Part 3
The Workflodize and Edge Component Patterns
Oct. 18, 2008 10:14 AM
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
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.
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
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.
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