- From: Nickolas Kavantzas <nickolas.kavantzas@oracle.com>
- Date: Mon, 18 Oct 2004 14:52:55 -0700
- 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