RE: Re[2]: Trading Partner Logical Identification based on EDIFA

[mwsachs@us.ibm.com]

Dave,

I haven't been around ebXML long enough to know what the old message set ID
is but let me go into conversation ID a little more.

A conversation (in tpaML terms) is the two way set of messages comprising a
single "unit of business".  It's sort of like a session as I think I
pointed out in an earlier post about the messaging specification.  So I
think it is equivalent to what you called a message set ID in your posting.
I did point out elsewhere that each party should be allowed to separately
identify the conversation and suggested that the existing conversation ID
should have separate subelements for the two parties.  The reason is that
for routing purposes, the conversation ID should be a rapid locator. I
suggested that each partner should be allowed to put in whatever it needs
for its half of the conversation ID to enable rapid locating.  We do use
the conversation ID for routing within each party in our IBM Research
prototype run-time. I'm not sure that the URI qualifies as a rapid locator
though of course using it shouldn't be precluded.

The TPA is an identifier of the TPA document itself.  The TPA ID identifies
the application and pair of parties while the conversation ID identifies a
specific conversation.  I did err in suggesting that both the TPA ID and
the conversation ID are needed for routing.  If the conversation ID is
unique within one party's messaging system, then conversation ID is the
routing quantity and the TPA ID could be part of the state information for
the conversation rather than being used for routing.  For the greatest
implementation flexibility, however, I strongly suggest that the TPA  ID
also be allowed to be a rapid locator and that each party be allowed to
choose its own value for the TPA ID.  Clearly, the local TPA IDs could be
associated with a global repository ID for the TPA but it's the two local
values that should be in the message header to give the best routing
implementation flexibility.

Regards,
Marty

*************************************************************************************

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



David Burdett <david.burdett@commerceone.com> on 08/16/2000 02:27:30 PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
Subject:  RE: Re[2]: Trading Partner Logical Identification based on EDIFA



Marty

Somewhere in this text you say ...

>>>Again, it is the combination of registry ID, partner ID, TPA ID, and
conversation ID that does the routing<<<

I'm under the impression that conversation ID is equivalent to what the TRP
used to call the Message Set Id which was defined as a unique identifier
for
the set of messages exchanged between two parties that support the instance
of an execution of a service.

On the other hand the current spec defines conversationId as a URI which
identifies the conversation instance of the Trading Partner Agreement which
governs the processing of the message and which holds the state of the
conversation between the two Parties

I don't think these things are quite the same. Can you clarify the
distinction between a TPA Id and a Conversation Id. As if a Conversation Id
means the same as the old Message Set Id I don't think it should be used
for
routing.

David

-----Original Message-----
From: mwsachs@us.ibm.com [mailto:mwsachs@us.ibm.com]
Sent: Tuesday, August 15, 2000 3:24 PM
To: David RR Webber
Cc: Mark NOBLES; ebXML-Transport@lists.ebxml.org
Subject: Re: Re[2]: Trading Partner Logical Identification based on
EDIFA


Quite a flurry of postings!  I just got caught up on it.  I sense a great
deal of violent agreement on the identifier subject.  I agree with Mark
Nobles' last posting and Dave Webber's agreement with it.  Here are a few
summary points:

<SNIP>