What is BPEL?
BPEL
BPEL is the Business Process Execution language, an XML language for defining the composition of services into new services, standardized at OASIS.
BPEL relies on WSDL for port types, messages/parts, and as a container for additional metadata, but BPEL itself is independent of protocol.
The expression language is based on XPath 1.0 with some extension functions.
There is also a loose dependency on XMLSchema, but other typing mechanisms can be used.
BPEL supports both abstract and executable processes. Abstract processes are useful for specifying expected protocols and publicly visible behaviors without too much detail. Some static analysis techniques may apply. Executable processes contain enough detail to fully specify execution.
Three services play constituent roles in a complex computation. The services are executed in sequence, and an input to the process and the output from a service provide the input for the next service in order.
<bpel:process name="simpleExampleProcess" targetNamespace="foo"
xmlns:bpel="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:links="wsdl://elsewhere">
[... declarations omitted ... ]
<bpel:sequence>
<bpel:receive partnerLink="invoker" portType="links:in" operation="computation" variable="input" />
<bpel:assign>
<bpel:copy>
<bpel:from variable="input" part="argument1" />
<bpel:to variable="input1" part="root" />
</bpel:copy>
</bpel:assign>
<bpel:invoke partnerLink="service1" portType="links:service1Input" operation="computation1" inputVariable="input1" />
[... more BPEL omitted ... ]
<bpel:reply partnerLink="invoker" portType="links:in" operation="computation" variable="result" />
</bpel:sequence>
</bpel:process>
BPEL functionality
BPEL deals explicitly with the functional aspects of business processes:
- control flow (branch, loop, parallel)
- asynchronous conversations and correlation
- non-determinism
- long-running, nested units of work, faults, and compensation
BPEL provides the usual branching and looping control flow constructs.
- <sequence> executes activities in serial order.
- <switch> executes at most one alternative based on expressions specified on child <case> elements with an optional <otherwise>.
- <while> loops through activities while a variable's value is true.
BPEL provides a parallel control construct through the <flow> activity.
Basic synchronization is achieved through named "links" with <source> and <target> on separate threads.
More complex synchronization is achieved through "join" expressions composed of link statuses and boolean operations (&& and ||).
BPEL correlates messages based on properties referenced in a <correlationSet>.
Multiple properties can be combined into a composite correlation key.
Properties are typed by XML Schema simple types and bound ("aliased") via XPath expressions to locations in message parts.
A <pick> activity waits:
- for a message specified by an <onMessage> child element, where correlation allows a specific process instance to be addressed.
- for an amount of time or until a time, specified with an <onAlarm> child element.
A <scope> is an execution context for the contained activities, and a <process> is, itself, a <scope>.
A <scope> defines local variables and can catch and handle either specific faults or all faults that occur with it.
A <scope> can have an <eventHandlers> child that behaves like a <pick> in that it can respond to <onMessage> or <onAlarm>, except that the triggered activities are executed concurrently with the <scope>.
Typical use cases include interrogation of a specific instance, receiving notifications, or sending notifications.
There is no way to roll-back an already executed activity, since a process may execute over hours or even months.
Instead, BPEL provides the option to attach a <compensationHandler> that can be run to "undo" the activities of a scope.
A <compensationHandler> is activated only after normal completion of a scope.
The <compensate> activity can execute the <compensationHandler> of an immediate child <scope> by name or, by default, of all immediate children in reverse order of completion.
The execution of a <while> loop creates one <compensationHandler> per iteration.
The <compensate> activity can only occur within a <compensationHandler> or during fault handling.
For example:
1. A fault in the top-level <scope> triggers a <catch>.
2. The <catch> invokes the <compensationHandler> in the middle <scope>.
3. The middle scope's <compensationHandler> invokes the <compensationHandler> in the innermost child <scope>.
BPEL is NOT:
BPEL is not workflow: there are no explicit abstractions for people, roles, work items, or inboxes in BPEL (among other things).
BPEL is also not BPM: no specified data model for measurement, reporting, or management.
BPEL is not integration: there is no explicit support for transformation, semantic interpolation, or specific protocols.
BPEL is not all-encompassing: there are some patterns that are difficult to model with BPEL.
Value-add of BPEL
BPEL (i.e., an implementation) abstracts the common, non-process-level concerns of business process execution.
As a service-tier composition language, BPEL is a key ingredient in a service-oriented architecture.
BPEL provides a deployment-level interface for higher-level tools (e.g., modeling).
"Low-hanging" innovation does not create sustainable competitive advantage.
Complexity will remain an unavoidable part of the enterprise technology landscape. Managing and minimizing that complexity will create leaders.
Defining the organizational processes around BPEL, i.e., who uses BPEL and how, is of paramount importance to the role and success of service oriented architecture.
Multiple modeling environments and standards are emerging to provide a high-level visual language for compilation into BPEL.
Business Process Modeling Notation ("BPMN", from BPMI) and Business Process Definition Metamodel ("BPDM", from OMG) are both notable in this regard.
Engines will come in a variety of form factors and use different techniques for runtime representation of processes, including:
- interpretive
- code generation
- OO models of activities
- reduction engines based on pi-calculus and related concepts.
BPEL will be a programmer's tool for low-level service orchestration and integration-oriented tasks.
BPEL will be an artifact of high-level modeling and process design environments.
The runtime, state persistence, and SOAP stack for the BPEL execution engine will expose hooks for security, management, monitoring, and analysis functionality.
-- CharltonBarreto - 29 Oct 2004
|
|
