Practical SOA for the Solution Architect

Most IT practitioners often lose sight of the core principles of Service-Oriented Architecture (SOA). This article and its extended white paper are a retelling of the SOA philosophy in an easily understandable and practically applicable form, independent of the actual tools used to implement it. It is specially targeted to 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. Date: Wed, 12th Oct, 2011 Level: Intermediate Reads: 3401 Comments: 0 | Login or register to post comments Printer-friendly version Send to friend PDF version Post to twitter

 

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:

Business Rules	Data Access
Registry/Repository	Governance
Activity Monitoring	Complex Event Processing
Presentation Support	Identity and Access Management

 

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.