• SOA Source Book
• Service-Oriented Architecture
• The Open Group Service Integration Maturity Model (OSIMM) Version 2
• SOA Reference Architecture
• Introduction
• Motivation
• Key Principles
• Basic Concepts
• Overview of the SOA RA Layers
• Capabilities and the SOA RA
• Description of Layers
• Operational Systems Layer
• Service Component Layer
• Services Layer
• Business Process Layer
• Consumer Layer
• Integration Layer
• Quality of Service Layer
• Information Layer
• Governance Layer
• Related Work and Usages of the SOA RA
• Relationship to Other SOA Standards
• Relationship to Open Group Guide: Using TOGAF to Define and Govern SOA
• Referenced Documents
• Acknowledgements
• Legal
• Service-Oriented Cloud Computing Infrastructure (SOCCI) Framework
• Using TOGAF to Define and Govern Service-Oriented Architectures
• SOA Governance Framework
• Service-Oriented Architecture Ontology Version 2.0
• Legacy Evolution to SOA
• Microservices Architecture
• SOA for Business Technology
• Navigating the SOA Open Standards Landscape Around Architecture
• SOA in the Digital Age

SOA Work Group

SOA Standards Discussion Forum

SOA Work Group Members Page

SOA Reference Architecture – 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:

• Introduction provides a general introduction.
• Motivation provides motivation for using the SOA RA.
• Key Principles provides an overview of the principles on which the SOA RA was derived.
• Basic Concepts overviews the basic concepts of the SOA RA.
• Overview of the SOA RA Layers reviews the layers of the SOA RA in detail.
• Capabilities and the SOA RA explains capabilities in the SOA RA.
• Description of Layers describes assumptions for the layers of the SOA RA.
• Chapters 8 through 16 each explain one of the nine layers of the SOA RA.
• Related Work and Usages of the SOA RA outlines related work and uses of the SOA RA.
• Appendix A relates the SOA RA to other SOA standards.
• Appendix B relates the SOA RA to The Open Group Guide: Using TOGAF to Define and Govern SOAs.

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.