ActiveBPEL® Designer User’s Guide
The WS-BPEL 2.0 specification includes many changes from version BPEL4WS 1.1, including the following.
Namespace changes
BPEL processes (executable): http://docs.oasis-open.org/wsbpel/2.0/process/executable
BPEL processes (abstract): http://docs.oasis-open.org/wsbpel/2.0/process/abstract
Service-ref elements: http://docs.oasis-open.org/wsbpel/2.0/serviceref
Supporting constructs in WSDL:
Partner Link Types: http://docs.oasis-open.org/wsbpel/2.0/plnktype
Properties and Property Aliases: http://docs.oasis-open.org/wsbpel/2.0/varprop
BPEL4WS 1.1 construct that no longer exist in WS-BPEL 2.0
Partners
Process-level compensation/termination handler (This is supported by ActiveBPEL as an extension)
enableInstanceCompensation attribute
XPath extended functions "getLinkStatus()" and "getVariableData()"
several standard faults removed or changed
NEW CONSTRUCTS
Process Properties and process-level elements
New property: Exit on standard fault
New elements: import (WSDL and XSD), message exchange
Partner Links
Scope-level partner links
Activities
New element for all activities: documentation
New activities: validate, rethrow, compensate scope, repeat until
Renamed activities: Switch is now If. Terminate is now Exit.
Receive, Reply, Invoke onMessage (Pick) and onEvent (Event handler) can copy message parts to and from process variables, eliminating the need to create an assign activity to do the copy.
Scope has termination handler, attribute name change (isolated)
Variables
WS-BPEL defines a data model to represent the BPEL variables and defines rules for mapping the data model to different expression languages.
The WS-BPEL data model is based upon XML infoset. Each BPEL variable is conceptually a separate set of XML documents. In the case of BPEL variables of WSDL message types, each WSDL message part is mapped into a separate XML document of the set.
WS-BPEL data model mapping to XPath 1.0 is simplified. The XPath extended functions "getLinkStatus()" and "getVariableData()" were removed, and propagation of application data is done using XPath variables.
For example, instead of using "getLinkStatus(linkName)" to access the status of a link, you can reference the link directly as an XPath variable by adding the "$" character to the link name, as shown in the following fragment:
<joinCondition>
$buyToSettle
</joinCondition>
The same idea applies to accessing BPEL variables. Instead of using "getVariableData(varName, partName)," one can reference the variable by using the "$varName" convention. However, in case of variables of WSDL messages, a part is referenced by appending the "." character and the part name to the variable name, as illustrated in the following snippet:
<assign>
<copy>
<from variable="value"/>
<to>$outputVar.value</to>
</copy>
</assign>
Queries on property aliases also make use of the same concept. In this case, a BPEL predefined variable named "source" must be used to reference the BPEL variable in question, as demonstrated below:
<bpel:propertyAlias propertyName="tns:phoneNumber"
messageType="tns:outputMessage">
<bpel:query>$source.value</bpel:query>
</bpel:propertyAlias>
Expression and Query Languages
XSL transforms allowed
Correlation
New pattern: join. Renamed pattern: in-out/request/response
Event Handling
WS-BPEL explicitly states that the global event handler is only enabled after the start activity has completed its execution, decreasing any chances for race conditions. An onEvent activity declares its own input variable, meaning each event handler instance works with its own local copy of the input data.
Fault Handling
Fault variable is declared in the catch, not in the enclosing scope.
Termination Handling
A scope termination handler replaces the standard fault, bpws:forcedTermination. A scope can run a termination handler instead of a fault handler.
Standard Faults
See BPEL Standard Faults.
Copyright (c) 2004-2007 Active Endpoints, Inc.