The SOA Reference Architecture (SOA RA) has nine layers representing nine key clusters of considerations and responsibilities that typically emerge in the process of designing an SOA solution or defining an enterprise architecture standard. Also, each layer is designed to correspond to reinforce and facilitate the realization of each of the various perspectives of SOA business value discussed in Key Business Benefits of SOA.
Taking a pragmatic approach, for each layer, we postulate three aspects that should be supported by the SOA RA: requirements (exemplified by the capabilities for each layer), logical (exemplified by the Architecture Building Blocks (ABBs)), and physical (this aspect will be left to the implementation of the standard by an adaptor of the standard using Solution Building Blocks).
The requirements aspect reflects what the layer enables and includes all of its capabilities; the logical aspect includes all the ABBs, design decisions, options, Key Performance Indicators (KPIs), etc.; while the physical aspect of each layer includes the realization of each logical aspect using technology, standards, and products that are determined by taking into consideration the different architectural decisions that are necessary to be made to realize and construct the architecture. The actual realization by a set of products or platform (i.e., Solution Building Blocks) will be left open to the implementer of the standard.
This standard provides specific focus on the logical aspects of the SOA RA, and provides a model for including key architectural considerations and making architectural decisions through the elements of the meta-model.
Three of the layers address the implementation and interface with a service (the Operational Systems Layer, the Service Component Layer, and the Services Layer). Three of them support the consumption of services (the Business Process Layer, the Consumer Layer, and the Integration Layer). Four of them support cross-cutting concerns of a more supporting (sometimes called non-functional or supplemental) nature (the Information Layer, the Quality of Service Layer, the Integration Layer, and the Governance Layer). The SOA RA as a whole provides the framework for the support of all the elements of an SOA, including all the components that support services and their interactions.
This logical view of the SOA RA addresses the question: “If I build an SOA, what would it look like, how is it structured, and what abstractions should be present?” Also, for the assessment usage scenario of the SOA RA, the question answered by this standard is, informally: “If I assess an architecture proposing to be built upon SOA principles, what considerations and building blocks should be present and what shall we assess against?”
The SOA RA enumerates the fundamental elements of an SOA solution or enterprise architecture standard for solutions and provides the architectural foundation for the solution.
Meta-Model for Instantiating the SOA RA for a Given Solution
As shown in Meta-Model for Instantiating the SOA RA for a Given Solution, the meta-model of the SOA RA includes the following elements:
Logical Solution View of the SOA RA
Logical Solution View of the SOA RA depicts an SOA as a set of logical layers. Note that one layer does not solely depend upon the layer below it and is thus named a partially-layered architecture: a consumer can access the Business Process Layer or the Services Layer directly, but not beyond the constraints of an SOA architectural style. For example, a given SOA solution may exclude a Business Process Layer and have the Consumer Layer interacting directly with the Services Layer. Such a solution would not benefit from the business value proposition associated with the Business Process Layer; however, that value could be achieved at a later stage by adding the layer. In this sense the SOA RA represents SOA with a partially layered architecture. The degree to which a given organization realizes the full SOA RA will differ according to the level of SOA maturity they exhibit, and the underlying requirements of the organization.
Logical Solution View of the SOA RA illustrates the multiple separations of concern in the nine layers of the SOA RA. The SOA RA does not assume that the provider and the consumer are in one organization, and supports both SOA within the enterprise as well as across multiple enterprises in the industry ecosystem. The need for both intra and inter-enterprise SOA is important, with the role of SOA as the foundation of Cloud Computing and Software as a Service (SaaS). The Services Layer is the decoupling layer between consumer and provider.
The lower layers (Services Layer, Service Component Layer, and Operational Systems Layer) are concerns for the provider and the upper ones (Services Layer, Business Process Layer, and Consumer Layer) are concerns for the consumer. The main point of the provider/consumer separation is that there is value in decoupling one from the other along the lines of business relationship. Organizations which may have different lines of business use this architectural style (where one is the consumer and the other is the provider), customizing it for their own needs and integrating and interacting among themselves; in such a case there is still real value in maintaining a decoupled consumer/provider relationship. Below we will describe each layer and describe the relationships between the layers in the subsequent sections.
Note that there are five horizontal layers that are more functional in nature and relate to the functionality of the SOA solution. The supporting layers are supportive of cross-cutting concerns that span the functional layers but are clustered around independent notions themselves as cross-cutting concerns of the SOA architectural style.