SOA Reference Architecture – Services Layer



Context and Typical Flow

The Services Layer consists of all the services defined within the SOA. This layer can be thought of as containing the service descriptions for business capabilities and services as well as their IT manifestation during design time, as well as service contract and descriptions that will be used at runtime.

Service Components or existing enterprise applications (legacy systems, packaged applications, etc.) are responsible for the actual implementation aka realization of a service. At runtime, this implementation will reside in a container within the Operational Systems Layer, which is responsible for runtime.

The Services Layer is one of the horizontal layers which provide the business functionality supported in the SOA. The Services Layer is the layer of the SOA which describes functional capabilities of the services in the SOA. The Services Layer introduces the notion of services which are well-defined interfaces for a capability into the architecture with the advent of SOA. The notion of “programming to interfaces rather than implementation” only existed in the programming models such as Java and C++, but was never part of the architectural style until the advent of SOA and services.

This layer primarily provides support for services, from a design-time perspective. In particular, from a design-time perspective this includes assets including service descriptions, contracts, and policies. It defines runtime capabilities for service deployment, but the runtime instantiation of the Architecture Building Blocks (ABBs) enabling these capabilities are housed in the Operational Systems Layer. It also provides the service contract elements that can be created at design time to support subsequent runtime requirements.

Service specifications provide consumers with sufficient detail to locate and invoke the business functions exposed by a provider of the service. Ideally, this is done in a platform-independent manner. Service specifications may include:

  • A description of the abstract functionality offered by the service similar to the abstract stage of a WSDL description [6]; note that the use of WSDL is illustrative and the description can be done in any language supporting description of the functionality
  • A policy document
  • SOA management descriptions
  • Attachments that categorize or show service dependencies

Some of the services in the Services Layer may represent versions of other services in the set, which implies that a significant successor/predecessor relationship exists between them. The actual home for the various versions of a service should be sought in the Governance Layer which houses and centralizes the service registry and repository.

The Services Layer can be thought of as supporting categories of capabilities of the SOA RA:

  • Functional capabilities aka services that enable business capabilities that business performs to achieve a business outcome or a milestone
  • Supporting capabilities to define and specify the “services” in terms of service interface/contract/description, message specification, and policy descriptions
  • Supporting capabilities to enable the runtime execution of the service and the support of service virtualization

These capabilities support the following main responsibilities of the Services Layer:

  • To identify and define services
  • To provide a container which houses the services
  • To provide a registry that virtualizes runtime service access
  • The provide a repository to house and maintain service design-time information


There are multiple categories of capabilities that the Services Layer needs to support in the SOA RA. These categories are capabilities which address the support of:

  • Service Definition: This category of capabilities provides the ability to define the service description.
  • Service Runtime Enablement: This category of capabilities provides the ability to support service versioning, to support service binding decoupling a service from its implementation, and provides the ability to provision services.
  • Policy Management: This category of capabilities provides the ability to manage and enforce policies associated with services.
  • Access Control: This category of capabilities provides the ability to manage access to services.
  • Service Clustering: This category of capabilities provides the ability to cluster services.

This layer features the following supported capabilities:

Service Definition

  1. Ability to define services in terms of service descriptions/contracts

Service Runtime Enablement

  1. Ability to support the resolution of service versions so that, over time, as a service evolves, there is support for successive versions; this occurs when an existing service, with existing consumers, changes to the newly created version
  2. Ability to enable the service container and the service registry to manage the storage and invocation of different services with minimal impact to users of the SOA
  3. Ability to interact with other layers within the SOA RA, particularly the Integration Layer
  4. Ability to define the binding to the Service Component that implements a given service
  5. Ability to support the hosting of services
  6. Ability to check the status and heartbeat of the services

Policy Management

  1. Ability to support the integration of the Quality of Service (QoS) policy descriptions for services with the runtime elements of the Governance and the Quality of Service Layers
  2. Ability to support standards that are compliant to consume the QoS policy descriptions and convert them into assets consumable by the ABBs within the layer
  3. Ability to enforce the policies within the layer, behaving as a Policy Enforcer
  4. Ability to support the audit and logging of runtime service usage to support QoS attributes, with the potential use of standards such as CBE and XDAS to ensure consistent and interoperable data which can then be easily integrated with the Quality of Service Layer to support capabilities such as service monitoring, audit, compliance, and runtime governance.

