• Introduction
• Service Oriented Architecture
• OSIMM Version 2 Technical Standard
• SOA Reference Architecture Technical Standard
• 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
• Acknowledgements
• Referenced Documents
• SOCCI Framework Technical Standard
• Using TOGAF to Define and Govern SOAs
• SOA Governance Technical Standard
• SOA Ontology Technical Standard
• Navigating the SOA Open Standards Landscape Around Architecture White Paper

SOA Work Group

SOA Work Group Members Page

SOA Reference Architecture Technical Standard : Operational Systems Layer

Overview

All runtime elements of architecture reside in this layer. Effectively, this layer can conceptually be thought of as the runtime or deployment time of the solution. If we conduct a thought experiment and “freeze” the operations within this layer in a frame of time and expand it out, we will discover the separation of concerns that tend to cluster building blocks within the architecture: the aspects most closely connected with the consumption of the services, the processes that are choreographed into a flow, the services whose interfaces are exposed for consumption, the Service Components that will ultimately be used to realize the implementation of the services, along with the other four major cross-cutting and supporting concerns (integration, information, Quality of Service (QoS) factors, and governance).

Context and Typical Flow

This layer describes the runtime and deployment infrastructure; the programs, platforms, application servers, containers, runtime environments, packaged applications, virtual machines, etc. that are on the hardware and are needed to support the SOA solution. These specifically include:

• All software and hardware infrastructure necessary to support the SOA and its components at runtime and design time (tools)
• All operational and runtime hosting of underlying physical system components
• All assets required to support the functionality of services in the SOA, including custom or packaged application assets, new services, services created through composition or orchestration, infrastructure services, etc.

This layer represents a “snapshot” and logical categorization and generalization of the runtime environment. As such, this layer supports all the capabilities of the infrastructure that are needed for running/executing all software. Therefore, this layer supports the execution of the capabilities and responsibilities of the other layers of the SOA RA, including the components implementing the services; i.e., those components that a service relies on for providing it with its functional capabilities.

For example, if we have a capability for an SOA that involves systems using mainframe and J2EE platforms, the Operational Systems Layer would instantiate the necessary Architecture Building Blocks (ABBs) in the Integration Layer and Service Component Layer and the underlying mainframe and J2EE components which provide the functional capability.

We can express this as a formula such as:

Operational Systems Layer = [Infrastructural elements of all other layers] + [Underlying infrastructure to run the infrastructural elements (i.e., Operating Systems, etc.)] + [Elements that realize the Functional Components of services]

Thus this layer provides the building blocks supporting the operational systems which implement the functional capabilities of the other horizontal layers and the supporting/cross-cutting layers. In particular, the capabilities supported by this layer include providing operational and runtime hosting, infrastructure services and infrastructure virtualization, functional delivery support including support for service implementations, and realizations.

Connection Point with Other Initiatives or Standards

This layer represents the intersection point between the actual runtime infrastructure and the rest of the SOA which runs on that infrastructure. In addition, it is the integration point for an underlying Infrastructure as a Service (IaaS) construct and the rest of the SOA in the wider context of cloud computing. Key requirements for this layer are outlined in the capability section describing the capabilities provided to fulfill those requirements.

Capabilities

There are multiple categories of capabilities that the Operational Systems Layer needs to support. These categories of capabilities are:

• Service Delivery: This category of capabilities is required for delivery of the functional elements of services. This includes the finding of the components implementing the services, the wrapping and the composition/ decomposition of the underlying services, and the implementation of the services.
• Runtime Environment: This category of capabilities is required for providing a runtime environment representing runtime infrastructure for SOA. This includes capabilities to support both the components required to support service functionality and those required to actually run the components and building blocks of the SOA RA itself. This includes capabilities for the hardware, operating system components and the Solution Building Blocks, which are the runtime instances or realizations of the ABBs of all layers in the SOA RA that have been selected for inclusion in a particular operating environment.
• Virtualization and Infrastructure Services: This category of capabilities provides underlying infrastructure such as computing power, network, storage, etc. in native or a virtualized manner.

This layer features the following capabilities:

Service Delivery

1. Ability to locate components implementing services
2. Ability to host applications and functionality to deliver service features
3. Ability to host databases needed for service implementation
4. Ability to host legacy systems needed for service implementation
5. Ability to act as a broker between services requests and invoking implementations
6. Ability to map service functional requirements to underlying or legacy solution
7. Ability to compose service function from underlying services and implementation of services
8. Ability to wrap custom and legacy platforms for service implementation
9. Ability to find Service Component associated with Solution Building Blocks
10. Ability to delegate request or invoke Solution Component for service

