- From: Tony Fletcher <tony.fletcher@choreology.com>
- Date: Tue, 19 Oct 2004 20:05:33 +0100
- To: "'Nickolas Kavantzas'" <nickolas.kavantzas@oracle.com>, "'Furniss, Peter'" <Peter.Furniss@choreology.com>, "'Steve Ross-Talbot'" <steve@enigmatec.net>
- Cc: "'WS-Choreography List'" <public-ws-chor@w3.org>
Dear Nick, Peter and others, Firstly the text for the parallel construct (2.5.1.2 Parallel) currently mentions nothing about when it completes. I think it should explicitly state that the parallel activity is not finished until all the activities in the parallel or finished. Secondly, I do not quite understand the Choreography Life-line proposal. Does it mean that the Boolean expression of the complete attribute is 'continuously' evaluated and if / as soon as it evaluates to true the choreography is terminated. I think we should spell out whether it is evaluated continuously or at what points it is evaluated and what happens to the choreography when it does turn true - I presume that messages 'in flight' do not suddenly vaporise, for instance. Best Regards Tony A M Fletcher Tel: +44 (0) 1473 729537 Mobile: +44 (0) 7801 948219 amfletcher@iee.org (also tony_fletcher@btopenworld.com) -----Original Message----- From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org] On Behalf Of Nickolas Kavantzas Sent: 19 October 2004 02:25 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, 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 19:06:06 UTC