What’s in the name “Web service”?
|Sometimes, the biggest battles in technology wars are fought over names. Right now, “Web services” is a name that looks good on resumes, is whispered in conspiratorial tones to new college graduates and, most importantly, opens up departmental budgets as managers nod sagely and imagine the proposed projects that will give them what the pundits call a competitive edge. This sort of high-stakes naming game is, of course, a hallmark of human affairs: Create graffiti and you might end up in prison; create art and you might end up a celebrity|
SOAP, the engine of Web services as media phenomenon, recently passed a major milestone in its release as SOAP 1.2, a W3C recommendation. From early on in its history, strong backers of SOAP have pushed to reserve the name “Web services” for SOAP message transport and WSDL API description. Technologies from which SOAP and WSDL emerged -- such as XML-RPC, HP eSpeak, WDDX or WIDL -- are not worthy of the name “Web services” despite the fact that the architectural differences are minor. Some technologies such as RSS, which have thrived under a different brand of buzz, are even more suited to the name “Web services” than SOAP-based technologies, but they are rarely referred to as such.
Interestingly enough, an influential cross-section of the SOAP world has come to accept a more generic idea of Web services. One of the fruits of the loud battles that led to SOAP 1.2 is that the blueprint “Web Services Architecture” that will be followed by standards organizations accepts a broad definition of “Web service” that encompasses REST, RSS feeds and the like. This has not brought an end to the name game, though, because in many circles the insistence on equating Web services with SOAP services remains strong.
Serving to raise the stakes is the fact that SOAP and WSDL do not provide all of the punch that would justify the excitement over the buzzword. Web services are supposed to provide everything from inexpensive application integration to the next generation of B2B commerce. SOAP is a means of exchanging text between systems, and WSDL is just a language for describing the shape of the text to be exchanged. Neither one provides the security, transaction processing, workflow management or application plug-ins that are generally spun into the Web services legend.
Now that SOAP and WSDL have established themselves, vendors have scrambled to the generally unplowed territory that makes up the rest of the Web services “stack,” and we now have the great war of WS-Foo and Bar-4-WS “standards” with no end in sight. At the other end of affairs, customers buy into Web services and then end up scratching their heads because all they have in practice are SOAP and WSDL, which don’t, by themselves, meet all their expectations.
The result is that the magical term that brings such marketplace cachet may well be on its way to being discredited. The CORBA and DCOM generation of distributed computing systems was as ambitious as Web services is today, yet they spent a decade in development before achieving only a modest proportion of these ambitions. Certainly, we have that experience to build on, but it’s hard to see how Web services will magically break through just because messages will now be exchanged in verbose XML documents rather than in compact binary forms.
This inevitable discreditation is a shame because there are very exciting things happening in the world of Web services (as a generic term). An unforeseen crop of Web “home pages” (a brief bio and photo on the top followed by lists of links to other home pages) was the engine of growth for the Web we now know. Weblogs, which are home pages with very important content and technology twists, are the current vanguard of a Web that truly is based on services deployed between machines. Perhaps it’s just as well that the term “Web services” is not adopted in these endeavors.
Successful commercial Web pages such as Google, Amazon and eBay provide very basic XML collections of their data, which has the effect of making any user with a clever idea and an XML parser a partner in a branded ecosystem. Organizations dutifully copied the success of the public Web in their intranets. They can share in the next step of Web services on the cheap by encouraging the availability of the raw data behind intranets as XML feeds accessible in multiple ways. Then any department can drive competitiveness using applications that weave that XML into all of the many technologies -- SOAP, REST, RSS, etc. -- one could call Web services. If you wait for the pundits and vendors to proclaim the true Web services, you’ll lose out to more nimble players whose motto is “just get ’em the XML by any means necessary.
Some of the kids who worked in spray paint when Hip-Hop was not mainstream are now hailed as the next generation of artists and are courted by city planners, galleries and high-fashion moguls. The route pioneered by Jean-Michel Basquiat has now been paved in terms of what people choose to call art. The path to establishment or obscurity of many of today’s leading technologies may be defined in terms of whether they are accepted under the remarkable buzzword of “Web services,” or indeed whether or not people learn to see through the buzzword.
To read more columns by Uche Ogbuji, click here.
Uche Ogbuji is a consultant and co-founder
at Fourthought Inc. in Boulder, Colo.
He may be contacted at firstname.lastname@example.org.