Access Control

  1. Ability to support the integration of the security access control descriptions for services with the runtime elements of the Governance and Quality of Service Layers of the SOA RA
  2. Ability to support standards that are compliant to consume the security policy descriptions and convert them into assets consumable by the associated ABBs within the layer

Service Clustering

  1. Ability to cluster services which are contained by the service provider to invoke layers such as the Integration Layer; this capability enables the Services Layer to support the QoS requirements with regard to response and reliability
  2. Ability to distribute services which are contained by the service provider to invoke layers such as the Integration Layer

Architecture Building Blocks (ABBs)

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

Capability Category

ABB Name

Supported Capabilities

Service Definition




Governance Layer: Service Repository


Service Runtime Enablement

Service Container



Service Interaction Manager



Governance Layer: Service Registry



Quality of Service Layer: Status Manager


Policy Management

Governance Layer: Policy Manager



Quality of Service Layer: Policy Enforcer


Access Control

Quality of Service Layer: Access Controller


Service Clustering

Cluster Manager


ABB to Capability Mapping for the Services Layer

Details of ABBs and Supported Capabilities

Details of ABBs

This section describes each of the ABBs in the Services Layer in terms of their responsibilities.


This ABB represents a published service that offers certain functionalities that business performs to achieve a business outcome or a milestone. This ABB is one of the core functional ABBs in SOA RA. Typically, a service is published to the Service Repository ABB in the Governance Layer during design time for search and re-use and the Service Registry ABB in the Governance Layer during runtime for service virtualizaton. A service is typically represented in a standard description language (e.g., WSDL) describing its accessible interfaces (e.g., function or method signatures). Service is one of the fundamental constructs of an SOA solution and analysis and design based on the service-oriented paradigm.

Governance Layer: Service Repository

See Service Repository ABB in the Governance Layer.

Service Container

This ABB acts as a container or gateway by providing the environment with the ability to invoke and run services (manage their runtime invocation, lifecycle, etc.). The Service Container is also commonly known as a Service Gateway. The primary responsibility of the Service Container is to encapsulate the code that implements the low-level details of communicating with a service into this ABB. Some Service Containers require capabilities beyond basic communication, such as transactions and security.

Thus, its key communication and virtualization responsibilities include the invocation and execution of services, encapsulating the components that implement the service (i.e., providing the service end-points), state management, and the binding of service invocations to cross-cutting layers (such as the Integration Layer and the Business Process Layer in particular), the clustering of services, and their distribution to different consumers.

It should be noted that all ABBs (including the Service Container) are instantiated in the Operational Systems Layer. For instance, a Service Container may be contained within a J2EE environment or a .NET environment. It is also possible for it to be a hardware device as long as it provides the ABBs required with the ability to support runtime invocation and running of services and integration with cross-cutting layers.

Within the Service Container are ABBs which enable it to invoke and execute service components, and support the integration with the cross-cutting layers – the Quality of Service Layer, Integration Layer, and Governance Layer. It leverages the Service Repository ABB and Service Registry ABB in the Governance Layer to support service versioning and virtualization.

Service Interaction Manager

This ABB is contained within the Service Container and in general manages the interactions required to invoke and run the services. It uses all the other ABBs within the Services Layer to achieve its goals.

Governance Layer: Service Registry

See Service Registry ABB in the Governance Layer.

Quality of Service Layer: Status Manager

See Status Manager ABB in the Quality of Service Layer.

Governance Layer: Policy Manager

See Policy Manager ABB in the Governance 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.

Cluster Manager

This ABB supports scalability within the Services Layer. It provides clustering and caching support when necessary.

Structural Overview of the Layer

The ABBs in the Services Layer can be thought of as being logically partitioned into categories which support the abilities to identify and specify services during design time and to provide a runtime environment for services and abilities to managing service metadata in support of the service runtime.

The service runtime environment needs to:

  • Provide runtime support for services
  • Provide the container to support runtime service lifecycle management
  • Separate out service types and versions and invoke these services
  • Support scalability, which becomes critical with high-volume service invocations
  • Integrate cross-cutting concerns, allowing access control, audit and identity integration (security policies), and QoS policies to be integrated
  • Support the actual conversion and binding to the platform for an individual service

