- 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>
> 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 UTC