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 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.
At the technology layer, it’s sufficient to remember that there are just three core components commonly required for SOA solutions.
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.
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.
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.
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|
|Activity Monitoring||Complex Event Processing|
|Presentation Support||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.
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.
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.
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.
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.