SOA Reference Architecture – Overview of the SOA RA Layers
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:
- Layer: An abstraction of a grouping of a cohesive set of ABBs, architectural decisions, interactions among ABBs, and interactions among layers, that support a set of related capabilities.
- Capability: An ability that an organization, person, or system possesses to deliver a product or service. A capability represents a requirement or category of requirements that fulfill a strongly cohesive set of needs. This cohesive set of needs or functionality is summarized by name given to the capability.
- ABB (Architecture Building Block): A constituent of the architecture model that describes a single logical aspect of the overall model [10]. Each layer can be thought to contain a set of ABBs that define the key responsibilities of that layer. In addition, ABBs are connected to one another across layers and thus provide a natural definition of the association between layers. The particular connection between ABBs that recur consistently in order to solve certain classes of problems can be thought of as patterns of ABBs. These patterns will consist not only of a static configuration which represents the cardinality of the relationship between building blocks, but also the valid interaction sequences between the ABBs. In this SOA RA, each ABB resides in a layer, supports capabilities, and has responsibilities. It contains attributes, dependencies, constraints, and relationships with other ABBs in the same layer or different layer.
- Method Activity: A set of steps that involve the definition or design associated with ABBs within a given layer. The method activity provides a dynamic view of how different ABBs within a layer will interact. Method activities can also be used to describe the interaction between ABBs across the layers, so that an entire interaction from a service invocation to service consumption is addressed.
- Options: A collection of possible choices available in each layer that impact other artifacts of a layer. Options are the basis for architectural decisions within and between layers, and have concrete standards, protocols, and potentially solutions associated with them. An example of an option would be choosing SOAP or REST-style SOA services since they are both viable options. The selected option leads to an architectural decision.
- Architectural Decision: A decision derived from the options. The architectural decision is driven by architectural requirements, and involves governance rules and standards, ABBs, KPIs, and Non-Functional Requirements (NFRs) to decide on standards and protocols to realize an instance of a particular logical ABB. This can be extended, based on the instantiation of the SOA RA to the configuration and usage of ABBs. Existing architectural decisions can also be re-used by other layers or ABBs.
- Interaction Pattern: An abstraction of the various relationships between ABBs. This includes diagrams, patterns, pattern languages, and interaction protocols.
- KPI (Key Performance Indicator): A KPI may act as input to an architectural decision.
- NFR (Non-Functional Requirement): An NFR may act as input to an architectural decision. NFRs help address Service-Level Agreement (SLA) attributes (e.g., response time, etc.) and architectural cross-cutting concerns such as security.
- Enabling Technology: A technical realization or instance of ABBs in a specific layer. Examples are web services or REST.
- Information Model: A structural model of the information associated with ABBs including information exchange between layers and external services. The information model includes the metadata about the information being exchanged.
- Solution Building Block: A runtime realization or instance of ABBs in a specific layer. A candidate physical solution for an ABB; e.g., a Commercial Off-The-Shelf (COTS) package such as a particular application server.
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.