T2 Behavior of IM and non IM MSH,was RE: T2 PLEAE READ - Sugges ted solution to RM Issues

["Burdett, David" <david.burdett@commerceone.com>]

Dan

You said ...

>>>It is thus even moreimportant that the spec clearly state its assumptions
about the intermediary functions above the level of the MSH including some
words about the case where there is a non-ebXML link in the path between two
intermediaries.<<<

At the end of August I posted a description of what the different From
Parties should do, see
http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00365.html to which
Marty Sachs then replied.

Does this answer you question.

-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Tuesday, September 11, 2001 7:26 AM
To: mwsachs@us.ibm.com
Cc: Burdett, David; chris.ferris@east.sun.com; arvola@tibco.com;
ebxml-msg@lists.oasis-open.org
Subject: Re: T2 PLEAE READ - Suggested solution to RM Issues


   Date: Mon, 10 Sep 2001 22:19:52 -0400
   From: "Martin W Sachs" <mwsachs@us.ibm.com>

   I agree with your comments on the case described in your posting (below)
   but it does call into question my previous posting. Consider this:

      A----B----C----D

   Clearly, A and D have to communicate end to end via ebXML messaging, CPA
   (virtual or real), and BPSS (virtual or real).

I agree.

   The problem is that there is nothing requiring that the link between B
and
   C be an ebXML path.  Therefore both of our previous comments that all IM
   nodes must have two MSHs are not correct.  In the simplest case (dumb
store
   and forward only), we can consider the combination of B and C as a single
   intermediary ("virtual ebXML IM") with what goes on between them an
   internal matter that is outside the scope of ebXML.  It is thus even more
   important that the spec clearly state its assumptions about the
   intermediary functions above the level of the MSH including some words
   about the case where there is a non-ebXML link in the path between two
   intermediaries.

I agree strongly about "clearly state its assumptions".


Perhaps a more useful analogy might be to the way the original Arpanet
worked.  The Arpanet was based around a "subnetwork" of
special-purpose computers called IMPs (interface message processors).
Every host was attached to an IMP via an Arpanet-standard hardware
interface.  Each IMP talked to up to four (or something much like
that) other IMPs, over dedicated 56Kbaud phone lines, forming a
not-fully-connected graph.

There were three protocols going on:
- IMP-IMP
- Host-IMP
- Host-Host

The IMP-IMP protocol was not advertised to those of us out at the
hosts.  It was entirely the IMPs own business how they got messages
from one place to another, and the Arpanet authorities (e.g. BBN) were
free to change that at any time.

The Host-IMP protocol let a host give commands to an IMP, particularly
"please take this byte-string and send it to host N".  As far as the
host-IMP and IMP-IMP protocols were concerned, the byte-string saw
opaque (an uninterpreted BLOB).  The Host-IMP protocol controlled
things like flow control (the IMP can't accept that byte-string now
because its buffers are full) and established a meaningful concept of
host address.

At a lower layer, a host knew about its own IMP; at a higher layer, a
host knew about the other host.  A host didn't know anything at all
about other IMPs.

So one way to look at your A - B - C - D example is as an analogy,
thinking of B and C as playing the role of IMP's.  A tells B, here is
a message, don't worry about its business content since that's D's
business, just get this message through to D.  The A - B communication
is like the host-IMP protocol; the A - D communication is like
host-to-host protocol; the B - C communication is like IMP-IMP
protocol.

The ebXML MS spec would be addressed to the person programming A.  It
would specify two things: how A should talk to B (a la host-IMP), and
how A should talk to D (a la host-host).  It would not say anything
about how B talks to C; like the IMP-IMP protocol, this is not
advertised to the people programming endpoints like A, especially
because, as you point out, there might be *many* different protocols
for the B's of the the world to talk to the C's of the world.

The part of the MS spec that talked about A - B communication would
talk about things like using HTTP versus SMTP, and would not talk
about things like services and actions.  The part that talked about A
- D would be exactly the opposite.

It seems to me that if the ebXMl MS Spec could be more clearly
separated into these two layers, it would become much more clear why
the MS Sec does not venture to prescribe how B talks to C.

-- Dan