Thus, the ABBs in the Services Layer enable design-time capabilities, such as service definition, and runtime capabilities, such as service container, providing a runtime environment for services. The Service ABB along with the Service Repository ABB in the Governance Layer supports design-time capabilities and the Service Container ABB along with the Service Registry ABB in the Governance Layer support runtime capabilities.

ABBs in the Services Layer

ABBs in the Services Layer illustrates the ABBs in the Services Layer and ABBs from other layers that are core to fulfilling the responsibilities of the Services Layer.

ABBs supporting design-time needs are:

  • Service ABB
  • Service Repository ABB in the Governance Layer
  • Policy Manager ABB in the Governance Layer

ABBs supporting runtime environment for the services are:

  • Service Container ABB
  • Service Interaction Manager ABB
  • Service Registry ABB in the Governance Layer
  • Policy Enforcer ABB in the Governance Layer
  • Access Controller ABB in the Quality of Service Layer
  • Cluster Manager ABB
  • Status Manager ABB in the Quality of Service Layer

Inter-Relationships between the ABBs

Relationships among ABBs in the Services Layer shows the inter-dependencies between the ABBs during design time and runtime.

Relationships among ABBs in the Services Layer

During design time, information such as metadata about service contracts gets stored in the Service Repository ABB in the Governance Layer and policy associated with services are defined using the Policy Manager ABB in the Governance Layer.

During runtime, the consumers of services interact with the Service Registry ABB in the Governance Layer to find the service. The Service Registry ABB then invokes the service hosted in the Service Container ABB where the Service Interaction Manager ABB then manages the interaction between the various ABBs within the container and other layers of the SOA RA. The Policy Enforcer ABB in the Quality of Service Layer enforces service policies (including both QoS and security policies). The Service Container ABB invokes the Service Component in the Service Component Layer to realize a service. Thus the functionality of the service and the physical service is the Service Component, while the role of the Services Layer is to act as the translation between the consumer and the Service Component. Upon completion of execution the service is propagated back up to the Service Binder, and then the Service Interaction Manager which applies policies using the Access Manager and the Policy Enforcement End-point, logs compliance and runtime logging information using the Policy Manager, and finally propagates the information via the Service Binder back to the Service Consumer.

Usage of a service by a consumer involves two steps – service discovery and location, and service invocation. The figures below show these steps.

Interaction Flow for Service Discovery and Location

Interaction Flow for Service Invocation

Significant Intersection Points with other Layers

Interaction with Cross-Cutting Layers

The Service Repository ABB in the Governance Layer acts as the interaction point at design time with the Information, Governance, and Quality of Service Layers, respectively. The Service Container interacts with the Integration Layer using ABBs such as the Service Integration Controller. The Service Container ABB uses the Service Repository and Registry in the Governance Layer to find information needed to support the service, such as policies and binding information. This relationship at runtime enables late binding of services.

The Policy Manager ABB in the Governance Layer, Access Controller ABB in the Quality of Service Layer, and Policy Enforcer ABB in the Quality of Service Layer exchange and enforce policies ensuring standards-compliant interaction that adheres to the governance regimen. Interactions from the Services Layer to the Cross-Cutting Layers illustrates these relationships.

Interactions from the Services Layer to the Cross-Cutting Layers

The Service Container ABB also leverages the Policy Enforcer ABB to enforce the service policies in order to deal with compliance of Service-Level Agreements (SLAs) of services.

Interaction with Horizontal Layers

The Service Registry ABB in the Governance Layer is where service consumers interact with the Services Layer to find the service end-point, by which a service is invoked (the actual specification of what is a service end-point varies based on the actual solution architecture and the resultant solution platforms). The Service Interaction Manager is the invocation integration point for the Service Container ABB which then manages using the Service Interaction Manager to coordinate all its internal ABBs. The Service Interaction Manager invokes the Access Controller ABB and the Policy Enforcer ABB in the Quality of Service Layer to assert the QoS contract of the service and to invoke the Service Interaction Manager to convert invocations into Service Component invocations, thus effectively executing the associated service functionality. Finally, Service Components upon completion of the service execution send back the service response data to the Service Interaction Manager which then propagates the service response data back to the service consumer. During execution, if the status of the service changes, the Service Interaction Manager notifies the Status Manager in the Quality of Service Layer of the change. Likewise, the Status Manager can interact with the Service Interaction Manager to change the status of the service.

