OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: reliable messaging - hop by hop

Some 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/29/2001 11:19:07 AM

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

To:   david@drummondgroup.com, John Ibbotson/UK/IBM@IBMGB
cc:   ebxml-msg@lists.oasis-open.org
Subject:  Re: reliable messaging - hop by hop

It seems to me that there is still some disagreement about exactly
what is meant by "reliable messaging".  It can mean either:

(1) If I sent a message reliably, then even in the face of certain
(enumerated and well-specified) failure modes, the message will
eventually get delivered to its final destination [1]


(2) If I sent a message reliably, I will get a positive
acknowledgement from the final destination saying that
the message was received.

(1) can be accomplished in a hop-to-hop fashion, whereas whether (2)
can or not depends on the set of failure modes.  My impression is that
MQSeries and HTTPR are both assuming a certain degree of trust in the
reliability intermediaries, whereas some conversations on this mailing
list have basically assumed that our set of failure modes must include
total distrust of intermediaries, i.e. an intermediary might just drop
a message at any time.  I think that in order to resolve the debates
about hop-to-hop, we have to be clear about whether our set of failure
modes includes total failure of intermediaries.

MWS:  In the HTTPR spec it doesn't just assume; it
states an assumption that intermediaries
store and forward reliably.  This is crucial to understanding how
the hop by hop reliability can work.  Without such a statement in
the MSG spec, it is necessary to not trust the intermediaries. That's
why (I agree) we must be clear about stating assumptions on how the
endpoints and intermediaries are designed.  We don't want to do the
design but we must say things like "this assumes that the intermediaries
store and forward reliably".

My impression from looking at the HTTPR spec is that it does not
actually address (2) in a multi-hop environment; is that right?

MWS:  I am still reading HTTPR.  If anyone knows the answer, please post

-- Dan

[1] Better, all reliable messages should have a time-to-live, and the
guarantee should be that either the message be delivered to its final
destination before expiration, or else it will not be delivered (or
that the original sender is reliably informed that the message was not
sent).  The time-to-live is really essential anyway, for duplicate
elimination purposes, as discussed earlier.

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC