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


Assuming there is programming interface to the application,
the application would convey to BSI layer which collaboration
it is taking part in.

If the inner collaboration has a start element of its own and the
application is allowed to use that collaboration, then
depending on the parameters, BSI would invoke the right collaboration
on either ends.

Starting the innner collaboration independent of starting as part
of outer collaboration are two difeerent activities.
Start for outer collaboration would point to BusinessTransactionActivity
as defined in outer collaboration and is different from
the BTA referred to by Start of inner collaboration. There
would be a transition from the outercollaboration to the
innercollaboration using a CollaborationActivity and this is what
would start the inner collaboration as part of outer collaboration.

-hima

Martin W Sachs wrote:

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



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


Powered by eList eXpress LLC