Sam Ruby and Jeffrey P Shell, in separate items ( 1, 2), raise questions about how easy the exportation of web services can or should be.
Sam cites an article by David Bau which notes that auto-generation of WSDL may promote brittleness. The reason is that automatically mapping classes to exported services fails to separate interface from implementation. "One of the goals of Web services technology," writes Bau, "is to break the gridlock of tight coupling by providing tools to simplify, clarify, and rationalize the information flow between systems." I suspect such tools will be hard to come by. Meanwhile, it's certainly true that vendors who tout features like WSDL auto-generation are overstating the case. The classes you'll want to annotate for such treatment should, in many cases, be abstractions of those that implement behavior. Creating such abstractions is, of course, more work -- and the kind of work that doesn't easily yield to automation.
Jeffrey P Shell, meanwhile, discusses the tradeoffs between Zope, which in effect publishes everything to the web, and Radio, which externalizes only that which passes through a services wrapper (i.e., scripts in the "/web services" directory). Writes Jeffrey:
The way that Radio seems to promote for Web Services is easy. And simple. But you're effectively writing scripted adapters and bridges into other code, something that could turn out to be a maintenance nightmare. The way that Zope has promoted for years (even though it's not a terrific Web Services player, sadly) says that "Objects and their methods are already published on the web. No gateway scripts needed.", but with that comes the price of maintaining security declarations similar to C#.NET's ASPX's declarative Web Service calls.
Both articles remind me that overhead and complexity are subtle issues. I don't think there is One Right Way. During a bootstrapping phase, a certain amount of tight coupling may be necessary to push things over the activation threshold. Will brittleness result later? Yes, but it's easier to make a popular-but-brittle system more flexible, than to make an unpopular-but-flexible system more popular.
Former URL: http://weblog.infoworld.com/udell/2002/05/06.html#a216