OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa-negot message

[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