Pattern 12: Represent Processes as Service Consumers
Constrain the BPEL that is written to implement process flow logic, to the higher levels of abstraction in the SOA Solution Stack.
Relationships
Main Description

Context

Many service-oriented solutions can be driven effectively using process execution engines.  Increasingly, these process servers execute BPEL (Web Services Business Process Definition Language) to choreograph the interactions between the services.  

The two upper layers of the SOA Solution Stack reference architecture relate to business processes and consumers of business processes. 

Problem

Without guidance, it is possible to overuse the capabilities of the process server engines in situations where lower-level languages, such as Java, are better technical choices for driving service interactions.

Forces

Overusing BPEL-based choreography can lead to reduced application performance and cause future architectural problems (see Pattern 01: Factor Composition Logic Away from Process Logic).


Solution

In the general case, use a service consumer to serve as a proxy for an executable business process that calls upon the services provided by a defined set of Participants.  This proxy is allocated to the Business Process layer of the SOA Solution Stack.  Limit the usage of BPEL implementations of process flow logic to implementations of such proxies.

These business process proxies subsequently can be called by model elements that represent things which trigger business process execution.  Examples include model elements that represent GUIs or the workflow infrastructure (because a previous task has completed and a new one is starting).  Such elements would be located in the Consumer layer of the SOA Solution Stack.

Rationale

Having a clear guideline for where in your architecture BPEL implemented process logic lives prevents the usage of BPEL in inappropriate places:

  • Prevent BPEL from being used to implement logic that is best implemented in Java language.
  • Prevent process logic being introduced somewhere inappropriate in the architecture. It needs to be driving the software, and therefore it needs to appear in the upper layers of your architecture.
More Information