Re: Trading Partner Logical Identification based on EDIFA

[Farrukh Najmi <Farrukh.Najmi@east.sun.com>]

Gordon,

I am still unclear on the second two of three suggested levels of windows. Can
someone give a reason for why we need the additional grouping of messages. Is it
not enough to group messages that are related to one conversation (ala JMS
transaction as suggested)? And why does the transport have any role to play in the
grouping of messages? Since these additional levels of "windows" add complexity at
the conceptual level I would like to understand the rationale behing them.

--

Regards,
Farrukh

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>
> > >
begin:vcard 
n:Najmi;Farrukh 
tel;fax:781-442-1610
tel;work:781-442-0703
x-mozilla-html:TRUE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Drive, MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh S. Najmi
end:vcard