T2 - Assertions and Questions

[David Smiley <dsmiley@mercator.com>]

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