Interaction with Horizontal Layers

To summarize:

The Service Repository ABB in the Governance Layer provides design-time storage of metadata for services.

The Service Registry ABB in the Governance Layer supports the storage of and access to bindings at runtime to services hosted in the Service Container/Gateway ABB. It manages service versioning allowing the appropriate service to be picked.

The Service Interaction Manager ABB plays three roles – acting as the outward-facing ABB which is invoked by other layers at runtime to invoke services, and invoking the service components from the service components layer, and converting data between different formats. The service binder invokes the service container to compose all the information required to invoke the service ABB. The Service Interaction Manager ABB uses the Policy Enforcer ABB and Access Controller ABB in the Quality of Service Layer to enforce and incorporate any security and QoS policies. It uses the state manager to address any state-related issues. It then calls the Service Invoker ABB in the Service Component Layer to execute the service functionality, accept the result from the service component, interact with the Service Interaction Manager ABB, and propagate it back via the Service Container ABB to the invoking consumer.

The runtime services are housed in a Service Container ABB using the hosting ABB. The Service Container ABB manages the runtime service lifecycle and uses the Service Interaction Manager ABB to invoke Service Components and the cluster manager to support scalability in the service container.

The Policy Enforcer ABB provides the interaction point, between the Quality of Service Layer and the Service Layer, supporting Policy Enforcement. The Access Manager provides Authorization and Authentication support in the context of the layer and integrates with corresponding ABBs which define security policies in the Quality of Service Layer. In practice, it too acts as a Policy Enforcer.

Types of Service

As outlined in Structural Overview of the Layer, one type of ABB in the Service Layer is a service. Services are naturally a key concept in any SOA and it is important to realize that there can be many different kinds. This section defines a standard categorization scheme for services. Services are categorized according to what they do; i.e., their function or purpose, in order to aid in ensuring both coverage and shared understanding. Of course, other categorization schemes are also possible and helpful.

Partitioning services into groups is a common activity in the development of the services and service portfolio in an SOA. Categories and groups of services affect how both business and IT views and understands the architecture and the portfolio of services that supports it.

Note that the categorization scheme for a particular type of ABB is distinct and separate from which layers in the reference architecture such ABBs are associated with. For example, there is no contradiction in defining “process services” as a category of services. A process service is simply process logic exposed as a service. Since these are in fact services, as service ABBs they belong in the Services Layer. Yet, having said that, their realization as processes properly belongs in the process layers and typically leverages other ABBs such as a Process Controller. In fact the process service implementations will often also rely on implementations of ABBs in other layers, like the Process Manager and policy ABBs in the Quality of Service Layer. The seeming dichotomy is not a dichotomy at all, but simply a natural consequence of delineating the service itself (as a service) from the realization of that service (as a process). This is consistent with The Open Group SOA Ontology [24] where there is a clear delineation between the logical service itself and things that perform that logical service.

Functional Categorization Scheme shows a functional categorization scheme for services found in a typical enterprise. As mentioned above, this categorization scheme is for the services themselves, not for their implementations (which will be ABBs of other layers of the SOA RA).

Functional Categorization Scheme

The categorizations of services are broken down in Functional Categorization Scheme. Those categories (such as the interaction services, process services, etc.) graphically connected to the Service Connectivity Services and Business Services category are considered to be domain-specific. Services in the domain-specific categories are solution-specific and thus require unique implementation-specific ABBs to implement their semantics.

The remaining services categories are considered to be domain-neutral. These domain-neutral categories include development services, management services, etc. Services in these categories can be used in any domain or solution. In general, domain-neutral services are used to plan, develop, support, and manage the domain-specific services in the solution.

Note that the Interaction, Process, and Information service categories support the Model-View-Controller Pattern. The value of separating these aspects in the traditional view of architecture still holds true for SOA.

Services categories are described below.

