[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Trading Partner Logical Identification based on EDIFA
Dick,
Thanks for itemizing various facets of reliable messaging that may or may not be in the
scope of ebXML.
I agree that we should nail down what is in and out of scope of RM for ebXMl first. IMO
the focus of RM should be "Once and only once delivery guarantee". Anything more stands
the risk of adding complexity, over-engineering and premature optimization. ebXML
adoption could be jeopardized if we forget the KISS principle.
Here is my opinion in detail:
Within Scope of ebXML RM
====================
-Once and only once delivery (includes identification and elimination of duplicate
messages)
- Persistence (required for Once and only once delivery)
Outside Scope of ebXML RM But Addressed Elsewhere in ebXML
=============================================
- Security (outside RM spec, being addressed in in security spec)
- Error notifications (being addressed in Error Handling spec. May have references in
RM spec)
- Fragmentation and reassembly of a large message
Dealing with delivery of large messages that need to be fragmented and re-assembled
may need to be addressed somewhere. IMO lets keep RM focused on Once and only once
delivery and address this elsewhere in TRP if needed.
- Compression
Not needed for Once and Only Once delivery. Could be addressed elsewhere TRP spec
if needed.
Outside Scope of ebXML RM
=====================
- Efficiency mechanisms:
This is where I feel implementations should be free to innovate. IMO it is not
needed for interoperability
I am unclear on your point about Reliability semantics. I assume the "boundary" for
ebXML's reliability is between a client sending a message to a partner and until a
transport level ack is received from the partner.
--
Regards,
Farrukh
Dick Brooks wrote:
> There are other aspects of reliable messaging being discussed within ebXML
> that may or may not be "within scope" of the PHASE 1 ebXML deliverable;
> this, I believe, is Nicks point. Some of the topics I've heard discussed
> within ebXML's Reliable Messaging discussions include:
>
> - Identification and elimination of duplicate messages
> - Efficiency mechanisms:
> - Sliding Windows (flow control and efficient async acknowledgement)
> - Batching
> - Persistence
> - Error notifications (at several levels)
> - Fragmentation and reassembly of messages
> - Compression
> - Security (both access control and PAIN)
> - Reliability semantics (what is the "boundary" for ebXML's reliability)
> - after a receiver acknowledges receiving the message by issuing a positive
> ack
> - after validation of header structure
> - after validation of payload structure
> - after validation of crypto (encryption/digital signatures)
> - after validation of header data values
> - after validation of payload data
> - after an application system issues a "business level acknowledgement"
> (e.g. X12 855)
> - after all related business transactions have been exchanged within a
> message set
>
> It seems the first step is to decide WHAT is within scope for the Phase 1
> ebxml deliverable. Define the "functional specifications" that will enable
> vendors to build interoperable solutions based on WHAT is defined.
>
> Dick Brooks
> Group 8760
> 110 12th Street North
> Birmingham, AL 35203
> dick@8760.com
> 205-250-8053
> Fax: 205-250-8057
> http://www.8760.com/
>
> InsideAgent - Empowering e-commerce solutions
>
> > -----Original Message-----
> > From: Nicholas Kassem [mailto:Nick.Kassem@eng.sun.com]
> > Sent: Friday, August 18, 2000 7:03 PM
> > To: gvh@progress.com
> > Cc: ebXML Transport (E-mail)
> > Subject: Re: Trading Partner Logical Identification based on EDIFA
> >
> >
> > List-Unsubscribe:
> > <mailto:ebxml-transport-request@lists.ebxml.org?body=unsubscribe>
> > List-Archive: <http://lists.ebxml.org/archives/ebxml-transport>
> > List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
> > <mailto:ebxml-transport-request@lists.ebxml.org?body=help>
> >
> > At 01:33 PM 8/18/2000 -0700, Gordon van Huizen wrote:
> > >Farrukh,
> > >
> > >There was a great deal of confusion about this in San Jose, and I'm not
> > >sure that we all came away with the same mental picture of what's being
> > >addressed WRT to windows.
> > >
> > >Here are the two levels of windows that I would have been comfortable
> > >with:
> > >
> > >1) A low-level framing mechanism for marshaling data over the wire based
> > >on a given transport protocol. The rationale for this mechanism is
> > >efficiently and reliably propagating all traffic over a given link.
> > >Traffic, here, means a mix of messages (for multiple logical sending and
> > >receiving parties and multiple conversations, with varying delivery
> > >guarantees, message priorities, etc.) that happen to be sent between
> > >service providers on two ends of a physical link. In practice this
> > >framing is necessary for performance and reliability over underlying
> > >transport protocols (certainly for TCP/IP). The key here is that the
> > >windowing is between service providers that own the physical link, not
> > >between logical parties. Few project team members were comfortable
> > >addressing this level of window in the spec, although it does affect
> > >performance, reliable messaging and the ability to have over-the-wire
> > >interoperability.
> >
> > Forgive me for re-hashing issues that may have already been
> > sorted out but
> > I'm struggling to understand the problem being tackled. My understanding
> > was (from way back in Dallas) that the goal of reliable messaging, in the
> > ebXML TRP context, was to offer a quality of service over and above what
> > e.g. HTTP/SMTP offer on their own, but less than what most MOM products
> > typically already offer today. The goal, presumably, is not to duplicate
> > what MOM products already do in a proprietary way but rather to unburden
> > applications from having to re-invent some basic notion of reliable
> > messaging every time. I think it would be good to de-couple the
> > fragmentation/re-assembly problem from the reliable messaging
> > problem. IMO,
> > the latter requires the definition of ebXML transport level
> > messages (that
> > are never seen at the ebXML application level - because that's the whole
> > point of this exercise) and their associated choreography. The
> > exchange of
> > such messages between peer ebXML transport providers would provide some
> > assurance to a message producing application entity (Business Process) as
> > to the delivery (or non-delivery) state of the application payload. This
> > may be good enough for most web centric business applications and
> > we could
> > also define ebXML transport level retry mechanisms, time-out's etc. Those
> > applications that need an MQ class of service will continue to
> > use the wide
> > range of commercial products out there and will utilize whatever API they
> > see fit.
> > Am I way off the mark ?
> >
> >
> > >2) An application-level message batching mechanism for application-level
> > >transaction management, ala JMS, where at the application level you can
> > >commit or roll-back a group of messages and receive notification of
> > >time-outs, etc. The scope of a window here is application-based. The
> > >group agreed that this was out of scope for the reliable messaging spec,
> > >indicating that the reliable messaging layer to be addressed is not an
> > >application-level issue.
> >
> > Agreed.
> >
> >
> > >What I believe we have in the reliable messaging spec is most definitely
> > >not #1, and I don't believe it's #2 either. Instead I believe it's some
> > >middle layer that will need to be mapped in both directions.
> >
> > Agreed. I think we need to be closer to #1 without going
> > overboard and with
> > an emphasis on inter-operability. The challenge is to explicitly define
> > what is meant by "reliable".
> >
> >
> > >-gvh-
> > >
> > >Farrukh Najmi wrote:
> > > >
> > > > 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:Van Huizen;Gordon
> > >tel;work:510-848-1988
> > >x-mozilla-html:TRUE
> > >url:http://www.sonicmq.com
> > >org:Progress Software;XML and Internet Technology
> > >adr:;;14 Oak Park;Bedford;MA;01730;
> > >version:2.1
> > >email;internet:gvh@progress.com
> > >title:Director, Product Management
> > >fn:Gordon Van Huizen
> > >end:vcard
> >
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC