W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2003

RE: Can anyone point us to information on WS-Reliability

From: Assaf Arkin <arkin@intalio.com>
Date: Thu, 9 Jan 2003 21:48:24 -0800
To: "Hao He" <Hao.He@thomson.com.au>, "Jeff Mischkinsky" <jeff.mischkinsky@oracle.com>, "Champion, Mike" <Mike.Champion@softwareag-usa.com>, <www-ws-arch@w3.org>
Message-ID: <IGEJLEPAJBPHKACOOKHNGEFADAAA.arkin@intalio.com>

> Just one comment on one part.
>
> 3.2.4 No clear why you would want an asynch ack if you are using a
> synchronous protocol, or how you could get synch ack when using an
> asynchronous protocol. From an implementation perspective, when
> would I want
> to use this operation?
>
> <hh>From our implementation experience, a synch ack always helps when you
> are using an asynchronous protocol.  It simplify greatly on coordinating
> between the client and the server. </hh>

Actually my question was about the element not the protocol.

The ack should be delivered upon receipt of the message, regardless of how
the message was delivered to the receiver. It should be delivered on the
protocol identified by the replyTo address. Let's say the replyTo points to
a service that has synchronous receipt of ack operation. You can only send
it using a synchronous protocol. But if it points to a service that has
asynchronous receipt of ack operation (e.g. SMTP) you can only send it usine
asychronous protocol.

If a message is sent synchronously (say using HTTP GET/PUT/POST/etc) then I
don't see a case where you would want the ack to be delivered any other way
that on the response message, or the benefit in doing so. If the message is
sent asynchronously then I don't think you could determine anything based on
how the ack is sent. You may experience less message loss for synchronous
reply, but can you factor that into the application?

arkin
Received on Friday, 10 January 2003 00:49:10 GMT

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