Interaction Services

Interaction services are a category of services that provide the presentation logic of the business design. These services are components that support the interaction between applications and end users. Interactions with the external world are not limited to just interactions with humans; interaction logic orchestrates the interface to all kinds of devices and control systems, including vehicles, sensors, and RFID devices. Every external interaction projects a view of the information system that is tailored for the specific interaction fidelity, frequency of interaction, and presentation composition that best fits the needs of the end user or device.

Interaction services may also be tailored to the situation as well as role-sensitive contexts. Adjusting what is seen and the behavior presented to the external world based on who the user is, what role they are performing, and their location. Authentication, privilege selection, and proximity may all be significant to what users can do and how. Collaboration and collaboration services also can be categorized as interaction services as they also provide a means for users to interact with the solution.

Interaction services are most closely aligned with the Consumer Layer. Interaction service implementations use the Presentation Controller ABB in the Consumer Layer to present the interface. The Presentation Controller ABB uses ABBs from other layers to complete its implementation; for example, it uses the Access Controller and the Policy Enforcer ABB implementations from the Quality of Service Layer to provide the support for role-sensitive content and authentication. Interaction service implementations may also use the Integration Controller and Mediator ABB implementations from the Integration Layer to communicate with the consumer. Together, these ABBs, and others, work across the layers to allow a user to interact with a given system.

Process Services

Process services are a category of services that include various forms of compositional logic. The most notable of which are business process flows, business state machines, business rules, and decision tree processing. It is appropriate to select the abstraction that best matches the implementation of the business design.

Process services and their composition abstraction preferences and the business logic where business rules are enforced have a tight integration with the business. The rate of change, administration requirements, and legal control of the logic behind these rules dictates whether another paradigm should be used to create and govern these rules.

Business rule engines are one way to customize a business process abstraction; for example, a business check, such as isItemTaxable(), can be inserted in the business logic, and rely on the business rules engine to consult a separately managed table of tax rules, which will return whether or not sales tax should be applied to the purchase. This table is managed by a business administrator who has the proper business authority rather than a business logic programmer – thus, separating the concerns of the business logic from the rules that govern the logic. This enables dynamic processes and support for decision services to make or advise on decisions in processes or at the end of processes.

Process services are most closely aligned with the process layer. Process service implementations implement or use implementations of the Process Controller and Process Flow Manager ABBs. In turn, these ABBs in the process layer implement ABBs from other layers, like the Business Rules Manager, where business rules are defined, in the Governance Layer.

Information Services

Information services are a category of services that contain the data logic of business design. The service implementations that provide the data logic have three major responsibilities: to provide access to the persistent data of the business, to support data composition of the business, and to provide their own sub-architecture for managing the flow of data across the organization.

  • Data Access: The data access information service implementations can include query statements for retrieving information or referential integrity checks on the information manipulated by these service implementations. Information services for data access incorporate federation of multiple data sources.
  • Data Composition: The data composition information service implementations compose information in a way that matches the composition of services in the business design. This is analogous to the kind of re-factoring that can occur with legacy applications to get them to fit better with the business design. In addition, it is common practice to implement these services to separate the database design from the application design to achieve the level of performance and scalability required in many enterprise computing environments.
  • Data Flow: The data flow information service implementations manage the movement of information from one part of the enterprise to another. The movement of data is needed to satisfy its own data flow and lifecycle requirements. This may involve the use of Extract-Transform-Load (ETL) mechanisms to process and enrich data in bulk, batch processing activities involved in bulk transaction processing, and migrating data from master-data-of-record databases to information warehouses that can be used to perform post-processing and business intelligence, analytics, and content management functions – which in turn are made available to the business application as services.

Information services are most closely aligned with the Information Layer. Information service implementations use the ABBs in the Information Layer. These ABBs include but are not limited to the Data Validator, Data Aggregator, Content Manager, Data Repository, and Data Federation. Together these ABBs provide the means for the service implementations to find and present data in a logical manner.

Business Application Services

Business application services are a category of services that implement core business logic. These are service implementations created specifically within a business model and that represent the basic building blocks of business design. These services are not decomposable within the business model, but can be composed to form higher-level services. Often implementations of these services will be composed in business processes (such as process flows or business state machines). However, these service implementations may also be invoked directly by presentation logic in interaction services.

