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

Re: Proposed text on reliability in the web services architecture

From: Miles Sabin <miles@milessabin.com>
Date: Tue, 21 Jan 2003 18:31:56 +0000
To: www-ws-arch@w3.org
Message-Id: <200301211831.56294.miles@milessabin.com>

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.


Received on Tuesday, 21 January 2003 13:32:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:02 UTC