[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa-negot] RE: BPSS Start element
JJ, If I understand you correctly, you are saying that I should not want to be able to define that a particular binary collaboration is embedded in an outer one and can only be validly entered by a transition from the outer one. Or at least you are saying that if I do that, I should not expect a BSI to verify that my partner and I are executing the choreography correctly. Why not provide a means of doing that without requiring everyone to do it that way? I don't believe that I am asking for something that cannot be evaluated by both sides. If only Message A can validly start a new instance of the choreography, then both sides know it and if either side sends Message B as the start of a new choreography instance, then both the sending and receiving BSIs can detect and flag the error. Regards, Marty ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* "Jean-Jacques Dubray" To: "'John Yunker'" <john.yunker@bleuciel.org>, Martin W <jjd@eigner.com> Sachs/Watson/IBM@IBMUS cc: <ebtwg-bps@lists.ebtwg.org>, <ebxml-cppa-negot@lists.oasis-open.org>, 08/09/2002 03:38 "'Jean-Jacques Dubray'" <jjd@eigner.com> PM Subject: RE: BPSS Start element I belong to the camp that does not like transition on Start elements. The main reason is pure logic. I you specify a condition there that can only be evaluated by one side of the collaboration you have created a state inconsistency (one side believes the collaboration is in one state, while the other side does not know the state or believes it is in a different state). Then the only way to resolve this paradox is to exchange a message that synchronizes the state. This simply means that the collaboration actually started one step before and the start element to that BTA had no condition (CQFD). Only very few condition expression can be evaluated by each party without exchanging a message: time conditions come to mind, authorized customer is on the limit because you still need to receive the first message to decide whether this is an authorized customer, but one could argue that you cannot be in the state of receiving a message since the condition cannot be evaluated ! My recommendation: avoid any condition on start, or precondition on the binary collaboration (which is the same). Jean-Jacques Dubray____________________ Chief Architect Eigner Precision Lifecycle Management 200 Fifth Avenue Waltham, MA 02451 781-472-6317 jjd@eigner.com www.eigner.com >>-----Original Message----- >>From: John Yunker [mailto:john.yunker@bleuciel.org] >>Sent: Friday, August 09, 2002 3:19 PM >>To: Martin W Sachs >>Cc: ebtwg-bps@lists.ebtwg.org; ebxml-cppa-negot@lists.oasis-open.org; >>Jean-Jacques Dubray >>Subject: Re: BPSS Start element >> >><MWS> I believe that if I want the nested collaboration to be treated as a >>state machine encapsulated within the outer collaboration, I should state >>my >>intention by omitting a Start element from the nested collaboration. The >>transition element in the outer collaboration will take me to the >>encapsulated nested collaboration at the appropriate place in the >>choreography without needing a start element in the nested collaboration. >>I >>don't find words in the BPSS spec that tell me to do that, </MWS> >> >>Marty, yes you could do that, however I would reserve the right to place >>conditions on both the transition and the nested start state. Since I am >>trying to reuse standard collaborations I will want to normalize the >>conditions between the transition (those conditions dependent on the >>context >>of both collaborations) and the nested start state (those conditions >>applicable to all uses of the nested collaboration). >> >>For instance, I may have a transition from a quote to an order (order >>encapsulated in quote) where in to start the nested transaction I need >>both >>an approved quote and an authorized customer. Note that the approved >>quote >>condition is important only when the order and quote are used together >>(place on transition), but the authorized customer is important for all >>uses >>of the nested transaction (place on nested start state). >> >>As we build standard libraries of business transactions, this ability to >>normalize will be critical. >> >>Thanks!!! >>John
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC