[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