Cherchant à se présenter à la fois comme champions du couplage lâche et comme nouvelle architecture de RPC (Remote Procedure Call), les Services Web SOAP semblent plus que jamais bâtis sur une contradiction que le décalage entre les exposés théoriques et les expériences pratiques présentées lors de ce cinquième Forum XML met en évidence.
Eric van der Vlist,
Dyomedea (vdv@dyomedea.com).
vendredi 15 novembre 2002
Le constat n'est pas nouveau. Il prolonge l'article publié lors de la précédente édition du Forum XML sous le titre "Services Web, à la mode mais à côté de la plaque?" et il est en quelque sorte confirmé par Jim Green qui, répondant à la question "que sont les Services Web?" distingue non pas deux mais quatre définitions partiellement convergentes:
- Pour le Gartner Group, ce sont des composants faiblement couplés qui interagissent grâce à des technologies Internet standards.
- Pour les éditeurs d'outils de développement, c'est une technologie qui permet d'améliorer leurs outils en facilitant l'intégration.
- Pour les éditeurs d'applications, c'est une nouvelle façon de définir des APIs.
- Pour les éditeurs d'EAI, c'est un moyen de faire communiquer des systèmes.
D'autres présentations confirment une double contradiction entre la vision théorique de couplage lâche en utilisant des technologies standards et l'implémentation physique grâce aux technologies habituellement associées aux Services Web (SOAP, UDDI, WSDL, ...):
- D'une part, la logique "RPC" de SOAP n'est pas réellement une logique de couplage lâche.
- D'autre part, si la sur couche introduite par SOAP peut effectivement utiliser les protocoles standards de l'Internet et notamment HTTP, l'utilisation qui en est faite est telle que les outils de gestion de ces protocoles doivent être totalement repensés pour les Services Web.
Ce point apparaît clairement dans les présentations de Cyril Dhénin "Web Services, quels gains pour quels coûts?", Didier Girard "Architectures et Web Services" et Jean-Philippe Moresmau "La qualité des Web Services" qui mettent en évidence l'insuffisance des fonctions d'administration, de supervision et de sécurité des infrastructures Web actuelles et la nécessité de développer un nouvelle infrastructure adaptée aux Services Web.
On semble donc se trouver en face de Services Web dont l'atout principal le couplage lâche et l'utilisation de protocoles existants qui reposent sur une implémentation de type RPC à couplage fort et ne permettent pas de réutiliser l'infrastructure de gestion des protocoles actuels.
Interrogé sur ce point, Cyril Dhénin y voit une nouvelle manifestation du décalage habituel entre le discours à destination des décideurs et la réalité technique. Une constatation faite de manière plus nuancée par Jean-Marie Chauvet qui distingue la vision stratégique à long terme des Services Web qui devraient permettre d'orchestrer les services de l'entreprise étendue grâce à l'exposition de leurs processus métiers et une vision tactique des Services Web par les développeurs qui les utilisent comme des RPC.
Notant que la vision tactique des Services Web est déjà bien réalisée, Jean-Marie Chauvet souligne le chemin qui reste à accomplir pour réaliser la vision stratégique et notamment le risque de "babelisation" de Services Web qui ne se comprendraient pas.
Divergence des discours techniques et marketing ou divergence des visions tactiques et stratégiques? Le mot de la fin reviendra peut-être aux réalisations concrètes qui suivent parfois des chemins imprévus.
Trois témoignages furent ainsi présentés lors de la session C07. Si le témoignage de Sidé Brahimi pour la DGA a montré une architecture BizTalk que l'on pourrait qualifier de classique, les témoignages de Stéphane Bidoul pour Elia et de Benoît Marchal et Patrick Bacher pour France Telecom montrent des architectures échangeant des documents XML directement sur HTTP préférées à SOAP pour des raisons de simplicité et de non stabilité de la version actuelle de la spécification SOAP.
L'architecture de ces applications correspond à celle préconisée par Roger Costello et mentionnée l'année dernière dans mon article. Elle a depuis gagné un nom et s'appelle maintenant architecture REST. Comme SOAP, elle utilise les protocoles existants, mais contrairement à SOAP elle les utilise de la même manière que les utilisateurs humains et permet de faire l'économie d'une partie de la refonte de l'infrastructure indispensable au déploiement des architectures Services Web classiques. De plus, contrairement à SOAP, elle ne cherche pas à recréer des mécanismes de RPC et est fidèle au principe de couplage lâche.
On ne peut bien entendu pas extrapoler les enseignements recueillis sur trois témoignages, mais il semble indéniable que la plupart des applications de Services Web déployées actuellement le sont sous forme d'architectures REST qui s'ignorent et que, loin des feux des projecteurs braqués sur le trio SOAP/WSDL/UDDI, cette architecture est l'architecture qui domine actuellement les Services Web.
Devant la puissance marketing déployée par des acteurs qui ont pour la plupart intérêt à ce que leurs clients renouvellent leurs infrastructures, on peut néanmoins se demander combien de temps cette dominance va pouvoir se maintenir.
Autres articles:
Copyright 2002,
Eric van der Vlist.
|
