SOAP Web Services: built on a contradiction?
13:18, 16 Nov 2002 UTC | Eric van der Vlist

The fifth annual Forum XML, on November 12-14 in Paris, featured a consistent theme--that SOAP-based Web Services seem more than ever based on a contradiction, even as they are being positioned by vendors as a foundation for both loosely coupled systems and a new RPC architecture.

This observation is not new and was already the subject of the article published with the title "Web Services missing the point?" after the last year's Forum XML conference. To some extent, Jim Green provided further confirmation: When answering the question "what are Web Services?", he identified not two but four definitions, which are only partially compatible:

  • loosely-coupled software components (according to the Gartner Group)
  • about using best-of-breed development tools (according to development tools vendors)
  • APIs to packaged apps (according to packaged application vendors)
  • what you use to get your systems to communicate (according to integration vendors)

Many other presentations confirmed a double mismatch between the theoretical vision of loosely coupled systems based on existing standards and the practical implementation based on technologies which are usually associated with Web Services (SOAP, UDDI, WSDL, ...):

  1. The RPC approach which is one of the selling points of SOAP can't be called loosely coupled.
  2. If the SOAP layer can use existing protocols such as HTTP, the usage that is done of these protocols is such that the infrastructure needs to be totally refactored to be suited for Web Services.

This second point was highlighted in presentations by Cyril Dhénin "Web Services, which gains for which costs?", Didier Girard "Architectures and Web Services" and Jean-Philippe Moresmau "Quality of Web Services" which did show the limitations of existing web infrastructures in a context of Web Services and demonstrate the need to develop a new infrastructure to develop, deploy and administer Web Services.

Questioned on this point, Cyril Dhénin said he saw this as a new example of the usual shift between the management and technical domains. An explanation also given under a slightly different angle by Jean-Marie Chauvet, who elaborated on the distinction between the strategical long term vision of Web Services as a way to manage the services of the extended enterprise by exposing their business objects through Web Services and the tactical short term vision of developers using them as a new RPC mechanism.

Noting that the tactical vision is already there, Chauvet said that the long term vision is still far away and that a lot needs to be done to avoid falling "from the bubble to XML Babel."

Aside from mismatch between business and technical views or between strategy and tactics, the final word will come from concrete implementations--and these may take unexpected paths. Three customer stories were presented during the session: Sidé Brahimi for the French Department of Defense showed a BizTalk based architecture that one could call "classical", and Stéphane Bidoul for Elia and Benoît Marchal and Patrick Bacher for France Telecom presented architectures exchanging XML documents over raw HTTP. They preferred plain XML to SOAP for the sake of simplicity--and because of the unfinished state of SOAP within the W3C Recommendation track.

The architecture of these applications is similar to what was described by Roger Costello and mentioned in my article last year and is now well known under the name "REST".

Like SOAP, REST uses existing protocols, but unlike SOAP, REST uses HTTP as human users would use it and this can make quite a difference in the amount of infrastructure refactoring needed to deploy Web Services. Furthermore, unlike SOAP, REST doesn't attempt to reinvent RPC mechanisms and is inherently loosely coupled.

Three examples are not enough to extrapolate, but it is very likely that most of the Web Services applications deployed so far are relying on REST architectures (whether they use the name or not) and that far from the glare of the spotlights this architecture is probably still dominating the market of Web Services.

Behind the marketing power deployed on the SOAP/UDDI/WSDL triple by organizations which have often a financial interest to see their customers renew their web infrastructures, one may wonder how long this will last.

| See all 11 comments

Newest comments

>SOAP has a document "style" of exchange so could be used to build REST like web services (assuming ...
Throwing some spanners;

REST is a concept not a technology or a standard.

SOAP has a document ...
Re: SOAP Web Services: built on a contradiction? (Yves Reynhout - 20:50, 17 Dec 2002)
I think we need to realize that one aspect of "Web Services" is that it's a document-oriented messag ...
Re: SOAP Web Services: built on a contradiction? (John R. Daily - 15:03, 17 Dec 2002)
It's not hard to tell the losing side in any debate: just look for personal vitriol, knee-jerk overr ...
xmlhack: developer news from the XML community

Front page | Search | Find XML jobs

Related categories