Kicking out the Cuckoo

April 24, 2002

Edd Dumbill

It is past time that the W3C called an end to its involvement in web services. Despite the name, web services have increasingly little to do with the Web as we know it, and those at the forefront of its development seem to have little fondness for the W3C or its technologies.

The genesis of web services technology began with Microsoft and, to a lesser extent, IBM; and the leadership of this movement lies still very much with these organizations. When SOAP first emerged, developers were distinctly wary of a Microsoft technology that seemed to want to own the Web. Microsoft, for its part, would clearly benefit from widespread acceptance of SOAP. Hence the move to the only other party in town at the time, the W3C, made enormous sense: Microsoft gets the stamp of "open standard" on its technology, and other companies get a forum in which to ensure they can have their turn steering the bandwagon.

Cut to the present. SOAP, as specified by Microsoft and IBM, is deployed widely, to the point where its proponents refer to the fact that it is part of "mission critical" systems. SOAP as per the W3C is still struggling. One and a half years on, the troubled and oversized XML Protocol Working Group is gearing up to release Last Call Working Drafts that stand a significant chance of being rejected by W3C members, thus facing delay.

Meanwhile, things start getting out of hand in the world of consortia. Encouraged no doubt by the success of UDDI -- not in producing useful technology, but in press-ganging companies into its membership -- the WS-I organization sprang into being. Spearheaded by Microsoft, IBM and BEA, the Web Services Interoperability Organization is in the business of promoting the interoperability of web services by "blessing" collections of specifications into profiles. At launch the WS-I avoided direct confrontation with the W3C by stressing a commitment to interoperability testing and creation of profiles. Of course, this makes complete sense. With over 100 member companies, the WS-I could not practically design new, competing, technology.

The real effect of the WS-I is to remove the W3C's imprimatur of authority over web services. The necessarily slow process of achieving consensus in a W3C Working Group does not suit the business plans of Microsoft and the other WS-I corporations. We should not be surprised then that the model IBM and Microsoft pursued with SOAP is resurgent, and this time it won't have an open organization like the W3C to slow it down. Take a look at web service related specifications published by MS and IBM over the last six months: WS-Security, WS-Routing, WS-Inspection and WS-Referral. It doesn't take too much imagination to see the sympathetically-named WS-I blessing these specifications.

It is hard to see how the W3C can compete when the business case for Microsoft and IBM is so urgent that creating alternative consortia is easier than pursuing development through a working group. The burdens of the W3C are just too many: the W3C has a responsibility for relating its technologies to the entire web architecture, and a strong dislike among the majority of the membership for imposing royalties on patented technology. WS-I has neither of these constrictions.

Slippery SOAP

Let's establish why developers at large should care about the machinations of corporations and consortia over web services. Happily, the Internet is still largely a free place, technologically speaking, and we are free to use whichever new technique we want. But we must also be aware of the consequences.

Extrapolating from the emergence of the WS-* specifications, it would seem that SOAP is the thin end of a wedge, the fat end of which will turn Internet programming into a proprietary platform. As Paul Prescod demonstrates elsewhere in XML.com this week, SOAP adds nothing to what can already be done with existing, openly available, and unencumbered, web technology, but it does add more restrictions.

The restriction explains the popularity -- SOAP toolkits are undeniably easy to use and avoid the tricky issue of having to consider the whole Web when creating an Internet-distributed service. It is well-worn wisdom that removing features makes a technology more accessible: XML itself is an example.

However, once steps have been taken down the SOAP road and commitments made, developers and vendors cut themselves off from existing benefits of the Web. For example, security and caching mechanisms must be reinvented. The solutions for many of these problems will come from the specifications being created by Microsoft and IBM, likely to be approved by the WS-I organization. It is not at all clear that these specifications will have the same degree of scrutiny that those developed at W3C or IETF endure, or that their creators will have the same attitude to intellectual property that allowed Web technology to blossom in the first place.

The ultimate end is that, for the majority of developers, programming over the Web will have become a matter of using Microsoft and IBM's platform, similar to the "Wintel" hegemony over personal computing. The leaders of the web services movement will then be free to add or remove features and break compatibility with the rest of the Web at will, as developers will then be beholden to the platform, and not have the liberty of the Web.

This is why the decision to pursue or reject the SOAP route is so critical, and why developers should be very careful. The choice is between open and established technology on which the Web is built, and the direction proposed by large corporations, whose existence depends on making money from their strategies.

The Cuckoo

It has become painfully obvious that accommodating the development of web services technology at the W3C makes little sense. Not only has SOAP's development been a distraction of attention and resources from developing parts of the Web and XML infrastructure, it thumbs its nose at the W3C's other work.

SOAP as commonly practiced offers nothing in the way of compatibility with HTML, XSLT, RDF, XLink, or SVG. In addition, it is responsible for the promotion of non-standard URNs (e.g. urn:GoogleSearch), collapses all the resources of an endpoint behind one URI, and uses HTTP in a way that most experts think is highly inappropriate. The "web" in "web services" is contemptible.

The W3C's attempts in January 2002 to respond to the larger need of web services by creating a Web Service Architecture group now look futile and redundant in the face of the WS-I, established one month later, which will essentially define web service architecture by blessing its component specifications.

There can be no doubt that the web service movement is the cuckoo in the W3C's nest. Sooner or later, one of the two will kick the other out.