Les web services : des middle-ware façonnés pour internet
Les web services relient des composants logiciels hétérogènes via HTTP. Ils représentent à la fois un puissant outil d’unification de l’existant (pont entre les modèles Com, Corba et Java) avec la plate-forme de développement des composants internet de demain.
Les serveurs d’application n’ont pas été conçus pour partager leur contexte sur internet. Au mieux, la communication n’a lieu que dans un sens : le site d’Amazon, par exemple, peut passer des informations (l’identifiant du bon de livraison, etc.) à celui de Fedex, mais ce dernier n’a aucun moyen de renvoyer ses données au serveur d’application d’Amazon.
Le libraire en ligne doit donc demander à ses clients de se connecter sur le site de Fedex pour suivre l’état de leur commande. Les architectures d’objets distribués classiques se révèlent inadaptées à internet. Elles se limitent au système d’information d’une seule société et ne peuvent être partagées entre deux partenaires dans une logique d’entreprise étendue. XML-RPC, seule offre de type service web, n’ayant pas réellement percé, les entreprises recourent pour l’instant à des solutions bâtardes. Pourtant, le concept de services web ou web services n’est pas nouveau puisqu’il propose simplement de faire communiquer des composants logiciels distants.
Les modèles Corba (Common Object Request Broker Architecture), DCom (Distributed Component Object Model) ou EJB (Enterprise javaBeans) devaient, en théorie, apporter une solution fiable à cette problématique.
Mais deux difficultés se posent dans la pratique. D’une part, il est difficile de faire communiquer un objet Corba avec un objet Com ; d’autre part, les coupe-feu des entreprises bloquent les protocoles de communication utilisés par ces objets, compliquant terriblement leur déploiement.
Chacun y va donc de sa solution. Les “gros” partenaires déploient leur système d’information dans une logique one-to-one qui devient vite très coûteuse. Les petits sites, quant à eux, utilisent des composants spécialisés dans le parsing des sites partenaires. Cette méthode, aussi inélégante qu’inefficace, consiste à récupérer la page web du site partenaire, à la déshabiller pour finalement réinjecter les données intéressantes dans son propre site.
Pour un meilleur service client
Lorsque l’entreprise possède des dizaines de partenaires, la situation devient vite intenable, le service rendu au client n’étant pas à la hauteur de ses attentes. Celui-ci doit sans cesse ressaisir les mêmes informations et assurer la coordination des différents services auxquels il fait appel puisque ces derniers ne sont pas pris en compte. C’est l’essor des architectures objet, ou tout au moins d’une approche par composants, qui a donné naissance au concept de service web. Les entreprises sont en effet de plus en plus nombreuses à assembler des composants à la volée pour fournir des pages sur mesure aux internautes.
Il ne restait plus qu’à pousser ce modèle un peu plus loin, de façon à ce que les serveurs d’application soient capables de pren-dre en compte les composants des partenaires directement via HTTP.
Services web = HTTP + Soap + WSDL + composant
Ensuite, aux différents éditeurs de logiciels à coopérer pour concrétiser cette vision. Microsoft, Sun, IBM, Hewlett-Packard ou Bowstreet ont donc décidé de bâtir une solution technologique commune, capable d’étendre leurs modèles respectifs au monde d’internet. C’est ce que proposent les services web. Il s’agit d’applications propriétaires auxquelles on ajoute une interface de description (WSDL pour Web Services Description Language), ainsi que des protocoles de communication standard (HTTP et Soap [Simple Object Access Protocol]).
“ Un service web ne possède pas d’interface utilisateur au sens classique du terme. Il se contente de dialoguer via HTTP avec d’autres services web à l’aide d’un contrat, c’est-à-dire une liste de méthodes“, précise Pablo Sanders, consultant stratégique chez HP. La description de l’interface suit exactement la même démarche qu’un IDL (Interface Definition Language) Corba.
Elle est assurée par WSDL, un langage de description qui s’appuie sur XML (eXtensible Markup Language). Le fichier WSDL expose les méthodes de l’objet Com, Java, C++, Cobol…, de façon à ce que n’importe quel autre service web puisse comprendre cette interface.
Typiquement, un programmeur qui utilise Visual Studio.Net de Microsoft analysera les propriétés d’un service web comme il le fait actuellement pour un objet Com. Une fois les méthodes découvertes, il pourra y recourir dans ses développements, sans se soucier de ce qui se passe au niveau internet, même si le service web obtenu est écrit en Java.
Le protocole Soap se charge du transport des données sur HTTP. Le message Soap transitant sur internet est lui-même codé en XML. Il transporte à la fois les données métier échangées entre les 2 objets distants et les données techniques nécessaires à la bonne exécution de l’appel : nom de la méthode appelée, types des données métier transportées, etc.
Les plates-formes de développement et d’exploitation de services web ont donc essentiellement deux objectifs. Le premier consiste à créer le fichier de description au format WSDL à partir d’un composant existant. Il s’agit en fait de décrire les différentes méthodes de l’objet en XML, ainsi que diverses autres propriétés. L’outil de développement doit être capable de lire un fichier WSDL en sens inverse afin d’exposer l’interface des objets distants au développeur. Le second objectif concerne la génération des proxies et des listeners Soap. Ces modules traduisent les requêtes des plates-formes d’exécution (Com, Java ou autre) au format Soap et vice versa. Ils jouent le rôle de traducteur et de passerelle entre le monde internet et le système d’information de l’entreprise. La génération de ces composants (fichier WSDL, proxy Soap) est statique ou dynamique. “ Mais concrètement, la génération dynamique, qui existait déjà en Corba, reste trop complexe à mettre en ?”uvre ; les développeurs préfèrent créer le proxy Soap et le fichier WSDL à la main “, précise Pablo Sanders de HP.
Sélectionner en permanence les fournisseurs les moins chers
Un système d’annuaire automatise la découverte des services répondant à des critères précis. Ainsi, et même si cela reste théorique, un marchand en ligne comme Amazon pourrait sélectionner en permanence l’entreprise de livraison la moins chère et inclure ses services dynamiquement dans son site. Le tout en temps réel.
Si Fedex vient à augmenter ses tarifs ou si son service web est en maintenance, il serait automatiquement remplacé par celui d’UPS. C’est UDDI (Universal Description, Discovery and Integration) qui autorise la découverte dynamique de services web. Défini conjointement par Microsoft, Ariba et IBM, ce standard sert à créer des annuaires à multiples facettes. Les “pages blanches” recensent les entreprises, les “jaunes” la description, au format WSDL, des services web associés.
Face à la réorganisation des entreprises autour de leurs clients et à une problématique croissante d’intégration, tant au niveau des partenaires qu’en interne, le système d’information s’oriente peu à peu vers un modèle de composants, assemblés selon des processus métier en perpétuelle évolution.
Des applications toujours plus centrées sur l’utilisateur final
C’est exactement cette vision qui sous-tend l’offre de Bowstreet, le pionnier des services web. Baptisé Business Web Factory, son outil assemble en effet à la volée et en temps réel plusieurs services web selon un “modèle” afin de donner naissance à un business web (application internet composée de plusieurs services web).
Les applications concrètes de cette approche sont légion. Deux PME échangent leurs données à moindre frais par ce biais, sans avoir recours à des outils EDI traditionnels.
De son côté, un web marchand a la possibilité de proposer en toute transparence l’offre de partenaire sur son site. Une opportunité d’ores et déjà saisie par Ineas (assurance) et la SBE (banque). Au final, le nombre d’applications autorisées par cette technologie est incalculable.
Elle permet en effet aux systèmes d’information de passer en douceur d’une organisation monolithique refermée sur elle-même à un réseau de services administrés par plusieurs entreprises, mais tournés vers les mêmes clients.
