Fiche technique

Si l'on reprend la définition de Mark Colan, Web Service and XML Chief Advocate chez IBM, les Web Services sont des "applications modulaires basées sur internet qui exécutent des tâches précises et qui respectent un format spécifique". Nous sommes bien conscients que cette citation apportera peu d'informations aux non initiés et nous allons tâcher d'en reprendre le contenu.

Il y a plusieurs manières de définir les web services :

• Si l'on s'en remet à une définition non-informatique, le terme "Web Service" décrit une fonctionnalité commerciale exposée par une entreprise sur Internet afin de fournir un moyen d'utiliser ce service à distance
  
• Si l'on s'en tient aux aspects opérationnels, les "Web Service" sont des applications modulaires qui peuvent être décrites, publiées, localisées et invoquées dans un réseau. Ainsi, cela permet à vos applications de faire appel à des fonctionnalités situées sur d’autres machines
  
• Si l'on détaille tout ceci, on peut dire que l'objectif initial d'un web service est de permettre l'utilisation d'un composant applicatif de manière distribuée
  

Plus clairement, cela consiste à permettre l'utilisation d'une application à distance. En fait, les "Web Services" facilitent l'invocation de certains traitements depuis Internet. Le modèle logiciel proposé contient à la fois un nouveau mode de développement et une nouvelle méthode de fourniture de services. Les concepts qui le composent en font presque un véritable paradigme de programmation.

L'avantage de ce modèle tient est de présenter ces services comme des "boîtes noires". En fait, les entrées-sorties d'un service sont gérées au sein de messages dont on connaît le format grâce à des interfaces clairement exposées mais sur lesquels l'implémentation interne du traitement n'influe pas au niveau de la structure. Ceci permet un haut niveau de modularité et d'interopérabilité. L'avantage du modèle de message est qu'il permet de s'abstraire de l'architecture, du langage ou encore de la plate-forme qui va supporter le service : il suffit juste que le message respecte une structure donnée pour qu'il puisse être utilisé.

Techniquement les concepts ayant donné lieu aux Web Services ne sont pas nouveaux. Nous venons d'évoquer les protocoles existants : DCOM, RMI, CORBA, DIIOP et Remote Procedure Call (RPC). Les implémentations propriétaires de ces protocoles ont mené à leur perte. Ceux-ci sont progressivement abandonnés au profit des Web Services. On peut toutefois s'attendre à les voir conserver tant que les technologies que nous allons vous présenter n'auront pas parfaitement adressé l'ensemble des problèmes que l'informatique distribuée recouvre.

Pour finir, la définition des Web Services ne serait pas complète si l'on n'évoquait pas ses principaux standards : SOAP, WSDL et UDDI, des protocoles mis en place par Microsoft, IBM, Sun et bien d'autres.

• SOAP est un protocole permettant l'invocation de méthodes à distance par l’échange de messages XML
  
• WSDL est une norme dérivée de XML qui permet la description de l'interface d'utilisation d'un Web Service. Ce standard est donc équivalent à la partie publique d'une classe ou au header d'un programme C.
  
• UDDI est un protocole d'annuaire permettant de trouver le web service que l'on recherche mais aussi d'en annoncer la disponibilité
  

Introduisons-les brièvement avant de leur consacrer de véritables chapitres.

SOAP
Au sein des protocoles dont nous venons de parler, SOAP fait figure de pièce centrale. En effet, le Simple Object Access Protocol (SOAP) définit un protocole à la fois simple et léger destiné à l'échange d'informations. Adopté par les plus grands, SOAP est utilisé pour différentes opérations, de l'échange de données aux fonctionnalités distantes de type RPC.

WSDL
Le Web Service Description Language (WSDL) est une grammaire dérivée de XML permettant de fournir les spécifications nécessaires à l'utilisation d'un web service en en décrivant les méthodes, les paramètres et ce qu'il retourne. WSDL est donc un langage de description des services. Le fichier WSDL présente l'interface publique du service et permet la génération automatique des stubs et skeletons des proxy à l'aide d'outils ad-hoc.

UDDI
Universal Description, Discovery and Integration (UDDI) est une spécification définissant la manière de publier et de découvrir les web services sur un réseau. Ainsi, lorsque l'on veut mettre à disposition un nouveau service, on crée un fichier appelé Business Registry qui décrit le service en utilisant un langage dérivé de XML suivant les spécifications UDDI. Les informations qu'il contient peuvent être séparées en trois types :

• les pages blanches qui incluent l'adresse, le contact et les identifiants relatifs au web service
  
• les pages jaunes qui identifient les secteurs d'affaires relatifs au web service
  
• les pages vertes qui donnent les informations techniques
  

En utilisant l'API UDDI, vous pouvez alors stocker ces informations dans un node UDDI. Elles sont ensuite répliquées de node en node par la technique des UDDI cloud services (somme toute assez proche dans l'idée des réplications de DNS). Une fois ceci fait, votre web service peut alors être connu de tous ceux qui le recherchent.

Utilisation des Web Services
Les équipes marketing des sociétés travaillant dans le domaine des web services mettent en avant différents domaines d'utilisation. Parmi les plus crédibles, on trouve la publication de modules applicatifs disponibles en tant que services à l'utilisateur final et la mise à disposition de système d'échange d'informations B2B.

Le premier exemple semble assez peu réaliste pour l'instant. Nous verrons dans le chapitre consacré au business des web services que les modèles économiques d'Application Service Providing, c'est-à-dire de mise à disposition d'applicatifs end-user sur internet sont encore balbutiants (certains diront que l'ASP a déjà montré ses limites).
Le second quant à lui semble plus important. Le principe des Web Services est de pouvoir concevoir des applications distribuées complètes à l'aide de composants interopérables à la manière d'un grand puzzle. En fait, c'est exactement ce qu'il nous manque pour rendre l'Internet plus convivial. Pour rentrer dans le concret, repensez à l'opération d'achat d'une voiture sur Internet. Vous allez d'abord vous rendre sur le site du concessionnaire pour en choisir le modèle à l'aide de son application de vente de véhicules. Vous allez ensuite être basculé sur le site du partenaire financier de ce concessionnaire afin de voir si l'on peut vous y accorder un crédit. Enfin, vous finirez sur le site d'un assureur afin d'assurer votre acquisition. Tout ceci serait bien plus simple si vous pouviez tout faire depuis le site de vente de voiture et si les informations relatives à votre achat étaient transférées automatiquement d'un système à l'autre. C'est ce que va permettre le modèle composants des web services. A l'aide des protocoles et des standards mis en place, deux applications seront capables de s'échanger des données de manière totalement transparente pour l'utilisateur.