Re: T2 - Assertions and Questions

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

Rejoinders 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 03:38:01 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 13:19:31 -0400
   From: Martin W Sachs <mwsachs@us.ibm.com>

   If X intends the message to go to Y but is not concerned with what
happens
   between C and Y, it either isn't reliable messaging.

MWS:  Let's restate your original statement thus:  X intends the message
to go to Y but sends it reliably to C, trusting C to forward the message
reliably to Y.  Yes, it's hop by hop reliable messaging.  As long as the
MSG spec states its assumption on what C will do to assure that it won't
lose the messages intended for Y, that's probably OK.  For example
(ignoring
arguments about what RFC2119 word to use):  C stores the incoming messages
in a persistent store;  when C recovers from any failure, it continues
processing the messages that remain in ints persistent store.

Well, I think I disagree (that it isn't reliable messaging), in the
context of the "chasm model".

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

As far as the Message Service protocol is concerned, it doesn't matter
whether C and Y are two CPU's of an SMP multiprocessor, or two nodes
of a shared-disk cluster, or two workstations on an Ethernet.  From the
point of view of MS, there is just one To Party.

If they are two CPUs on an SMP multiprocessor, they are really one
node from any viewpoint since in an SMP, the two CPUs are simply
dividing up the CPU load but not necessarily processing separate
independent tasks.  In any case, for all these possiblities, as I
noted above, there is still a committment to get the message reliably
to the Y software.

The CPP for the To Party contains a PartyInfo/Transport/Endpoint
element, in which the To Party asserts "this is the URI that I want
you to use to send stuff to me".  The To Party takes the responsibility
of selecting the URI, and it asserts that if the Message Service,
using its reliable messaging protocol, delivers the message to that
URI, then the To Party promises that it will process the message.

MWS:  OK.  I guess I said that above in this level of comment.

Here's an analogy.  Suppose I want to cancel my American Express card,
and so I send a letter through the U.S. Postal Service, using their
"delivery confirmation" feature
(http://www.usps.com/shipping/deliver.htm).  I address it to whatever
address American Express tells me that I should send such things to; I
just look at my latest bill and there's this address on it.  Now, for
all I know, the address is some generic company in the midwest that
receives mail for lots of different companies and forwards it.  Or
maybe that address is Amex's central North American corporate
mailroom, which will receive my mail and dynamically figure out which
Amex employee (George Foobar) ought to handle my request, and forward
it to him, perhaps indirectly through some other route.  So there are
all kinds of "intermediaries" happening here, entirely invisible to
me.  Months later, it turns out Amex hasn't cancelled my card, which
has caused me to lose money for some reason, so I sue them, and I want
to present evidence in court that I really did ask them to cancel my
card and they really did receive my mail.  I present my "delivery
confirmation".  Does the judge say "Oh, that delivery confirmation
doesn't mean anything at all, because it's not an end-to-end
confirmation from George Foobar himself"?  I don't think so.  From a
business point of view, my letter was reliably delivered to the To
Party, namely American Express Corp.  What happens to it from that
point on is not part of the protocol.

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.

The main drawback (in a sense) to the "chasm model" is that it takes
the position that the protocol doesn't deal with a concept of
"intermediaries" at all.

Consider Chris F.'s use case, there's an intermittently connected SME
(what does SME stand for?) that "uses an intermediary as a way
station".  In the "chasm model", the SME and the way station would be
considered part of a single From Party, and the communication between
the two of them would *not be specified* by the Message Service
protocol.  In the "chasm model", the Message Service protocol
relinquishes responsibility for that kind of communication: it's the
job of some lower-level protocol that is not specified.

MWS:  As long as the chasm guarantees that it won't lose things sent
into the chasm, that's fine.  Again, this requires a clear statement
of the responsibilities that the intermediaries must fulfill in order
to provide reliable messaging to the To and From parties.

So the "chasm model" implies either that the ebXML standard just
doesn't standardize or specify how that kind of communication works,
or else that ebXML needs to specify a new protocol, at a lower level
than Message Services, that would govern this kind of communication.

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

(David S., if I'm not representing your ideas accurately, I apologize
and please correct me.)

Is this making any sense?

-- Dan

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org