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

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.

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.

Cheers,


Miles

Received on Tuesday, 21 January 2003 15:39:30 UTC