RE: T2 - Assertions and Questions

[David Smiley <dsmiley@mercator.com>]

Colleen,

Thanks for the feedback. Apparently, I made myself imperfectly clear. Or,
imperferctly clear :)

My premise is that there are no intermediaries for us to be concerned about
in the messaging spec, therefore, no black boxes and no magic are needed. I
understand that this is different thinking from what was attempted in the
spec. So, I'm either so completely off base that these ideas will die from
neglect, or, looking at the problem differently might bring out a valid,
alternate approach.

Looking at the sequence I described, there is a single point at which you
cross the boundary between the From Party and the To Party and this is the
only chasm we must cross. I think of it as a small gap over a very deep pit.
(Imagine Indiana Jones trying to find the Holy Grail where he must take a
step but there doesn't seem to be a bridge!) We don't need to walk very far,
but we must be able to cross over or return safely. 

The rest of the processes, regardless of how many steps, messaging
protocols, software applications, brokers and 3rd parties are involved, all
represent either the From Party or the To Party. Each of these chains may be
very long, and I think we can only expect to define that one missing link. 

All of this is from a messaging point of view. There should be higher level
processes defined, but I don't think that's our job.

And just to get in a "weakest link" reference.... "Goodbye"

David Smiley
Director of Standards
Mercator




-----Original Message-----
From: Colleen Evans [mailto:cevans@sonicsoftware.com]
Sent: Monday, August 13, 2001 4:41 PM
To: David Smiley; ebXML Msg
Subject: Re: T2 - Assertions and Questions


David,
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.

Colleen

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