- From: Miles Sabin <miles@milessabin.com>
- Date: Tue, 21 Jan 2003 18:31:56 +0000
- To: www-ws-arch@w3.org
Assaf Arkin wrote, > What if we drop the nack. If the message can be delivered to the > application then the gateway would send an ack. Sure ... but then you've subtly changed the nature of the protocol. An ack would now only mean "the message was successfully delivered to the last node participating in the RM protocol" rather than "the message was successfully delivered to the application". > Of course the application may not be able to process it (at any point > in time) and may fail to indicate so. The gateway would be > responsible to somehow extract the result of the processing and > determine which applicable message to send back (which WSDL operation > to perform against the original sender). This could be modeled by a > choreography, or if it implies transaction rollback, done through the > coordination protocol. Right, but this could be hard or impossible in some cases. Here's an ugly example. Someone puts a shiny new WS front-end on a crufty legacy HTML form-based or EDI mail based application. The gateway node forward the message via an HTTP POST or via SMTP, but the message only gets as far as the HTTP/SMTP server and never reaches the application. As far as the gateway is concerned the message has been delivered so it responds to the sender with an ack when in fact there's been a failure. Your fix, effectively extending RM through an existing HTTP/SMTP server to a legacy application, might simply not be a viable option. In this kind of situation I think a gateway node should be allowed to refuse to participate in RM on the grounds that it can't provide the expected guarantees. Cheers, Miles
Received on Tuesday, 21 January 2003 13:32:28 UTC