[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa-negot] Re: BPSS Start element
Hima,
Please see my comments below.
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, ebxml-cppa-
com> negot@lists.oasis-open.org
Subject: Re: BPSS Start element
08/09/2002 10:19
AM
Assuming there is programming interface to the application,
the application would convey to BSI layer which collaboration
it is taking part in.
<MWS> I agree that this would work. However one of the functions a
BSI can perform is to assure that both Parties' applications are
playing by the same
rules. Allowing the application to tell its BSI the starting point
leaves open the possibility that a programming error at one or both
Parties will cause one or both to tell its BSI the wrong starting point.
One of the important value propositions for both a CPA and a BPSS instance
is that the two Parties have agreed to a single copy of the CPA and BPSS
instance and then both deploy identical copies. That ensures that the
two BSIs are playing by the same rules and will detect cases where the
applications are not playing by those rules. For this to work reliably,
the BSIs must be able to infer the starting point of the choreograpny
directly from the information in the BPSS instance. </MWS>
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.
<MWS> Again, this assumes that the applications do make errors in their
API invocations.</MWS>
Starting the innner collaboration independent of starting as part
of outer collaboration are two difeerent activities.
<MWS> Allowing the inner collaboration to be both independent and
nested inside the outer collaboration complicates the BSI's analysis
of the choreography. As I said above, leaving it to the application to
tell the BSI works only if one of the Parties does not nake an error.
</MWS>
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.
<MWS> I agree. This scenario requires a Start element only in the outer
collaboration since the starting point in the inner collaboration is
given by the Transition element in the outer collaboration. <MWS>
-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