- From: Burdett, David <david.burdett@commerceone.com>
- Date: Thu, 5 Dec 2002 12:53:16 -0800
- To: "'Mark Baker'" <distobj@acm.org>, David Orchard <dorchard@bea.com>
- Cc: www-ws-arch@w3.org
I agree that simple acknowledgment protocol is useful as it is the basis of all RM protocols that I know of. RM really consists of three main components: 1. A method of sending an acknowledgement 2. A sender behavior which involves resending a message if an acknowledgment is not received 3. A recipient behavior which removes duplicate messages (if this is required) 4. A method of determining when to give up (i.e. your time out) 5. A method of notifying interested parties/software that the message was (probably) not delivered The problem with this is that, just after you have given up, you might receive the acknowledgement that indicates the message was received ... which is where it gets more complicated. David -----Original Message----- From: Mark Baker [mailto:distobj@acm.org] Sent: Thursday, December 05, 2002 10:52 AM To: David Orchard Cc: www-ws-arch@w3.org Subject: Re: "Reliable" web services for Next Big Thing? (was RE: Agenda for 5 December WSA telcon) On Thu, Dec 05, 2002 at 09:41:23AM -0800, David Orchard wrote: > I think that a simple acknowledgement protocol in soap headers would be very > useful and hit an 80/20 point. We've consistently heard from customers and > partners that reliable messaging is very important to them. I support the > discussion and architectural description of reliable messaging in this > forum. I agree that would be useful, but I think it's a long way from an 80/20 solution. > And saying that reliable messaging protocols don't make sense is akin to > saying that we don't need tcp as ip already exists. Maybe I wasn't clear. I'm for "reliable messaging protocols" if they're application layer extensions. I'm (generally) against them if they're transport protocols (like HTTPR). MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
Received on Thursday, 5 December 2002 15:53:10 UTC