Re: T2 PLEAE READ - Suggested solution to RM Issues

[Martin W Sachs <mwsachs@us.ibm.com>]

My comments below.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Dan Weinreb <dlw@exceloncorp.com> on 09/11/2001 09:45:24 AM

Please respond to "Dan Weinreb" <dlw@exceloncorp.com>

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   chris.ferris@east.sun.com, ebxml-msg@lists.oasis-open.org
Subject:  Re: T2 PLEAE READ - Suggested solution to RM Issues



   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.

MWS:  Correct; an IM is not as simple as a LAN bridge.

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.

MWS: At a minimum, the IM higher level function has to get the messages
out of input persistent store, figure out what to do with them, do some
transformations on the header (perhaps), figure out where to send them,
and pass them to the output MSH.  That function lives in the application
domain and is basically an application but with a very simple "BPSS" spec.

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.

MWS:  This is something like the blind men and the elephant.  Each of us
has a narrow (and different) view of what an IM is.

MWS:  This is why it is crucial to state the assumptions on what an IM
must do to support reliable messaging.

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.

MWS:  An IM that can lose track of the messages will not meet a multihop
reliable messaging spec. Again, we need to state the requirements on an
intermediary. At leeast: "An intermediary MUST provide reliable store and
forward of
messages"

MWS:  I suppose that we could attempt to define an MSH bridge but I doubt
that it would meet many people's requirements for an intermediary.

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.

MWS:  IMHO, anything that takes a message out of a persistent store and
does something with it is in the application domain.  You
can't argue that the intermediary consists solely of two MSHs sharing
a persistent store.  The From MSH has to get information from above in
addition to the message, i.e. whatever information the MSH expects to
receive across its undefined API.  "Above" may (will?) also have to modify
the
message header information before passing it to the From MSH.

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.

MWS:  Again:  We don't want to design the intermediary function but
we do have to state
a requirement on what the intermediary must do to conform to
reliable messaging.

-- Dan