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: Nickolas Kavantzas <nickolas.kavantzas@oracle.com>
Date: Mon, 18 Oct 2004 18:25:20 -0700
Message-ID: <00d801c4b57a$7fb03b30$48af2382@us.oracle.com>
To: "Furniss, Peter" <Peter.Furniss@choreology.com>, "Steve Ross-Talbot" <steve@enigmatec.net>
Cc: "WS-Choreography List" <public-ws-chor@w3.org>

Peter, you are correct (great catch)!!!

I've realized myself that there is a bug on the text in the spec when I was
coding up this use-case.
Here is what I was thinking for fixing the problem:

Choreography Life-line
A Choreography completes successfully when there are no more matched Work
Unit(s) performing work within it and there are no enabled Work Unit(s)
within it. Alternatively, a Choreography completes successfully if its
complete condition, as defined by the optional complete attribute within the
choreography element, evaluates to "true". In this case, the actions,
including enclosed Choreographies, within the explicitly completed
Choreography are completed abnormally before the Choreography completes.



Thoughts?



--
Nick


----- Original Message ----- 
From: "Furniss, Peter" <Peter.Furniss@choreology.com>
To: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>; "Steve
Ross-Talbot" <steve@enigmatec.net>
Cc: "WS-Choreography List" <public-ws-chor@w3.org>
Sent: Monday, October 18, 2004 4:29 PM
Subject: RE: Here is my note for meeting the CDL Challenge regarding
business protocol race-conditions


> Nick,
>
> Thanks - I'd never noticed that. Good that parallel does mean ALL unless
> there's a complete clause.
>
> But there still seems to be a problem with the interrupted workunit. At
> 2.4.8 it says:
>
> A Choreography completes successfully when there are no more matched
> Work Unit(s) performing work within it and there are no enabled Work
> Unit(s) within it. Alternatively' a Choreography completes successfully
> if its complete condition' defined by the optional complete attribute
> within the choreography element' evaluates to "true" there MUST NOT be
> any matched Work Unit(s) performing work within it but there MAY be one
> or more Work Units still enabled but not matched yet.
>
> Surely in your example the do-cancel workunit is a "matched work unit
> performing work", which is disallowed by that text.
>
> A collision is likely to involve an incomplete activity in many cases -
> as with this one, where the cancelledOrder interaction would be valid to
> be sent, but apparently not valid to receive (because it gets there too
> late)
>
> Peter
>
>
>
> > -----Original Message-----
> > From: Nickolas Kavantzas [mailto:nickolas.kavantzas@oracle.com]
> > Sent: 18 October 2004 22:53
> > To: Furniss, Peter; Steve Ross-Talbot
> > Cc: WS-Choreography List
> > Subject: Re: Here is my note for meeting the CDL Challenge
> > regarding business protocol race-conditions
> >
> >
> > Peter,
> >
> > look within the choreography element, for the attribute
> > 'complete'. This is used to break out of the parallel (since
> > parallel completes when both of its branches complete).
> >
> > --
> > Nick
> >
> > ----- Original Message ----- 
> > From: "Furniss, Peter" <Peter.Furniss@choreology.com>
> > To: "Nickolas Kavantzas" <nickolas.kavantzas@oracle.com>;
> > "Steve Ross-Talbot" <steve@enigmatec.net>
> > Cc: "WS-Choreography List" <public-ws-chor@w3.org>
> > Sent: Monday, October 18, 2004 10:01 AM
> > Subject: RE: Here is my note for meeting the CDL Challenge
> > regarding business protocol race-conditions
> >
> >
> > > 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
> >
> >
>
>
> Choreology Anti virus scan completed
Received on Tuesday, 19 October 2004 01:26:06 GMT

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