RE: Proposed text on reliability in the web services architecture

> -----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 12:39 PM
> To: www-ws-arch@w3.org
> Subject: Re: Proposed text on reliability in the web services
> architecture
>
>
>
> Assaf Arkin wrote,
> > 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?
>
> Well, ultimately RM is only interesting insofar as it supports overall
> reliable operation.

But who defines and exposes that operation in your example?


> But pretty clearly "messaging" has to come to an end somewhere,
> conceptually at least. That point, whereever it is, would be the right
> place to terminate an RM protocol. Assuming that messaging stops at the
> HTTP server in your extension of my example, then it'd make sense to
> say that the message was delivered successfully but that the subsequent
> processing failed. Hopefully the application will have some way of
> reporting that failure ... but note that that wouldn't be a report of a
> messaging failure, it'd be a report of some other application-level
> failure.

Of course. But a lot more could go wrong in the application. It may grab the
message start processing and then fail. So you either way you need reliable
processing guarantee which means you have to deal with what happens after
the message gets delivered. And that is true even in a world with perfect
delivery.


> I think it's just fuzzy here, particularly wrt gateways. Looked at one
> way, once a message reaches a gateway it's reached the application.
> Looked at another equally legitimate way, the gateway is just a
> messaging intermediary.

I would think that the one that provides the service definition and the
end-point is the service. Anything on the way is an intermediary because it
can affect the message on its way to the service. Everything afterwards is,
as we like to say, implementation detail. Once it got to the service it got
to the service.

If you knew what happens after the gateway then that would be the service,
the gateway would be an intermediary and the gateway could lie but you won't
listen since not being the service it can't ack the message.


> Concretely, I think the arch doc should simply flag this potential
> fuzziness; note that it might be particularly problematic where
> gateways are involved; and recommend that gateways should either not
> support RM if they can't guarantee delivery to the application, or
> ensure that senders are aware that an RM ack only implies successful
> delivery to the gateway and not necessarily to the application.

Definitely.

Since this is another point of confusion, the arch document should clarify
that RM is about delivery to the service and what happens afterwards is not
visible in the operation definition and is therefore outside of scope. In
other words, if the service will perform the input operation then it should
ack.

arkin

>
> Cheers,
>
>
> Miles

Received on Tuesday, 21 January 2003 15:58:35 UTC