All That is Solid Melts Into Air
March 6, 2002
The computer industry, or at least the marketing arms of its largest corporations, tends to float along on waves of hype, from buzzword island to buzzword island, like an itchy junkie in search of the next fix and the next. Everyone in the industry, from pundits to CEOs to analysts to, especially, developers and engineers, decries the hype, the jittery use of buzzwords, the thinking-by-acronym; but, like every other kind of addiction, the desire to hype is unrelenting. The only time it changes is to become more clamorous, more frantic.
One of the newest, most faddish drugs is "Web Services", which most of the largest corporations in the industry, including IBM, Microsoft, and Sun, are pushing vigorously. Breathless marketeers are calling "Web Services" the next "Web revolution", piling high the myths and overblown expectations. And yet, as is too often the case, it's not entirely clear what Web Services is... or are -- the indecision seems to go all the way down to the grammar: is "Web Services" one thing, an "architectural vision", perhaps, or is it a lot of disparate or related things?
Despite the confusing hype, it seems clear that, whatever else Web Services may or may not be, HTTP, SOAP, and XML will be centrally important to building Web Service applications. A Web Service application includes some form of intermachine communication facilitated by HTTP, SOAP, and XML. A pretty large cross-section of the industry sees XML, SOAP, and HTTP as the way forward.
Or does it? XML-DEV has seen lots of long, detailed conversations about the various infelicities and inadequacies of SOAP. Just when it seemed that something solid -- whether it's reasonable or smart is another question -- about Web Services had emerged, the XML-DEV mailing list, and the developer community it represents, resumed long-running conversations in which the nature and long term viability of HTTP and XML were questioned -- sparked this time, respectively, by comments from a Microsoft evangelist and a well-respected XML developer.
HTTP Isn't Here to Stay?
Don Box, who's a regular contributor on XML-DEV, gave a keynote address at European DevWeek in which he said, as reported by ZDNet UK News, that one of the "big challenges facing Web Services is our reliance on HTTP." Box further suggested that HTTP's statelessness, asymmetry, and RPC nature were among its problems from the perspective of Web Service and peer-to-peer applications.
Paul Prescod answered Box's criticisms of HTTP. As to the question of HTTP's asymmetry, Prescod said that "[a]ll protocols are asymmetric. Somebody initiates the connection. Someone else is listening. The question is whether they can change [roles]". And, according to Prescod, the responder and requester can change roles in HTTP. "You simply put," Prescod claims, "a client implementation and a server implementation in one box...". As to its statelessness, Prescod said that "[y]ou simply register a callback and are informed when your information is read. It's two hours work to implement". Andrzej Jan Taramina made the same kind of response:
One easy way to solve this problem is by decoupling the request from the response. Send a request (with an indication of how to respond....a URL, Web Services Callback, and email address etc.) and receive a "transaction received" HTTP response (which should be almost immediate). Some time later the service uses the response indicator info to send a "real" response to the transaction. Damn....that sure sounds like message queuing doesn't it?
However, as Michael Brennan pointed out, the HTTP callback approach is not applicable to every sort of distributed application: "...some interactions can't afford an open-ended contract for when the response finds its way back to the originator of the request".
Thomas Passin sketched out a HTTP usage scenario, one with a definitely RESTful flavor, in response to Brennan's point. Passin suggested that in response to a POST, a server application might create a subsidiary resource and return a CREATED response and a pointer to the subsidiary resource, which the requester is then free to GET. If, as Brennan suggested, the server application cannot generate the subsidiary resource and a pointer to it immediately, it instead returns, as Passin said, "a CREATED message that says when it expects the new resource to contain the data, and what [URL] it will be at".
Leigh Dodds, with whom I share this column every month, responded to Box's claim that HTTP is RPC by pointing out that Roy Fielding, one of HTTP's designers and the doyen of REST, claims that HTTP is not RPC. Simon St. Laurent offered an interesting characterization of Fielding's claim that HTTP is not RPC. What Fielding actually does, in St. Laurent's view, is "called redefining something in order to prove that you are not it. It's a nice rhetorical trick, and useful with people who already believe your definitions, but I don't think Fielding escapes all claims that the HTTP protocol is itself RPC". Dodds further suggested that in his view there's nothing "in web services that requires new technologies, or fundamental reworkings other than the possibility to make someone a lot of money".
The reaction of independent developers to Microsoft's dissatisfaction with HTTP suggests a justifiable amount of skepticism as to its motivations. But it also suggests that the technical merits of HTTP are far from exhausted, especially when it comes to its use in building Web Service applications.
XML isn't Extensible?
The other fundamental element of the Web Services trio to come under criticism on XML-DEV recently -- to say nothing of the antipathy it garners in other programming communities -- is XML itself. Which is nothing new. Several projects to build working subsets of XML have their origins in XML-DEV conversations. This time around, in a conversation which remains active as of this writing, Eric van der Vlist questioned the extensibility of XML, calling it a myth. As van der Vlist put it, "XML is based on trees which are not the most extensible structures (compared to tables or triples). If you extend a tree you are likely to break its structure (and existing applications). I would say that trees grow but are not 'extended'".
In a subsequent message, van der Vlist provided an example of his worries about extensibility.
<ns1:foo>This is a simple example.</ns1:foo>
If I extend this example to include a semantic element to identify "simple" as an adjective:
<ns1:foo>This is a <ns2:adj>simple</ns2:adj> example.</ns1:foo>
I am changing a text leaf node into a mixed content including 2 text nodes separated by a child element and this will likely break 90+% of the existing applications.
That is, van der Vlist makes notable three claims: first, XML's underlying data structure is a tree; second, trees are less extensible than tables or triples; third, extending a tree often means breaking it and applications that expect it to have a particular form. Simon St. Laurent responded to the latter claims, conceding, in the first place, that "[f]or some applications...different approaches like RDF probably make sense...". But, he suggested, "I have a very hard time imagining writing my data in triples, and a harder time imagining triples having anywhere near the transparency that relatively flat tree structures have".
|
|
|
Also in XML-Deviant |
|
As for whether extending a tree necessarily means breaking it, St. Laurent said that it "isn't difficult so long as you haven't tightly bound yourself to a particular vision of how the tree must absolutely positively precisely be structured. If you're willing to accept that adding a new branch to a tree or reorganizing a branch doesn't automatically make it a diabolical mutant, there's a lot more flexibility". Which sounds an awful lot like the same redefinition rhetorical trick by which, in St. Laurent's view, Fielding shows that HTTP isn't RPC.
Bill de Hora observed that, rather than showing that XML is not really extensible, van der Vlist's example highlighted that, first, if the example change broke application code, it wasn't very well written code, that it wasn't sufficiently "additive or data-directed"; and, second, that if an application wasn't able to handle the change because the change violated some contract or requirement, which the application expected the data to honor, "[y]ou might reasonable ask...what on earth possessed anyone to write a requirement like that".
Taking a less technical, more social and historical view, Mike Champion offered a twist on van der Vlist's lament that XML 1.0 was unlikely to be changed to take account of all that's been learned since it was first made public. "...XML is not the ultimate answer," Champion admits, "it's the re-capitulation of the 'hierarchical data' meme after 15 years of submergence under the 'table' meme. It came in from the wilds, even though Microsoft in particular nurtured it and propagated it". And just as with every other large-scale technological pattern or facility, Champion added, "people are trying to force-fit everything into XML...some of it makes sense and some of it doesn't. Some of it will succeed, and much of it won't". Likewise, as van der Vlist suggested initially, "in 5 or 10 or 15 years some new meme will come in from the wild and displace the now-ossified XML".
But what if the question is wrong? What if expecting data alone to be extensible, independent of the application and programming logic that handles it, is misguided. Nicholas Lehuen's perspective is that you must consider both data and application or programming logic to find the sum of a system's meaning. "[E]xtensibility is not something," Lehuen says, "that can be achieved by looking at the data only".
Conclusion
It is clear, I think, that there appears to be more consensus in the computer industry about how to build Web Service applications than actually exists. And while diversity of opinion is a good thing in most technological contexts, the "Web Services" marketing campaign is about markets, about corporate profits, returns on investment, about large egos and larger budgets.
It is interesting, however, to note the different ways that consensus breaks down, especially when comparing corporate marketing and independent (or individual) developer opinion. Despite Microsoft's dissatisfaction with HTTP, it remains highly prized by the developer community, which is regularly demonstrates that HTTP is a technology with legs. Many developers, for example, think that the REST approach to building web applications is superior to other approaches, but that belief is unlikely to matter very much in terms of market (or marketing) success, for reasons that are pretty well understood. On the other hand, there has always been some level of dissatisfaction among developers with XML, though it may well be more dissatisfaction with XML 1.0 plus the welter of ill-factored follow-on specifications. And yet the big, and sometimes not so big, corporations making up both the computer industry as well as a great many other industries have flocked to XML like junkies flocking to the dealer on Free Sample Day. The most unquestioned and unquestionable part of the Web Services idea is XML. And the number of XML vocabularies increases with no end in sight.
So HTTP, XML, and SOAP are all, according to someone's requirements or expectations, either useful and elegant or inadequate and kludgeful, either a dream come true or a nightmare realized. As with so much of life, in technology, where you sit depends on where you stand.