RE: "Reliable" web services for Next Big Thing? (was RE: Agenda for 5 December WSA telcon)

Agreed, but the decision to give up can be logged for human follow up to resolve the potentially inconsistent state of affairs...  One has to do this occaisionally following heuristic decisions taken when a 2PC participant never recives the reply from the coordinator notifying the decision result...  In other words, no mechanism is perfect or going to solve everything (actually three phase commit solves the uncertainty problem in 2PC but is too expensive to be practical), so let's at least start here, there seems to be some level of consensus around this by now.

Eric

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Thursday, December 05, 2002 3:53 PM
To: Baker, Mark; 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)



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 Friday, 6 December 2002 15:39:55 UTC