RE: Proposed text on reliability in the web services architecture

What if we drop the nack. If the message can be delivered to the application
then the gateway would send an ack.

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.

arkin

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Miles Sabin
> Sent: Tuesday, January 21, 2003 10:02 AM
> To: www-ws-arch@w3.org
> Subject: Re: Proposed text on reliability in the web services
> architecture
>
>
>
> Peter Furniss wrote,
> > The cure, as Miles says, is to get the assurance of processing from
> > the processor, not from the intermediary.
>
> Agreed.
>
> But the crux of my mail was that an endpoint WS node might effectively
> be an intermediary if it's acting as a gateway to a non-WS "legacy"
> system. These kinds of adapters are surely very common, and likely to
> stay that way for the foreseeable future.
>
> The problem is that arranging for those backend systems to signal a
> failure back to the gateway, so the later can provide a nack back as
> part of a WS reliable messaging protocol, might be difficult or
> impossible. So if the gateway sends an ack back to the sender it could
> be misreporting a failure as a success ... hence the connection with
> byzantine failures.
>
> I think the right think to do here is to allow a node a "can't say"
> option in addition to ack and nack, and probably allow the sender to
> require an ack or a nack (ie. if a gateway node can't guarantee either
> it should return a fault).
>
> Cheers,
>
>
> Miles

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