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, ...):
- The RPC approach which is one of the selling points of SOAP can't be called loosely coupled.
- 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 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.
|