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


The word Ubiquitous comes to mind.  MQseries (and I assume HTTP/R) work because
they are ubiquitous -- they control every hop and every node with appropriate
queues.  We do not.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Wednesday, August 29, 2001 10:19 AM
To: david@drummondgroup.com; john_ibbotson@uk.ibm.com
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]

or

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

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

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