Les services web sont à l’heure actuelle, le seul moyen de mettre en place des architectures orientées services. Dans cette partie, nous allons nous échapper un peu de l’aspect conceptuel des architectures orientées services pour nous attarder sur l’aspect fonctionnel et technique des services web. Nous étudierons tout d’abord les différents protocoles de base permettant de mettre en place une architecture à base de services web. Nous verrons enfin les outils existants permettant d’implémenter facilement un service web.
1.2.1 Les protocoles de base des services web
L’on commence à parler proprement de la pile des technologies de services web avec les protocoles de base : WSDL et SOAP. Ces protocoles imposent un format de message XML. WSDL (Web Service Description Language) est le langage de description des Services Web, même s’il n’est pas formellement imposé par l’architecture de référence du W3C (1).
On peut cependant considérer aujourd’hui qu’une description WSDL est nécessaire pour qu’une application puisse revendiquer la qualification de service web.
SOAP (Simple Object Access Protocol) est, quant à lui, le protocole standard d’interaction, d’échange d’informations entre un client et un prestataire. Les prestataires des services web, leurs interfaces et leurs points d’accès, peuvent être enregistrés, découverts et localisés via des technologies d’annuaire comme UDDI (Universal Description, Discovery and Integration). Autant un standard ouvert (non propriétaire) sur les annuaires de services semble indispensable, surtout pour la mise en œuvre d’architectures dynamiques, autant la technologie UDDI, qui est clairement une technologie de services web, n’est pas encore formellement considérée aujourd’hui comme le standard des annuaires.
Fig. 1.2 Les protocoles de base des Services Web
Source : O. MORA [9]
WSDL, SOAP et UDDI constituent l’ensemble des technologies clés des services web, sur lesquelles d’autres technologies plus proches de la problématique applicative peuvent être spécifiées et mises en œuvre.
La partie qui suit va s’attarder à détailler précisément certaines caractéristiques des protocoles de base. Cette partie est en fait essentielle pour bien comprendre la suite des travaux.
XML
XML (Extensible Markup Language) est un langage de balisage extensible qui a été mis au point par le XMLWorking Group sous l’égide du W3C. Les spécifications XML 1.0 sont reconnues comme recommandation par le W3C, ce qui en fait un langage reconnu. XML est un standard qui sert de base pour créer des langages balisés spécialisés ; c’est un “méta langage”. Il est suffisamment général pour que les langages basés sur XML, appelés aussi dialectes XML, puissent être utilisés pour décrire toutes sortes de données et de textes. Il s’agit donc partiellement d’un format de données. Son objectif est, dans un échange entre systèmes informatiques, de transférer, en même temps, des données et leurs structures. Permettant de coder n’importe quel type de donnée, depuis l’échange EDI (Electronic Data Interchange ou Echange de Données Informatisées) [10] jusqu’aux documents les plus complexes, son potentiel est de devenir le standard universel et multilingue d’échange d’informations.
XML Namespaces est une extension de la recommandation XML qui permet de créer des espaces de nommages. Les espaces de noms d’XML permettent de qualifier de manière unique des éléments et des attributs. On sait alors à quel domaine de définition se rapporte un objet et comment il doit être interprété, selon sa spécification. Différencier des espaces de noms permet de faire coopérer, dans un même document, des objets ayant le même nom, mais une signification différente, souvent liée à un modèle de contenu différent. Cette spécification est une avancée importante car, à partir du moment où beaucoup de formats s’expriment selon XML, les risques de “collision de noms” deviennent plus importants et cette spécification prend alors toute son importance.
WSDL
Dans le cadre des recommandations du modèle de référence OASIS (2), une description de service représente les informations nécessaires afin d’utiliser un service et facilite la visibilité et l’interaction entre les consommateurs et les fournisseurs de services. La spécification WSDL (Web Service Description Langage) a vu le jour afin d’offrir une grammaire qui décrit l’interface des services web de manière générique. Toutefois, dans un environnement ouvert comme Internet, le modèle de description des services web n’est d’aucune utilité s’il n’existe pas un moyen de localiser aussi bien les services que leurs descriptions WSDL [11].
Dans la mise en place des architectures de services web aujourd’hui, la fonction de contrat de service est portée par le document WSDL. Le choix d’un format universel et extensible de structuration de documents basé sur XML s’impose, pour satisfaire les deux contraintes principales qui pèsent sur le contrat de service :
– Le contrat de service doit être, en même temps, lisible par des acteurs humains et exploitable (généré, interprété, agrégé, décomposé, indexé, mémorisé, etc.) par des agents logiciels ;
– Le contrat de service doit être tout aussi facilement extensible, c’est-à-dire adaptable à l’évolution des services, des architectures et des technologies, et capable d’accueillir les nouveaux formalismes propres à de nouveaux types d’engagements.
Actuellement, le document WSDL ne permet de définir que l’implémentation de l’interface, à savoir : les styles d’échange, les formats des messages, les conventions de codage, les protocoles de transport, les ports de réception.
Un document WSDL dé nit une suite de descriptions de composants. Le chier WSDL est principalement composé de 6 éléments, avec d’autres éléments optionnels :
– définitions : élément racine du document, il donne le nom du service, déclare les espaces de noms utilisés, et contient les éléments du service (obligatoire) ;
– types : décrit tous les types de données utilisés entre le client et le prestataire. WSDL n’est pas exclusivement lié à un système spécifique de typage, mais utilise par défaut la spécification XML Schéma (définition abstraite) ;
– message : décrit un message unique, que ce soit un message de requête seul ou un message de réponse seul. L’élément dé nit le nom du message et peut contenir (ou pas) des éléments ” part “, qui font référence aux paramètres du message ou aux valeurs retournées par le message (définition abstraite) ;
– portType : combine plusieurs messages pour composer une opération. Chaque opération se réfère à un message en entrée et à des messages en sortie (définition abstraite) ;
– binding : décrit les spécifications concrètes concernant la manière dont le service sera implémenté : protocole de communication et format des données pour les opérations et messages définis par un type de port particulier. WSDL possède des extensions internes pour définir des services SOAP; de ce fait, les informations spécifiques à SOAP se retrouvent dans cet élément (définition concrète) ;
– service : dé ni les adresses permettant d’invoquer le service donné, ce qui sert à regrouper un ensemble de ports reliés. La plupart du temps, c’est une URL invoquant un service SOAP (définition concrète).
Fig. 1.3 Spécifications WSDL
De nombreuses implémentations de services web se sont juste limitées à l’utilisation de la couche de transport SOAP pour faire interagir un client et un prestataire sans déclarer le service au travers d’un document WSDL. Cela est suffisant dans une situation où le service en question ne présente qu’un intérêt limité, propre aux deux acteurs qui contrôlent les nœuds de communication concernés. En revanche, si le service web est destiné à une utilisation dans un cadre plus élargi, il va rapidement devenir fastidieux pour le fournisseur de ce service de décrire et d’informer chaque consommateur potentiel des caractéristiques fonctionnelles et techniques de ce service. Il sera certainement préférable que ce fournisseur concentre ses ressources sur les aspects commerciaux et contractuels de son offre par exemple. Ainsi, la spécification WSDL joue un rôle pivot dans une architecture de services web. C’est la présence d’un contrat WSDL qui permet d’affirmer que l’on met en œuvre un service web.
Le seul usage de SOAP dans la communication entre les applications réparties ne suffit pas pour qualifier ces applications de services web.
SOAP
SOAP (Simple Objet Architecture Protocole) [12] fournit un mécanisme qui permet d’échanger de l’information structurée et typée entre applications dans un environnement réparti et décentralisé. Il ne véhicule pas de modèle de programmation ou d’implémentation, mais fournit les outils nécessaires pour définir des modèles opérationnels d’échange (styles d’échange) aussi diversifiés que les systèmes de messagerie asynchrone et l’appel de procédure distante (RPC).
Le message SOAP est un document XML. Un message SOAP présente une structure normalisée. Il est toujours constitué d’une enveloppe (SOAP-ENV : Enveloppe) munie d’un en-tête (SOAP-ENV : Header) optionnelle et d’un élément (SOAP-ENV : Body) obligatoire contenant le corps du message, suivis d’éventuels éléments applicatifs spécifiques. La spécification considère explicitement que les en-têtes SOAP sont destinés à la mise en œuvre de couches supérieures et transversales de la technologie des services web, comme la gestion des transactions, la gestion de la sécurité, etc.
UDDI
UDDI (Universal Description and Discovery Integration) [13] constitue une norme pour les annuaires de services web : les registres UDDI. Les fournisseurs disposent d’un schéma de description permettant de publier des données concernant leurs activités, la liste des services qu’ils offrent et les détails techniques sur chaque service. La spécification UDDI offre aussi une API (3) aux applications clientes, pour consulter et extraire des données concernant un service et/ou son fournisseur. En e et, les registres UDDI sont eux-mêmes exposés comme des services web. La mise en place d’un registre UDDI suit un processus uniforme imposé par la spécification W3C. Chaque organisation qui veut mettre en place un registre UDDI doit suivre ce processus pour devenir un opérateur UDDI. Les registres UDDI créées sont organisés en réseaux, ils partagent ainsi les différentes informations publiées. La publication d’un service chez un opérateur donne automatiquement lieu à un processus de propagation des informations aux différents registres UDDI. L’accès à l’ensemble des informations des registres peut se faire de n’importe quel opérateur UDDI.
Chaque registre UDDI stocke trois sortes de données :
– Des données concernant les fournisseurs de services appelées pages blanches,
– Des données concernant l’activité ou le service métier des fournisseurs appelées pages jaunes,
– Les données techniques de chaque service publié, qui constituent les pages vertes.
L’annuaire UDDI est accessible soit via un navigateur web qui dialogue avec une application web dédiée, interface spécifique à l’annuaire accédé, soit par programme, en utilisant l’API dé nie par la spécification. L’API comporte deux groupes de fonctions :
– les fonctions de recherche (Inquiry API) : navigation, recherche et consultation des informations de l’annuaire ; les fonctions de publication (Publishing API) : publication, création, modification ou suppression des informations de l’annuaire.
Il existe d’autres fonctions dans l’API UDDI, mais celles-ci sont plutôt dédiées à l’exploitation de l’annuaire (par exemple, l’API de réplication entre annuaires). Il existe principalement deux types de registres de services :
– Les registres privés sont ceux implémentés dans le cadre d’une entreprise et ne sont accessibles que par les acteurs internes au système.
– Les registres publics quant à eux sont ceux accessibles sur Internet. Dans le cadre d’un registre public, lorsque l’administrateur UDDI d’une organisation (entreprise, administration, université, …) souhaite publier des informations dans un annuaire UDDI, il doit d’abord choisir l’un des opérateurs de l’annuaire et ouvrir un compte auprès de l’opérateur retenu (public ou privé). Ensuite, il pourra interagir avec l’annuaire au moyen d’une interface web dédiée ou par programme via l’URL du service web d’accès aux fonctions de publication du site de l’opérateur choisi. Les informations qu’il publiera seront alors automatiquement répliquées vers les autres implémentations de l’annuaire UDDI. S’il souhaite mettre à jour les informations initialement enregistrées, il ne pourra le faire qu’auprès du site de l’annuaire initialement utilisé, quelque soit le canal d’accès choisi (interface web ou service web).
Toute tentative de modification, à partir d’une autre implémentation de l’annuaire (gérée par un autre opérateur), sera refusée et un message d’erreur sera retourné.
Cela vient du fait que, contrairement au contenu de l’annuaire, les comptes d’accès aux différents sites d’un annuaire ne sont pas eux-mêmes répliqués.
1.2.2 Composition et architecture des services web
Les services web sont la déclinaison du paradigme des architectures orientées services, sur le web. Bien que les architectures orientées services soient récemment proposées, elles connaissent un engouement et focalisent l’attention de bon nombre de professionnels dans le domaine des technologies de l’information et de la communication, des chercheurs et des industriels. Techniquement, les services web se présentent comme des entités logicielles sans état, dont la caractéristique majeure est de promouvoir un couplage faible. Une architecture à base de services web est une architecture en couches. Le groupe de travail “Web Service Architecture” (WSA) du W3C propose une vision de cette architecture, qui peut elle-même être raffinée n’étant pas unique [14].
Fig. 1.4 Couches de l’architecture des web services
La couche transport
Cette couche de base adresse les aspects liés au transport des messages [15], c’est à dire les différentes communications. Il est souvent possible de spécifier le style et le protocole d’une communication. On distingue au moins deux styles de communication :
– Le style RPC (Remote Procedure Call – appel de procédure à distance) précisément XML-RPC, SOAP ou alors l’architecture REST [16].
– le style Document (communication sous la forme de documents XML auto-descriptifs). Quant au protocole de communication, le support le plus souvent utilisé est HTTP mais il peut aussi être HTTPS (4), SMTP (5), FTP (6), JMS (7), etc.
La couche message
Le standard actuel qui assure la messagerie est le protocole SOAP (Simple Object Access Protocol). SOAP est un protocole léger destiné à l’échange d’informations structurées dans un environnement décentralisé, distribué. Il utilise des technologies XML pour définir une structure d’échange de messages fournissant une construction de messages pouvant être échangés sur divers protocoles sous-jacents. La structure a été conçue pour être indépendante de tout modèle de programmation et autres sémantiques spécifiques d’implémentation. Plus en détail, la spécification du SOAP ne dé nit rien d’autre qu’une enveloppe contenant les informations à transmettre (englobant une entité entête et une entité corps). La partie entête pouvant être optionnelle contient l’entête du protocole de transport (par exemple HTTP) ainsi que les métadonnées qui portent sur d’éventuelles propriétés non fonctionnelles du service (contexte de transaction, certificat de livraison, etc.). La partie corps regroupe, quant à elle le contenu du message.
La couche description
Dans le cadre des recommandations du modèle de référence OASIS, une description de service représente les informations nécessaires afin d’utiliser un service et facilite la visibilité et l’interaction entre les consommateurs et les fournisseurs de services. Le protocole SOAP met à la disposition des services web, un moyen standard de structuration et d’échange de messages XML. Il ne fournit en aucun cas une indication sur la structure que le message doit respecter vis à vis du service web sollicité. La spécification WSDL (Web Service Description Langage) a vu le jour afin d’offrir une grammaire qui décrit l’interface des services web de manière générique. Toutefois, dans un environnement ouvert comme Internet, le modèle de description des services web n’est d’aucune utilité s’il n’existe pas un moyen de localiser aussi bien les services que leurs descriptions WSDL. Un troisième standard a été conçu pour réduire l’écart entre les applications clientes et les services web, appelé UDDI (Universal Description, Discovery and Integration) [17].
La couche qualité de service
A l’heure où le triptyque coût – qualité – délai devient essentiel pour les entreprises, il paraît indispensable de voir émerger des caractéristiques et des métriques qui portent sur la qualité des services web et des architectures orientées services. Ainsi une spécification pour la qualité de service a été proposée : WS-QoS qui met en évidence les différentes composantes de la qualité, comme par exemple la performance, la disponibilité, la mise à l’échelle, la robustesse, l’intégrité, l’accessibilité, etc. Plusieurs travaux ont pour objectif d’exprimer et de mesurer l’une ou l’autre de ces composantes. Certaines composantes de la qualité de service ont été plus largement étudiées.
On retiendra principalement les travaux portant sur la sécurité et la gestion transactionnelle.
Dans le cadre de la qualité de service, on peut aussi recenser des travaux visant à analyser et vérifier le comportement des architectures orientées services afin d’assurer un certain niveau de confiance.
De par le déploiement de savoir-faire et de données sur Internet via des services web, la notion de sécurité devient un point important au sein des architectures orientées services [18]. Plusieurs aspects sont alors à prendre en compte, comme par exemple :
– L’identification d’un client et/ou d’un fournisseur,
– Le cryptage des données,
– L’intégrité des données,
– Le contrôle d’accès.
Au début des services web, leurs fournisseurs considéraient que la sécurité serait entièrement gérée au niveau de la couche transport, au moyen de SSL (8)/TLS (9) (HTTP, HTTPS), c’est pourquoi les standards initiaux (SOAP, WSDL, UDDI) n’abordaient pas la sécurité [19]. Mais celle-ci a pris de l’importance dès lors que les services web se sont multipliés. C’est ainsi que plusieurs spécifications ont commencé à voir le jour telles XML Signature, XML Encryption, SAML (Security Assertion Markup Language) ou encore XKMS (XML Key Management Specification).
La couche de processus
Au commencement des services web, les termes Web Service Composition (WSC) et Web Service Flow (WSF) étaient utilisés pour décrire la composition de services web au sein d’un processus, c’est à dire la combinaison de services existants pour former de nouveaux services. Plus récemment, les termes “orchestration” et “chorégraphie” ont été utilisés [18].
La chorégraphie est, par nature, collaborative. Elle décrit les différents messages qui transitent entre les différents acteurs d’un processus (les services) et donne ainsi une vision abstraite des échanges au sein d’un processus.
Fig. 1.5 Chorégraphie des services
L’orchestration décrit quant à elle comment les services web peuvent interagir entre eux selon une perspective opérationnelle, avec des structures de contrôle, incluant l’ordre d’exécution des interactions.
Fig. 1.6 Orchestration des services
1 W3C : World Wide Web Consortium, est un organisme qui a pour principal objectif la mise au point des normes et protocoles ouverts et libres pour le web.
2 OASIS : Organization for the Advancement of Strutured Information Standards.
3 API : Application Programming Interface
4 HTTPS : Hyper Text Transfer Protocol Secure
5 SMTP : Simple Mail Transfer Protocol
6 FTP : File Transfer Protocol
7 JMS : Java Message Service
8 SSL : Secure Socket Loyer
9 TLS : Transport Layer Security