RE: Trading Partner Logical Identification based on EDIFA

[Marc Breissinger <marcb@webmethods.com>]

The Message Window (which I believe as been renamed in the latest version of
the Reliable Messaging spec) is not the same as the conversation.  Messages
from many conversations can be within the same window.

==========================================================================
Marc Breissinger                                   voice (W): 703-460-2504
Director, Product Strategy - webMethods, Inc.      voice (C): 703-989-7689
Email:  marcb@webmethods.com                               We're hiring!!!
Email2: breissim@earthlink.net              URL: http://www.webmethods.com
==========================================================================


> -----Original Message-----
> From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
> Sent: Friday, August 18, 2000 9:54 AM
> To: ebXML Transport (E-mail)
> Subject: Re: Trading Partner Logical Identification based on EDIFA
>
>
>
> The EbXML header also calls this (i.e. Message Set ID) a
> Conversation ID. I find this
> term to be the most descriptive because an ebXML based Business
> Process may be conducting
> several concurrent conversations with the same trading partner.
> Since this ID is used to
> link Messages associated with the same conversation I propose we
> stick with Conversation
> ID. This will also reduce confusion since the term is already in
> use in the ebXML header
> DTD.
>
> On a related subject, I have heard the term Message Window in the
> Reliable Messaging
> spec. Again my interpretation is that this is referring to a
> Conversation. If so we
> should align the terminology and consistently call this concept a
> Conversation that is
> identified by a Conversation ID.
>
> Is there a horizontal team that makes sure we get rapid alignment
> on common terminology
> across working groups? If so they should resolve this terminology
> issue quickly.
>
> --
>
> Regards,
> Farrukh
>
> srh@us.ibm.com wrote:
>
> > When we decided in Dallas on the term "Message Set" (my suggestion) the
> > intention was
> > merely to give identification within *an undefined context at the time*
> > to that conversation/unit-of-business. I happen to like the term, as it
> > avoids the overloaded *transaction*.
> > There was no further semantic impled, certianly not routing. If we can
> > seperate what/how issues it may help.
> >
> > Scott Hinkelman
> > Senior Software Engineer, IBM Austin
> > Emerging Technologies, SWG
> > 512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
> > srh@us.ibm.com, Fax: 512-838-1074
> >
> > Martin W Sachs/Watson/IBM@IBMUS on 08/16/2000 03:15:12 PM
> >
> > To:   David Burdett <david.burdett@commerceone.com>
> > cc:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
> > Subject:  RE: Re[2]: Trading Partner Logical Identification
> based on EDIFA
> >
> > 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>
>