Introduction – Why Practical SOA
Service-Oriented Architecture (SOA) is a term that may seem tired and over-hyped today.
However, it is WSO2’s case that SOA has always made perfect sense. It’s just that IT practitioners have often lost sight of its core principles in the noise and confusion of the market battle to sell SOA products. Our white paper, “Practical SOA for the Solution Architect”, is a retelling of the SOA philosophy in an easily understandable and practically applicable form, independent of the actual tools used to implement it.
Our target audience is the Solution Architect, because at the end of the day, SOA is nothing but a way to put components together to build flexible, durable and reusable business solutions, and the solution architect is the person responsible for this outcome.
The Two Layers of Practical SOA
The solution architect must consider two layers of the design – technology and data. If we only look at the technology layer, we will fail to “do SOA”, because poor data design can result in the dreaded tight coupling that SOA tries so hard to eliminate.
The 3 Core SOA Technology Components
At the technology layer, it’s sufficient to remember that there are just three core components commonly required for SOA solutions.
1. The Service Container
When you have to write business logic from scratch and can’t buy it off the shelf, yet want to reuse this functionality in different parts of your business, you will need to host it within a Service Container.
2. The Broker
When business logic or data already exists somewhere in your organisation (as is most likely
the case), but it’s not readily accessible or usable, you will need to use a Broker to access it.
A Broker acts as an adapter to hide proprietary protocols, as a transformer to convert data
into a more digestible form, and as a mediator to hide the physical location and other attributes of the native service or data provider that should not be exposed.
3. The Process Coordinator
When a business process requires many steps to be performed, and these steps often depend on the situation at run-time, a more dynamic approach to composing services is required. A Process Coordinator is the right component to use in such cases.
Supporting Technology Components
While the above three components are “core”, there are other components at the technology level that play a supporting role in refining a solution design by providing specialised
capabilities in different areas. The most common of these areas are:
||Complex Event Processing
||Identity and Access Management
While the technology layer of a solution is very important, we must not neglect the design
of the data layer. Many ostensibly SOA-based solutions suffer from the negative impacts of
tight coupling, because some simple principles were not followed. Adherence to the following four simple principles can eliminate such expensive mistakes.
1. Identify and Remove Unnecessary Dependencies
Once you understand the dependencies that exist between systems, you can also identify
which of them are legitimate and which of them exist for legacy reasons that no longer
make sense. You should try and eliminate dependencies that don’t make sense.
2. Identify Implicit Dependencies and Make Them Explicit
Sometimes, even legitimate dependencies are assumed knowledge rather than explicitly
stated. These can throw up nasty surprises in future. Hence all legitimate dependencies
must be explicitly stated in the form of contracts between systems. You can better manage
change when you have confidence in the dependencies that exist between systems, and you
have ways to hide the changes occurring inside a system to shield others by simply ensuring
continuing adherence to their contracts.
3. Ensure a Loose Association of Message Data with
A misconception that lies at the heart of much data-related tight coupling is the failure to
distinguish between domain data (which is the data held inside systems) and message data (which is the data exchanged between systems). While the two are obviously related, an excessive dependence of one on the other can make integration brittle. You must ensure that
you only associate message data with domain data (perhaps through mapping) rather than
attempt to derive or generate one from the other.
4. Choose an Intermediate Granularity for Domain Data Models
Sometimes, SOA practitioners go too far in the other direction, i.e., they attempt to find a
universal vocabulary that covers every data item in their organisation. Rather than waste
time and effort on this mammoth activity, you should identify more granular sub-domains
with their own domain data models, and standardise these. Broker components exist to
transform data between domains, and you should exploit them.
SOA is a practically useful discipline and fairly simple at its heart. WSO2’s white paper “Practical SOA for the Solution Architect” provides a quick refresher for those who may have lost
sight of the core SOA principle of loose coupling in all the seeming complexity of various
SOA products in the market. Simple principles at the technology and data layers will help
solution architects use SOA tools in a way that delivers on the promise of SOA to reduce
operational cost and risk, and improve organisational agility.
Download the full white paper