• SOA Source Book
• Service-Oriented Architecture
• The Open Group Service Integration Maturity Model (OSIMM) Version 2
• SOA Reference Architecture
• 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
• Referenced Documents
• Acknowledgements
• Legal
• Service-Oriented Cloud Computing Infrastructure (SOCCI) Framework
• Using TOGAF to Define and Govern Service-Oriented Architectures
• SOA Governance Framework
• Service-Oriented Architecture Ontology Version 2.0
• Legacy Evolution to SOA
• Microservices Architecture
• SOA for Business Technology
• Navigating the SOA Open Standards Landscape Around Architecture
• SOA in the Digital Age

SOA Work Group

SOA Standards Discussion Forum

SOA Work Group Members Page

SOA Reference Architecture – Business Process Layer

Overview

Context and Typical Flow

With the advent of SOA came the promise of agility and flexibility. An organization that has embarked on the journey of SOA would be successful in delivering the promise of agility and flexibility only when its business processes and associated flows are realized in the architecture in a fashion that allow rapid changes in the implementation of these business processes. In the past, business process flows were typically embedded in software components and user interfaces. The SOA Reference Architecture (SOA RA) recognizes the promise of SOA and the challenges in the past in the ability to change the business processes as market changes and therefore introduces a specific layer for business processes and flows. The layer is called the Business Process Layer and allows externalization of the business process flow in a separate layer in the architecture and thus has a better chance to rapidly change as the market condition changes.

The Business Process Layer covers process representation and composition, and provides building blocks for aggregating loosely-coupled services as a sequencing process aligned with business goals. Data flow and control flow are used to enable interactions between services and business processes. The interaction may exist within an enterprise or across multiple enterprises.

This layer includes information exchange flow between participants (individual users and business entities), resources, and processes in a variety of forms to achieve the business goal. Most of the exchanged information may also include non-structured and non-transactional messages. The business logic is used to form service flow as parallel tasks or sequential tasks based on business rules, policies, and other business requirements.

Business processes represent the backbone of the flow of a business. The dynamic side of business architecture is realized through business processes. These business processes used to be implemented through a combination of static applications or, at best, a hardwired workflow. With service-orientation, a process can be realized by service compositions (which may be interim as an orchestration or a choreography) and the ability to insert “human intervention” and support long-running transactions.

In particular, compositions of services exposed in the Services Layer are defined in this layer: atomic services are composed into a set of composite services using a service composition engine. Note that composition can be implemented as a choreography of services or an orchestration of the underlying service elements.

Services combined or composed into flows or, for example, choreographies of services, bundled into a flow, work together to establish an application. These applications support specific use-cases and business processes. Typically, a visual flow composition tool will be used to design the application flow. Services Orchestration shows how a Business Process “P” can be implemented using Services A, B, C, and D from the Services Layer. Process P contains the logic for the sequence in which the services need to be invoked and executed, as well as having responsibility for many of the non-functional aspects such as state management. The services that are aggregated into a business process can be sourced from individual services or composite services.

Services Orchestration

The Business Process Layer leverages the Services Layer to compose and choreograph services and to coordinate business processes to fulfill customer requirements. Visual flow composition tools such as BPMN-based tools can be used for design of application flow.

In more detail, the Business Process Layer performs three-dimensional process-level handling: top-down, bottom-up, and horizontal. From the top-down direction, this layer provides facilities to decompose business requirements into tasks comprising activity flows, each being realized by existing business processes, services, and service components. From the bottom-up direction, the layer provides facilities to compose existing business processes, services, and service components into new business processes. From the horizontal direction, the layer provides services-oriented collaboration control between business processes, services, and service components.

The decomposition of a business process first decomposes it into smaller tasks; then each task is mapped into coarse-grain service (i.e., candidate services) that will be realized by actual web services in the Services Layer. In other words, the layer provides the ability to decompose a business process into coarse-grain candidate services that fulfill the business functions.

Value Proposition

Building process blocks on-demand with reduced cost allows the supporting technology changes from being high volume/transactional to sophisticated but much smaller footprint applications. In fact, a business process captures the activities needed to accomplish a certain business goal. In today’s business solutions, a business process has played a central role in bridging the gap between business and IT.