Runtime Environment

1. Ability to support operating systems platforms
2. Ability to support runtime hosting platforms
3. Ability to support runtimes of software needed to run service implementation
4. Ability to support runtimes and software needed to deploy service implementations
5. Ability to run supporting ABBs and Solution Building Blocks from other layers of the SOA RA
6. Ability to support the software environment in which the Solution Component runs

Virtualization and Infrastructure Services

1. Ability to provide infrastructure needed by runtime infrastructure
2. Ability to provide infrastructure in a virtualized manner to platforms
3. Ability to provide infrastructure in a virtualized manner to service implementation
4. Ability to manage infrastructure and virtualized infrastructure
5. Ability to provide a single point of control for security of the Operational Systems Layer

Architecture Building Blocks (ABBs)

The ABBs responsible for providing these sets of capabilities in the Operational Systems Layer are:

ABB to Capability Mapping for the Operational Systems Layer

Details of ABBs and Supported Capabilities

Details of ABBs

Solution Component

This ABB represents realization of subsystems that represent logical groupings of functionality and associated functionally cohesive services. Its bill of material contains the Service Component, Functional Components, and Technical Components from the Service Component Layer realizing services that provide well-defined interfaces for the subsystems. For example, it could be an invocation of a legacy component, or an existing or new database request, application, or a component wrapped within a Commercial Off-The-Shelf (COTS) package. Thus, it is a runtime instantiation of a group of cohesive components residing within a subsystem that collectively provide an implementation for a set of related services.

Implementation Controller [IC]

This ABB receives a request to invoke an underlying Solution Component and delegates it to the appropriate Solution Component. It also incorporates logic for composition and decomposition of legacy applications into Solution Components. This is required because historically most legacy applications have not been written with the intent of being elements in an SOA and the service Solution Components within them need to be exposed through service composition and decomposition.

Integration Layer: Integration Controller

This ABB is responsible for coordinating and brokering or mediating the interactions between the applications, database, security, etc. that need to work in concert to effectively provide a runtime experience.

Applications (Packaged and Custom)

This ABB represents the applications that are running as units of execution within the runtime environment.

Legacy System

This ABB describes the legacy systems running in the Operational Systems Layer.

Database

This ABB represents the databases running in the Operational Systems Layer.

Quality of Service Layer: Policy Enforcer

See Policy Enforcer ABB in the Quality of Service Layer.

Quality of Service Layer: Access Controller

See Access Controller ABB in the Quality of Service Layer.

Runtime Hosting Environment [RHE]

This ABB provides support for operational and runtime services. These include software services such as the operating system instance on which the Solution Platforms run, as well as underlying infrastructural services such as hardware support, memory, storage, networks, etc.

Solution Platform

This ABB supports the software environment in which the Solution Components and Solution Building Blocks deploy and run. Examples would be Java Virtual Machines (JVMs) hosting a Service Container Solution Building Block, or a CICS environment.

Solution Building Block

This ABB represents the runtime component of ABBs from other layers in the SOA RA. Thus, for example, a Mediation ABB from the Integration Layer runs as a Solution Building Block.

Deployment Unit

This ABB represents an executable application that can be deployed as a single unit (e.g., exe, war, ear, etc.) in the target hosting environment. This ABB is deployed on Solution Platforms.

Hardware

This ABB represents an abstraction of the physical hardware that is the platform on which Deployment Units are actually deployed and are executing (running).

Virtualized Infrastructure

This ABB supports the utilization of infrastructure in a virtualized manner by the operational and hosting runtime environment. Thus, the use of shared disk space in a cloud environment would be an example.

Quality of Service Layer: IT Systems Manager

See IT Systems Manager ABB in the Quality of Service Layer.

Quality of Service Layer: Security Manager

See Security Manager ABB in the Quality of Service Layer.

Structural Overview of the Layer

The ABBs in the Operational Systems Layer can be thought of as being logically partitioned into the categories that support:

• Solution Components which provide the functional capability of services and the solution
• Runtime environment required by the SOA and that runs the actual Solution Components and their supporting infrastructure
• Supports the interfacing with underlying infrastructure, so that they can be virtualized and leveraged as such by the underlying architecture

In the Structural Overview of the Layer diagrams in this specification, the ABBs are color-coded to match the other layers in the architecture that they belong to. For example, in the following diagram the ABBs from the Quality of Service Layer are a dark gray, while the ABBs from the Integration Layer are a black.

ABBs in the Operational Systems Layer

Inter-Relationships between the ABBs

