Whither Web Services?
October 23, 2002
Whatever else they have or haven't been, web services have been a boon for the popular technology media. On the way up the hype curve, breathless reports of the coming automation of our very existence filled pages and pages. Software executives jostled to join the right cabals, and to sit in smoke-filled rooms hammering out the formation of committees and specifications with daft acronyms.
The more ambitious schemes have plainly just not taken off (can you spell UDDI?), and everyone's realized there's a lot more work involved than the ardent PR folk claimed. Happily for the tech press, this means many more pages can now be written about this realization, too. I can't say that these more sober articles are incorrect, they often make a lot of sense. But they would have made a lot of sense two years ago, too.
I won't take up time here pondering mainstream technology journalism and the hands that feed it; suffice to say that those of us who were against the web services hype two years ago can now permit ourselves a satisfied smile. (Those of us who earn a living by writing might also wonder a little sorely what the dollar-word rate was for writing such credulous articles.)
Where does this readjustment of expectations leave web services? Following the rise, and now the plateau, are we headed for a crash?
The hype has certainly been strong enough. In an interview on the subject of web services a year ago I opined that web services technology would be most useful hooking systems together inside an enterprise, rather than outside, and that talk of a sea-change was overrated. Unfortunately this interview never saw the light of day. I can only assume it wasn't exciting enough. Despite the obvious problem that humans are involved in inter-organization transactions, a lot of people who should have known better believed the loud noises from Microsoft, IBM, and Sun, disdaining the dictates of their own common sense. The vision of revolutionized business, where whole industries would gain an automated e-business backbone, was just around the corner. Point and click trade. The stakes were high. We all watched the Microsoft BizTalk vs OASIS rush to host schema repositories and business registries.
Two or so years on we have empirical evidence to back up the views of the more conservative among us. There is no doubt that there is a "there" there in web services, but it's not the overarching architecture we were told us about. It is, rather, the practical nuts and bolts technology that was there before "web services" became the new name for it, and which will be there long after it gets a new name.
In short, I believe that the concept of web services is basically what got a lot of us excited about XML in the first place, and that the state of web services as a whole has never been better. Let me expand on this a little.
First, attempts to take control of a top-down architecture have failed. Despite numerous proposals, there's been no global "eureka!" moment. You can still deploy a web service and have it implemented pretty much as you like. There's no license fee to access a web service superhighway.
Second, since the world hasn't changed overnight, developers are able to investigate alternatives. While I'm not in any particular camp in the protocols debate, it has been heartening that plain old XML & HTTP (aka REST) and BEEP have had a hearing alongside the bigger initiatives, as well as grass roots inventions like Jabber. Heterogeneity rules, for the moment at least, giving us hope of better technical solutions in the long run.
Third, and most excitingly, any developer that wants to create a web service, invent an ad hoc application protocol, and do useful work can do so -- and can share this with others by making their protocol open.
All of these points apply equally well to XML: you can choose from different architectural styles, different schema languages, and invent your own schemas to your heart's content. Apart from the immediacy of document exchange, it's hard to draw the line between creating an XML vocabulary and a web service. I'd like, therefore, to do what has defied most commentators for a while. I hereby propose the modest definition of "web services" as XML in motion.
Once we have this understanding of web services as a continuation of some of the fun things we planned to do with XML, it makes the rise and fall of the hype curve a lot less significant. If we viewed XML 1.0 at its publication with the foreknowledge of today's specifications, we would have been horrified. As I've written elsewhere, W3C XML specifications being developed today are far from the spirit of the original and take up ever increasing amounts of effort with decreasing returns. Yet at the base of this now tottering pyramid is the dependable yet exciting platform of XML itself. The spirit of invention is very much alive in the XML community, a broad yet coherent church, whose continuing creativity owes much to its refusal to clamber to the top of the tower of specs. So I'm now less worried by the machinations of the W3C committees. XML has a foundation and future separate from the standards bodies.
I now take the same view of web services. For a long time I have been and remain skeptical of much of the standardization work going on around web services. Much of which seems a premature attempt at capturing as-yet-unknown best practice and, despite the honest efforts of those involved in committees, driven a lot more by the political motivations of the member companies than by technical requirements.
What I missed in my skepticism of the web services movement, though, is the opportunity for the useful composition and re-use of resources. XML's big success is the separation of content from its presentation. Web services' big success will be the separation of communication from implementation -- both sit on the foundation of a shared syntax. XML's achievement wasn't in creating a new concept, but in getting the network effect of adoption for that concept. This is an ongoing process, and something that's taken a longer time than the hype merchants told us it would.
I have the same hope for web services as they follow the same basic adoption patterns of XML. There's a lot of bluster, a lot of rubbish, but much real innovation and genuine advance, often from the grassroots. First we'll see the big benefits inside organizations, and over time we'll figure out how and when things should scale in the larger world.
So, if they should shortly start appearing in the tech media, rumors of the death of web services will be greatly exaggerated. In fact, things are just getting started.
Fragments
-
The progression of XML 1.1 to Candidate Recommendation at the W3C is generally to be seen as a good thing, expanding as it does the use of Unicode characters in XML. It has also revived controversy over the inclusion of the NEL line-break character, needed for supporting IBM mainframe systems. Paul Festa's CNET report on the story is an amusing read, and includes this curious reporting of Steve Holbrook from IBM:
Holbrook said the line-break issue that has been foiling mainframe XML implementations was the result of IBM's having been left out of the original group that wrote the XML 1.0 specification.
Also in <taglines/>
Given the free-for-all pile-on that was the rush to join the XML Working Group in 1998, and that the Microsoft, Sun, and HP all made the party, I shan't be rushing to send IBM my sympathy for the delay. In fact it wasn't until 2001 that IBM formally urged a change in XML 1.0.
- Don Box, the man who famously combined his ablutions with lecturing on Windows programming, wrote recently that he has fallen out of love with RDF, which he originally thought, as many did, "brought with it some magic pixie dust that would be revealed later." Discussing the "RDF tax" levied on technologies such as RSS 1.0, Box reports that he has come to support the simplifiers' point-of-view (figurehead Dave Winer, progenitor of ultra-simple web services protocol XML-RPC.) Don then goes on to wish that Winer would move his support away from the "XML-RPC goo" and toward SOAP 1.2 and WSDL. Perhaps Microsoft has a larger supply of pixie dust?