The SOA RA Provides a Way to Assess or Design your SOA

By Dr. Ali Arsanjani, IBM

The Standard in Summary

The SOA Reference Architecture (SOA RA) published by The Open Group provides a prescriptive means of assessment or creation of a service-oriented architecture (SOA) solution, including the architecture for Cloud-based solutions. It does so by grouping the capabilities required of an SOA into a set of layers, each containing a set of Architectural Building Blocks (ABBs) that can serve as a checklist for an implementation of an SOA, depending on the level of maturity required by an organization. The SOA RA is intended to support organizations adopting SOA, product vendors building SOA infrastructure components, integrators engaged in the building of SOA solutions and standards bodies engaged in the specifications for SOA.

The SOA RA provides a vendor-neutral product-agnostic perspective on the logical architecture that supports the service eco-system of providers, consumers and brokers bound together by services, their interfaces and contracts.

A high level description of the SOA RA can be found above. The layers shown in figure 1 above provide a starting point for the separation of concerns required to build or assess an SOA. Each group of the separated concerns is represented by a “layer” of their own.

Starting with a robust and complete set of building blocks provided by the standard is a key enabler for the achievement of the value propositions of an SOA, such as business agility, cost-reduction, faster time to market enabled by a flexible IT infrastructure. It does so in part by providing insights, patterns and the building blocks for integrating fundamental elements of an SOA into a solution or Enterprise Architecture. 

Background

In recent years, the decoupling of interface from implementation at the programming level has been elevated to an architectural level by loosely coupling the interface of a service consumed by a service consumer from its implementation by a service provider and by decoupling the implementation from its binding. This concept is reflected in a layer in the architecture corresponding to each of these notions: i.e., a layer for services and a layer for the runtime operational systems.

This style of architecture has come to be known as SOA, where rather than the implementations of components being exposed and known, only the services provided are published and consumers are insulated from the details of the underlying implementation by a provider.

Thus, an SOA enables business and IT convergence through agreement on a (contract consisting of a) set of business-aligned IT services that collectively support an organization’s business processes and business goals. Not only does it provide flexible decoupled functionality that can be reused, but it also provides the mechanisms to externalize variations of quality of service in declarative specifications such as WS-Policy and related standards.

The SOA RA can be used as a template to be used in defining capabilities and building blocks for SOA-based solutions. This is provided by the standard as a checklist of key elements that must be considered when an SOA solution is being evaluated or architected. The SOA RA provides this through a definition of layers and architectural building blocks within those layers. The elements underlying the SOA RA is based on a meta-model defined in figure 2:

The main SOA RA abstractions, represented in figure 2 above, collectively provide a logical design of an SOA and the inter-relationships between a set of architectural building blocks residing in its layers. During Architectural Assessments or the design of a solution or Enterprise Architecture, the SOA RA provides enterprise architects with a set of architectural building blocks and their associations in each layer, the available options, and architectural and design decisions that need to be made at each layer. This allows organizations to gradually mature into the implementation of more intricate SOA designs in a gradual fashion.

In the next blog post I will describe the details behind each of the layers.

Here is a brief description of those layers as an introduction.

Brief Description of Layers

The layers that are defined in the SOA RA each provide a set of capabilities that are then realized through the use of the architectural building blocks. Note that there are five functional layers providing direct business functional value in SOA solutions. An additional four layers (Integration, Information, QoS and Governance) provide cross-cutting capabilities expected of SOA and Cloud –based solutions. A brief description of these layers is provided below:

• Operational Systems Layer – captures the new and existing organization infrastructure and is needed to support the SOA solution at design, deploy and run time.

• Service Component Layer – contains software components, each of which provide the implementation or “realization” for a service, or operation on a service. The layer also contains the functional and technical components that facilitate a Service Component to realize one or more services.

• Services Layer – consists of all the services defined within the SOA. The service layer can be thought of as containing the service descriptions for business capabilities, services and IT manifestation used/created during design time as well as runtime service contracts and descriptions that used at runtime.

• Business Process Layer – covers the process representation, composition methods and building blocks for aggregating loosely coupled services as a sequencing process aligned with business goals.

• Consumer Layer – where consumers interact with the SOA. It enables a SOA solution to support a client-independent, channel agnostic set of functionality, which is separately consumed and rendered through one or more channels (client platforms and devices).

• Integration Layer – enables and provides the capability to mediate, which includes transformation, routing and protocol conversion to transport service requests from the service requester to the correct service provider.

• Quality of Service Layer – supports non functional requirement (NFR) related issues as a primary feature/concern of SOA and provides a focal point for dealing with them in any given solution.

• Information Architecture Layer – is responsible for manifesting a unified representation of the information aspect of an organization as provided by its IT services, applications, and systems enabling business needs and processes and aligned with the business vocabulary – glossary and terms. This enables the SOA to support data consistency, and consistency in data quality.

• Governance Layer – contains the registries, repositories, and other capabilities required to support the governance of your SOA within the SOA ecosystem and is adapted to match and support the target SOA goals of the organization.

Conclusion

The SOA RA is an excellent tool in the toolbox forEnterpriseand Application Architects.  It maps out the path for enterprise architects to assess their current SOA implementations against an industry agreed upon standard and define and customize their own internal implementations and product mappings against it.  The SOA RA provides the tools necessary to allow architects to speak in a standard, consistent vocabulary to the business line executives when designing solutions for the enterprise.  As the industry moves more towards the Cloud, the SOA RA ensures a strong foundation to pave the way towards Cloud Computing, helping businesses leverage the investments they have made in SOA services that will keep them on solid ground while moving towards the Cloud Computing Model.  Lastly, the SOA RA defines the architecture for all kinds of services based solutions, where Cloud extends and leverages services into the infrastructure in a virtualized, elastic and monitored model of pooled resources on a grander scale.

Dr. Ali Arsanjani is Chief Technology Officer (CTO) for SOA, BPM & Emerging Technologies within IBM Global Services where he leads a team responsible for developing worldwide competency in SOA/ BPM and increasing delivery excellence of SOA solutions using IBM and non-IBM tools and SOA offerings. Dr. Arsanjani represents IBM in standards bodies such as The Open Group and is responsible for co-chairing the SOA Reference Architecture, SOA Maturity Model, Cloud Computing Reference Architecture standards within that body.