SOA Reference Architecture Technical Standard : Introduction

 

Objective

A Service-Oriented Architecture (SOA) facilitates the creation of flexible, re-usable assets for enabling end-to-end business solutions. Increasingly, companies are adopting the principles and techniques associated with SOA for different types of projects in different industries worldwide.

The usage of the SOA Reference Architecture (SOA RA) is a key enabler for the achievement of the value propositions of an SOA.

This specification presents an SOA RA, which provides guidelines and options for making architectural, design, and implementation decisions in the implementation of solutions. The goal of this SOA RA is to provide a blueprint for creating or evaluating architecture.

Additionally, it provides insights, patterns, and the building blocks for integrating fundamental elements of an SOA into a solution or enterprise architecture.

Informally, the aim of the SOA RA is to answer some of the key questions and issues encountered by architects, including but not restricted to common questions such as:

  • What are the aspects, building blocks, and layers of an SOA that I need to consider in designing solutions, establishing enterprise architecture guidelines, or assessing an architecture based on service-oriented principles?
  • What are the building blocks I need to include in each layer of my solution or standardize as part of a enterprise architecture?
  • What are some of the key architectural decisions I need to make when designing a solution, or assessing an architecture that is based on service-oriented principles?
  • How do I increase my chances of gaining benefit from using SOA by taking into account key layers and building blocks with which I may initially be unfamiliar as our company makes it journey through higher levels of maturity? One of the ways in which we can establish a baseline and move to higher levels of maturity is to use The Open Group Service Integration Maturity Model (OSIMM) [21].
  • Which roles in a project would benefit from using these principles and guidelines?

The SOA RA is used as a blueprint and includes templates and guidelines for enterprise and solution architects as well as software engineering roles within the software development life-cycle. These facilitate and ultimately enable automation and streamlining the process of modeling and documenting the architectural layers, the capabilities and the Architecture Building Blocks (ABB) within them, options for layers and ABBs, mapping of products to the ABBs, and architectural and design decisions that contribute to the creation of an SOA. It 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.

Overview

In this Open Group standard we present the results of abstracting and using an SOA RA based on multiple projects in different industries across the world.

During these projects, a number of key underlying themes have emerged that have been formalized into a meta-model for the SOA RA, as shown in Meta-Model for Instantiating the SOA RA for a Given Solution.

This meta-model defines a number of layers, ABBs, architectural and design decisions, patterns, options, and the separation of concerns needed to design or evaluate architecture.

Furthermore, these elements represent the results of applying an SOA method to identify, specify, realize, and implement services, components, and flows of an end-to-end solution in the context of a service-oriented approach. The SOA RA provides common systems architecture [7], and the mechanism to translate it to industry architecture and individual solution architecture, as well as providing traceability between these specializations of architecture.

Thus, the SOA RA also acts as a communication vehicle for organizations to use to provide a high-level specification of what SOA components are and how to pick specific solutions, and a mechanism to align technology with business requirements.

The SOA RA, being composed of a collection of layers, uses an approach in which each layer provides a set of “capabilities” that are realized by a set of ABBs. The ABB or group of ABBs may be implemented in a target implementation platform or product by multiple vendors.

This approach allows users of the SOA RA to look for a set of capabilities and assess or create an architecture that realizes those capabilities using a set of logical building blocks without tying those building blocks to a specific vendor implementation.

It thus allows the user of the standard to align the technical capabilities with business capabilities and requirements, without necessarily implying implementation decisions. The SOA RA then provides the ABBs that will realize those capabilities, thus acting as a mechanism for initially deferring and then explicitly making implementation decisions to indicate how a given component of the solution, the ABB, will choose to be implemented on their project.

The SOA RA is based on establishing the building blocks of SOA: services, components, and flows (processes) that collectively support business processes and business goals. The metadata underlying each layer and relationship between layers can further facilitate in bridging the gap between business and IT from solution modeling to solution realization.

Another major capability afforded by the SOA RA is the increase in re-usability when designing and developing solution assets for rapid development, deployment, and management of SOA solutions within industry or across industries.

This document is organized as follows:

Conformance

Intentionally left blank in this version.

Terminology

Can

Describes a permissible optional feature or behavior available to the user or application. The feature or behavior is mandatory for an implementation that conforms to this document. An application can rely on the existence of the feature or behavior.

Implementation-dependent

(Same meaning as “implementation-defined”.) Describes a value or behavior that is not defined by this document but is selected by an implementer. The value or behavior may vary among implementations that conform to this document. An application should not rely on the existence of the value or behavior. An application that relies on such a value or behavior cannot be assured to be portable across conforming implementations. The implementer shall document such a value or behavior so that it can be used correctly by an application.

Legacy

Describes a feature or behavior that is being retained for compatibility with older applications, but which has limitations which make it inappropriate for developing portable applications. New applications should use alternative means of obtaining equivalent functionality.

May

Describes a feature or behavior that is optional for an implementation that conforms to this document. An application should not rely on the existence of the feature or behavior. An application that relies on such a feature or behavior cannot be assured to be portable across conforming implementations. To avoid ambiguity, the opposite of “may” is expressed as “need not”, instead of “may not”.

Must

Describes a feature or behavior that is mandatory for an application or user. An implementation that conforms to this document shall support this feature or behavior.

Shall

Describes a feature or behavior that is mandatory for an implementation that conforms to this document. An application can rely on the existence of the feature or behavior.

Should

For an implementation that conforms to this document, describes a feature or behavior that is recommended but not mandatory. An application should not rely on the existence of the feature or behavior. An application that relies on such a feature or behavior cannot be assured to be portable across conforming implementations. For an application, describes a feature or behavior that is recommended programming practice for optimum portability.

Undefined

Describes the nature of a value or behavior not defined by this document that results from use of an invalid program construct or invalid data input. The value or behavior may vary among implementations that conform to this document. An application should not rely on the existence or validity of the value or behavior. An application that relies on any particular value or behavior cannot be assured to be portable across conforming implementations.

Unspecified

Describes the nature of a value or behavior not specified by this document that results from use of a valid program construct or valid data input. The value or behavior may vary among implementations that conform to this document. An application should not rely on the existence or validity of the value or behavior. An application that relies on any particular value or behavior cannot be assured to be portable across conforming implementations.

Will

Same meaning as “shall”; “shall” is the preferred term.

Future Directions

Subsequent drafts of the SOA RA may include examples of application of the standard. There is no commitment to any particular additional content and other content not mentioned here may be added.

 

 

 

The Open Group
Platinum Members
HP IBM Oracle Philips