W3C home > Mailing lists > Public > public-ws-chor@w3.org > October 2004

RE: Here is my note for meeting the CDL Challenge regarding business protocol race-conditions

From: Furniss, Peter <Peter.Furniss@choreology.com>
Date: Mon, 18 Oct 2004 18:01:01 +0100
Message-ID: <221369570DEDF346AE42821041345E89730B4E@imap.choreology.com>
To: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>, "Steve Ross-Talbot" <steve@enigmatec.net>
Cc: "WS-Choreography List" <public-ws-chor@w3.org>
I've just been through this carefully to understand how it works. So the
following is to 
see if I've got it right.  But I've come up with a surprise on what
<parallel> means (see
"Important bit >>>" below.

Peter's understanding of Nick's example:

a) down to the <parallel> it is just setting things up. on entry to
<parallel>,
both sides have their PO-state as "Active". (All interactions change
PO-state
after each interaction)

b) both sides have an X-Internal-State variable, which is the
representation of their
"decision making".

then it's a question of globalised triggers with two parallel workunits

c) i) if Buyer decides to cancel, and both sides are still Active
	interaction cancelOrder, set PO-state to Cancelling

    ii) then, if both sides have PO-state Cancelling
		interaction cancelledOrder, set PO-state to Cancelled

d) in parallel to c)
	if Seller decides to complete, and seller is still Active, and
buyer is Active or Cancelling
		interaction CompletedOrder, set PO-state to Completed


So the race occurs if c) i) starts at Buyer while d) starts at Seller
(assuming the interactions are
effectively one-way messages, and "after" occurs at the sender before it
occurs at the receiver. (I first thought
the race was d) running between c) i) and c) ii), but that isn't right,
because c) i) disables the guard
for d) by setting PO-state at Seller to Cancelling. 

If the collision happens, the Seller will perceive the cancelOrder
interaction as unable to
follow c) i); whereas Buyer will be happy to let interaction
CompletedOrder follow d), since the 
guard condition is met.

So an interaction that is apparently invalid for the present state is
not (necessarily) an error.
(Not easy to phrase this right, since an interaction isn't exactly a
message, but Seller is 
certainly liable to receive a message that has the appearance of the
likeness of an interaction)
Is that correct ?


Important bit >>>>>>>
Also, I think I misunderstood what <parallel> meant, believing it to be
the same as BPEL's flow. 
But from Nick's example, it's not. BPEL <flow> "completes when all of
the activities in the flow have completed." 
But the <parallel> in Nick's example completes when ANY of its elements
complete.

Is that right ? Is doesn't seem to be stated anywhere - the explanation
of parallel is just that the 
activities in it are all enabled - it says nothing about completeion. Is
there a need for the opposite
construct, where there are a number of activities that should run in
parallel and all to completion ? (If 
we need both, it would seem more powerful to make <parallel> mean "run
all to completion" and have a
"break" or "abandon" construct that meant jump out.)

