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:

>
>
>
>
> Hmmm.  I go away for a few hours and you guys get way ahead of me :-)  I am
> going to reply to each posting in sequence rather than attempting to
> analyze everything first.
>
> JJ, I would like the BSI to detect and flag an error if my business partner
> opens the conversation by erroneously sending the message that is
> appropriate for the enbedded collaboration without first traversing the
> outer collaboration. The whole point of expressing the choreography as an
> XML description is to allow middleware (BSI) to police what is being done.
> If middleware weren't going to police the choreography, I might as well
> just describe the choreography in text and let the application programmers
> figure out whether it is done correctly by the other partner. So, I need
> the ability to distinguish between nested business collaborations and
> independent ones.  I need something that tells the deployment tool that
> each conversation must start with the outer collaboration. One way to do
> this is to omit the Start element for the embedded collaboration.  The
> schema actually allows me to do that (minOccurs="0") but there is nothing
> that tells a BSI what omitting the Start element means.
>

<hima> Wouldn't one way of doing this be using the actions exposed
in the CPA, which conveys what all collaborations can be
used. In this way there wouldn't be actions in the CPA for
internal collaborations. Actions would point to nested collaborations.
This way the BSI layer can match the action to nested collaboration
and if a particular trading partner uses the same "action" to
instantinate internal collaboration without the scope of
outer collaboration, it can be identified by BSI and marked as error
</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, "'John Yunker'" <john.
>                       <jjd@eigner.com>          yunker@bleuciel.org>
>                                                cc:       <ebtwg-bps@lists.ebtwg.org>, <ebxml-cppa-negot@lists.oasis-open.org>,
>                       08/09/2002 03:12          "'Jean-Jacques Dubray'" <jjd@eigner.com>
>                       PM                       Subject:  RE: BPSS Start element
>
>
>
>
> To me, the Start-B pseudo state is not necessarily causing any trouble.
> Then the BSI reaches the state of collaboration activity (defined by
> collaboration B), it enters it, reaches the start-B state which has an
> automatic transition to the first BTA of collaboration B. The BSI is
> then in the position of enabling the request of this BTA to happen. I
> don't see anything illogic about it, hence I don't see any reason not to
> use a start-B state. Do you?
>
> Thanks,
>
> 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 3:01 PM
> >>To: John Yunker
> >>Cc: ebtwg-bps@lists.ebtwg.org; ebxml-cppa-negot@lists.oasis-open.org;
> >>Jean-Jacques Dubray
> >>Subject: Re: BPSS Start element
> >>
> >>
> >>
> >>
> >>
> >>
> >>John,
> >>
> >>Thanks,  I believe you do understand what I am driving at.  I believe
> that
> >>the reply I just posted to JJ is also appropriate to your posting but
> let
> >>me restate in your terms:
> >>
> >>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,
> >>
> >>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
> >>**********************************************************************
> ****
> >>***********
> >>
> >>
> >>
> >>                      "John Yunker"
> >>                      <john.                   To:       Martin W
> >>Sachs/Watson/IBM@IBMUS, "Jean-Jacques Dubray" <jjd@eigner.com>
> >>                      yunker@bleuciel.         cc:       <ebtwg-
> >>bps@lists.ebtwg.org>, <ebxml-cppa-negot@lists.oasis-open.org>
> >>                      org>                     Subject:  Re: BPSS
> Start
> >>element
> >>
> >>                      08/09/2002 02:35
> >>                      PM
> >>
> >>
> >>
> >>
> >>
> >><MWS> 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? </MWS>
> >>
> >>Actually, this question is easily answered.  Since the collaborations
> >>inherit from UML activity model, which itself is a state model, it is
> >>clear
> >>that the outer collaboration "Start Element" starts the collaboration.
> >>Now,
> >>if the nested collaboration is part of the initiating business action,
> >>then
> >>no messages are exchanged until the nested transaction starts.
> >>
> >>This is actually a very important feature, since business state may
> >>dictate
> >>that a collaboration is required.  That state can be expressed on the
> >>outer
> >>start state, and still have conditions critical to the function of the
> >>inner
> >>transaction normalized to the inner transaction.  The fact the
> >>collaboration
> >>instance has been "started" is of value regardless of whether any
> message
> >>exchanges have taken place.
> >>
> >>So, to recap, the nested collaboration must be considered a state
> machine
> >>encapsulated in an individual state within the encapsulating
> transaction,
> >>(nested state machines) thus for the encapsulated collaboration to
> start,
> >>the encapsulating collaboration must have started.
> >>
> >>I can see incredible value in being able to normalize conditional
> elements
> >>between the two start elements.
> >>
> >>Thanks,
> >>John
> >>
> >>(p.s. I cannot post to the CPPA list, Marty, could you do it for me?
> >>Thanks!!!)
> >>
> >>
> >>
> >>
> >>
> >>
> >>----------------------------------------------------------------
> >>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