[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