BOURSE

Déjà très actif dans l'élaboration des standards des Web Services tels que WSDL, UDDI ou SOAP, IBM propose d'ajouter une nouvelle brique à l'édifice avec la spécification "httpr". Comme le laisse supposer son nom, httpr s'apparente à une extension du protocole http utilisé pour demander et recevoir des pages Web. Pourquoi ajouter une extension à http ? Pour rendre plus robuste l'échange de messages entre applications via le web.

Combler les insuffisances de http
Assez rustique, http ne prévoit pas de mécanisme permettant de s'assurer qu'un message est bel et bien arrivé à destination et qu'il n'a été délivré qu'une fois. De fait, avec http des paquets d'informations peuvent être perdus sans qu'il soit donné suite à cette défaillance. Ces "pertes" sont sans gravité quand il s'agit simplement de délivrer à un utilisateur une page d'information. En revanche, une telle défaillance peut avoir des conséquences fâcheuses si l'émetteur est une application qui attend une confirmation pour valider une transaction. Et le problème est ardu: il ne suffit pas d'identifer qu'un message n'a pas été délivré; il faut aussi pouvoir le ré-expédier, ce qui suppose d'en avoir conservé une copie quelque part; en outre, cette ré-expédition doit par exemple respecter un créneau horaire... Pour garantir une telle intégrité, émetteur et récepteur doivent être informés avec précision du statut (de l'état) du traitement.

Dossier: La révolution des Web Services > Sommaire > Soap, WSDL, UDDI: comprendre le puzzle > Interview: "Les Web Services vont se généraliser rapidement" > Sun dévoile (vraiment) Sun One

Utiliser le Web comme un canal d'échange de messages entre applications demande donc de lui apporter certains des mécanismes que l'on trouve dans des logiciels appelés "middlewares orientés messages" comme MQ Series d'IBM ou encore Microsoft Message Queuing (MSMQ). Telle est la vocation de httpr qui intègre dans l'entête des messages beaucoup plus d'informations de statut que ne le fait http. En s'appuyant sur ce protocole, les gestionnaires de messages et les différents agents chargés de stocker le statut des messages pourront appliquer des règles afin de réagir aux éventuelles défaillances, qu'elles proviennent d'un serveur ou d'un réseau.

Le choix de la couche transport
On peut s'étonner que les architectes de MQ Series à l'origine de httpr n'aient pas choisi d'intégrer de telles fonctions dans Soap, protocole utilisé pour l'échange de messages entre Web Services. De la sorte, il aurait été possible d'assurer une telle intégrité au-dessus d'un large éventail de couches de transports. IBM objecte que ce choix aurait en effet déplacé la gestion de l'intégrité des messages de la couche transport à la couche application applications mais aurait aussi rendu plus complexe l'élaboration des logiciels de suivi des processus business. Le choix d'IBM présente aussi l'avantage de ne pas perturber les protocoles existants puisqu'un message Soap aura la même forme qu'il soit véhiculé via http ou httpr.

IBM entend soumettre prochainement la spécification httpr à l'IETF (Internet Engineering Task force).