(as it is we seem to already have the "AtLeastOne" construct I found I
needed when
I tried the collision resolution the other day. Given that,
I think my solution may be an incomplete version of Nick's)

Peter

> -----Original Message-----
> From: Nickolas Kavantzas [mailto:nickolas.kavantzas@oracle.com] 
> Sent: 11 October 2004 19:00
> To: Steve Ross-Talbot
> Cc: WS-Choreography List
> Subject: Here is my note for meeting the CDL Challenge 
> regarding business protocol race-conditions
> 
> 
> 
> 
>   Order Fulfillment Collaboration use-case coded using WS-CDL
> 
>                             Nickolaos Kavantzas
>                          Web Services Architect
>                                      Oracle
>                              October 10, 2004
> 
> 
> The use-case described here demonstrates an end-to-end 
> business process that's concerned with handling orders 
> between a really big corporation (RBC) and an outside 
> supplier, STC, which manufactures and distributes t-shirts. 
> RBC and STC are engaged together in the 'Order Fulfillment' 
> Collaboration in order to achieve their common business goal.
> 
> For this to work successfully, RBC must provide the business 
> protocol rules under which it's willing to engage in an 
> electronic business with suppliers such as STC:
> 
> 1. RBC starts the procurement of t-shirts by creating an 
> order with STC.
> 
> 2. STC acknowledges the purchase order. This initiates a business
>    process in STC that handles the PO. For all RBC knows, STC 
> has an employee
>    at a computer handling the PO, or a sophisticated Process 
> Management System
>    that's linked with back-end manufacturing, logistics, and 
> procurement systems
> 
> 3. After the internal processes within STC regarding the PO are
>    completed, which may take days or even months, STC sends a 
> Purchase Order
>    Completed message back to RBC in order for RBC to complete 
> its own business
>    process
> 
> 4. RBC can send a Cancel Order message to abort STC's 
> business process,
>    any time before RBC receives the Purchase Order Completed 
> message from STC
> 
> 5. If the Cancel Order message arrives at STC before the Purchase
>    Order Completed message is sent from STC, then STC aborts 
> its business process
>    and acknowledges this to RBC with the Purchase Order 
> Cancelled message in order
>    for RBC to abort its own business process too. Otherwise, 
> if STC has already
>    sent the Purchase Order Completed message, it ignores the 
> Cancel Order message
>    because RBC has agreed that it will honor POs when 
> cancellations are not sent
>    out within an agreed-upon timeframe
> 
> 7. If RBC has already sent the Cancel Order message and then 
> it receives the
>    Purchase Order Completed message, then instead of aborting its own
>    business process it rather completes it
> 
> 
> 
> 
> 
> 
> The following WS-CDL snippet codes the use-case described 
> above, including the possible race-condition between the 
> Cancel Order and the Completed Order messages:
> 
> 
> 
> <package name="Oracle, Nickolaos Kavantzas--Order Fulfillment 
> Business Protocol--october-10-2004">
> 
> 
> <roleType name="B">
>    <behavior name="B-behav1" interface="B-Intf" />
> </roleType>
> 
> <roleType name="S">
>    <behavior name="S-behav1" interface="S-Intf" />
> </roleType>
> 
> <relationshipType name="rel">
>    <role type="B" />
>    <role type="S" />
> </relationshipType>
> 
> 
> <choreography name="Order Fulfillment"
>               complete="cdl:getVariable(PO-State) == Cancelled) OR
>                         cdl:getVariable(PO-State) == Completed )" >
>   <relationship name="rel">
> 
>   <variableDefinitions>
>      <variable  name="PO-State" />
>      <variable  name="B-Internal-State" roleType="B" 
> silentAction="true" />
>      <variable  name="S-Internal-State" roleType="S" 
> silentAction="true" />
>   </variableDefinitions>
> 
>   <seq>
>      <ixn oper="createOrder">
>         <participate relationship="rel" fromRole="B" toRole="S"/>
> 
>         <exchange action="request" >
>            <send    recordRef="rec"/>
>            <receive recordRef="rec"/>
>         </exchange>
> 
>         <record name="rec" when="after">
>            <source  var="ActivePending"/>
>            <target  var="cdl:getVariable(PO-State)"/>
>         </record>
>      </ixn>
> 
>      <ixn oper="placedOrder">
>         <participate relationship="rel" fromRole="S" toRole="B"/>
>         <exchange action="request" >
>            <send    recordRef="rec"/>
>            <receive recordRef="rec"/>
>         </exchange>
> 
>         <record name="rec" when="after">
>            <source  var="Active"/>
>            <target  var="cdl:getVariable(PO-State)"/>
>         </record>
>      </ixn>
> 
> 
>      <parallel>
> 
>         <workunit name="do-cancel"
>              guard="cdl:globalizedTrigger(
>                            
> "cdl:isVariableAvailable(B-Internal-State) AND
>                             cdl:getVariable(PO-State, "B") == 
> Active" , "B",
>                            "cdl:getVariable(PO-State, "S") == 
> Active" , "S")"
>              block="true" >
> 
>            <sequence>
>               <ixn oper="cancelOrder">
>                  <participate relationship="rel" fromRole="B" 
> toRole="S"/>
>                  <exchange action="request" >
>                      <send    recordRef="rec"/>
>                      <receive recordRef="rec"/>
>                  </exchange>
> 
>                  <record name="rec" when="after">
>                      <source  var="Canceling"/>
>                      <target  var="cdl:getVariable(PO-State)"/>
>                  </record>
>               </ixn>
> 
>               <workunit name="do-cancelled"
>                  guard="cdl:globalizedTrigger(
>                            "cdl:getVariable(PO-State, "B") == 
> Canceling", "B",
>                            "cdl:getVariable(PO-State, "S") == 
> Canceling", "S")"
>                  block="true" >
> 
>                  <ixn oper="cancelledOrder">
>                     <participate relationship="rel" 
> fromRole="S" toRole="B"/>
>                     <exchange action="request" >
>                        <send    recordRef="rec"/>
>                        <receive recordRef="rec"/>
>                     </exchange>
> 
>                     <record name="rec" when="after">
>                        <source  var="Cancelled"/>
>                        <target  var="cdl:getVariable(PO-State)"/>
>                     </record>
>                   </ixn>
>                </workunit>
>            <sequence>
>         </workunit>
> 
>         <workunit name="do-complete"
>              guard="cdl:globalizedTrigger(
>                            "cdl:getVariable(PO-State, "B") == 
> Active OR
>                             cdl:getVariable(PO-State, "B") == 
> Canceling", "B",
>                            
> "cdl:isVariableAvailable(S-Internal-State) AND
>                             cdl:getVariable(PO-State, "S") == 
> Active"   , "S")"
>              block="true" >
> 
>               <ixn oper="completedOrder">
>                  <participate relationship="rel" fromRole="S" 
> toRole="B"/>
>                  <exchange action="request" >
>                      <send    recordRef="rec"/>
>                      <receive recordRef="rec"/>
>                  </exchange>
> 
>                  <record name="rec" when="after">
>                      <source  var="Completed"/>
>                      <target  var="cdl:getVariable(PO-State)"/>
>                  </record>
>               </ixn>
> 
>         </workunit>
> 
>      </parallel>
> 
>   </seq>
> 
> </choreography>
> 
> </package>
> 
> 
> 
> 
> 
> 
> 
> 
> --------------------------------------------------------------
> -------------------------------------
> Steve Ross-Talbot wrote:
> 
> > Nick has signed up to meeting the CDL challenge at the F2F 
> and JJ said 
> > he would also provide a solution.
> >
> > I re-issue the challenge below as it was originally sent out and I 
> > look fwd to two examples that shows how it can be done.
> >
> > Best regards
> >
> > Steve T
> >
> > Begin forwarded message:
> >
> > > Resent-From: public-ws-chor@w3.org
> > > From: Steve Ross-Talbot <steve@enigmatec.net>
> > > Date: 23 June 2004 15:07:39 BST
> > > To: WS-Choreography List <public-ws-chor@w3.org>
> > > Subject: CDL Challenge
> > >
> > > Members and interested parties,
> > >
> > > Nick sent a set of slides sometime ago all about CDL. 
> They were ones 
> > > he had used with Oracle for external outreach activities. 
> I enclose 
> > > one of those slides here.
> > >
> > > The challenge is to code up the slide in WS-CDL taking account of 
> > > any state alignment necessary. What is not required is the full 
> > > blown WS-CDL but what is required is the choreography 
> definitions to 
> > > support the slides.
> > >
> > > I look forward to hearing from any of you who manages to 
> do this and 
> > > share it with the group on this list.
> > >
> > > Cheers
> > >
> > > Steve T
> > >
> >
> >                                                   
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> -------------------------------
> >                    Name: slide27.tiff
> >    slide27.tiff    Type: TIFF Image (image/tiff)
> >                Encoding: base64
> 
> 
> 


Choreology Anti virus scan completed
Received on Monday, 18 October 2004 17:01:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:01:06 GMT