Business application services are most closely aligned with the Services Layer. Business application service implementations implement or use implementations of the Service Container and Service Interaction Manager ABBs. Business application service implementations may also implement or use implementations of ABBs from other layers, including the Access Controller and Policy Enforcer from the Quality of Service Layer as well as the Policy Manager from the Governance Layer.

Access Services

Access services are a category of services that are dedicated to integrating legacy applications and functions into the SOA solution. This can be as simple as wrapping those functions and rendering them as service implementations. This can also be a more complex case that augments the logic of the existing function to better meet the needs of the business design. In other architectures we have often referred to these access service implementations as adapters. In the SOA RA, these service implementations are distinctly responsible for rendering these adapters so that they can be manipulated and composed within business processes like any other service implementation component.

Access services are most closely aligned with the Services Layer. Access service implementations implement or use the implementation of the Service Invoker ABB in the Component Layer which interacts with other ABB implementations within the Component Layer for binding to the service interface and accessing the Operational Systems Layer’s Solution Component and Hardware ABBs.

Partner Services

Partner services are a category of services that capture the semantics of partner interoperability that have a direct representation in the business design. These services include the policies and constraints that other businesses must conform with to work within the business. Partner service implementations are somewhat analogous to interaction service implementations in that they project a view of the business to the partners, and control the interaction with them as an external entity. Partner service implementations are also analogous to access service implementations because they render the capabilities of that partner as a service so that those functions can be composed into the business processes.

Partner services are most closely aligned with the Services Layer. Partner service implementations use the Service Interaction and Service Container ABBs. These ABB implementations also use or implement ABBs from other layers, including the Integration Controller in the Integration Layer, the Access Controller and Policy Enforcer from the Quality of Service Layer, and the Service Registry and Repository and Policy Manager from the Governance Layer.

Service Connectivity Services

Service connectivity services are a category of service that assumes the responsibility for binding service consumers with service providers – they implement this responsibility by resolving their location automatically to achieve an optimal routing of requests across the network and meet the goals of the business. The presence of service connectivity services, like Enterprise Service Buses (ESBs), should be transparent to the consumer of functional services in the SOA solution. Though transparent, service connectivity services are fundamental to simplifying the task of invoking services – making the use of services wherever they are needed.

Implementations of the service connectivity services support interconnectivity and host Mediations – logic that may perform message transformation, intelligent routing, augmented functionality (such as logging or auditing) to enable the interconnectivity of services. Because the service connectivity services are a transparent fabric interconnecting service consumers with service realizations/implementations, then, by extension, the service connectivity service implementation also makes hosting mediating logic, and more specifically the hosting topology, transparent to the service consumers and providers which are being mediated. Service connectivity services are a mix of domain-neutral (messaging products and ESBs available from many vendors), and domain-specific (the implementations of adapters needed from existing services and operational systems into the ESB).

Service connectivity services are implemented mostly with the ABBs in the Integration Layer. The ABBs used could include the Integration Controller, Mediator, Router, Adapter, Data Aggregator, and Message Transformer, depending on the exact needs.

Asset and Registry Services

Asset and registry services are a category of services that provide access to the assets that are part of the overall architecture. Implementations of these services provide access to service descriptions, software services, policy, documentation, and other assets or artifacts that are essential to the operation of the business. These are assets and artifacts that need to be registered for search and consumption and therefore need to be managed (usually by services in the lifecycle category). Services that provide access to these assets are especially important in a heterogeneous environment as they allow for the query of assets within the environment across multiple registries. Once located, these assets can then be incorporated into the overall SOA and invoked to provide necessary function for the business. It is important to note that asset and registry services are used by lifecycle service implementations, but they do not provide lifecycle services themselves.

Asset and registry services implementations implement or use implementations of the ABBs from the Governance Layer such as the Service Repository ABB and the Service Registry ABB.

Infrastructure Services

Infrastructure services are a category of services that form the core of the information technology environment for hosting SOA applications. It is through these service implementations that a reliable system can be built to provide efficient utilization of resources, ensure the integrity of the operational environment, and balance workload to meet service-level objectives, isolate work to avoid interference, perform maintenance, secure access to confidential business processes and data, and simplify overall administration of the system.

