RE: Reliable messaging; solution or requirement?

Mark

What you are suggesting sounds awfully like two-phase commit, where you can
be sure that the state of information at the sender and receiver is known
consistent and there is a roll-back procedure that is used when delivery
fails.

Although this is valid and a useful case, it often does not work since it
might not be possible to completely reverse the state, for example at the
receiver, since the message has been processed.

Reliable Messaging on the other hand is much more analogus to the service
provided by the likes of FedEx and UPS who put in place the receipt and
tracking proccesses required to make sure that a message is almost always
delivered and a notification is sent back to the sender if it is not.

I think there is a "requirement" for both and that they are distinct.

David

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Wednesday, July 10, 2002 1:57 PM
To: Joseph Hui
Cc: www-ws-arch@w3.org
Subject: Reliable messaging; solution or requirement?



On Wed, Jul 10, 2002 at 01:22:36PM -0700, Joseph Hui wrote:
> There's a chasm between our understandings in what constitutes
> a specific solution (based on our previous few message exchanges),

Let's see if I can capture the two positions.

You (and others) appear to believe that unreliable messaging is a
problem requiring a solution.

My belief is that the problem is "reliable coordination".  That is,
how do two pieces of software distributed on an unreliable network,
coordinate to achieve some goal in a reliable manner (such that both
know that the goal has been achieved or failed, etc..)?  So I see
"reliable messaging" as just one possible solution to that problem.

Does that help?

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Wednesday, 10 July 2002 18:25:41 UTC