Understanding the SOA Reference Architecture

What is SOA?

A quick refresh of  SOA definition, a service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity.  Service-oriented architectures are not a new thing. The first service-oriented architecture for many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on the CORBA specification 

Wikipedia defines SOA (Service-oriented architecture) as a style of software design where services are provided to the other components by application components, through a communication protocol over a network. The basic principles of service-oriented architecture are independent of vendors, products and technologies.[1] A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online.

Key points to note are that a service has four properties according to one of many definitions of SOA:

•     It logically represents a business activity with a specified outcome.
•     It is self-contained.
•     It is a black box for its consumers.
•     It may consist of other underlying services

Key Business Benefits of SOA

As a flexible and extensible architectural framework, SOA has the following defining capabilities:

1.  Reducing Cost:Through providing the opportunity to consolidate redundant application functionality and decouple functionality from obsolete and increasingly costly applications while leveraging existing investments.
2. Agility: Structure business solutions based on a set of business and IT services in such as way as to facilitate the rapid restructuring and reconfiguration of the business processes and solutions that consume them.
3. Increasing Competitive Advantage: Provide the opportunity to enter into new markets and leverage existing business capabilities in new and innovative ways using a set of loosely-coupled IT services. Potentially increase market share and business value by offering new and better business services.
4. Time-to-Market :Deliver business-aligned solutions faster by allowing the business to decide on the key drivers of a solution and allowing IT to rapidly support and implement that direction.
5. Consolidation :Integrate across silo’ed solutions and organizations, reduce the physical number of systems, and enable consolidation of platforms under a program of “graceful transition” from legacy spaghetti dependencies to a more organized and integrated set of coexisting systems.
6. Alignment : SOA enables organizations to better align IT to business goals, enabling the business to associate IT with capabilities that an organization wants to achieve in alignment with its strategic plan, leading to both sustained agility and re-use over time.

However, significant challenges in creating an SOA solution still remain:

•     Service identification,
•     Service selection,
•     Service design,
•     Solution element selection and combination,
•     Service modelling
•     Service governance,
•     Interoperability and the ability to identify different components key to the effective design, usage, and evolution of SOA.

For example, from a technical perspective, the architect needs to answer questions such as:

1.     What are the considerations and criteria for producing an SOA solution?
2.     How can an SOA solution be organized as an architectural framework with inter-connected architectures and transformation capabilities?
3.     How can an SOA solution be designed in a manner that maximizes asset re-use?
4.     How can automated tools take the guesswork out of architecture validation and capacity planning?

In order to address these issues, there is need for a SOA Reference Architecture for SOA-based solutions. SOA reference architecture provides a high-level abstraction of an SOA partitioned and factored into layers, each of which provides a set of capabilities required to enable the working of an SOA. Each layer addresses a specific set of characteristics and responsibilities that relate to unique value propositions within an SOA. As mentioned above, underlying this layered architecture is a meta-model consisting of layers, capabilities, Architecture Building Blocks (ABB) or ABB, interactions, patterns, options, and architectural decisions and the relation between capabilities, ABB, and layers. These will guide the architect in the creation and evaluation of the architecture.  Likewise, an ABB represents a basic element of re-usable functionality, providing support for one or more capabilities, that can be realized by one or more components or products; examples of the responsibilities of an ABB include: service definition, mediation, routing, etc.