Infrastructure services virtualize the underlying computing platform and resource dependencies. The service implementations themselves are built using SOA principles – exploiting the characteristics of loose coupling to enable highly flexible and composable systems.

The SOA RA has been designed to specifically allow different technologies to be plugged at various layers of the system – allowing the trade-off of tight-integration QoS with the flexibility to pick-and-choose which mix of product technologies are appropriate for the business requirements and goals, and to address the inevitable heterogeneity of legacy environments.

Infrastructure services are most closely aligned with the Operational Systems Layer. Infrastructure services implement or use implementations of the Solution Component, Implementation Controller, as well as Hardware and Virtualized Infrastructure ABBs. Infrastructure service implementations implement or use implementations of many of the ABBs in the Quality of Service Layer to provide the management of the infrastructure services and underlying resources; i.e., IT systems manager, availability manager, and performance manager. These ABBs work together to provide an overall IT environment for hosting an SOA solution.

Management Services

Management services are a category of services that represent the set of management tools used to monitor service flows, the health of the underlying system, the utilization of resources, the identification of outages and bottlenecks, the attainment of service goals, the enforcement of administrative policies, and recovery from failures. This includes in a business process management context the management of business processes and monitoring of performance metrics and Key Performance Indicators (KPIs). Management service implementations can be used to help prioritize the resolution of problems that surface in the information system, or to direct the allocation of execution capacity to different parts of the system based on service-level goals that have been set against the business design.

Management services are most closely aligned with the Quality of Service Layer. Management services implementations implement or use implementations of some of the ABBs in the Quality of Service Layer, including the Command and Control Manager, IT Systems Manager, Event Manager, Policy Enforcer, Configuration Manager, Security Manager, and Solution Manager, which include an Availability Manager, Reliability Manager, and Performance Manager. These ABB implementations then rely on the Service Repository and Policy Manager ABB implementations in the Governance Layer to help implement the management services.

Business Services

Business services are a category of services that capture the business function and then introspect on the business design to improve it through a combination of iterative refinement and analysis of real-time business metrics.

Management service implementations in the Quality of Service Layer help to define KPIs; that is, those business objectives and general metrics that are desired to be monitored. The service implementations will be linked directly into the information system to both collect performance metrics coming out of the system as well as to enable the change of which metrics are measured as monitoring needs change. Automated analysis of these metrics could automatically suggest improvements to the business design to better meet the business goals and objectives. However, capturing them for consideration by business executives, business analysts, and other human experts obviously meets an immediate and long-standing need, and is an incremental step toward the automation and flexibility promised by SOA.

Business services are consumers of the functional services outlined in the previous section and closely aligned with the Consumer Layer for implementation ABBs. Business service implementations also use the management ABBs in the Quality of Service Layer to implement the support for metrics and metrics monitoring; i.e., the Monitoring Metrics Tools ABB, the Policy Enforcer ABB, and the Business Activity Manager ABB. These ABBs work across the layers to provide and monitor business services.

Strategy and Planning Services

Strategy and planning services are a category of services that supports creating a vision, blueprint, and transition plan for improving business outcomes. Specifically, these are services that process the strategies of the business to create an implementation roadmap covering both business and IT. In other words, these services support the long-term evolution and effectiveness of an enterprise.

Strategy and planning services produce strategies and enterprise blueprints that define a desired future state and are used to prioritize, select, guide, and govern the execution of projects – the purpose is the planning of effective change. Examples of enterprise blueprints are work products such as component business models, business architectures, and enterprise architectures, all created with the purpose of achieving business and IT alignment and better business outcomes.

Strategy and planning services are typically used (or produced) by roles such as strategists, enterprise architects, and business architects. Included in the category of strategy and planning are services for governance, architectural, and organizational change. Included in this category are also services that support collaboration and coordination across planning and delivery.

Strategy and planning services are most closely aligned with the Governance Layer and allow business and IT to plan and prioritize changes to solutions and operations. The Policy Manager and Business Rules Manager, Reporting Tools, and Change Control Manager ABBs are used to implement and provide these strategy and planning services.

Development Services

