Introduction to Concurrency


We'll explore concurrency by example.

Imagine an online music store that caters to children and requires two kinds of information: preference information from the child, and credit-card details from a parent. You can fulfill those requirements at more or less the same time, in two parallel streams, and we can assume that completion of both streams is required before some other action occurs - for example, before you inform partner companies about the new customer.

In a more complex case, one stream can be internally dependent on another. The process might send a thank-you note to the child, for example, only after the parent's credit is approved, as shown in Figure 7.6.

image from book
Figure 7.6: Concurrency example

When activities run concurrently and one activity is forced to wait for another, the activities are said to be synchronized when the second activity starts.

You may say, "If a thank-you note requires that the process receive preferences and gain credit approval, you don't need a concurrent stream for the note-sending activity at all. The note-sending activity can start later, after you inform the partner companies."

That's true. BPEL provides alternate ways to accomplish the same purpose. If one activity in your business depends on the successful completion of another activity, you can enforce the dependency by writing a BPEL process in either of the following ways:

  • by including the two activities in a sequence activity, where an embedded · · activity runs subsequent to another embedded activity in an unchanging order

  • by fulfilling two tasks:

    • Place both activities in a flow activity, where an embedded activity runs concurrently with another embedded activity.

    • Establish a link between the two activities. Name a link, assign the link as a source in the activity that must occur earlier, and assign the link as a target in the activity that must occur later.

Listing 7.6 shows an outline of a flow activity that enforces a dependency but does not fulfill the business requirement. We'll describe the activity and make the necessary changes.

Listing 7.6: Sample flow activity outline

image from book
 <flow>    <links><link name= "creditApproval"/> </links>    <sequence name="interactWithChild">       <receive name="acceptPreferences"/>       <invoke name="sendNote">          <targets>             <target linkName="creditApproval"/>          </targets>       </invoke>    </sequence>    <sequence name="interactWithParent">       <receive name="creditCardDetails"/>       <invoke name="creditConfirmation"/>       <if name="approved">          <condition> ... </condition>             <invoke name="informPartnerCompanies">                <sources>                   <source linkName="creditApproval"/>                </sources>             </invoke>       <else/>       </if>    </sequence> </flow> 
image from book

In the outline, two activities run concurrently. The sequence activity named interactWithChild accepts the child's preferences and sends a thank-you note. The sequence activity named interactWithParent receives credit-card details, confirms the parent's credit-worthiness, and, if credit is approved, informs the partner companies.

A link called creditApproval enforces a dependency, as indicated by the use of the target and source elements. The process will not send a note to the child unless the parent-related invoke activity succeeds. In general terms, a target activity depends on one or more source activities.

The problem is that the target activity is dependent on informing the partner companies and is not dependent on approving the parent's credit.

"The solution," you may say, "is to move the link source from the invoke activity to the if activity."

 <if name="approved">    <condition> ... </condition>    <sources> <source linkName="creditApproval"/> </sources>    <invoke name="informPartnerCompanies"/> <else/> </if> 

The change seems sensible but creates a new problem. The source activity is now the if activity, which can complete successfully even if the else logic (if any) is invoked. Assuming no fault occurs, the process sends a note to the child regardless of whether the parent's credit is approved.

Let's do as follows:

  • Introduce the BPEL empty activity to the if activity, to help us enforce a precise synchronization.

  • Use a BPEL sequence activity as a container in the if activity.

     <if name="approved">    <condition> ... </condition>    <sequence name="oneActivity">       <empty>          <sources>             <source linkName="creditApproval"/>          </sources>       </empty>       <invoke name="informPartnerCompanies"/>    </sequence> <else/> </if> 

In this case, the empty activity is a container for the link source, and the sequence activity is a syntactic requirement. An if activity can include no more than one activity between the if start tag and the next else or elseif activity, if any.

That example fulfills the business need.

"Wait!" you say as you synchronize your thoughts with what you've read. "Can link sources and targets be in any BPEL activity?"

They can, although a few restrictions apply. It is not valid, for example, to place a link source (or link target) inside a loop while the related link target (or link source) is outside the loop, as in the following outline.

 <!- Not Valid! -> <flow>    <links><link name="sentFinalContract"/> </links>    <invoke name="sendIt">       <sources>          <source linkName="sentFinalContract"/>       </sources>    </invoke>    <while name="loop">       <sequence name="oneActivity">          <empty>             <targets>                <target linkName="sentFinalContract"/>             </targets>          </empty>          <invoke name="sendPartyInvitation"/>       </sequence>    </while> </flow> 

Here is a possible solution:

 <flow>    <links><link name="sentFinalContract"/> </links>    <invoke name="sendIt">       <sources>          <source linkName="sentFinalContract"/>       </sources>    </invoke>    <while name="loop">       <targets>          <target linkName="sentFinalContract"/>       </targets>       <invoke name="sendPartyInvitation"/>    </while> </flow> 




SOA for the Business Developer. Concepts, BPEL, and SCA
SOA for the Business Developer: Concepts, BPEL, and SCA (Business Developers series)
ISBN: 1583470654
EAN: 2147483647
Year: 2004
Pages: 157
Authors: Ben Margolis

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net