[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa-negot] Re: BPSS Start element
Martin W Sachs wrote: > > > > > Hima wrote: > > <hima> If the start element is omitted for internal collaboration, how > would > BSI figure out which BTA to initiate when collaborationAcitivity is > initiated. > </hima> > > MWS: As I understand your draft Negotiation CPA, the toBusinessState > attribute of a Transition element in the outer business collaboration > identifies the next CollaborationActivity, which in turn points to the > nested binary collaboration, which in turn points to the next BTA. Am I > misunderstanding something? <hima> Yes. This is how it exists in the BPSS instance that I sent out. The way the BinaryCollaboration referred to by the CollaborationActivity points to BTA is by using the "Start" element which points to first BTA in the collaboraiton. If "Start" is made optional, then how can you figure out the first BTA.. </hima> > > > 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 > ************************************************************************************* > > > "Himagiri(Hima) > Mukkamala" To: Martin W Sachs/Watson/IBM@IBMUS > <himagiri@sybase. cc: Jean-Jacques Dubray <jjd@eigner.com>, ebtwg-bps@lists.ebtwg.org, > com> ebxml-cppa-negot@lists.oasis-open.org > Subject: Re: BPSS Start element > 08/09/2002 10:15 > PM > > > > <hima>inline > > Martin W Sachs wrote: > > > > > > > > > > > JJ, > > > > The spec shouldn't "handle bugs". What it should do is to enable enough > > precision in a BPSS instance to allow a BSI to detect errors. > > > > You said "What we could add to the spec is an attribute which could > > indicate that a given collaboration definition can only be used in nested > > mode, otherwise an error is returned by the BSI." I agree that this can > be > > done. The point in my previous posting is that the spec "almost" does > this > > already because the Start element has minOccurs="0". So, your suggestion > > could accomplished merely by adding a statement that if the Start element > > is omitted from a binary collaboration, that binary collaboration can > only > > be used in nested mode. > > <hima> If the start element is omitted for internal collaboration, how > would > BSI figure out which BTA to initiate when collaborationAcitivity is > initiated. > </hima> > > > > > > > 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: Martin W > Sachs/Watson/IBM@IBMUS, "'Jean-Jacques Dubray'" <jjd@eigner. > > <jjd@eigner.com> com> > > cc: ebtwg-bps@lists. > ebtwg.org, ebxml-cppa-negot@lists.oasis-open.org > > 08/09/2002 03:15 Subject: RE: BPSS Start > element > > PM > > > > > > > > Marty: > > > > I don't see why the spec should handle "bugs". If a bug is detected, a > > few collaboration will be screwed up but someone can fix the bug and > > then everything works just fine. Why would you think otherwise? > > > > What we could add to the spec is an attribute which could indicate that > > a given collaboration definition can only be used in nested mode, > > otherwise an error is returned by the BSI. > > > > Best regards, > > > > 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: Martin W Sachs [mailto:mwsachs@us.ibm.com] > > >>Sent: Friday, August 09, 2002 2:56 PM > > >>To: Jean-Jacques Dubray > > >>Cc: ebtwg-bps@lists.ebtwg.org; ebxml-cppa-negot@lists.oasis-open.org > > >>Subject: RE: BPSS Start element > > >> > > >> > > >> > > >> > > >> > > >> > > >>JJ, > > >> > > >>OK, now how does this work? (The following use case is for the CPA > > >>negotiation BPSS instance.) > > >> > > >>Using your notation, I have a collaboration A with start element > > "start- > > >>A". > > >>Nested inside it, I have a collaboration B with start element > > "start-B". > > >>It is my intention that Collaboration B start only as a result of a > > >>transition from Collaboration A. So, the choreography normally begins > > >>with > > >>the other party sending me document Da. Suppose that some business > > >>partner > > >>has a software error and attempts to start collaboration A but sends > > >>document Db. That is an error and the BSI should signal an error. > > How > > >>will it know that starting with document Db is an error? > > >> > > >>I believe that there has to be something about the BPSS instance > > document > > >>that tells the BSI that each new instantiation is required to begin > > with > > >>document Da but I can't find anything. I hypothesize that I should > > omit > > >>start element start-B if I want each new instatiation to always start > > with > > >>document Da but I can't find any words that allow me to do omit > > start-B in > > >>order to force the BSI to flag an error if an instantiation starts > > with > > >>document Db. > > >> > > >>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: Martin W > > >>Sachs/Watson/IBM@IBMUS > > >> <jjd@eigner.com> cc: > > >> Subject: RE: BPSS > > Start > > >>element > > >> 08/09/2002 02:31 > > >> PM > > >> > > >> > > >> > > >> > > >> > > >>Sorry, I did not understand the question like this. I don't see any > > >>ambiguity unless both collaboration would start from the exact same > > >>(logical) document. The BSI has a global view of all collaboration > > >>definitions so it is not really important if they are nested or part > > of > > >>the same definition. If collaboration B is nested in collaboration A > > and > > >>Da (Db) is the document that starts the collaboration A (B) then when > > Da > > >>arrives as part of the first request, only Collaboration A can be > > >>instantiated. Nothing prevents us to send Db in this case > > collaboration > > >>B would be instantiated. When a collaboration has started we then have > > a > > >>correlation for all subsequent message so we know how to distinguish > > >>between a Db that starts a collaboration (no correlation) and a Db > > that > > >>starts the nested collaboration within collaboration A. > > >> > > >>Hope that helps, > > >> > > >>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: Martin W Sachs [mailto:mwsachs@us.ibm.com] > > >>>>Sent: Friday, August 09, 2002 10:12 AM > > >>>>To: Jean-Jacques Dubray > > >>>>Cc: ebtwg-bps@lists.ebtwg.org; ebxml-cppa-negot@lists.oasis-open.org > > >>>>Subject: RE: BPSS Start element > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>JJ, > > >>>> > > >>>>Thanks for the reply. However, I would like to restate my question. > > >>>> > > >>>>One of the essential services a BSI can provide is to ensure that > > >>everyone > > >>>>is obeying the choreography described in the BPSS instance. That is > > >>>>especially important in a world in which two trading partners may > > have > > >>>>obtained their application software from different vendors. In order > > >>to > > >>>>perform this service, the BSI must know what is the start of the > > >>>>choreography. > > >>>> > > >>>>I have a BPSS instance two binary collaborations, one nested inside > > >>the > > >>>>other, and both have Start elements. How does a BSI know which Start > > >>>>element actually starts the choreography? > > >>>> > > >>>>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: Martin W > > >>>>Sachs/Watson/IBM@IBMUS, <ebtwg-bps@lists.ebtwg.org>, <ebxml-cppa- > > >>>> <jjd@eigner.com> negot@lists.oasis- > > >>>>open.org> > > >>>> cc: > > >>>> 08/09/2002 09:31 Subject: RE: BPSS > > >>Start > > >>>>element > > >>>> AM > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>Marty: > > >>>>>> > > >>>>>>1. How does a BSI know the starting point of a choreography > > defined > > >>in > > >>>>a > > >>>>>>BPSS instance document? Is that the function of the Start > > element? > > >>>>If > > >>>>>>not, what is the indicator? (It can't be preCondition since in BPS > > >>>>1.05, > > >>>>>>that attribute is for documentation only.) > > >>>>>> > > >>>>[JJ] The start element is used to "point to" the first business > > >>>>transaction activity of the binary collaboration (actually nothing > > >>>>prevents you to point to a fork element therefore enabling several > > BTA > > >>>>at the same time). The request of the BTA pointed to by the start > > >>>>element is the message that will initiate the binary collaboration > > >>>> > > >>>> > > >>>>>>2. If a BPSS instance contains more than one binary collaboration > > >>(not > > >>>>>>nested), are they treated as separate choreographies? Should each > > >>>>have a > > >>>>>>Start element? > > >>>>[JJ] Yes they are completely independent and all should have a start > > >>>>element. > > >>>>>> > > >>>>>>3. If a BPSS instance contains one "top-level" binary > > collaboration > > >>>>and > > >>>>>>another binary collaboration nested inside it, should both binary > > >>>>>>collaborations have start elements? If so, how does a deployment > > >>tool > > >>>>or > > >>>>>>BSI know where the starting point is? It seems to me that it > > would > > >>>>have > > >>>>>>to > > >>>>>>analyze the flow in detail to figure out where the choreography > > >>>>begins. > > >>>>>> > > >>>>[JJ] I don't see a probleme there, the start element is a > > >>pseudo-state, > > >>>>so in the case they are nested (as a Collaboration Activity in the > > >>>>parent binary collaboration definition), the BSI will simply expect > > >>the > > >>>>next BTA will be the one pointed to by the start element of the > > child > > >>>>collaboration. In other words the BSI does not "stop" at this start > > >>>>element, it automatically transitions to the BTA pointed to by this > > >>>>element. You always need a start element to point to where you > > start. > > >>>>Otherwise, you would have to analyze all the transitions and detect > > >>the > > >>>>BTA that does not have a transition to it. > > >>>> > > >>>> > > >>>>>>I have a suspicion that the answers are: > > >>>>>> > > >>>>>>1. The Start element is supposed to tell the BSI where the > > >>>>choreography > > >>>>>>starts. > > >>>>>> > > >>>>>>2. Non-nested binary collaborations are separate choreographies > > and > > >>>>each > > >>>>>>needs a Start element. > > >>>>>> > > >>>>>>3. The nested binary collaboration should not have a Start element > > >>>>since > > >>>>>>the choregraphy starts with the top-level binary collaboration and > > a > > >>>>>>Transition element defines the starting point of the nested binary > > >>>>>>collaboration. > > >>>>>> > > >>>>>>Am I right? > > >>>>>> > > >>>>>>Incidentally, BPSS 1.05 states that for the Start element, > > >>>>>>maxOccurs="unbounded" although the text in 8.1.24 strongly implies > > >>>>that > > >>>>>>maxOccurs should be "1". > > >>>>>> > > >>>>[JJ] That could be a bug, I'll look into it. Conceivably, it is not > > >>>>impossible to think of multiple start element, the question is > > simply, > > >>>>once such a collaboration has started to we disable the other start > > >>>>element or do we leave them enabled? Note that this behavior can be > > >>>>achieved with a single start followed by a fork (XOR or All) which > > >>will > > >>>>be followed by the corresponding BTAs. > > >>>> > > >>>>Cheers, > > >>>> > > >>>>JJ- > > >>>> > > >>>> > > >>>>>>Regards, > > >>>>>>Marry > > >>>>>> > > >>>>>>****************************************************************** > > ** > > >>** > > >>>>**** > > >>>>>>*********** > > >>>>>> > > >>>>>>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 > > >>>>>>****************************************************************** > > ** > > >>** > > >>>>**** > > >>>>>>*********** > > >>>>>> > > >>>>>> > > >>>>>>---------------------------------------------------------------- > > >>>>>>To subscribe or unsubscribe from this elist use the subscription > > >>>>>>manager: <http://lists.ebtwg.org/ob/adm.pl> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>---------------------------------------------------------------- > > >>>>To subscribe or unsubscribe from this elist use the subscription > > >>>>manager: <http://lists.ebtwg.org/ob/adm.pl> > > >> > > >> > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: <http://lists.ebtwg.org/ob/adm.pl> > > > > ---------------------------------------------------------------- > > To subscribe or unsubscribe from this elist use the subscription > > manager: <http://lists.ebtwg.org/ob/adm.pl> > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.ebtwg.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC