L'histoire récente des Web services a commençé par un grand succès : tous les acteurs importants se sont mis d'accord (courant 2000/2001) sur une enveloppe technique "primaire" séduisante avec SOAP, WSDL et UDDI. Cette unanimité des constructeurs et éditeurs était tout à fait indédite dans l'histoire de l'informatique, c'était même du jamais vu !

Suite au traumatisme de l'éclatement de la bulle, l'industrie informatique était à la recherche de sa planche de salut et tous les espoirs semblaient permis avec cette nouvelle technique prometteuse. Hélas, après la grande convergence, vint la grande divergence. Tous ces acteurs, qui s'étaient miraculeusement entendus sur l'enveloppe technique minimum de la "pile Web service", se déchiraient désormais sur le contenu et la nature de l'enveloppe technique étendue...

Pourquoi une telle situation qui s'apparente à du sur-place ?
Tout d'abord, le hype et les divergences affichées par les acteurs pour l'enveloppe technique étendue de la pile Web services ont convaincu les clients, qu'en la matière, il était urgent d'attendre !
Pourtant, ajouter la capacité transactionnelle aux Web services est perçu comme le mur qui reste à franchir et le besoin est présent depuis longtemps.

On connait bien et depuis longtemps les exigences du transactionnel distribué :
Livraison garantie des messages/requêtes une fois et une fois seulement,
Authentification des demandeurs et non-répudation des demandes confirmées,
Orchestration et routage mais également surveillance des performances (monitoring).

Cet ensemble ressemble fort aux objectifs de l'enveloppe technique étendue de la pile des Web services. Or, dans le contexte actuel de divergence entre les acteurs, cet objectif paraît être un horizon lointain et incertain.

Un horizon d'autant plus lointain et incertain qu'on a jamais réussi à mettre au point le transactionnel distribué dans un contexte "local" (voir à ce propos les nombreuses tentatives en matière de client-serveur et de middlewares ces dix dernières années...). Il y a donc peu de chances qu'on y parvienne dans le cadre de l'Internet...

Clairement, l'approche actuelle privilégiée pour l'évolution des Web services est une impasse. Pourquoi et que faudrait-il faire pour en sortir ?

L'impasse vient qu'on considère qu'on peut fiabiliser et optimiser une liaison client-serveur point à point. Car, rappelons-le, l'appel de procédure distante via un Web service n'est pas autre chose qu'une conversation client-serveur.

Or, le couplage lâche tant vanté des Web services n'est vrai qu'au niveau applicatif, pas au niveau des protocoles (les deux parties en présence doivent échanger sur le même mode, par exemple, HTTP et SOAP de part et d'autre). On le vérifie une fois encore, le mode conversationnel en point à point est trop contraignant.

La solution ? Il faut déplacer le problème !
C'est ainsi que, il y a quelques années, on est passé du client-serveur lourd au Web client-serveur en ajoutant un intermédaire (le serveur Web était cet intermédiaire à facade standard) plutôt que d'empiler des couches "tout-prévu-tout-compris".

C'est ce retour de l'intermédiaire que l'on voit arriver aujourd'hui avec une nouvelle notion : les Web Services Networks (WSN). Un intermédiaire à valeur ajoutée, sorte de place de marché transactionnelle, s'intercale dans la chaine de liaison et prend à sa charge l'ensemble des contraintes tout en jouant le rôle de tiers de confiance (ajoutant ainsi une garantie supplémentaire, souvent nécessaire dans un cadre réglementaire).

Est-ce donc un retour des RVA comme au temps de l'EDI ?
Et les Web Services n'étaient-ils pas supposés rendre ces RVA inutiles ?

Non, les WSN sont mieux que les RVA : pas un simple relais, mais une infrastructure partagée et standard (pas de logiciels spécifiques à installer au niveau des parties concernées, le WSN présente une facade standard s'appuyant sur l'enveloppe technique minimale). Les WSN proposent de faire pour les données ce que fait FedEx ou Chronopost pour les paquets…

Ces intervenants offrent une infrastructure de liaison entre les parties avec des données de suivi (le N° de tracking) à partir d'une simple enveloppe normalisée (comme les enveloppes Chronopost que vous pouvez acheter partout).

Les avantages des WSN sont nombreux. D'abord, il n'y a pas de contraintes de configuration entre les parties (l'un peut se connecter à la place transactionnelle avec le protocole HTTP alors que l'autre va utiliser SMTP, MQ-serie ou un autre middleware). Ensuite, on peut étendre les parties concernées par la transaction sans remettre en cause l'ensemble et y ajouter des transformations (comme passer d'un format à un autre). Enfin, toutes les fonctions liées à la sécurité vont être assurées et garanties par le WSN.

Mais, il y a aussi, forcément, quelques inconvénients à passer par un WSN. Déjà, les parties concernées doivent forcément être clientes du même WSN. Également, il est probable que les échanges synchrones vont être plus lents puisque l'ajout d'un noeud dans la boucle va augmenter la latence.

Et puis, la topologie de type "hub and spoke", propre à ce type d'architecture, met en question la scalabilité de l'ensemble (comment le WSN va supporter la montée en charge au fur et à mesure de l'augmentation du nombre de participants ?). De plus, pour l'instant, il y a encore peu d'intervenants qui se soient positionnés sur le marché comme WSN. L'exemple de Grand Central Communication (www.grandcentral.com), reste encore isolé.

Ceci dit, l'intermédiation apporté par les WSN ne sera peut-être pas suffisante pour permettre aux web services de décoller enfin…

Et si c'était le postulat de départ qu'il fallait remettre en cause ?
Et si on n'avait pas besoin d'un appel de procédure pour déclencher un Web service ?

En effet, l'acharnement actuel autour de SOAP ressemble fort à la foi aveugle qu'une bonne partie de l'industrie avait pour CORBA il n'y a encore pas si longtemps (avec une absence de résultat sidérante au vu des efforts investis !).

Cette remise en question de SOAP, qui peut paraitre iconoclaste, est à faire sans tarder pour sortir de l'impasse actuelle. Tout d'abord, il est important de défaire SOAP de ses vertues supposées : SOAP n'est pas conforme au standard du Web simplement parce qu'il supporte HTTP ou SMTP. En l'occurrence, on peut dire que SOAP supporte HTTP comme la corde supporte le pendu !

En vérité, SOAP utilise HTTP en mode "tunnel" pour passer plus facilement les firewalls mais c'est plus une astuce qu'une véritable adhésion aux standards du Web. De part ce recours "furtif" aux protocoles standards, SOAP ne permet de ne bénéficier d'aucun des mécanismes mis au point au fil des années pour optimiser la conversation Web : les proxies, les caches et même les firewalls ou les listes de contrôles d'accès sont complétement court-circuités par les échanges SOAP.

Les défauts de conception de SOAP sont tellement évidents que la version la plus récente (la 1.2) permet enfin d'avoir recours à la fonction HTTP GET à la place du POST qui était incontournable jusque-là. Mais si SOAP n'est qu'un sous-corba mal revu et à peine corrigé, par quoi le remplacer, par XML-RPC ?

Certainement pas. Cette autre création de Dave Winer présente le même défaut fondamental que SOAP : c'est un appel de procédure qui n'utilise HTTP qu'en mode tunnel. Alors, quoi ?

Il existe une alternative mais elle est encore peu connue, il s'agit de REST (NDLR: voir le tutoriel de JDN Développeurs). La bonne surprise avec REST c'est que vous n'avez besoin de rien d'autre que ce que vous avez déjà (en matière de standard) : HTTP, les URI et XML.

Bien que peu connue, REST n'est pas une niche exotique vénérée seulement de quelques rares initiés. Il faut savoir que c'est le modèle qu'Amazon.com a retenu pour ses Web services. La mauvaise surprise, c'est que REST n'est soutenue par aucun des grands fournisseurs du marché qui tous préférent la complexité de SOAP et peuvent ainsi discuter entres eux sans fin sur ses nécessaires évolutions…

Ceux qui vous disent qu'on ne peut pas faire de véritables Web services avec REST sont les mêmes qui vous disaient, il y a quelques années, qu'on ne pouvait pas réaliser de véritables applications transactionnels avec le web…
Ne vous laissez pas abuser parce type de discours, REST est aux Web services ce que l'open source est au projets logiciels : un modèle qui marche et une véritable libération !

Documentez-vous sur REST (voir en particulier son wiki) et profiter de toute la puissance des Web services vraiment simples et vraiment standards, tout de suite.