Re: Proposed text on reliability in the web services architecture

>  Recall that the SOAP and WSA attempt to be protocol-neutral. There is no
> assumption that RM *is* atop a TCP connection; there may be different
> protocols, there may be unreliable intermediary processes, there may be
> caches that expire and authentications that fail and transactions that are
> rolled back and on and on and on.  Clearly by making enough assumptions or
> adding enough constraints we could come up with a scenario where RM is
> pointless.  We can also come up with plenty in where it is useful.   

Also, a reliable transport layer is no guarantee of a reliable 
application layer. Walden's concerns about simplicity 
notwithstanding, outsourcing applciation layer reliablity to the 
transport is imo an antipattern.


> Again, it would be much more useful to identify alternative scenarios and
> assess their architectural strengths and weaknesses than to propose one's
> favorite scenario and argue that the others aren't strictly necessary, or to
> argue that its' upsides outweigh its downsides, etc.  Deep down in this
> thread there is a lot of good stuff, but it's really hard for the editors to
> mine it out.

If you're serious about this, I'd suggest starting with defining a 
comms model (ie, sender, senderBuffer, channel, receiver, 
receiverBuffer) rather than working from usecases (they can come 
later). With that model agreed upon, it can be determined 1) what 
level of reliability is acheivable - for example if the model is 
pure client/server, that affects what claims you can make for RM and 
2) what is out of scope - for example you'll probably want to have 
something to say about Byzantine/arbitrary failure cases.

Bill de hÓra

Received on Tuesday, 21 January 2003 05:33:57 UTC