Web Services: It's So Crazy, It Just Might Not Work
by Clay ShirkyOctober 03, 2001
That high-pitched sound you hear is the Web Services hype machine revving up, as words like "revolution' and "paradigm" begin making their regularly scheduled appearance in the press and white papers, where we are promised a Shiny New World of on-the-fly software creation.
The hype is happening just as practical applications for XML-structured data beginning to appear. Web Services can reduce the effort and quicken the process of creating standards between developers or businesses which want to work together, an important if somewhat modest improvement in the Internet's plumbing.
Unfortunately, though, Web Services are being sold not only as improved plumbing but also as a way to create fantastic new software, seamlessly and automatically connecting any two business processes or applications anywhere on the network as if by magic.
|
Table of Contents XML: Parseability != Interoperability WSDL and UDDI: Its Turtles All the Way Up Its Windy, Ain't It? No, Its Thursday |
A bit too much as-if-by-magic, in fact, because against the backdrop of inflated claims for automatic interoperability is the usual set of mundane but intractable problems that plague any grand vision. While these problems are complex and various, their essence can be summed up fairly simply:
Two old men were walking down the street one day, when the first remarked to the second, "Windy, ain't it?"
"No," the second man replied, "It's Thursday."
"Come to think of it," the first man replied, "I am too. Lets get a coke."
If two parties are out of sync, communication can seem to be happening, without much really getting communicated. To see in more detail why the idea of automatic interoperability is (much) harder than it first appears, it helps to look at the examples of public Web Services being offered as proof of concept.
Hello, WRLD
Automated stock price retrieval is the the standard Web Service -- it is simple, obvious, and valuable, and almost every description of Web Services uses it as an example. It is not, however, representative of any real-world challenges.
Stock prices exist in an extremely constrained world: there is a canonical list of company-to-ticker-symbol mappings, the types of data that can be derived from these ticker symbols are both narrow and well understood, and it is illegal to tamper with the data.
The stock quote example, in other words, illustrates Web Service technology without solving a single problem of shared context, because all the coordination has been established in advance. The connections between company names, ticker symbols, and stock prices were worked out not just prior to Web Services, but prior to the Web, the Internet, and even computers.
Financial data is a lousy proof of concept; networking examples using financial data are almost always successful, even on networks with otherwise poor technological characteristics, e.g. WAP.
Without the shill of financial data, the Web Service examples start to look a little thin. A scan of XMethods.com, which lists existing public Web Services, reveals that most of the entries either rely on services where the terms are already well understood by all parties -- lease calculators, flight information, converting Fahrenheit to Celsius or inches to millimeters -- or places where the data is already publicly available on the Web but the interface can be automated -- address lookups, eBay auctions, Amazon book ranks.
If these are proof-of-concept implementations, what concepts are they proving? Take the inches-to-millimeters example; who would willingly incur the overhead and latency of a remote HTTP call when they could simply multiply inches by 25.4 to get millimeters? These sample services illustrate that it's difficult to create a web service that doesn't rely on both the client and the server understanding the terms of the transaction in advance.
No Bootstrapping Coordination
 |
|
Clay Shirky will deliver his keynote, "The Great Re-Wiring," at the O'Reilly P2P & Web Services Conference. |
Hideous hype, or an important advance? Share your view on web services in our forum. |
| Post your comments |
The problem these examples sidestep is shared context. How can you create interoperability among two parties who've never interacted with one another before? Without defining in advance what language they will use to communicate?
And the answer of course is "you can't," unless you're willing to limit yourself to applications like inch-to-millimeter conversions, where the units involved are so trivial and so universally defined as to present no real problems of interoperability in the first place. Any coordination problem worth solving does not have a solution that can be completely specified in advance.
The vision of Web Services as a framework for automated interactions suffers from these coordination issues at several different points.
- XML only eases interoperability, it doesn't create it
- The current Web Services stack simply moves the problem to higher and higher layers
- As long as there are humans involved, there will be context errors, both intentional and unintentional
