SOA Reference Architecture – Service Component Layer

Overview

This layer contains software components, each of which provides the implementation or “realization” for services and their operations, hence the name “Service Component”. The layer also contains the Functional and Technical Components that facilitate a Service Component to realize one or more services. Service Components reflect the definition of the service they represent, both in terms of functionality and Quality of Service (QoS). They “bind” the service contract/specification to the implementation of the service in the Operational Systems Layer. Service Components are hosted in containers which support the service specifications.

The Service Component Layer manifests the IT conformance with each service contract/description/specification defined in the Services Layer; it guarantees the alignment of IT implementation with service description.

In detail, each Service Component fulfils the following goals:

Realizes one or more services
Provides an enforcement point for service realization
Enables IT flexibility by strengthening the decoupling in the system, by hiding volatile implementation details from service consumers

In particular, the Service Component Layer:

Enables IT flexibility by strengthening the decoupling in the system; decoupling is achieved by hiding volatile implementation details from consumers
Often employs container-based technologies, such as EJBs

Each Service Component:

Realizes one or more services
Provides an enforcement point for service realization
Offers a façade behind which IT is free to do what is wanted/needed
Generally contains business-specific logic with no reference to integration logic

Context and Typical Flow

The Service Component Layer provides the following:

Ability to support the exposure of a service in a standards-compliant manner supporting interoperability; note that the protocol (SOAP/REST/J2EE, etc.) is not prescribed but determined by the associated architectural decision
Ability to expose the service via an integration stack from the underlying platform in which the service functionality resides (aka within the Operational Systems Layer)
Ability to publish and deploy the Service Component itself: expose services in an interoperable manner; bind to the Operational Systems Layer at runtime; publish service contract information in an interoperable and standards-compliant manner so that other elements of the SOA can invoke it; deploy the service into the associated “services container”

Capabilities

There are multiple categories of capabilities that Service Component Layer need to support in the SOA RA. These capabilities include both design-time and runtime capabilities. These capability categories are:

Service Realization and Implementation: This category of capabilities supports the realization of the services.
Service Publication and Exposure: This category of capabilities supports service exposure and service contract publication.
Service Deployment: This category of capabilities supports service deployment.
Service Invocation: This category of capabilities supports service invocation.
Service Binding: This category of capabilities supports service binding.

Note: Service Realization and Implementation, Service Publication and Exposure, and Service Deployment are design-time capabilities, while Service Invocation and Service Binding are runtime capabilities.

Service Realization and Implementation (Design Time)

Ability to realize a service; for example, using component-based design and development

Service Publication and Exposure (Design Time)

Ability to publish the service contract/descriptions in a standards-compliant, interoperable manner for other layers of the SOA RA and design-time service repositories and runtime service registry in the Governance Layer
Ability to provide information about the services to the Services Layer

Service Deployment (Design Time)

Ability to provide for the deployment of the physical service to the existing solution platform which contains the associated service Solution Component

Service Invocation (Runtime)

Ability to support a standards-compliant, interoperable, runtime invocation of the service

Service Binding (Runtime)

Ability to support service interoperability
Ability to implement a part of the broker pattern
Ability to convert from the service description to service calls supported by the platform (in the case of a WSDL web service, the conversion from WSDL service description to the service invocation)
Ability to convert at runtime into a standards-compliant form for consumption by standards-compliant service consumers on both input and output
Ability to convert from the standards-compliant form to the form acceptable to the underlying Solution Component which satisfies the service’s functional capability on both input and output
Ability to enforce policies and access control during service binding

Architecture Building Blocks (ABBs)

The ABBs responsible for providing these sets of capabilities in the Service Component Layer are:

Capability Category	ABB Name	Supported Capabilities
Service Realization & Implementation	Service Component (This can use any technology, not necessarily SCA.)	1
	Functional Component	1
	Technical Component	1
Service Publication and Exposure	Service Publisher	2-3
	Integrated Development Environment (IDE) for Service Development	2
	Governance Layer: Service Repository	2-3
Service Deployment	Service Deployment Manager	4
Service Invocation	Service Invoker	5
Service Binding	Service Implementation Binder	6-8
	Method Input/Output Transformer	9
	Service Implementation Adapter	10
	Quality of Service Layer: Policy Enforcer	11
	Quality of Service Layer: Access Controller	11

ABB to Capability Mapping for the Service Component Layer

These ABBs help in the realization of services and SOA in general and support the binding of services based on standards required for integration with other SOA RA layers in a standards-compliant and interoperable fashion.

Details of ABBs and Supported Capabilities

Details of ABBs

Service Component

This ABB realizes one or more services that are important to the enterprise to be managed and governed as an enterprise asset.

Functional Component

This ABB provides business functionality and aids in the realization of the Service Component. A Functional Component may be composed of other Functional Components and/or domain objects.