The Solution Component ABB represents realization of subsystems that represent logical grouping of functionality and associated functionally cohesive services. Its bill of material contains the Service Component, Functional Components, and Technical Components from the Service Component Layer realizing services providing well-defined interfaces for the subsystems. Requests are first validated as secure by the Access Controller ABB and Security Manager ABB in the Quality of Service Layer, and then translated into Solution Component ABB requests by the Implementation Controller ABB and executed by the Solution Components in the Solution Platform.

The runtime hosting and operational environment capability is supported by the Solution Platform ABB and Runtime Hosting Environment ABB. Thus, both ABBs from all layers of the SOA RA run as Solution Building Blocks on the Solution Platform hosted by the Runtime Hosting Environments.

The infrastructure services and infrastructure virtualization capability basically is responsible for exposing the underlying infrastructure in an on-demand manner, encapsulating the invoking ORE and enabling rapid scaling.

In the following diagram, the arrows between the ABBs indicate an interaction from one ABB to another.

Relationships among ABBs in the Operational Systems Layer

Significant Intersection Points with other Layers

There is a significant intersection between the Operational Systems Layer and all other layers of the SOA RA as this layer provides the actual runtime environment to the other layers to execute at runtime. It intersects with the rest of the SOA RA including, of course, the cross-cutting and supporting layers, such as the Quality of Service Layer which acts as an aggregation point for monitoring, managing, and securing the runtime environment.

We will summarize this connection below in terms of intersection with the rest of the SOA RA including cross-cutting or supporting layers.

Intersection with the Rest of the SOA RA

1. There are two points of intersection of the Operational Systems Layer with the rest of the SOA RA: The first perspective is that the Operational Systems Layer supports the functionality of the SOA RA rendered by the more abstract layers above. There are two parts to this perspective: providing a wrapper which exposes the service aspect from the Service Component Layer, providing a mapping to the underlying Solution Component ABB which actually supports the capability. The Solution Platform ABB provides a platform to deploy and run the Solution Components realizing the functionally cohesive services in a subsystem.
2. The second perspective is that the Operational Systems Layer provides the runtime environment for the ABB from other layers. These ABBs from the other layers are instantiated as Solution Building Blocks for the runtime environment. The Solution Platform ABB provides a platform to deploy and run these ABBs from other layers.

Interaction with Cross-Cutting Layers

The Operational Systems Layer relies on cross-cutting layers of the architecture to fulfill its responsibilities.

It relies on the Quality of Service Layer for the following capabilities:

• Ability to authenticate/authorize for service invocation
• Ability to enforce operational policies
• Ability to monitor health and wellbeing of underlying infrastructure and solution and applications deployed on the infrastructure

It relies on the Information Layer for the following capabilities:

• Ability to store and retrieve metadata and data

It relies on the Integration Layer for the following capabilities:

• Ability to invoke business processes and/or services
• Ability to transform data from one format to another

It relies on the Governance Layer for the following capabilities:

• Ability to set and store business rules
• Ability to manage policies for IT management
• Ability to manage security policies

Key Interactions of Operational Systems Layer with Cross-Cutting Layers

Therefore, Operational Systems Layer interfaces with the following ABBs of cross-cutting layers of the architecture to provide its capabilities:

1. It leverages Policy Manager ABB in the Governance Layer enabling consolidation of policies as well as the management and administration of the security policies in one place – addressing the very important issue of security in the distributed environment as in the case of an SOA. It should be noted that in practice it may coordinate or integrate with the security mechanisms of the Solution Platform and Runtime Hosting Environment in which the SOA runs.
2. It leverages Access Controller ABB in the Quality of Service Layer to enforce access privileges and Policy Enforcer ABB in the Quality of Service Layer to enforce policies. These ABBs from the Quality of Service Layer enable the Operational Systems Layer to operate across platforms and support a consistent set of policies for specific scenarios, and limit the amount of associated risk. The Access Controller ABB and Policy Enforcer ABB in the Quality of Service Layer provide a single Policy Enforcement Point (PEP) for control for security for the Operational Systems Layer, and in practice for all the runtime components of the SOA RA. The policy enforcement could be federated. The Security Manager ABB in the Quality of Service Layer implements a participating filter pattern, where in-bound requests are submitted to policy enforcement and then the appropriate delegation of security to the Solution Platforms and Runtime Hosting Environment occurs.
3. It leverages IT Systems Management-related ABBs in the Quality of Service Layer such as Systems Manager ABB, Network Manager ABB, Storage Manager ABB, and Application Systems Manager ABB to monitor, check heartbeat, and manage the infrastructure, systems, and applications.
4. It interfaces with the Integration Controller ABB to leverage the capabilities of the Integration Layer for coordinating and brokering or meditating the interactions between the applications, database, security, etc. that need to work in concert to effectively provide a runtime experience.

