A new WSO2 white paper entitled "Practical SOA for the Solution Architect" positions SOA as a
... common sense discipline that is as relevant today as it has been ever since the information age began.
With this in mind, the paper tries to
... provide a practical approach to using SOA that is easily grasped and immediately applicable. It is also vendor-neutral since it deals with universally applicable concepts and also logical components that are likely to be found in any vendor’s product line-up.
The paper focuses on two most relevant aspects for a Solution Architect:
- At the technology level, Solution Architects need to understand the right tools for the job.
- At the data level, they need know how to reduce or eliminate unnecessary dependencies between systems.
When it comes to the technology (tools) layer, there are three core SOA technology components that are most frequently used, according to the paper:
- The Service Container
- The Broker
- The Process Coordinator
These components that Solution Architects need to put together existing and planned functional components to create an end-to-end business solution should be used as follows:
- The service container is a platform housing new services implemented as part of the solution
- The service broker is a tool allowing to expose functionality of existing enterprise application as a service. It serves as a combined adapter/transformer/mediator for existing functionality
- The process coordinator is used for implementing business processes, tying together execution of services.
According to the paper, in addition to these three, additional components commonly used in SOA implementations include: rules engines, data access tools, registry/repository tools, management and monitoring tools, governance tool, custom events processing, presentation support, etc.
The paper goes further, explaining that simply choosing correct technical components is not sufficient to ensure SOA success:
We need to ensure that the gains we have made through the use of appropriate SOA technology components are not negated by tightly-coupled data design.
It provides the following four rules that should be obeyed in order to achieve a SOA design with low data coupling:
- Identify implicit data and make it explicit - hide the changes occurring inside a system to shield others by simply ensuring continuing adherence to their contracts.
- Eliminate needless dependencies between systems - you should try and eliminate dependencies that don’t make sense.
- Keep domain data and message data loosely coupled - rely on data mapping rather than data generation or derivation to achieve this.
- Standardize vocabulary within a logical domain, not across the entire organization - trying to standardize vocabulary across an enterprise as a whole can be like "boiling an ocean"
The paper also provides several examples from the banking and insurance industry to explain practical applications of described concepts
It concludes by stating that:
These simple yet powerful ideas are key to effective SOA design, and you now have these conceptual tools in your repertoire of skills... [they] enable you to hit the ground running with your next project, so you can intuitively design a solution that conforms to SOA principles.
Although it is difficult to disagree with the conclusions of the white paper, and the importance of principles it defines, it does not really bring anything new compared to existing SOA publications. On the technical side, it is basically telling that the execution of services that can be either built from scratch leveraging service containers or by exposing existing legacy applications through the adapter/transformer/mediator pattern should be orchestrated by business processes. This same technical solution is a foundation of the modern ESBs. On the data side, the idea of "canonical" enterprise data model was introduced by EAI about 15 years ago and was widely adopted by many SOA implementations. As for implicit to explicit conversion and eliminating unnecessary dependencies - those are directly related to existing service design patterns - loose coupling of services and hiding service implementation behind well defined interfaces.
On another hand, reminding these principles to SOA practitioners is always useful.