OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

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


Subject: RE: [ebxml-cppa] Re: Notes from BPSS/CPPA conference call



Stefano,

We are definitely in agreement that CPAid.UUID is not always enough for
routing. ConversationId can disambiguate the ambiguous cases that have been
mentioned so far.

I CC'd the list on this since this discussion is generally useful
information.

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



"Stefano POGLIANI" <stefano.pogliani@sun.com> on 11/26/2001 11:20:35 AM

To:    Martin W Sachs/Watson/IBM@IBMUS
cc:
Subject:    RE: [ebxml-cppa] Re: Notes from BPSS/CPPA conference call



Marty,

 I thought that the thread was around the following assertion:

 "The concatenation CPAId.UUID has to guarantee that a message
 arriving in a system will be directed to the proper software
 entry point for that CPA."

I think that we both agree that this is not true, right?

/stefano

> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: 26 November 2001 17:12
> To: Stefano POGLIANI
> Subject: RE: [ebxml-cppa] Re: Notes from BPSS/CPPA conference call
>
>
>
> Stefano,
>
> Since the conversationId is in the message header, it does not have to be
> stored in the CPA info block.  It could be stored in a list whose
> origin is
> in the CPA info block but for routing purposes, that isn't necessary
since
> it is in the message header.
>
> 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
> ******************************************************************
> *******************
>
>
>
> "Stefano POGLIANI" <stefano.pogliani@sun.com> on 11/26/2001 10:58:33 AM
>
> To:    Martin W Sachs/Watson/IBM@IBMUS
> cc:
> Subject:    RE: [ebxml-cppa] Re: Notes from BPSS/CPPA conference call
>
>
>
> Marty,
>
>  more likely is me that I am sidetracking or who did not
> catch enough.
>
> I explain myself. Suppose that the is PartyA which executes
> the same BP with many other parties. His software would,
> probably, have a single instance of the BPSS process instantiated;
> the software itself would be able to distinguish between the
> different partners by some other means.
>
> Now, PartyA executes the same BP with PartyB. This implies
> "one" CPA between PartyA and PartyB (i.e. one CPAid).
> Many instances of the BP between PartyA and PartyB are executed
> concurrently (suppose that PartyB place multiple orders,
> all of them in parallel).
>
> This would imply that the runtime software of PartyA would
> not be able to properly distinguish conversations with
> PartyB if it only considers:
>  - the UUID of the BP
>  - the CPAid
>  - the CPAid.UUID combination
>
> The only way for the runtime to properly distinguish one
> order from the other (coming from teh same PartyB) would
> be to have another "qualifier". This qualifier may well
> be the "conversationId". This conversationId is "local"
> in the sense that it can be anything which makes sense
> between PartyA and PartyB (since CPAid.UUID is able
> to disambiguate up to that level). But the "conversationID"
> cannot be stored in the CPA; it should be something
> happening at Runtime.
>
> Did I get the problem in teh correct way ?
>
> Thanks a lot. Ciao
>
> /stefano
>
> > -----Original Message-----
> > From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> > Sent: 26 November 2001 16:13
> > To: Stefano POGLIANI
> > Subject: RE: [ebxml-cppa] Re: Notes from BPSS/CPPA conference call
> >
> >
> >
> > Stefano,
> >
> > In my mind, the place to keep the local information is in either the
CPA
> > information block or with the conversation state information.
> Both CPAId
> > and conversationId have scopes of uniqueness wide enough to enable them
> to
> > participate in the routing information. Is there something that I don't
> > understand?
> >
> > 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
> > ******************************************************************
> > *******************
> >
> >
> >
> > "Stefano POGLIANI" <stefano.pogliani@sun.com> on 11/26/2001 09:57:40 AM
> >
> > To:    Martin W Sachs/Watson/IBM@IBMUS
> > cc:
> > Subject:    RE: [ebxml-cppa] Re: Notes from BPSS/CPPA conference call
> >
> >
> >
> > Marty,
> >
> >  I think that CPAId, UUID and their combination may not be
> > enough to disambiguate, as well as any "static" information.
> > My impression is that "static disambiguation" may help to constrain
> > the process/parties, but not further.
> >
> > This does not mean that an application should need to do routing
> > (actually, routing should be done much before the application).
> > But that the routing information should be able to account for
> > some "local" (to the involved parties) information to help
> > disambiguate
> >
> > Best regards
> >
> > /stefano
> >
> >
> > > -----Original Message-----
> > > From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> > > Sent: 26 November 2001 15:33
> > > To: Stefano POGLIANI
> > > Subject: RE: [ebxml-cppa] Re: Notes from BPSS/CPPA conference call
> > >
> > >
> > >
> > > Even if all those business relationships use the same code,
> somehow the
> > > message has to get to the right data structure.  CPAId should be
> > > sufficient.  ConversationId is also available to help disambiguate
the
> > > routing.  We should definitely try hard to avoid the
> application having
> > to
> > > do its own routing.
> > >
> > > Another case that might be a problem is two partners, each
> playing both
> > > roles.  There is one BPSS instance document and two different
> > > CollaborationRole elements in the same CPA.  In one CollaborationRole
> > > element, PartyA plays role R1 and Party B plays role R2.  In
> the other,
> > > PartyA is role R2 and PartyB is role R1.  Using
> conversationId as party
> > of
> > > the routing information should disambiguate this case.
> > >
> > > 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
> > > ******************************************************************
> > > *******************
> > >
> > >




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


Powered by eList eXpress LLC