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

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.

Quality Attribute (level1)	Quality Attribute (level2)	Sample Scenario
Flexibility	Add process	For radical all pre-paid plans, adding support for the new plan will take less than 2 days.
Reusability	Core module	Reuse 90% or more of the of the common sales process for each new plan

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.

Edge Component
The last pattern of the basic patterns is the Edge Component Pattern. Unlike the other patterns, which are basic just because they are very common, the Edge Component is also basic because it is a platform for implementing other patterns. Because the Edge Component Pattern is a step in implementing other patterns, it's a little hard to come up with a concrete example that shows exactly why it is needed, since the concrete examples fit the patterns that build on the Edge Component. Instead I'll try to introduce few short examples and the communalities between them will lead us to the Edge Component.

The Problem
Scenario 1
At one company I worked for we developed a Military Naval C4I platform. This platform had services that are reusable per solution. For example, one of the core services provides a unified and centralized view of targets. The first implementation that was built on that platform used a messaging infrastructure using TIBCO Rendezvous. The next implementation has to use a different technology altogether (WSE 3.0 [Microsoft interim solution for the WS-* stack before Windows Communication Foundation]). Both implementations had to use the same business logic but needed different technologies to access that logic.

Scenario 2
On another project (that is also mentioned in the Workflodize pattern), a cellular carrier constantly wanted to introduce new usage plans and offerings such as friends and family, night rate, and the like to a service that handled ordering . The service interface remained pretty stable as the changes in the details were part of the XML, but the business logic kept changing and adapting to the new plans.

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

Scenario 3
The last scenario is a common situation in many projects. You normally have more than one service in a system. Each of these services handles a different business aspect, yet all of them have to perform common tasks such as making sure a request is authorized before performing a request, saving an audit trail, etc.

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[1] 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.

The Solution
Separation of concerns is a well-known concept in the object-oriented thinking. The root principle behind it is known as the "The Single Responsibility Principle" or SRP for short. SRP states that a class should have only one reason to change and that a responsibility is such a reason. We can apply the same principle within SOA and consider the business logic as one responsibility and the other concerns as another responsibility we get the following pattern:

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.

• SOA Patterns: Basic Structural Patterns - Part 1
• SOA Patterns: Basic Structural Patterns – Part 2