Accueil
 chercher             Plan du site             Info (English version) 
L'histoire de XML s'écrit en ce moment même. XMLfr vous aide à la suivre et à en dégager les tendances.Les listes de discussions XMLfr sont à votre disposition pour réagir sur nos articles ou simplement poser une question.Si vous ètes passionnée(e) par XML, pourquoi ne pas en faire votre métier ?XMLfr n'est heureusement pas le seul site où l'on parle de XML. Découvrez les autres grâce à XMLfr et à l'ODP.Les partenaires grâce auxquels XMLfr peut se développer.Pour tout savoir sur XMLfr.XMLfr sans fil, c'est possible !Pour ceux qui veulent vraiment en savoir plus sur XML.L'index du site.
 Manifestations XML francophones et internationales.L'actualité des affaires et stratégies XML.L'actualité des technologies XML.Les nouveautés et l'actualités de notre site.Pointeurs sur l'actualité XML sur d'autres sites, en français comme en anglais.


Services Web: bâtis sur une contradiction

Répondez à cet article.

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.


 

Mots clés.



L'histoire de XML s'écrit en ce moment même. XMLfr vous aide à la suivre et à en dégager les tendances.


Les documents publiés sur ce site le sont sous licence "Open Content"
Conception graphique
  l.henriot  

Conception, réalisation et hébergement
Questions ou commentaires
  redacteurs@xmlfr.org