From the top-down approach, a business process can be defined by business people based on customers’ requirements. In order to optimize the business process for better IT implementation, a business process should be componentized as re-usable services that can be modeled, analyzed, and optimized based on business requirements such as Quality of Service (QoS) (historical data described in the Quality of Service Layer), flow preference, price, time of delivery, and customer preferences. From the bottom-up approach, after a set of assets is created, they could be leveraged in a meaningful business context to satisfy customer requirements. The flexibility and extensibility of services composition guided by business requirements and composition rules enable business process on-demand for addressing different types of customer pinpoints by re-using services assets.

From an interaction perspective, the Business Process Layer communicates with the Consumer Layer (aka presentation layer) to communicate inputs and results with role players (e.g., end user, decision-makers, system administrator, etc.) through web portal or Business-to-Business (B2B) programs. Most of the control flow messages and data flow messages of the business process may be routed and transformed through the Integration Layer. The contents of the messages could be defined by the Information Layer. The Key Performance Indicators (KPIs) for each task or process could be defined in the Quality of Service Layer. The aggregation of services could be guided by the Governance Layer.

All the services should be represented and described by the Services Layer; and Service Components are represented by the Service Component Layer. From a technical perspective, dynamic and automatic business process composition poses critical challenges to researchers and practitioners in the field of web services. First, business processes are driven by business requirements, which typically tend to be informal, subjective, and difficult to quantify. Therefore, it is critical to properly formulate the descriptive and subjective requirements into quantifiable, objective, and machine-readable formats in order to enable automatic business process composition.

Second, existing web services-based business process description languages do not adequately accommodate detailed requirement specification, which fact makes it difficult to create optimal business process compositions.

Third, present web services specifications generally lack a facility to define comprehensive relationships among business entities, business services, and operations. These relationships may be important to optimize business process composition. For example, suppose enterprise E1 needs to compose a business process including service S. Enterprises E2 and E3 both provide similar service S.

However, there is a partnership between E1 and E2 that leads to a discount on services, and there is no partnership relationship between E1 and E3. If price is a requirement for party E1, this partnership between E1 and E2 needs to be taken into consideration in order to form the most appropriate business process. Fourth, nowadays more and more web services are published to the Internet on the daily basis. How to clearly specify search requirements to discover the most appropriate web services candidates remains a challenge. Fifth, a typical business process generally requires multiple web services to collaborate in order to serve business requirements.

Therefore, each Service Component not only needs to satisfy individual requirements, but also needs to coexist with other Service Components in order to best fit the overall composed business process. In other words, the entire business process needs to be optimized prior to execution.

In summary, the Business Process Layer in the SOA RA plays a central coordinating role in connecting business-level requirements and IT-level solution components through collaboration with the Integration Layer, Quality of Service Layer, as well as the Information Layer, the Services Layer, and the Service Component Layer. Addressing those challenging issues are being covered in this Business Process Layer to further differentiate the proposed SOA RA with other conceptual reference models from other vendors.

Typical Flow

A typical calling sequence is to invoke a composite service in this layer, which implements a business process. This layer will then be responsible for orchestrating or choreographing the set of required underlying atomic or composite services that are combined to constitute the business process. It will typically maintain state for the flow, provide or collaborate with the Quality of Service Layer for monitoring the process flow, applying policies by working with the Governance Layer. Note that the invocation of the services may occur directly, or preferably, through the Integration Layer, thus enabling a separation of concerns between requester and provider to be managed by the capabilities and Architecture Building Blocks (ABBs) of the Integration Layer. For example, a single or federated set of Enterprise Service Bus(es) (ESBs) may be used to realize the invocation.

This layer will rely on the infrastructure provided by the Operational Systems Layer, in which, for example, the BPEL engine implementation will physically reside.

Capabilities

This layer supports and manages business processes and enables the SOA to choreograph or orchestrate services to realize business processes. Business Process Management (BPM) is to be found to start in this layer. There are multiple categories of capabilities that the Business Process Layer needs to support. These categories of capabilities are:

• Process Definition: This category of capabilities is required for defining the business processes/operational flow of the business.
• Event Handling: This category of capabilities handles business events in the context of a business process such as emitting/publishing events and subscribing/listening to business events.
• Process Runtime Enablement: This category of capabilities enables BPM and helps to realize the business processes in the runtime environment using standards such as BPEL, SCA, etc.
• Process Information Management: This category of capabilities manages the information needs of a business process such as managing its state, transforming data in the process flow, and maintaining a repository of assets.
• Decision Management: This category of capabilities defines and manages the decision points and associated rules within a business process.
• Process Integration: This category of capabilities facilitates integration with others layer of the SOA RA and helps to expose a business process as a service.
• Security and Policy Compliance: This category of capabilities enables access control and policy enforcement in the business processes.
• Process Monitoring and Management: This category of capabilities monitors and manages business processes, identifies bottlenecks in the business processes, and optimizes workload assignment.

