Les fausses pistes des Web Services

Publié le Mis à jour le

Le récent Forum Intégration XML (www.technoforum.fr) a consacré les Web Services comme le produit phare de la vague XML. De plus, avec la notion de Web Services, on a vu un phénomène inédit en informatique : l’unanimité des éditeurs (reste à convaincre les clients …) !

Oui, depuis des dizaines d’années, jamais l’ensemble des acteurs n’arrivait à se mettre d’accord sur une nouvelle technique ou un nouveau standard, jamais. On décomptait toujours au moins quelques dissidents de taille et le plus souvent on constatait un affrontement entre blocs.


Mais, bien sûr, cette « nouvelle » unanimité n’est que de surface et elle s’exprime surtout sur le niveau basique des Web Services, SOAP et WSDL, qui s’inspirent de XML-RPC, mécanisme déjà éprouvé depuis des années. Dès qu’on s’intéresse aux niveaux supérieurs de la normalisation des Web Services (sécurité, orchestration, etc.), la bataille fait de nouveau rage !

Il semble donc bien que le XML ait enfin trouvé une voie de plus avec les Web Services en tant que mécanisme de base d’une nouvelle classe de middleware non intrusifs et adaptés à Internet. Mais, ici aussi les fausses pistes abondent !

Les types de Services Web

En effet, on peut déjà identifier trois types de processus publiables et appelables par Web Services :
– les processus de type calcul de données discrètes
– les processus de cohérence de données opérationnelles (propagation de mises à jour)
– les processus de traitement fonctionnel

Le premier type (calcul de données discrètes) est le plus simple : appel d’un service qui va vous donner la température en fonction de telle localisation, le numéro de téléphone en fonction d’une adresse, trouver un code postal en fonction d’un nom de lieu ou encore obtenir une habilitation en fonction d’un login/password. Le mode de fonctionnement est dans ce cas simple : un seul aller et retour, paramètres en entrée, résultats en sortie. Ce type de Web Services est déjà répandu et facile à utiliser.

Le second type (cohérence de données opérationnelles) est tout aussi simple à utiliser mais comporte des « d’enjeux » plus importants. Il s’agit par exemple, de transmettre une mise à jour de données entre deux systèmes autonomes afin d’éviter la double saisie. On utilise alors les Web Services comme un mécanisme léger de réplication de données sans pour autant se situer dans un logique transactionnelle avec ses contraintes. Ce type de Web Services est surtout utilisé en interne comme solution d’urbanisation, mais commence aussi à être proposé par des prestataires d’ASP, comme salesforce.com, qui voient ici une façon simple de mieux intégrer leur offre avec l’existant des clients. Le mode de fonctionnement se complexifie puisque l’on doit assurer l’intégrité des données et gérer l’ensemble des cas d’erreurs (la partie la plus complexe dans le cas d’échanges d’informations entre deux systèmes).

Le troisième type (traitement fonctionnel) est le plus sophistiqué : il s’agit de permettre le déclenchement d’une série de traitements fonctionnels avec un déroulement logique qui suppose forcément un routage, une orchestration et même, éventuellement, une gestion transactionnelle entre les appels de Web Services … Ici, la promesse est d’utiliser les services distants de manière transparente comme s’ils étaient des fonctions de l’application appelante en conservant la richesse de tels appels (transaction, sécurité, gestion des sessions, orchestration …).

Pour ce dernier type d’utilisation, il est clair que le niveau de standardisation actuel des Web Services n’est pas suffisant. Et, c’est bien la mise en place de traitements distribués du troisième type qui est l’enjeu des dernières batailles entres les grands acteurs.

Les éditeurs visent-ils la bonne cible ?

Ceci dit, il ne faut pas trop se faire d’illusion : depuis vingt ans, on sait que le transactionnel distribué entre systèmes autonomes est une entreprise très difficile et tout un spectre de techniques ont été expérimentées dans ce sens sans grand succès (du commit à deux phases à la réplication dynamique de données). Il est donc douteux qu’on obtienne des résultats concrets en voulant à tout prix hisser les Web Services au même niveau de richesse que CORBA. Il ne faudrait pas oublier que c’est sa légèreté qui a été le moteur du succès des Web Services et que c’est précisément la complexité qui a tué CORBA.

Ce fossé entre le monde des éditeurs et la « vraie vie » existe déjà. Il était tout à fait palpable lors du Forum Intégration XML. Les éditeurs rivalisaient de nouveaux standards et de produits d’avant garde alors que les cas client présentaient des utilisations fonctionnelles passionnantes bâties sur des technologies simples. Une des présentations Clever Age portaient sur un cas d’utilisation des Web Services dans le domaine de l’assurance voyage en exploitation depuis plusieurs mois. On y apprenait notamment que la plupart des voyagistes préfèrent les appels de Web Services via des échanges de documents XML sur HTTP (approche de type REST) plutôt que SOAP pour des raisons de simplicité (pas d’installation de SOAP client sur leur plateforme de production, facilité de mise en œuvre pour les équipes de développement, pas de risque technologique …). Le hasard du calendrier des présentations a voulu que l’on passe derrière une présentation détaillant les améliorations apportées par SOAP 1.2 dont la seule chose que l’on puisse affirmé sur sa disponibilité est qu’elle est lointaine … Un fossé voire un gouffre ?

L’épisode UDDI

On a déjà connu ce type de fausse piste avec UDDI, rappel des faits…

A l’instar des sites orientés vers le consommateur final, les Web Services dédiés aux entreprises devaient connaître une expansion fulgurante si on en croyait les prévisions affichées par les observateurs dès 2000. Le problème classique se posa alors aux professionnels confrontés à une offre extrêmement riche et d’identification difficile : où (et comment) trouver l’information ?

Ce dont avait besoin le marché, c’est d’un service simple qui devait permettre de trouver le bon partenaire (celui qui propose le ou les Web Services qu’il vous faut) et de disposer de toutes les informations nécessaires pour pouvoir échanger électroniquement avec lui (accéder à son contrat WSDL entre autres). C’est à ce niveau qu’intervient UDDI (Universal Description, Discovery, and Integration).

Initié par quelques géants de l’informatique (IBM, Microsoft et Ariba, et oui, le même trio que pour WSDL et ce n’est pas un hasard…), UDDI apparaît comme une vaste base de données mondiale des services proposés sur le Web. Au moins 130 sociétés ont promis un support à UDDI. 36 sont des membres du projet initial et 94 ont rejoint le mouvement depuis. Le projet a d’ores et déjà réussi à rassembler autour de lui des sociétés telles que Accenture, Cargill, Clarus, CommerceOne, Compaq, Dell, I2, ICG, Rational, Sabre, SAP, Sun, Tibco, webMethods. Il est perçu par tous ces acteurs comme une avancée majeure.
UDDI propose un cadre technique indépendant vis-à-vis des plates-formes et totalement ouvert pour permettre aux entreprises de se trouver les unes avec les autres, pour définir comment ils doivent interagir sur Internet et pour définir comment partager l’information selon une immatriculation mondiale.

En réalité, le tableau était bien moins rose qu’il n’y paraissait initialement.

Ce qui a freiner le démarrage d’un annuaire comme UDDI, c’est le même facteur qui a handicapé les places de marché : le vrai besoin des entreprises, c’est plus de travailler mieux avec les partenaires connus que d’en trouver de nouveaux. Le fait de proposer de l’intermédiation de processus via les Web Services ne change rien à l’affaire, l’attente en matière d’optimisation des échanges entre les entreprises passe par une plus forte intégration de proximité…

Du coup, l’intérêt pour UDDI est retombé à son niveau normal : on considère de nouveau UDDI comme une pièce du puzzle technique, pas comme un élément indispensable dans l’envolée commerciale des Web Services !

Ayant analyser les limites de UDDI, Microsoft propose en complément DISCO, un mécanisme simplifié de découverte de services, mais on est encore loin de l’adoption unanime par tous les acteurs des Web Service, seul moyen maintenant de pérenniser une technologie.

En conclusion, si l’intérêt fonctionnel des Web Services est évident (les cas clients l’attestent), il faut en éviter les pièges technologiques. Il faut en effet garder à l’esprit que les professionnels ont tout intérêt à conserver un minimum de complexité dans les protocoles pour justifier leurs produits et services. Une approche projet modulaire guidée par le souci de simplicité est la clé de la réussite « métier » de vos Web Services.