OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: T2 - Assertions and Questions

Good food for thought.  I follow you up to assertion #3C.  We took the black box
approach to intermediaries before, and I don't believe it solved the confusion
factor.  The "and then magic happens" part needs to be expalined in some
detail.  You have to deal with the mechanics of how you cross the chasm (which
bridges you use, etc.) to achieve true end to end reliability.  If the
intermediary hops aren't reliable, the bridge doesn't connect the end points.
You're only as strong as your weakest link.  There was also a requirement for a
trace history across intermediaries, and a way to define message semantics
between intermediaries.   I'm not clear regarding your thoughts on how we can
avoid all of that.


David Smiley wrote:

> Great con call today folks...
> I'm just going to float these thoughts out there. (In other words, I'm going
> to poke at this hornet's nest and then stand back and watch what happens. Of
> course, I may get stung myself, but that's the risk of this approach.)
> Assertion #1:
> Application-level processing of any kind is out of scope of the Message
> Service Specification.
> Any discussion of acks and delivery receipts and the like are only relevant
> at the message service level. There is no To Party application messaging
> back to the From Party MSH.
> Assertion #2:
> The To Party defines the location where messages intended for it are to be
> sent.
> Once delivered to the defined location, the burden of message delivery is
> removed from the From Party's MSH. Any subsequent failure of any kind
> (messaging, application software, whatever) is the responsibility of the To
> Party or its proxies. This supports the case where the To Party is using a
> defined intermediary, such as C1.
> Assertion #3A:
> From a business viewpoint, there is no such thing as an unknown intermediate
> party.
> Regardless of the complexities of the paths taken between the From Party
> application and the To Party application, there is only one exchange of
> messages that crosses the chasm between the two. It is this chasm that we
> are crossing. The From Party (and its proxies) has full responsibility up to
> one edge of the chasm and the To Party (and its proxies) has full
> responsibility on the other side.
> Assertion #3B:
> This still works in an ecommerce marketplace scenario.
> When the To Party is a true ecommerce marketplace, that marketplace is *not*
> an intermediary. It is a known business partner with whom, once a business
> relationship is established, performs as any other known To Party would. The
> fact that they fulfill their business obligations in a distinctly different
> way from some other business is immaterial. After all, we make no
> distinction between manufacturers and wholesalers, as long either can
> fulfill our business need.
> Assertion #3C:
> For our purposes, there is no such thing as a multi-hop message.
> The "chasm" must be crossed in one hop. (You can't hop to the middle of the
> chasm and then on to the other side.)
> Here's an attempt, in ascii :), to show a the sequence of an application
> event from one trading partner to another:
> Company A:  An event occurs in an application
> Company A:  That event causes a message to be placed in a message queue
> (JMS, MQSeries, whatever)
> Company A:  The message on the queue is picked up by an ebXML-aware software
> application (eb-ASA?)
> Company A:  The eb-ASA identifies the To Party, uses the CPA and passes the
> relevant info and invokes the MSH
> Company A:  The From Party MSH sends the message to the appropriate
> destination
> The Chasm:  bits and bytes are whizzing through the internet between the two
> MSHs
> Company B:  The To Party MSH receives the message.
> Company B:  more stuff happens
> Company B:  more stuff happens
> Company B:  more stuff happens
> Company B:  Finally, some application that cares receives the data.
> So, if you've made it this far and you agree with these assertions, here are
> some questions:
> Question #1:
> Can we eliminate any references to multi-hop or intermediate MSH from the
> spec?
> Questions #2:
> Do we need to be concerned about message handling anywhere other than "The
> Chasm"?
> Question #3:
> If these issues remain unresolved at the time of the face-to-face meeting,
> will security personnel be present? I don't want anyone getting hurt.
> I think I've done enough poking for one day. I'm sure my inbox will suffer
> for this one.
> David Smiley
> Director of Standards
> Mercator
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC