Re: T2 - Assertions and Questions

[Dan Weinreb <dlw@exceloncorp.com>]

   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".

					  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.

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.

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.

-- Dan