[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] RE: [ebxml-msg] Comments on ebMS_v1.04c
Date: Mon, 15 Oct 2001 15:34:48 -0500 From: David Fischer <david@drummondgroup.com> Reliable Messaging has to do with retries/acks, not with duplicate elimination. While we can define the term "reliable messaging" to mean whatever we want it to mean, I think it would be rather weird to use the name "reliable messaging" for a facility that sometimes delivers duplicates. It seems to me that "reliable messaging" should mean, at the very least, that a message is delivered "once and only once". RM could actually work w/o duplicate elimination -- but who would want to do this? I don't think there's any such thing as "reliable message without duplicate elimination". But retry/ack without duplicate elimination is meaningful. In the computer science literature it's known as "at least once" semantics. It's useful in cases where -- not getting the message at all is BAD -- getting the message more than once is OK If the service being provided is both inexpensive and idempotent, "at least once" does a good job. Why not just always use "once and only once"? Because duplicate elimination costs something, and there's no reason to pay that cost if you don't need it. For example, party A wants to keep party B up-to-date about how many washing machines party A has in his inventory. So whenever party A's inventory level of washing machines changes from X to Y, he sends party B a message saying "I now have Y washing machines". If the message gets through more than once, nothing is harmed. It simply becomes a matter of performance: if B's cost to process such a message is low compared with the cost of duplicate elimination in the message layer, then "at least once" performs better overall than "once and only once". -- Dan
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC