W3C home > Mailing lists > Public > www-ws-arch@w3.org > December 2002

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

From: David Orchard <dorchard@bea.com>
Date: Fri, 6 Dec 2002 15:44:15 -0800
To: "'Newcomer, Eric'" <Eric.Newcomer@iona.com>, "'Baker, Mark'" <distobj@acm.org>
Cc: <www-ws-arch@w3.org>
Message-ID: <020e01c29d99$f2d68f60$d11f11ac@beasys.com>
Thanks Eric.  I completely agree with the dissocation of ack from synchrony.
I, nor anybody in my company, has any idea what it means, or the utility
therein, to "ack" a synchronous procedure call.  Particularly under server
failure.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Newcomer, Eric
> Sent: Friday, December 06, 2002 12:36 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 believe what Dave is referring to (an ack) would allow 
> application level reliability protocols to be built, and I 
> support his proposal to start with it.
> 
> As a sort of aside, a lot of the Web services discussions 
> remind me both of the early days of integration (when 
> everything was a file get, put, update, or delete, and the 
> application was expected to interpret all the data in the 
> file) and of issues related to asynchronous message queueing. 
>  In this latter category the simple ack is very valuable, and 
> I hope we're not getting sidetracked thinking about reliable 
> messaging for RPCs ;-)
> 
> Eric
> 
> -----Original Message-----
> From: Baker, Mark 
> Sent: Thursday, December 05, 2002 1:52 PM
> 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 21:41:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:11 GMT