RE: Proposed text on reliability in the web services architecture

> Assaf Arkin wrote,
> > 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.
>
> Agreed, completely.
>
> But the complication is: what counts as delivery? Does it mean delivery
> to the application? Or does it mean delivery to the last node that's
> participating in the RM protocol (the HTTP/SMTP server in my example)?
>
> If you count the HTTP/SMTP server as part of the application, then these
> two coincide of course. Unfortunately there's a lot of scope for
> confusion about whether they are or not (ie. exactly what the
> boundaries of the application are), and consequently potential for
> ambiguity about what reliable delivery actually amounts to.

That's a good question and I'm not sure I have a good solution, but let me
try something.

Let's assume you sign each message you send and you expect a signature back
from the receiver. Whoever identifies as the receiver (the ultimate target
of the message) can sign an ack and send it back signifying delivery. If the
gateway does this, then the gateway is the one you are talking to.

Whoever put the gateway there made a contract with you. 1) the gateway is
the ultimate receiver so you will accept its signature 2) the message is
acked if it can be delivered to the ultimate receiver (the gateway).

Back to your example. Let's say the gateway uses HTTP to fill a form, it
gets the message to a Servlet the Servlet invokes an EJB bean the EJB bean
makes a database call, the database is not connected. There are four places
where the chain can be broken preventing the message from being processed.

How far do you go? Do you want the RM to delve into the implementation of
the Web service and make sure all its components are working?

If you are looking at it from the perspective of WS RM than if the message
is delivered to the WS, the message is delivered. What happens afterwards
happens after delivery. It's not what the RM deals with. If the WS is the
gateway (and every WS has a gateway of sort) that is who you are talking to,
the one you deliver to, the one that acknowledges delivery.

There's a lot of things that can go wrong after the message gets delivered
to the WS, but by definition that happens after deliver so not a concern for
the RM.


> Ultimately, this is a problem without a solution ... reliable
> communication is an end to end property of the link between the
> ultimate applications at either end of the link, and if that can't be
> arranged then reliability along only part of the link doesn't really
> help.
>
> But all I think that implies is that a sender ought to be able to insist
> on RM and a gateway receiver ought to be able to decline if it can't
> provide it onwards.

That would cover just about every WS I know. Every WS I have seen is
componentized into the layer that accepts the message and the layer that
processes, and the layer that accepts can approve acceptance but can't
determine whether processing would occur.

But that's not a problem since RM is about delivery not processing, so if it
was delivered to the service the service must acknowledge. The service can't
say "I don't know if the message was delivered". If it got the message it
knows. It was delivered.

arkin

>
> Cheers,
>
>
> Miles

Received on Tuesday, 21 January 2003 15:18:15 UTC