Web Services: It's So Crazy, It Just Might Not Work
by Clay Shirky
October 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.
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
[1] [2] [3] Next