This layer features the following capabilities:

Process Definition

1. Ability to define business processes representing dynamic behavior of the business

Event Handling

1. Ability to detect, emit, and listen to business events in the context of business processes

Process Runtime Enablement

1. Ability to realize and deploy the business processes in a runtime environment
2. Ability to create and manage individual instances of the business processes
3. Ability to execute the instances of a business process, its sub-processes, and activities therein
4. Ability to define the elements of an assembly at design time and have the assembly occur at runtime based on a set of rules
5. Ability to intelligently decide the end-point of the enabling services using the process context
6. Ability to manage the interaction of the business process with humans

Process Information Management

1. Ability to manage the context of a business process
2. Ability to manage the state of a process
3. Ability to transform the data flowing through a business processes based on its needs
4. Ability to store and retrieve assets required and requested by an ongoing process

Decision Management

1. Ability to configure the relationships between the composition and the non-functional characteristics of the process flow
2. Ability to encapsulate/isolate the decisions and rules affecting those decisions associated with the execution of a business process from the actual process flow itself

Process Integration

1. Ability to make available the business processes as a service
2. Ability to schedule the execution of a business process

Security and Policy Compliance

1. Ability to define policies, enforce them, and verify the compliance of the elements of process with a set of predefined policies
2. Ability to control access to a process flow at design or runtime

Process Monitoring and Management

1. Ability to monitor a business process and insert points at which metrics may be gathered, identify bottlenecks, and optimize workload assignments

Architecture Building Blocks (ABBs)

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

ABB to Capability Mapping for the Business Process Layer

Details of ABBs and Supported Capabilities

Details of ABBs

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

Business Process

This ABB represents a process that a business performs. This ABB is one of the core fundamental ABBs in the SOA RA. Business process is one of the fundamental constructs of an SOA solution and analysis and design based on the service-oriented paradigm.

Integration Layer: Event Listener

See Event Listener ABB in the Integration Layer.

Integration Layer: Event Producer

See Event Producer ABB in the Integration Layer.

Process Container or Process Engine

This ABB provides an environment to manage the execution and flow of business processes, and to manage the interaction of humans with business processes. It is also is responsible for managing the instances of running processes and their context.

Process Manager

This ABB is responsible for deploying processes in the process container.

Process Factory

This ABB is responsible for creating instances of deployed processes in the process container.

Process Flow Manager

The ABB is responsible for managing process templates and process instances. Process templates describe the business process model. At runtime, this ABB creates process instances from process templates using the Process Factory ABB. A process instance is the representation of a single running business process. The ABB’s job is to manage one or more process instances concurrently. It can support multiple interfaces that interact with business processes; for example, an SCA interface for interacting with other service components, and a generic process API for interacting with J2EE clients. It works cooperatively with the Workflow Manager or Human Task Manager ABB. The ABB has a core responsibility to split and manage processes and its sub-processes together and enabling services. This becomes an important part of an SOA’s ability to support business processes of varying granularity. For example, a Process Claim business process might have underlying business processes that support the Process Claim business process. This ABB in this case then manages all the interactions and the decomposition relationships for that individual’s sub-processes and enabling services.

Process Controller

The ABB acts as a controller that supports all the interactions between the invocation of a business process and the building blocks supporting that invocation. It is the core of a process container and responsible for executing the process activities.

Dynamic Assembler

This ABB is responsible for invoking the appropriate end-point that needs to serve the request based on the context. Context provides the extra information that this ABB needs to make the intelligent decisions on which end-point is to be invoked.

Workflow Manager or Human Task Manager

This ABB is responsible for the coordination of requests that require human intervention. It is also responsible for the management of the state of human tasks and work items. This ABB supports the ability of the Business Process Layer to integrate human intervention into business processes. In practice this might mean using the Service Adapter and Integration Adapter to integrate with the Consumer Layer. This ABB is often required in process error handling situations (e.g., the involvement of a customer service representative when the customer enters a wrong account number in a self-service banking scenario).

Process State Manager

The ABB supports the ability of the layer to retain and manage state (not status) during a business process. It manages the process state within each business process instance. This is an important capability, for example, for orchestrating a series of state transitions which might involve multiple business processes.

Context Manager

The ABB manages the context of various instances of the business process.

