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.
|