Another example has to do with event handlers. In BPEL 1.1 global event handlers are enabled as soon as the process starts, but the specification does not go into details to define exactly what that entails. Would an event handler instance be executed concurrently with the execution of the start activity that created the process instance? If so, what if the event handler instance is accessing some variable that would have been initialized by the start activity? All of these issues are left for the vendor implementation to answer. In contrast, BPEL 2.0 explicitly states that the global event handler is only enabled after the start activity has completed its execution, thus decreasing any chances for race conditions. However, what if there are multiple event handler instances? Do they operate on the same input variable? In BPEL 2.0, an "onEvent" activity declares its own input variable, hence each event handler instance works with its own local copy of the input data. The following snippet provides an example of a BPEL 2.0 event handler declaration:

<onEvent partnerLink="eventLink" operation="event1" variable="inputVar"
messageType="tns:eventMessage">
   <correlations>
     <correlation set="id" initiate="no"/>
   </correlations>
   <sequence>
     <!-do something -->
   </sequence>
</onEvent>

BPEL does not allow a process instance to have multiple outstanding replies for the same request-response operation. This restriction prevents concurrent event handler instances for the same request-response operations from being supported. BPEL 2.0 solves this problem by allowing "correlationSets" to be declared in an "onEvent," thereby disambiguating the event handler instances. However, because this is a common user scenario, it is expected that vendors solved this specification shortcoming of BPEL 1.1 by providing their own vendor-specific mechanism that will likely differ from the BPEL 2.0 solution.

There is no automatic way of migrating a business process to address these issues. People will have to understand how the vendor-specific behavior of the BPEL 1.1 engine being used is different from the BPEL 2.0-compliant behavior and take the appropriate actions. For example, consider the issue of the new BPEL fault "missingReply." It may be that one vendor-specific behavior prior to BPEL 2.0 was to raise a vendor-specific fault, i.e., "vendor:myFault," in which case the migration consists of replacing the vendor-specific fault with the new BPEL standard fault "missingReply."

Compensation Handling
Compensation handling is one of the distinguishing features of BPEL. It allows business processes to support long-running activities.

In BPEL 1.1, a compensation handler is executed with a frozen snapshot of the BPEL variables made at the time that the compensation handler was installed. In contrast, compensation handlers in BPEL 2.0 work off live data; that is, they use the current value of the BPEL variables. One way of mitigating this difference by guaranteeing that the BPEL variables are not changed is to declare them local to the scope that may be compensated.

Compensation handlers declared within isolated scopes are not themselves isolated in BPEL 1.1. This is changed in BPEL 2.0: compensation handlers within isolated scopes also have isolated behavior. Note however that the scope and the compensation handler do not share the same isolation domain.

In BPEL 2.0, attempts to invoke the same compensation handler more than once result in a no-op operation, as a replacement for raising the BPEL standard fault "repeatedCompensation," which has been removed. This makes sense because it seems unlikely that a business process would have a need to handle such a fault.

Data Manipulation
Data manipulation has changed significantly in BPEL 2.0. There are two parts to understanding these changes. First, BPEL 2.0 defines a data model to represent the BPEL variables. Second, BPEL 2.0 defines rules for mapping this data model to the different languages, such as XPath 1.0.

The BPEL 2.0 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.

BPEL 2.0 data model mapping to XPath 1.0 is simplified, the BPEL XPath extended functions "getLinkStatus()" and "getVariableData()" were removed, and propagation of application data is done using XPath variables.

Let's look at the first case. Instead of using "getLinkStatus(linkName)" to access the status of a link, one can just reference the link directly as an XPath variable, that is, 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 would 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:

<bpws:propertyAlias propertyName="tns:phoneNumber" messageType="tns:outputMessage">
<bpws:query>$source.value</bpws:query>
</bpws:propertyAlias>

In BPEL 1.1 it is not clear what the result of "getVariableData()" is. Is it an XML document fragment? Is it just character data? BPEL 2.0 tightens the definition by specifying that the XPath variable referencing a BPEL variable resolves to the document element of the appropriate XML document. Thus it becomes clear what can or cannot be accessed in the resulting document. For example, you are able to access the XML attributes and child elements of a BPEL variable using XPath 1.0 expressions, however you will not be able to navigate to a parent node to try to access a different WSDL message part using XPath 1.0, since we have seen that each WSDL message part is contained in a separate XML document. There is one caveat to this rule: when used in the context of an expression (in contrast to being used in the context of a query), BPEL variables of simple type return the simple type content itself (character data) instead of the document element. This is done to simplify common usage scenarios. Listing 2 shows XPath 1.0 expressions being used to access multiple BPEL variables of different Schema types.