Guideline: Allocating SOA Elements to Architectural Layers
This guideline provides advice regarding where to allocate service-relevant artifacts across a reference layered architecture.
Relationships
Main Description

Here, we describe where to logically allocate services artifacts across IBM's SOA Solution Stack reference architecture.  We focus more specifically on allocations across the five functional layers, those being:

  • Consumers
  • Business processes
  • Services
  • Service components
  • Operational systems

This reference architecture is illustrated below:

                        

Per the SOA Solution Stack concept, this is not a strongly-layered architecture.  For example, every layer does not need to be populated.  Further, elements in one layer can communicate with elements in non-adjacent layers.  For example, an exposed service can communicate directly with an implementing operational system, rather than communicate with that system using an intermediate facade which serves as a service component. 

Consumers

Although the contents of this layer are not limited to such, presentation layer components (and supporting infrastructure) for business applications generally are positioned here.

Other components that might be allocated to this layer in a logical sense include:

  • Non-service-based applications and systems that are known to make use of services from this SOA.
  • Service components which are part of another SOA solution, but which are known to make use of services from this SOA for their realization.

Business Process

The business process layer handles all business logic regarding service composition.  This includes run-times responsible for executing the choreography of services to realize a business process, components for managing access control, components for managing the state of long-lived processes, etc.

Pattern 1: Factor composition logic away from process logic provides a best practice that applies for this layer.  Briefly, it is feasible to contain all the choreography logic for a given business process within a single choreography artifact (such as a single BPEL4WS file).  However, doing this reduces flexibility with respect to the future re-implementation of the realization of sub-processes of the process.  Refer to the pattern documentation for a discussion of alternative approaches that improve business agility.

Services

The services layer includes all the services in an SOA solution.  These include both atomic services (those which do not depend upon other services for their implementation) and composite services (those which depend upon more than one other service for their implementation).  Service Participants (service providers and consumers) also are found here. The service layer also contains run-time components that manage service discovery and run-time binding. 

Service Components

The service components layer includes code containers that implement service operations.  In addition to using code (functional and technical components) that is also allocated to this layer, a service component can use functionality from the Operational Systems layer, the Services layer, or the Business Process layer.

This layer also contains supporting components, such as (1) adapters to mediate between operational systems and service components and (2) converters to ensure compatibility of data as it moves through a component chain.

Operational Systems

This layer contains existing operational assets, such as packaged applications and custom (in-house) systems.  This layer also includes the run-time components, such as application servers, process servers, and database servers that are required to deploy an SOA.

More Information