Re: T2 PLEAE READ - Suggested solution to RM Issues

[Dan Weinreb <dlw@exceloncorp.com>]

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

      Date: Sat, 08 Sep 2001 01:45:33 -0400
      From: Martin W Sachs <mwsachs@us.ibm.com>

							  We can't make any
      assumptions on the implementations of any of the nodes.

   Why is that?

   MWS:  Let me clarify.  I agree that we must assume that an IM node has a
   properly implemented FROM MSH and a properly implemented TO MSH. What
   we cannot assume is what goes on between those two MSHs because that is
   outside the scope of the MS Spec.  

Ah, I see, that's very helpful.  So the point here is that an IM
should *not* be considered to be a kind of "bridge" analogous to a
bridge in a LAN.  By a bridge I mean something that operates entirely
at the level of the MS Spec: messages come in, messages go out (or
perhaps get lost sometimes), but are not interpreted at a higher
level.

But you're saying that the "bridge" analogy is *not* appropriate.
Rather, you're thinking of the IM as running an "application" (by
which I mean something at a higher level of abstraction than the MS
Spec), and the application is not within the scope of the MS Spec.
The application might read in messages, and then maybe it might decide
to transmit them, or it might not; that's entirely up to it.  And
therefore we cannot rely on the IM to be part of our reliable
messaging protocol, and therefore we need end-to-end retransmit, etc.

This is tricky because some of the use cases I have heard for IM's
really do make them sound like "bridges".  For example, the "mailroom"
use case, where the From Party is only occasionally connected to the
Internet, so it sends its messages to an IM which is always connected
and always up.  This IM's acts as a bridge.  Its only job is to
retransmit the message, without any interpretation; there's no
"application" here and no need to go out of the scope of the MS Spec.

Also, various people have asserted at various times on this mailing
list that the endpoints are "not aware" of the IM's.  This also
suggests a view of IM's as mere bridges.

Here's another use case, courtesy of David Burdett:

   3. Routing intermediary.
   The intermediate MSH provides routing functionality. It analyzes the ebXML
   message it receives and then forwards it to the correct URL for the To
   Party. This avoids the need for the From Party to keep routing tables or
   separate CPAs for every single partner they deal with. It also enables the
   To Party to notify just one location rather than many about any changes to
   how it supports eCommerce.

Here it's not immediately clear whether the "routing functionality" is
something that we want to think of as being at the MS Spec level, or
being at a higher level and not part of the MS Spec at all.  In the
latter case, the software doing the routing is, from our (MS Spec)
point of view, an "application", unknowable and not under our control.
It reads in messages, thinks about where to send them, and maybe loses
track of them in case of a crash or other anticipable failure.

Another use case from David Burdett:

   6. Value added intermediary. Altering the Payload. 
   The intermediary adds data to the Payload, for example adding an additional
   authorization to a Purchase Order before it is sent to the Supplier. The
   payload is altered. The intermediary is in a different division of the From
   Party at a separate location to the originator of the message.

Here it's completely clear that there's an application involved.

And in cases like these, the IM's are less invisible than ever.  In a
chain A - B - C - D, if an IM named C is adding an authorization
that's important to the business process, you'd think that at least at
some level, endpoint A has to "know" about C's existence, because A
cares about the authorization that C is generating and A wants to be
sure that this authorization gets added before the messages reaches D.
We've talked about preagreements (such as CPA's) between the endpoints
(A and D) and between adjacent nodes (A and B), but here it looks
like there has to be someplace where A knows about C as well.

-- Dan