Plus l’informatique joue un rôle croissant dans la vie des entreprises, plus les applications se répandent. Ces applications sont développées en de multiples technologies et fonctionnent sur des plateformes hétérogènes. Prenez n’importe quelle chaîne de valeurs au sein d’une entreprise et remontez les applications informatiques qui la supportent. Alors, l’hétérogénéité des systèmes apparaîtra comme une évidence. Ajoutez-y les systèmes informatiques des fournisseurs, partenaires et clients de cette entreprise et vous serez définitivement convaincus du « chaos » dans lequel nous ont plongé quelques décennies de progrès fulgurants.
Le concept des Web Services vise à répandre la perception des logiciels en tant que services et non plus en tant que bloc monolithique. Il englobe une série de technologies dont le but est d’exposer des services de l’entreprise (prise de commande, suivi de commande, consultation de stock …) au travers d’interfaces standardisées. Ainsi, les Web Services offrent-ils une réponse séduisante aux problématiques d’intégration d’applications notamment car ils reposent un couplage lâche. Si un service est appelable suivant une norme reconnue de tous, il est alors inutile de connaître le langage, le système d’exploitation … dans lequel il a été développé pour s’y connecter.
Par conséquent, l’enjeu est d’encapsuler les fonctionnalités des applications nouvelles et existantes dans une interface normalisée et de rendre ces services accessibles via des protocoles standards du Web. Ces services pourront ensuite inter opérer au sein d’une même entreprise mais également en dehors de l’entreprise. A ce titre, le Gartner estime que 75 % des entreprises ayant un revenu supérieur à 100 millions de dollars utiliseront les Web Services en 2002.
Architecture orientée services
Les Web Services reposent sur une architecture orientée services (SOA : Service Oriented Architecture). Comme tout SOA, ils reposent sur trois entités :
- des consommateurs de services
- des fournisseurs de services
- des référenceurs de services
Finalement, rien de bien nouveau par rapport à des technologies telles que RMI, DCOM, Corba … si ce n’est que la quasi-totalité de l’industrie informatique et les organismes de normalisation, W3C en tête ont décidé d’avancer de concert. SOAP, WSDL et UDDI sont les standards en devenir les plus avancées.
SOAP, WSDL et UDDI
Dans sa forme la plus simple, un appel de Web Service ne nécessite que l’usage de SOAP (Simple Object Access Protocol). SOAP est un protocole d’échanges de message XML en environnement distribué. Il permet de faire communiquer des objets distants via HTTP, SMTP …
Sur le schéma ci-dessus, WS_Analyse appelle la méthode GetCours( )de WS_Quotation. Pour formuler cet appel, le consommateur doit connaître le prototypage du fournisseur de service et créer un message XML respectant la norme SOAP. Ensuite, ce message doit être envoyé à la bonne destination (URN : Uniform Ressource Name) via HTTP ou SMTP. WS_Quotation lit le message effectue le traitement correspondant à la méthode appelé et encapsule sa réponse dans un message SOAP et ré-envoit le message à son destinataire. On voit que ce protocole d’échanges est extrêmement simplifié par rapport aux technologies objets distribués existantes. Par ailleurs, le fait que l’on véhicule du XML sur des protocoles maîtrisés évacue tout problème de routage, de traversée des pare-feux …
Pour faciliter la description des méthodes fournies par un Web Service, le W3C a normalisé WSDL (Web Services Description Language). Comme l’IDL pour Corba ou DCOM, WSDL définit le contrat de service d’un Web Service. Un fichier WSDL décrit l’ensemble des méthodes accessibles d’un Web Service ainsi que leur prototypage. Le premier intérêt de WSDL est de faciliter la tâche aux développeurs. Si un développeur souhaite intégrer un appel à un Web Service dans son application, il suffira de lui transmettre le WSDL pour qu’il puisse formuler correctement ses requêtes SOAP. Un deuxième intérêt est de permettre l’appel dynamique de Web Services. On peut imaginer qu’une application demande le fichier WSDL à un Web Service et construise dynamiquement l’appel au service distant. Ce cas de figure est néanmoins improbable pour diverses raisons techniques. Mais, la principale est que WSDL ne fait justement que la description technique d’un service. En aucun cas, il ne décrit le fonctionnel des services ni des paramètres des méthodes distantes. Il est alors impossible via WSDL de savoir que la méthode GetReco( ) de WS_Analyse ne prend en paramètre que les codes SICOVAM (donc, bourse de Paris uniquement) et renvoie une recommandation échelonnée de 1 à 5.
Quant au référenceur de services, il porte le nom d’annuaire UDDI (Universal Description Discovery and Integration). L’objectif de ces annuaires est de référencer des services au sein d’une même entreprises ou sur Internet. L’UDDI Business registry contient une série d’informations accessibles par trois moyens :
- les pages blanches donnent les noms, adresses, contacts … des entreprises référencées et proposant des Web Services,
- les pages jaunes informent sur le métier des entreprises, les types de services que ces dernières proposent,
- les pages vertes apportent les informations nécessaire à l’utilisation des services (description fonctionnelle des méthodes, adresse des services, …).
Les limitations
Le schéma ci-dessus décrit un appel de Web Service après avoir utiliser une recherche dans un annuaire UDDI. A noter que l’accès à l’annuaire se fait via SOAP rendant l’annuaire lui-même un Web Service. Ce process lui aussi est encore très théorique aujourd’hui. En effet, de nombreuses problématiques business ne sont pas résolus de manière satisfaisante dans l’utilisation d’un annuaire UDDI telles que la gestion des droits d’accès, le workflow, la répartition de charges, la facturation … C’est pour cette raison que l’on ne trouve à ce jour dans les annuaires UDDI accessible sur le Web que des Web Services extrêmement basiques (conversion de devises, calcul de taux d’intérêt …).
En conclusion, il convient donc aujourd’hui d’expérimenter la mise en place de Web Services entre applications d’un même système d’information ou entre partenaires proches. Cette démarche permettra notamment de faire l’analyse des process de l’entreprise et de percevoir les applicatifs comme un enchaînement de « services ». Les entreprises qui veulent aller plus loin, se tourneront vers des solutions d’orchestration de process basées sur ebXML, RosettaNet … pas encore standardisés. En revanche, la découverte de Web Services sur le Web nécessite encore du travail de la part des éditeurs et des organismes de normalisation avant que les entreprises ne s’y intéressent.