 | 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:
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, ...):
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 dot.com 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. Newest comments
|
 |