Technical Component

This ABB provides abstraction of infrastructure to support Functional Components.

Service Publisher

This ABB publishes Service Component design-time metadata and description to a design-time Service Repository ABB in the Governance Layer.

Integrated Development Environment (IDE) for Service Development

This ABB helps define and develop Service Components and associated Functional and Technical Components. This includes service contracts and any other associated service metadata.

Governance Layer: Service Repository

See Service Repository ABB in the Governance Layer.

Service Deployment Manager

This ABB deploys runtime Service Components to a services container and registers service description information in the Service Registry ABB in the Governance Layer. This can be automated through different mechanisms (from build scripts to an automated deployment, etc.).

Service Invoker

This ABB supports the invocation of the Service Components by the Services Layer. This includes invoking the Service Container to bind to and load the Service Component into the Service Container (a Services Layer ABB described in the Services Layer).

Service Implementation Binder

This ABB provides any bindings required to the invoking services and other layers. For example, if this were a WSDL-based service, then the invoking services or Integration Layer component would require its service request converted or mapped to an underlying Service Component call. The aspect of converting the in-bound call leverage Method Input/Output Transformer ABB is the responsibility of this ABB.

Method Input/Output Transformer

This ABB helps in transformation of input and output parameters of service operation and conversion of associated data elements from one format to another. It is used by the Service Implementation Adapter ABB to do the transformation/translation. It retrieves its metadata from the Information Layer and leverages the Data Transformer ABB in the Integration Layer to perform the necessary transformation.

Service Implementation Adapter

This ABB interfaces with the Operational Systems Layer and passes on the service call to the Operational Systems Layer in a form that is compliant with the Solutions Platform in the Operational Systems Layer, where the underlying Solution Components for the service are housed.

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.

Structural Overview of the Layer

The Service Component Layer can be thought of as supporting capabilities dealing with design-time and runtime aspects. One of the key responsibilities of the Service Component Layer is to provide the integration between other SOA RA layers (e.g., the Integration Layer), and the underlying Operational Systems Layer. The Service Component Layer thus supports the binding to other SOA RA layers and the standards required to support that interoperability. It also provides the binding to the Implementation Controller and thus the underlying Solution Building Blocks in the Operational Systems Layer. This binding is achieved through the implementation of the broker pattern.

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

Realization and implementation of services
Exposure and contract publication of services
Deployment of services
Invocation of services
Binding of services

ABBs in the Service Component Layer illustrates the ABBs supporting the capabilities of the Service Component Layer.

ABBs in the Service Component Layer

Inter-Relationships between the ABBs

As menitoned earlier, the ABBs in the Service Component Layer can be grouped as follows:

ABBs that support the design-time capabilities of the layer
ABBs that support the runtime capabilities of the layer

Illustrative Interaction Flow among Design-Time ABBs in the Service Component Layer illustrates the interaction flows among ABBs in the Service Component Layer enabling design-time capabilities.

Illustrative Interaction Flow among Design-Time ABBs in the Service Component Layer

The interaction flow among design-time ABBs in the Service Component Layer is described as follows:

During service design, an Integrated Development Environment (IDE) for Service Development is used to develop a service contract and specification using agreed upon standards.
The service contract and specification is given to a Service Publisher ABB to publish the service.
The Service Publisher ABB publishes the service contract and specification in the Service Repository ABB in the Governance Layer for use by other SOA layers and cross-cutting concerns.
The Service Publisher also invokes a Service Deployment Manager to execute deployment functions so that the service is available to access in the appropriate services container, according to the contract and other information.

Illustrative Interaction Flow among Runtime ABBs in the Service Component Layer illustrates the interaction flows among ABBs in the Service Component Layer enabling runtime capabilities.

Illustrative Interaction Flow among Runtime ABBs in the Service Component Layer

The interaction flow among runtime ABBs in the Service Component Layer is described as follows:

The Service Invoker ABB is invoked from all other layers of the SOA RA (except the Operational Systems Layer) and provides the ability for the Services Layer to invoke the Service Component realizing the services.
The Service Invoker ABB calls the Service Component ABB which is the binding stack to bind to external layers.
The Service Component ABB can invoke the Method Input/Output Transformer ABB to have the data formats transformed for interaction with the service consumers or other layers of the SOA RA.
The Service Component ABB then passes control to the Service Implementation Adapter.
The Service Implementation Adapter then maps the invocation into the Operational Systems Layer.

Significant Intersection Points with other Layers

The Service Component Layer provides the IT conformance with each service contract defined in the Services Layer and it guarantees the alignment of IT implementation deployed on the Operational Systems Layer with service description. Each Service Component:

Provides an enforcement point for “faithful” service realization (ensures QoS and Service-Level Agreements (SLAs))
Enables business flexibility by supporting the functional implementation of IT flexible services, their composition, and layering
Enables IT flexibility by strengthening the decoupling in the system; decoupling is achieved by hiding volatile implementation details from consumers