Development services are a category of services that encompass the entire suite of architecture tools, modeling tools, development tools, visual composition tools, assembly tools, methodologies, debugging aids, instrumentation tools, asset repositories, discovery agents, and publishing mechanisms needed to construct an SOA-based application. Some development tools, like Eclipse, have a built-in mechanism for modularizing and plugging in tool services, thus encouraging the construction of the development tools as services following many of the same principles promoted by SOA.

Development services use repository ABBs in the Governance Layer to get the descriptions needed during development. Development service implementations can also register the appropriate services in the appropriate service registries by leveraging asset and registry services, or possibly even directly via the Service Registry ABB.

Lifecycle Services

Lifecycle services are a category of services that support managing the lifecycle of SOA solutions and all of the elements that comprise them across development and management, ranging from strategy to infrastructure. Lifecycle services can be applied to all categories of services, managing and governing the service definitions and service implementations within that category. Managing and governing the full lifecycle of an SOA solution includes SOA Governance, Policy Management, Requirements Management, and Configuration Management.

Implementations of the lifecycle services rely strongly on asset and registry service implementations since these provide access to some of the portfolio of assets that the lifecycle service implementations must manage. The assets that are managed include service implementations, processes, documents, etc.

Lifecycle services are most closely aligned with the Governance Layer. The Service Repository and Service Registry ABBs are used to implement and provide lifecycle services.


These categories or types of services can be kept in mind when developing your service portfolio and your SOA solution portfolio. Use these as a checklist to ensure that you have considered all the possible services and can make the right choices on fulfilling the development or purchase of those services. The examples of which SOA RA layers and ABBs can be used to develop the services should make selecting the right ABBs easier for your solution architecture.

Usage Implications and Guidance

Exposed services reside in this layer. They can be discovered and invoked, or possibly choreographed to create a composite service. Services are functions that are accessible across a network via well-defined interfaces of the Services Layer. The Services Layer also provides for the mechanism to take enterprise-scale components, business unit-specific components, and in some cases project-specific components, and externalizes a subset of their interfaces in the form of service descriptions. Thus, the components provide services through their interfaces. The interfaces get exported as service descriptions in this layer, where services exist in isolation (atomic) or as composite services.

For example, a service container, in which the services are hosted and invoked from, is also a part of the Services Layer. The service container is compliant with the standards for service specification being supported by the service, and runs on a hosting platform in the Operational Systems Layer.

This layer contains the contracts that bind the provider and consumer. Services are offered by service providers and are consumed by service consumers (service requestors).

The layers and their underlying building blocks in the target architecture may be defined according to the service identification activities which may be defined through three complementary techniques of domain decomposition, existing asset analysis, and goal-service modeling to identify, specify, and realize services, components, and flows [1][20]. They represent the heart of the SOA value proposition, which is improved agility via the decoupling of business and IT. The quality of these service definitions will have a significant impact on the benefit of the given SOA effort.

Services are accessible independent of the implementation and transport. This allows a service to be exposed consistently across multiple customer-facing channels such as the web, Interactive Voice Response (IVR), etc. The transformation of response to HTML (for the web), VoiceXML [16] (for IVR), and XML string (for XML client) can be done via XSLT [19] functionality supported through transformation capability in the Integration Layer.

It is important to acknowledge that Service Components may consume services to support integration. The identification and exposure of this type of service; i.e., the internal services, does not necessarily require the same rigor as is required for a business service. While there may be a compelling IT-related reason behind the use of such services, they are not generally tied back to a business process and as such do not warrant the rigorous analysis required for business services.

In addition to being an important template for defining an SOA solution at a logical level, the SOA RA is also a useful tool in the design of vendor-neutral SOA solutions. This is because it enables the objective identification of SOA infrastructure requirements. The SOA RA provides a well-factored decomposition of the SOA problem space, which allows architects to focus on those parts of an SOA solution that are important in the context of the problem they are solving and to map the required capabilities onto vendor product capability – rather than try and reverse engineer an SOA solution architecture from the capability of a particular vendor’s products. This set of requirements can be used to better leverage the various capabilities provided by a mix of different vendors who may offer the same ABB. Using the same SOA RA, SOA business services can be delivered based on the same deployment framework.