Advanced Concurrency

BPEL supports complex synchronization scenarios:

• A target activity may depend on several source activities.

• Several target activities may depend on the same source activity.

To see how the ideas fit together, consider the outline shown in Listing 7.7, which is from a service that verifies customer details at Highlight Insurance. Two aspects of the outline are of interest and are explained next: transition conditions, as declared in the transitionCondition elements, and join conditions, as declared in the joinCondition elements.

Listing 7.7: Advanced concurrency example

 <flow name="approveAndPurchase">    <links>       <link name="CreditLink1"/>       <link name="DMVLink1"/>       <link name="DMVLink2"/>    </links>    <invoke name="RunCreditCheck"       <sources>          <source linkName="CreditLink1">             <transitionCondition>                $checkResponse.creditCheckResult/valid             </transitionCondition>          </source>       </sources>    </invoke>    <sequence>       <invoke name="CheckApplicantWithDMV">          <sources>             <source linkName="DMVLink1">                <transitionCondition>                   $dmvResponse.retrieveLicenseStatusResult/valid                </transitionCondition>             </source>       </invoke>       <invoke name="CheckDependentsWithDMV">          <sources>             <source linkName="DMVLink2">                <transitionCondition>                   $dmvResponse.retrieveLicenseStatusResult/valid                </transitionCondition>             </source>          </sources>       </invoke>    </sequence>    <sequence name="Accepted">       <targets>          <target linkName="CreditLink1" />          <target linkName="DMVLink1" />          <target linkName="DMVLink2" />          <joinCondition>             $CreditLink1 and $DMVLink1 and $DMVLink2          </joinCondition>       <targets>       <assign name="copyAcceptanceData" />       <invoke name="sendAcceptanceNote"/>    </sequence>    <sequence name="Rejected">       <targets>          <target linkName="CreditLink1" />          <target linkName="DMVLink1" />          <target linkName="DMVLink2" />          <joinCondition>                not($CreditLink1 and $DMVLink1 and $DMVLink2)          </joinCondition>       </targets>       <assign name="copyRejectionData" />       <invoke name="sendRejectionNote"/>    </sequence> </flow> 

Transition Conditions

A transition condition is a Boolean expression that is specific to a link source. When a source activity completes successfully, the BPEL engine evaluates the transition condition for each link source in that activity and assigns the value to each of the related links.

In response to a policy request, for example, Highlight Insurance verifies details with a credit agency and with the DMV, using parallel streams to save time. If RunCreditCheck (the invoke statement that contacts a credit agency) succeeds (which means, ends without a fault), the link CreditLink1 is set to true or false, depending on the credit agency's response. A similar assignment occurs for each of the two DMV-related invocations.

If multiple link sources are present for a single activity, the order of evaluation is the order of the source elements. If a transition condition is not present for a given source activity that succeeds, the value of the link is true.

When a source activity fails (ending with a fault), the transition condition evaluates to false. That rule does not apply, however, in the following cases:

• The source activity is a scope.

• A fault occurs in that scope.

• The scope's fault handler completes without throwing a fault.

In that situation, the BPEL engine evaluates the transition condition as if the scope had succeeded. As always, the default transition condition is true.

Join Condition

A join condition is an expression that is specific not to a link target but to a target activity. The target activity can run only when two conditions apply:

• The BPEL engine resolves every related link source to true or false.

• The join condition for the target activity evaluates to true.

In our example, if the credit and DMV checks resolve to true, the sequence named Accepted runs. If any check resolves to false, the sequence named Rejected runs.

The join condition can include only the value of each link, plus Boolean operators that combine the values. The default join condition combines the link values so that if any of the links are true, the target activity runs.

If a join condition evaluates to false, processing continues normally or the BPEL engine throws the fault bpel:joinFailure. The specific outcome depends on the value of attribute suppressJoinFailure in the target activity. If the value of that attribute is yes, processing continues normally. The implication is that processing can skip activities for which the join condition was false until an activity is reached that is valid to run. The skipping of target activities during normal processing is called dead path elimination.

If a join condition fails and the value of attribute suppressJoinFailure is no, the BPEL engine throws a fault.

If you do not specify a value for the attribute suppressJoinFailure, a value is derived from the nearest enclosing activity or process for which you did specify a value, even if that enclosing activity is outside the flow activity. The default value for the process-level suppressJoinFailure attribute is no so that you don't need to change a default setting to ensure that fault handling occurs.

In the following outline, the value of attribute suppressJoinFailure in the invoke activity is yes.

 <flow suppressJoinFailure="yes">    <links><link name="creditApproval"/> </links>    <sequence>       <receive/>       <invoke>          <targets>             <target linkName="creditApproval"/>          </targets>       </invoke>    </sequence>    <sequence>       .       .    </sequence> </flow> 

In the next outline, the value of attribute suppressJoinFailure in the invoke activity is also yes.

 <flow suppressJoinFailure="no">    <links><link name="creditApproval"/> </links>    <sequence suppressJoinFailure="yes">       <receive/>       <invoke>          <targets>             <target linkName="creditApproval"/>          </targets>       </invoke>    </sequence>    <sequence>       .       .    </sequence> </flow> 

If no enclosing activity specifies a value, you can assign a default value at the process level. Here, the value of attribute suppressJoinFailure in the invoke activity is also yes:

 <process suppressJoinFailure="yes">    <flow>       <links><link name="creditApproval"/> </links>       <sequence>          <receive/>          <invoke>             <targets>                <target linkName="creditApproval"/>             </targets>          </invoke>       </sequence>       <sequence>          .          .       </sequence>     </flow>  </process>