High-Level Interaction of the Service Component Layer with Layers Above and Below in the SOA RA

The Solution Component ABB in the Operational Systems Layer can be thought of as a runtime instantiation of a solution enabling a subsystem of services. A subsystem is implemented by one or more Service Components realizing one of more services and related Functional and Technical Components. The Solution Component ABB is a runtime instantiation of the Service Components and associated Functional and Technical Components realizing a subsystem of services. Service architects and developers must determine which standards to conform to in the protocols for the service as well as to connect to the underlying Operational Systems Layer. Which standards are used to describe the service (e.g., WSDL) and these protocols is also an important decision.

Interaction with Cross-Cutting Layers

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

It relies on the Governance Layer for the following capabilities:

Ability to store metadata about services during design time
Ability to define and manage (storage, retrieval, etc.) of rules used by the components realizing the services

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

Ability to authorize during invocations on the underlying components.

It relies on the Information Layer for the following capabilities:

Ability to store and retrieve metadata and data required by the components

It relies on the Integration Layer for the following capabilities:

Ability to transform data from one format to another

Key Interactions of the Service Component Layer with Cross-Cutting Layers

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

It leverages the Access Controller ABB and Policy Enforcer ABBs in the Quality of Service Layer to enforce access control privileges and other policies.
It leverages the Data Aggregator ABB, Data Federator ABB, Data Consolidator ABB, Information Metadata Manager ABB, and Data Repository ABB from the Information Layer to provide information about services for the other layers of the SOA RA.
It leverages the Message Transformer ABB and Data Transformer ABB from the Integration Layer to transform data from one format to another. The Method Input/Output Transformer ABB leverages these ABBs from the Integration Layer.
It leverages the Service Repository ABB in the Governance Layer to store metadata about services. IT Governance has a significant influence on the Service Component Layer. The choice of implementation technology, the manner in which Service Components may/may not consume behaviors from other Service Components, and decisions about where to place integration logic are examples of where this layer may be influenced by IT Governance and the Governance Layer. For another example, the implementation options for a Service Component may include BPEL, a Session EJB, a Message Broker Flow, a SOAP/CICS operation, etc. Some of these alternatives may eliminate/involve a governance exception, because the Technology Roadmap established by IT Governance excludes them.

Interaction with Horizontal Layers

The Service Component Layer realizes the services from the Services Layer and then uses the Operational Systems Layer to execute the services in a runtime environment. In order to fulfill these core responsibilities, the ABBs in the Service Component Layer interact with the Services Layer and Operational Systems Layer.

The Service Invoker ABB interacts with the Services Layer and Integration Layer.
The Service Publisher ABB interacts with the Services Layer.
The Service Deployment Manager ABB interacts with the Operational Systems Layer.
The Service Implementation Adapter ABB interacts with the Operational Systems Layer.

Key Interactions of the Service Component Layer with Horizontal Layers

Interaction with the Services Layer

Relationships between the Services Layer and Service Component Layer

By its nature, this layer is coupled to the Services Layer of the SOA RA. A service definition change is likely to cause a direct side-effect on the Service Component in this layer. For example, if a service is retired from the Services Layer, the corresponding Service Component could also be retired if no other services are using it. (It can be argued that the service component may continue to provide values when the service has been retired, as it may continue to be used in the implementation of other service components or services. While this is true, it is important to recognize that the significance of the software component as a service-aligned component has been lost and as such it is no longer subject to the same governance as a service component.) Finally, it is the responsibility of Service Components to faithfully reflect the definition of one or more services. To ensure that this relationship is maintained, a Service Component must not exhibit behaviors not defined in a service description.

The runtime relationship between the Service Component Layer and the Services Layer is illustrated in Use of Runtime Capabilities in the Service Component Layer. Services are deployed in the services container in the Services Layer. The services can be discovered using the Service Registry ABB in the Governance Layer; this can provide the contract and support for virtualization. The service then invokes the corresponding Service Component in the Services Component Layer which is then bound to the solution platform and invoked in the Operational Systems Layer.

Use of Runtime Capabilities in the Service Component Layer

Interactions with the Operational Systems Layer

Service Components often consume behaviors from the Operational Systems Layer. This relationship creates a dependency on the behaviors consumed. If a decision is made to change the manner in which the Operational Systems Layer behavior is realized, there are likely side-effects on the Service Components that consume it. For this reason, traceability between the Service Component Layer and the Operational Systems Layer is an important element of an SOA.

Also, it is often the case that the Operational Systems Layer behavior required by a Service Component is not available in a convenient fashion. In such circumstances, the refactoring of the behaviors in the Operational Systems Layer may be necessary. This is an example of why the implementation of SOA may result in or require changes to the existing Operational Systems Layer.