Integration Layer: Data Transformer

See Data Transformer ABB in the Integration Layer.

Process Repository

The ABB acts a repository store for all business processes. This ABB is internal to the layer and interfaces with the Data Repository ABB in the Information Layer and Asset Repository ABB in the Governance Layer. It is the Process Repository ABB where other ABBs such as the Process Controller ABB will turn to obtain process information such as state information.

Process Service Adapter

This ABB integrates the Business Process Layer with other SOA RA layers, in particular the Services, Integration, and Consumer Layers. It acts as the mechanism to expose business processes as services.

Scheduler

This ABB supports the ability to schedule the invocation of business processes and process activities at different times.

Governance Layer: Business Rules Manager

See Business Rules 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.

Quality of Service Layer: Business Activity Monitor

See Business Activity Monitor ABB in the Quality of Service Layer.

Structural Overview of the Layer

The Business Process Layer is a critical component of the SOA RA. ABBs in the Business Process Layer can be thought of as being logically partitioned into categories which support:

• Definition, composition, and decomposition of a business process
• Handling of events
• Runtime enablement and realization of business processes
• Management of information and associated data flow in the context of the business processes
• Management of decision points/points of variability and associated rules in the context of the business processes
• Integration capabilities necessary for realizing business processes
• Security and policy compliance pertaining to business processes
• Monitoring and management of business processes

ABBs in the Business Process Layer illustrates the ABBs partitioned into key categories:

ABBs in the Business Process Layer

Each business process is composed of data flows and process/control flows. Data flows pertain to how information is represented and conveyed in relation to the process data flow. The process and control flow pertains to the sequence of activities or services that are being invoked to enact a business process.

Inter-Relationships between the ABBs

Key Relationships among ABBs in the Business Process Layer show the inter-relationships and a non-normative sequence of interaction. The final, prescriptive sequence of interaction will be defined by the underlying solution architecture and the standards that are invoking the support of other SOA RA layers.

Key Relationships among ABBs in the Business Process Layer

Significant Intersection Points with other Layers

Interaction with Cross-Cutting Layers

The Business Process 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 for policies
• Ability to support management (storage, retrieval, etc.) of rules to support rules associated with decision points in service mediation, orchestration, and composition

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

• Ability to authenticate/authorize for service invocation

It relies on the Information Layer for the following capabilities:

• Ability to store and retrieve metadata and data required for the execution of the business processes

It relies on the Integration Layer for the following capabilities:

• Ability to invoke services to realize systematic process steps
• Ability to transform data from one format to another

Key Interactions of the Business Process Layer with Cross-Cutting Layers

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

• It leverages the Service Registry ABB and Service Repository ABB from the Governance Layer for storing metadata such as policy, schema, etc. and for providing access to the metadata. This Service Registry ABB also contains service definitions at runtime and supports service virtualization and service discovery. Service virtualization in this context is the exposure of a service end-point through a “proxy” (the registry).
• It leverages the Business Rule Manager ABB in the Governance Layer to manage the rules supporting the decision points or points of variability within a business process.
• It leverages the Access Controller ABB in the Quality of Service Layer for authenticating/authorizing the facility for service invocation and workload assignment.
• 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 store and assess data.
• It leverages the Access Controller ABB in the Quality of Service Layer to enforce access privileges and the Policy Enforcer ABB in the Quality of Service Layer to enforce policies.
• It interfaces with the Integration Controller ABB to leverage the capabilities of the Integration Layer such as data transformation, service request, etc. It leverages the Mediator ABB in the Integration Layer to integrate with existing systems and applications. It leverages the Data Transformer ABB in the Integration Layer to transform data from one format to other. It leverages the Event Producer ABB and Event Listener ABB in the Integration Layer to publish events or subscribe to events.

Interaction with Horizontal Layers

The Consumer Layer can invoke or trigger events that will execute business processes in the Business Process Layer. Business processes in the Business Process Layer are composed of services in the Services Layer either using orchestration or choreography. Essentially an executable business process is composed of either human task or systematic steps. The systematic steps can be enabled by services in the Services Layer.

Key Interactions of the Business Process Layer with Horizontal Layers

Usage Implications and Guidance

The Business Process Layer incorporates the ability to either statically or dynamically configure the orchestration or choreography of services in its composition.

To summarize, the Business Process Layer supports capabilities required for enabling SOA such as process composition and decomposition, orchestration or choreography of services, collaboration between processes, information and services using a set of policies and business rules that aid in its execution of the process flow.