Whither Web Services?
by Edd DumbillOctober 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.
|
Related Reading 
Web Services Essentials |
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?
Agree or disagree? Share your comments in our forum.
(* You must be a member of XML.com to use this feature.)
Comment on this Article
| Titles Only | Titles Only | Newest First |
- The Exagerated Demise of Web Services
2002-10-28 08:21:43 Mark Baker [Reply]
If I understand you and Edd correctly, you're suggesting that redefining "Web services" will somehow save them? I don't buy that. Most users have a pretty clear idea in their head what they are. And most of the Web services "gurus" have a pretty similar model in their heads that they're trying to write down in the Web Services Architecture WG. But that model is utterly broken, as the recent mess of unnecessary choreography/orchestration specs has demonstrated.
Web services will most definitely fail; the backlash has already begun, and there's not enough good associated technology in place to turn that around. Plus, whatever chance they might have had, they lost when the major promoters failed to educate people how to build them properly - though they probably didn't even know themselves; those people who did have a clue in those companies, had their voices drowned out by the vast majority who were clue-challenged.
- The Exagerated Demise of Web Services
2002-10-25 18:06:23 Kurt Cagle [Reply]
Having long been a skeptic of web services in general (for most of the same reasons that you bring up in your superb article) I am glad that the hype-pendulum is beginning to swing the other way. I especially liked your definition of Web Services as "XML in Motion", a definition which has to me served as a benchmark for most of the work I've been involved with for the last several years.
The principle difficulty with web services as defined specifically by Microsoft is that it places upon XML the onus of acting as if it was a binary brokering protocol, with the implicit added assumption that it should exist solely for the purpose of servicing COM components. The irony here is that in order to do this it is necessary to create a complex structure (and lots of standards) that add to the overhead of building applications while simultaneously ignoring XML's role as a means of transporting semantic state information.
Web Services (even in the more restrictive SOAP/WSDL/UDDI sense) will continue to get a lot of play by Microsoft, IBM, et al., but the attempt to build up a complex infrastructure that affects everything from UI to security to transaction management will probably collapse of its own weight because it relies far too much on both retrofitting the Internet to accomodate these complex standards and the continued cooperation of arch-competitors towards a level of interoperability that has relatively little demand.
Meanwhile, people will continue to build REST applications without knowing it, because such applications are the most intuitive (and most effective) ways of working with XML on the web. The web has evolved not because large companies established the standards (as much as the revisionist line would indicate otherwise), but because individuals attempted to solve local problems as simply as possible. XML web services will be no different.
Concerning RDF - RDF can be mind-bendingly complex at times, because its focus, creating relational frameworks, skirts the edge of the most conceptually sophisticated philosophical arenas of study - how we think. It is not, I will agree with Don Box on this, a magic pixie dust, but it is powerful when used properly, and has evolved the way it has because the issues that it is used with cannot be reduced into simpler forms. I suspect that the difficulty that Microsoft in general has with RDF (based upon the lack of RDF usage in everything except the rather odd channel specification developed very early on) comes from the fact that it doesn't fit easily into the API mentality that effects everything from application development to ... well, web services.
-- Kurt Cagle
- The Exagerated Demise of Web Services
2002-10-28 08:22:19 Mark Baker [Reply]
If I understand you and Edd correctly, you're suggesting that redefining "Web services" will somehow save them? I don't buy that. Most users have a pretty clear idea in their head what they are. And most of the Web services "gurus" have a pretty similar model in their heads that they're trying to write down in the Web Services Architecture WG. But that model is utterly broken, as the recent mess of unnecessary choreography/orchestration specs has demonstrated.
Web services will most definitely fail; the backlash has already begun, and there's not enough good associated technology in place to turn that around. Plus, whatever chance they might have had, they lost when the major promoters failed to educate people how to build them properly - though they probably didn't even know themselves; those people who did have a clue in those companies, had their voices drowned out by the vast majority who were clue-challenged.
- The Exagerated Demise of Web Services
2002-10-29 01:40:20 Edd Dumbill [Reply]
No, I don't think you understand what I was saying. I have long admired your ardour against the tottering tower of web services specs, and think it justified, but it may have colored your perception of what I wrote.
What I was saying is that the real excitement of web services is basically the same as that from exchanging XML. Whatever protocols rule the roost it's the interoperability and potential network effects that are interesting.
- The Exagerated Demise of Web Services
2002-12-04 17:56:42 Ian Hollingworth [Reply]
Edd
I agree with you that the it is the "exchanging XML" part of the web services that offers the real value today.
Using XML to exchange information becomes useful when it allows a community with a common interest to orchestrate (or choreograph) standardized end-to-end business processes involving multiple organizations and disparate information systems.
Once the community has (with some rigour) specified how the standardized end-to-end business process will operate (a huge challenge in my experience if the business process has any degree of complexity) the community then needs to agree on the structure and content of the XML business documents used to exchange information (i.e. agree on an XML schema and XML tag usage).
Finally, there must be agreement on how the documents are going to be transmitted (messaging) - this is rarely a major issue.
The hype suggests that web services technologies can make multi-enterprise business process integration a simple "plug 'n play" exercise. The theoretical potential is there, but I think this is many years away. In the mean time, SOAP and WSDL have a place as useful tools (among other viable alternatives) that a community may deploy to facilitate "through the firewall" application integration. SOAP and WSDL do not address the most significant challenge however: obtaining agreement up front within a community on a standardized end-to-end business process.
- The Exagerated Demise of Web Services
- The Exagerated Demise of Web Services
- The Exagerated Demise of Web Services