Interaction with Horizontal Layers

The Operational Systems Layer provides the runtime environment for other horizontal layers that are more functional in nature. Each of the other horizontal layers – namely, Consumer Layer, Business Process Layer, Services Layer, Service Component Layer – have some functional ABBs and some supporting ABBs that are needed to provide a runtime environment for the functional aspects of the solution. In a nutshell, the functional ABBs of the solution get rendered into a Solution Component in the Operational Systems Layer during runtime, whereas supporting ABBs get rendered into Solution Building Blocks in the Operational Systems Layer during runtime.

Key Interactions of Operational Systems Layer with Horizontal Layers

Usage Implications and Guidance

Options and Design Decisions

The capabilities supported by the Operational Systems Layer include enablement of infrastructure services for realizing the SOA; i.e., the (re-)use and composition of assets required as infrastructural elements for running the SOA.

From an SOA perspective, the Operational Systems Layer enables organizations to integrate in a perimeter-less, cross-organizational manner, such as Cloud-based virtualization in the form of SaaS applications which involves the integration of infrastructure services used in the Cloud, and the re-use of existing application assets originating from the diverse portfolio of custom and packaged applications that are running within an organization. This integration in a perimeter-less, cross-organizational fashion enables the foundation for service re-use by allowing the sharing of functionality and supporting capabilities across the portfolio.

In particular, this layer directly influences the overall cost of implementing SOA solutions within enterprises, the alignment and legacy modernization impact of SOA, the re-use of legacy solutions, and the positioning of SOA for next-generation SOA evolution, such as Cloud Computing.

Finally, it is important to note that a service executes its functionality through building blocks that are assets in this layer. For example, a patient record update service that contracts to update patient records does so using different components running in application assets hosted in the Operational Systems Layer.

A number of existing software systems are part of this layer. Those systems include but are not limited to:

• Existing monolithic custom applications including J2EE [17] and .NET [18] applications
• Existing SOA services
• Legacy applications and systems
• Existing transaction processing systems
• Existing databases
• Existing package applications and solutions including ERP and CRM packages

Implementation Considerations

Considerations when using this layer include:

• When dealing with legacy, custom, and COTS applications, plan on a layer to support composition/ decomposition and integrate with the underlying systems.
• Try to federate security, and potentially event monitoring, to support the traceability and the agility required for an effective SOA. For example, if you have a J2EE environment currently and build federation in, as you go through a Merger and Acquisition scenario where the CICS, .NET, and SaaS components need to be added, a core security framework is critical for incorporating these components in an agile manner.

When dealing with virtualized infrastructure, it is important to consider the following:

• Isolation and containment services: multi-tenancy, data privacy (both data in motion and at rest), auditability, authorization/authentication/access control
• Application support services: elasticity – dynamic resource provisioning/de-provisioning, service location awareness, infrastructure QoS management (as opposed to Application Service QoS)
• Data integrity services: disaster recovery, high availability clustering, data backup, data QoS management, data mobility
• Infrastructure accounting services: chargeback services, configuration management/auditability, capacity management services

Runtime and Deployment View of the SOA RA

As described in the first paragraph, the Operational Systems Layer supports all the capabilities of the infrastructure that are needed for running/executing all software. Therefore, this layer supports the execution of the capabilities and responsibilities of the other layers of the SOA RA, including the components implementing a service itself and the components that provide the SOA capabilities like Service Container ABB from the Services Layer, Data Transformer ABB from the Integration Layer, Process Flow Manager ABB from the Business Process Layer, etc.

The Solution Building Block in the Operation Systems Layer is defined as representing the runtime component of ABBs from other layers in the SOA RA. Thus, for example, a Protocol Conversion ABB in the Integration Layer runs as a Solution Building Block in the Operational Systems Layer. But a business service, such as Get Customer Information, runs ultimately as a Solution Component.

In the description of the various layers this infrastructural support from a deployment perspective will be mentioned several times. The service container component will be introduced in the Services Layer, but will actually contain/deploy components from both the Services Layer and the Service Component Layer. All runtime building blocks from the other layers will be deployed directly as Solution Building Blocks, as mentioned above.

In Deployment View of the SOA RA this deployment view of the SOA RA is visualized.

Deployment View of the SOA RA

The light gray colored building blocks are from the Operational Systems Layer. The dark gray colored building blocks are partly generalized building blocks from the other layers.