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:

Data Principles

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

Domain Data

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.

Conclusion

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