Web Services: It's So Crazy, It Just Might Not Work
by Clay Shirky
|
Pages: 1, 2, 3
Parseable != Interoperable
XML has been oversold as a kind of semantic pixie dust for creating interoperability. Sun says, in its ONE (Open Net Environment) white paper, that the
industry is clearly focusing in on the eXtensible Markup Language (XML) as the lingua franca to enable Web services...XML-based Web services communicate over standard Web protocols using XML interfaces and XML messages, which any application can interpret. Hence, all XML-based Web services can interoperate -- at least in theory.
Even with the "in theory" caveat, this goes too far. XML is not only not a lingua franca, it isn't even a lingua.
|
Related Reading Programming Web Services with XML-RPC |
As an analogy, take English and Danish. They have almost identical alphabets but are nevertheless different languages. An alphabet is a limited set of characters that can represent an unlimited number of words through recombination. XML is an alphabet, not a language. It provides the primitives for describing larger concepts, and it works by allowing an unlimited number of semantic concepts to be encoded using those primitives. Any XML parser should be able to declare any given XML document structurally valid -- analogously to the way native speakers can tell if a word is or isn't part of their native tongue -- but that says nothing about whether the contents of that document will be comprehensible to the recipient.
At best, XML makes it possible for businesses or developer groups to share data, provided they agree on the semantics of that data in advance. This is not to say XML is not an enormous advance. It plainly is. However, its advance lies in aiding data interoperability where shared semantics can be assumed. It does nothing at all to create semantic interoperability.
WSDL and UDDI: It's Turtles All the Way Up
To answer XML's inability to produce shared semantics between unknown parties, the Web Services world has begun to define a stack built on top of XML, in an attempt to bootstrap coordination. The first layer to take on the problem of automated interoperability is the Web Services Description Language, which provides a way to describe the simple aspects of a web service such as data types, operations supported by the service, bindings, and so on.
WSDL lets a provider describe a service in XML. But even that doesn't solve the problem, since a provider can't describe critical business aspects of their services, such as price or contractual requirements. Furthermore, to get a particular provider's WSDL document, you must know where to find them. Enter another layer in the stack, Universal Description, Discovery, and Integration (UDDI), which is meant to aggregate WSDL documents. But UDDI does nothing more than register existing capabilities; it doesn't actually create shared semantics either. As the UDDI technical white paper says,
The ability to locate parties that can provide a specific product or service at a given price or within a specific geographic boundary in a given timeframe is not directly covered by the UDDI specifications. These kinds of advanced discovery features require further collaboration and design work between buyer and sellers.
Even after using XML to create a description in WSDL and registering it with UDDI, two arbitrary entities still can't achieve automatic interoperability because there is no guarantee that an entity looking for a Web Service will be able to specify its needs clearly enough that its inquiry will match the descriptions in the UDDI database.
Even the UDDI layer does not ensure that the two parties are in sync. Shared context has to come from somewhere, it can't simply be defined into existence.
Its Windy, Ain't It? No, Its Thursday.
UDDI has proposed solution, yet another set of layers, optimistically entitled the Universal Service Interop Protocols, though, as they dryly note on their Web Services stack diagram, "these layers are not defined yet."
This attempt to define the problem at successively higher layers is doomed to fail because it's turtles all the way up: there will always be another layer above whatever can be described, a layer which contains the ambiguity of two-party communication that can never be entirely defined away.
No matter how carefully a language is described, the range of askable questions and offerable answers make it impossible to create an ontology that's at once rich enough to express even a large subset of possible interests while also being restricted enough to ensure interoperability between any two arbitrary parties.
The sad fact is that communicating anything more complicated than inches-to-millimeters, in a data space less fixed than stock quotes, will require AI of the sort that's been 10 years away for the past 50 years.
Without AI, the description and discovery of Web Services is going to require a great deal of good old fashioned human intelligence. And whenever humans get involved, things get sticky.
