Re: Trading Partner Logical Identification based on EDIFA

[Jim Hughes <jfh@fs.fujitsu.com>]

Fujitsu wrote the draft RM spec from the viewpoint of the second item 
below. It assumes *no* knowledge of a particular transport and is not aware 
of any business ralationship with other messages (if that is what you mean 
by 'conversation'!).

Process check. If there is not agreement on the *requirements* for reliable 
messaging, then let's focus on the *requirements document* and not the 
latest draft RM specification. And, let's come to an agreement that the 
requirements document is well-specified and closed before we get into the 
trenches discussing the actual spec...

Jim

At 12:28 PM 8/18/00 -0700, Gordon van Huizen wrote:
>I know we've had a lot of discussion about this, but it seems to me that
>there are three levels of "windows" involved in the current model for
>ebXML messaging:
>
>- Conversation-level windows (more like transacted messages in JMS)
>- Reliable messaging windows (at a logical level, above transport
>bindings)
>- Windows for framing messages carried across a particular transport
>
>Is this what everyone else is picturing? If so, the Reliable Messaging
>window can be pretty simple, and then we have the issue of mapping these
>to the other two levels. I want to be clear on this point prior to
>making final comments on the reliable messaging spec.
>
>If the above separation is NOT what we're doing, the reliable message
>spec needs some work.
>
>-gvh-
>
>Marc Breissinger wrote:
> >
> > 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>
> > >