Re: Proposed text on reliability in the web services architecture

Hao He wrote:
> I think Walden has made a good point. We don't really care about RM, which
> itself has been solved in the TCP/IP layer or other messaging layer already.
> The whole RM thing is misleading within Web Services context. What we really
> care is a reliable way of coordinating a client and its server, although RM
> might be helpful.

I think we need to care about RM. One of the key points made in 
Waldo et al's paper is that you need to think about relibility 
(partial failure) at the /application/ level. You can also interpret 
Deutsch's 'the network is not reliable' assumption is this manner.

Handing this responsibility off to a transport is an antipattern, 
one which I'm seeing increasingly often (maybe it's an Irish thing). 
The exception to this is that you know reliable delivery semantics 
aren't an issue for your app, but imo partial failure is always 
lying around to bite you.

Some observations:

  -TCP/IP is reliable across one connection. Sometimes we need 
reliability across a number of connections.

- HTTP runs on top of TCP/IP. HTTP is not a reliable protocol, 
that's fine for HTTP, but it should tell us something about making 
application level assumptions about transports.

  - RM isn't standardized at the level of protocol like HTTP. This 
is the reason people can and do successfully argue for end to end 
vendor homegeneity in messaging systems (BizTalk, MQSeries). JMS as 
a standard programming API doesn't help any.


> Making an operation idempotent seems to be a simple and effective solution.
> What we need to distinguish
> is the difference between logical operations and physical operations.

I think we need to distinguish between RM and ACID.

Bill de hÓra

Received on Thursday, 16 January 2003 06:42:40 UTC