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


<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>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC