RE: Trading Partner Logical Identification based on EDIFA

[Dick Brooks <dick@8760.com>]

Farrukh,

Firstly, I agree 100% with your KISS point.

What I meant by "boundary" with regard to reliability was the notion that a
message passes several "checkpoints" in the delivery process where
acknowledgements (and hence reliability) can be addressed:

- Successfully passed authentication/access control
- Successfully sent the bits to the other end
- Successfully checked the packaging
- Successfully checked the header structure
- Successfully checked the header data
- Successfully checked the signature on a header
- Successfully decrypted the payload
- Successfully verified the signature on a payload
- Successfully checked the structure of a payload
- Successfully "translated" the payload (from XML, X12, EDIFACT)
- Successfully passed the translated payload to a backend system/application
for processing
- Backend application successfully processed the payload

In addition to all the "successful" cases above there are a significant
number of error conditions that can occur at each of these points.

My question to the group was, which of these "checkpoints" are within scope
for the phase 1 reliable messaging deliverable?


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: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
> Sent: Monday, August 21, 2000 8:56 AM
> To: Dick Brooks
> Cc: ebXML Transport (E-mail)
> 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
> > >
>