RE: Proposed text on reliability in the web services architecture

> 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".

Actually not what I ment, but without the example I didn't really understand
what you ment. But I think there's a subtler issue here.

Let's say that the problem you describe goes away. The message is always
successfully delivered to the application. However, the application try as
it may cannot process it. So you're still at square one: you know it was
delivered, but not that it was processed.

That's the scope of RM. RM is about delivery not processing. When you start
worrying about whether the message was processed or not you need to look at
higher levels of coordination. The RM simply says that an ack means
delivery.

So in your case if the gateway can guarantee that it will deliver the
message to the application, in spite of failure that may cause the gateway
to crash (e.g. by persisting the message), then it provides RM. It can't
force the application to actually accept and process the message.

The issue is different for an intermediary. Let's say an intermediary
receives a message, persists it and then sends an ack. The intermediary
indicates that it guarantees delivery. Let's say that the message expires in
two hours and the recepient is down for four hours. The intermediary is
lying.

So the intermediary should never return an ack directly to the application
at the other end, but it could return an intermediary ack to the sender
indicating successful delivery in part of the path to the destination.

And you can check whether the ack is coming from the intermediary or the end
application by using signatures.

arkin

>
> > 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:46:56 UTC