- From: Walden Mathews <waldenm@optonline.net>
- Date: Thu, 09 Jan 2003 22:04:06 -0500
- To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arch@w3.org
Mike, > > Network application developers who don't want to think about network > > failures should find a different line of work. The Waldo > > paper has been > > cited enough times already. > > Well, I've read the Waldo paper several times, most recently last week. > "Hiding the network" by trying to pretend that partial failures don't happen > (e.g., a write occurs but the network dies before the success code can be > propagated) is clearly a Bad Thing and leads to the problems of NFS that he > notes. Okay. > I'm merely asserting that there is a middle ground: that non-RPC Web > services that *do* have a rich notion of error notitification can be used in > a way that puts the bulk of the mechanical burden on the infrastructure > (e.g. WS-Reliability or WS-Transact) That confuses me some. I assume that by "non-RPC Web services" you mean applications, so their "error notification capability" must be at the application layer. What that has to do with WS-Reliability or WS-Transact I don't get. > and simply forces the application to > deal with indeterminate status codes, asynchronous notification of > success/failure, two-phase commit protocols, or whatever. Now I'm baffled, because those things sound like a pain in the arse, not a "good thing". > > Clearly Waldo has a lot to teach us, e.g. about the desirability of > designing systems so that updates are idempotent. I don't follow the > assertion that this doesn't require redesign from the ground up in systems > that weren't designed that way; that's the whole POINT of his NFS example, > no? Not sure about his example, but I believe we've established today that wrapping a legacy application is an easy and effective way to avoid a "ground up" redesign. If not, please advise. > > Anyway, as I said in the draft, a clear statement of how RESTful > applications can work well without assuming a reliable infrastructure, and > what are some of the principles of designing robust systems that handle > network failure gracefully (without necessarily assuming any particular > architectural style) would be much appreciated. As an open-ended task, that's a bear. Do we have a set of "reliability" use cases laying around as a starting place? If not, can we get some? > Just recall that many of > the use cases for Web services include the integration of applications that > CANNOT be redesigned. If you can debunk my mistaken assertions that REST > doesn't work for this use case, go for it. Addressed this above, but I'd like to hear from you where we stand on it. Walden
Received on Thursday, 9 January 2003 22:04:13 UTC