Re: T2 - Assertions and Questions

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

Comments below.

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

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 08/14/2001 05:51:53 PM

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

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   dsmiley@mercator.com, ebxml-msg@lists.oasis-open.org
Subject:  Re: T2 - Assertions and Questions



   Date: Tue, 14 Aug 2001 17:08:00 -0400
   From: Martin W Sachs <mwsachs@us.ibm.com>

   In David S.'s "chasm model", from the point of view of the Message
   Service protocol, the "To Party" is implemented by two computers, C
   and Y.  The boundaries between C and Y, and the way they divide their
   responsibilities, are modularly hidden from the Message Service level
   of abstraction.

   MWS:  Not really hidden since between C and Y, there is another
   Message Service level of abstraction.

Sorry, let me try that again.  There are two layers of abstraction
going on here, very much the way TCP and IP are two layers of
abstraction.  There's a higher-level protocol that the From Party and
To Party are using to talk to each other.  Then there's some
lower-level protocol being used within the internal components of the
To Party (namely C and Y).  From the viewpoint of the higher-level
protocol (or, from the viewpoint of the From Party which is talking
the higher-level protocol), the lower-level protocol being used by the
components of the To Party (and the fact that the To Party even has
more than one "component") is hidden (you could change the lower-level
protocol, you could chuck out C entirely, and the From Party would
experience exactly the same thing).  That's what I mean by "hidden".

MWS:  I think that the argument here is over the meaning of "higher"
and "lower".  In a model in which the message exchange is between X and
Y and part of it happens to be performed by something going on between
C and Y, I would agree that what goes on between C and Y is lower level,
though it might actually be ebXML messaging under the ebXML messaging
between X and Y.  In your model, in which the messaging is between X
and C and then between C and Y, the protocol between C and Y is really
at the same level of a communications stack and technically might be
a higher level of abstraction (e.g. MQ) or a lower level of abstraction
(e.g. bare IP, to take an extreme case).

                           Of course the connection between
   C and Y may or may not be ebXML but if it isn't ebXML, it must have
   reliability equivalent to ebXML RM or better.

Agreed.

   MWS:  Sure, but if American Express doesn't guarantee to process the
   request, it will see far too many suits.  The point is that unless the
   C-Y implementation(s) can guarantee that it will processes all messages
   for it that are received by C, including under conditions of C or Y node
   failure and recovery, it fails in its duty.

Agreed.

   MWS:  (sorry for the repetition):  For any RM model involving
   intermediaries
   passing the message along, the ebXML MSG spec will be derelict in its
   duties if it doesn't clearly explain what the intermediaries must to
   do ensure that they don't spoil the reliability (e.g. recovery from
   failures must include processing any reliable messages that remained
   in the persistent store when the node went down).

Um, well, yes and no.  I'm afraid that either I'm being unclear or
that we're somehow talking past each other, and I don't want to be
pedantic or anything, but I do think this point is rather important so
let me make one more try:

The idea is to avoid having an "RM model involving intermediaries" at
all.  The goal of the modular separation between the two levels is to
make it so that the MSG spec doesn't even have to *mention* the
concept of "intermediaries" as entities that the spec deals with.  The
MSG spec will certainly have to make it clear that if a Party
advertises (CPP) that it accepts ebXML MSG reliable messaging at some
Endpoint, then it absolutely must commit that it will get the message
to its intended destination.

MWS:  I think this is OK as long as the spec really does make the above
point.  I do believe that in this model, there had better be a BPSS
instance document that describes what Party C does with the messages.

Actually, if we want to be formal about this, we should come out and
say more about our actual assumptions about what kind of failures we
intend to tolerate.  Obviously we cannot guarantee reliable messaging
in the face of arbitrary undetected, Byzantine failures.  For example,
if a message is spontaneously and undetectably erased from a
persistent queue, there's nothing we can do about it.  Or if our
database system claims to have committed data to disk but actually has
a bug such that it didn't store the data, there's nothing we can do
about that, either.  Or if our CPU sometimes spontaneously jumps to a
random address, so that it executes algorithms different from the ones
we programmed, we're similarly up the creek.

MWS: I completely agree that we have to be more explicit about the
assumptions.  One is that the persistent store is really persistent.
Another is that if a CPU is flaky, it doesn't affect the persistent
store.  However, I suspect that these are really implicit.  The important
statements that have to be made are, for example, about assumptions
that the intermediate
nodes and the To node will recover from failures and not lose messages
in the persistent store.

There is a certain set of failures that we are robust against, such as
fail-stop processors (that may halt at any time, losing all volatile
memory), networks that drop or duplicate or reorder messages, and so
on.  So, in the "chasm model", we'd want to state that however the
lower-level protocol works, it should be resilient against this *same*
set of failure modes, so that it is, as you say, *as reliable* as
ebXML MSG reliable messaging.

MWS:  Sounds good to me.

-- Dan