- From: Bill de hÓra <bill.dehora@propylon.com>
- Date: Tue, 21 Jan 2003 10:32:02 +0000
- To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
- CC: "'www-ws-arch@w3.org '" <www-ws-arch@w3.org>
> 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