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 14:52:55 -0700
Message-ID: <00ba01c4b55c$d32b5e70$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,

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
Received on Monday, 18 October 2004 21:53:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:05 UTC