Usage Implications and Guidance

Options and Design Decisions

There are multiple technology alternatives or realizations for the implementation of the Service Components. The selection criteria employed when choosing a realization technology would include a balance of the following criteria:

Capability: The capability to realize the value proposition of Service Components and to realize the required behavior of a given service.
Familiarity: Whether the capability of using the technology already exists in the organization.
Strategic: Whether the technology is in line with the technology roadmap of the organization.
Manageability: Whether the technology allows for the effective management of Service Components with respect to the Key Performance Indicators (KPIs) defined.

Often the selection requires the prioritization of these criteria. One alternative may offer features that are suited to the needs of a particular service component (e.g., message mediation) but not offer the management capabilities that other Service Components require (e.g., high availability).

Architectural decisions that are often made in connection with this layer include a choice of realization technologies, hosting, and runtime environments. As the Operational Systems Layer is connected with the four vertical layers which represent the cross-cutting concerns that are enablers for the functional layers, decisions regarding those cross-cutting layers will often involve the Operational Systems Layer. Therefore, this layer may be involved in questions pertaining to architectural decisions such as:

What is the best hosting environment for a particular application?
What is an appropriate runtime environment for a particular subset of an application?
What kind of runtime capabilities are required in terms of NFRs?
Should integration always occur through a Mediator ABB in the Integration Layer? Can it be performed inside a Service Component?
Should collaborating Service Components consume each other through the Services Layer or through a platform-specific interface (e.g., EJB-to-EJB or EJB-to-Service)?
Where are transformations performed? In the Service Component Layer or in the Integration Layer?
Should component implementations be portable across multiple runtime environments?

Given that this layer alternately hosts the runtime for the implementation of the various services defined in the Services Layer, the salient KPIs are those that are of common concern in the enterprise systems, such as latency, availability, scalability, reliability, and security.

Latency refers to the delay of accessing a specific service due to internal implementation details and processes. Availability refers to the percentage of how a specific service can be available during a specific timeframe. Scalability refers to the ability of a specific service that supports various scales of consumer groups. Reliability refers to the ability of a specific service that stays no fail during a specific timeframe. Security refers to the ability of a service that provides an authorization and authentication facility to ensure secure access.

Implementation Considerations

Typical Interaction Sequences: A Narrative of the Flow

Refer to the example illustrated in Service Components as a Facade where Service A is implemented using a combination of behavior from third-party Package X and Application Y. The consumer Application B is coupled only to the description of the exposed service. The consumer must assume that the realization of the service is faithful to its published description and it is the providers’ responsibility to ensure that such compliance is achieved. The details of the realization, however, are of no consequence to Application B. Service Component A acts as a service implementation façade; it aggregates available system behavior and gives the provider an enforcement point for service compliance. Application B invokes and interoperates with a service contract and specification defined in the interface in Service A.

Service Components as a Facade

Subsequently, the provider organization may decide to replace “Package X” with “Package M”. The required modifications are encapsulated in Service Component A with the result that there is no impact on any consumers of Service A such as Application B. This example illustrates the value of the Service Component Layer in supporting IT flexibility through encapsulation.

Composition Scenarios

Composition of existing application assets occur frequently in the context of transforming legacy systems into services. Interaction Flow in a Composition Scenario shows an example of how to construct Service Components using existing application assets. Assume two existing application systems – Applicaiton 1 that maintains customer addresses, and Applicaiton 2 that validates postal codes. These two existing applications were developed on proprietary platforms using proprietary technologies. In other words, these two applications are legacy systems. A new project intends to build two web services that can be accessed via the SOAP prototol. First is a “safe” address updating service that would validate postal codes before making changes to addresses. Second is to build a dedicated “validate postal code” service.

Interaction Flow in a Composition Scenario

As shown in Interaction Flow in a Composition Scenario, there is a need to have an “adapter” component that represents particular existing application assets and provides an API for Service Components to consume and expose through necessary functions of this particular application assets. For example, both legacy applications have their own dedicated adaptors. “Adapter” is owned by the same organization that owns the application asset system and is legislated to be the only way to access this application asset. Such an adapter is provided as an API to the legacy system.

In order to construct a SOAP-enabled Service Component, a “service enabler” is a typical instrument, as shown in Interaction Flow in a Composition Scenario. Each Service Component contains a service enabler component if it contains access to legacy systems through adapters. Service Component 1 composes two legacy systems through dedicated adapters, and enables the composed service to SOAP access through a Service Enabler 1. Service Component 2 composes two legacy systems through dedicated adapters, and enables the composed service to SOAP access through a Service Enabler 2. Note that Application 2 only has one adapter, which is re-used in both Service Component 1 and Service Component 2.

⇒ Services Layer

SOA Work Group

SOA Standards Discussion Forum

SOA Work Group Members Page