SOA Patterns: Basic Structural Patterns – Part 3
The Workflodize and Edge Component Patterns
Oct. 18, 2008 10:14 AM
Quality Attribute Scenarios
The main benefit of using Workflodize is the added flexibility. Programming a workflow is a visual process (at least with most workflow implementations), which is very easy to master. The added flexibility can also result in quicker time-to-market for change requests. Workflow is, in my opinion, one of the most important tools to incorporate in a service on the long and winding road to business agility.
Here are a couple of examples for scenarios that can point you to looking at the Workflodize Service Pattern.
Workflodize Pattern adds a lot of flexibility to a service as you can dynamically change behavior; another aspect of flexibility can be found in the Edge Component Pattern.
What we see here is the opposite of what we had in scenario 1; here the interface and technology are stable and the business logic changes
In this scenario we have a functionality that is not related directly to a single service and is mostly repetitive across services - as it takes pretty much the same code to log the request even if one service handles orders and the other handles customers.
The commonality between these scenarios is that we have different concerns (business logic, technology, logging, etc.) all bundled within each service. As we've seen in the different scenarios, each of these concerns can change independently of the others depending on the circumstances - we need a way to enable that flexibility so our problem is
How do we allow the business aspects of the service, technological concerns and other cross-cutting concerns like security, logging etc. to evolve in their own pace and independently of each other?
The simplest, not to say simplistic, option is not to do anything in particular. An example of this approach is taking a piece of logic and directly exposing it as a web-service which by the way, is very common in online samples that technology vendors, such as Microsoft (WCF) or Sun (JAX-WS), provide on their tutorials. However, when the handling of the contract is directly intertwined with the business logic implementation, the maintainability of the code greatly suffers - for example, it would have been very hard to support scenario 1 and replace technology using this approach.
We could try to solve the problem of replacing a technology for an existing service by making a new copy of the service and making the changes there, an approach also known as "own and clone." The problem is that this creates a maintainability problem as you now have multiple copies of the same business logic lying around and you'd have to make changes to all copies, not to mention that it doesn't solve problems such as the ones presented in scenario 3 of adding logging capabilities to several services.
If not doing anything and cloning don't work, maybe we can go for separation of concerns.
Add Edge Component(s) to the service implementation to add flexibility and separate between the business logic and the other concerns like contacts, protocols, end point technology and additional cross-cutting concerns.
• • •
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