- From: Mark Baker <distobj@acm.org>
- Date: Wed, 19 Feb 2003 10:22:11 -0500
- To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
- Cc: www-ws-arch@w3.org
On Wed, Feb 19, 2003 at 09:28:13AM -0500, Champion, Mike wrote: > > This is so meta. 8-) > > I don't think so. I was just referring to the fact that we're talking about a trout pond. 8-) > This is the essence of the SOA "vs" REST debate that has > gone on for more that a year. I've been at it for about five years! > > How about this; > > > > DELETE http://example.org/pond/trout/?status=dead > > Uhh, there's an impedance mismatch between the physical trout pond and the > Web representation of it. That DELETE request will surely time out in the > time it takes Joe to scoop out the dead fish! In this particular case, it > probably DOES make more sense to model the interaction between the "Trout > Pond Manager Client" and the physical trout pond via requests to perform an > action ("methods") rather than exchanging state representations. DELETE just means "remove all representations". It's not an attempt to actually delete the resource, which could be something physical as you say. I know, poor name. "FLUSH" or "CLEAR" would have been better. > > But before anybody jumps on that with "Aha! Web services are > > for those cases!", I'd point out that it's very uncommon to > > find such an action in practice. > > I beg to differ. You've been on the Web too long, son :-) Indeed. 8-) It's all that experience that lead me to this conclusion. > Bottom line: at least SOME (a large class of interesting examples!) Web > services use cases involve "services" that are performed out in the real > world. It is probably possible to model all these RESTfully, e.g. instead > of DELETEing the virtual dead fish PUT-ing the state of the trout pond to > "CleanupInProgress" and Joe will set it to "Clean" when he's done. (Not > sure whether we need a God to set it to "Unclean" when the next fish dies or > what). But I've seen no plausible argument that "CleanTroutPond(Joe)" is > not a good way to model this class of problems. It's that a priori issue again; that the REST approach works in the context of an already deployed coordination language, while typical Web services construct per-service coordination languages. Coordination languages are *extremely* expensive to deploy (and extremely difficult to design, for that matter). That's why, during a typical day, I use perhaps three of them (HTTP, SMTP, POP). Web services suggests that we'll have a new one for each service I might want to use. For example, here's a coordination language for coordinating the sending and receiving of faxes; http://www.interfax.cc/webservice/dfs.asmx?WSDL and here's one for doing public key operations; http://ntg.webs.innerhost.com/RSAFunctions/RSAFuncs.asmx?WSDL and here's one for sending and managing SMS messages; http://www.abctext.com/webservices/SMS.asmx?WSDL You get the idea ... Anyhow, I've got a fair bit of empirical evidence backing me up on these claims. In all my time studying successful Internet scale systems, I've yet to see one that wasn't built around a single, general coordination language. To suggest that there's no important difference in the ability for coordination language based systems, and non-coordination language based systems to be deployed on the Internet, flies in the face of this evidence. MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis
Received on Wednesday, 19 February 2003 10:19:19 UTC