Architecture des services Web

Les services sont implantés par les fournisseurs, qui mettent à disposition les descriptions de services sous forme de fichiers. Ces descriptions sont centralisées et stockées dans des annuaires. La notion d’annuaire est comparable aux annuaires téléphoniques. Les applications clientes envoient des requêtes aux annuaires pour sélectionner les services. Elles téléchargent ensuite les descriptions des services sélectionnés, et les invoquent directement [MRI07]. Ces mécanismes sont illustrés par la figure 02.

Page 11

Figure 02 : Architecture des services Web

Pour garantir l’interopérabilité des trois opérations précédentes (publication, recherche et liaison/invocation), des standards ont été élaborés pour chaque type d’interaction.

1.2.2.1.1 WSDL: Web Service Description Language

Le standard de description des services Web proposé par le W3C est le langage WSDL (Web Service Description Language). WSDL, basé sur XML, permet de décrire le service Web, en précisant les méthodes disponibles, les formats de messages d'entrée et de sortie, et comment y accéder. Un document WSDL décrit un service Web en deux parties : une partie abstraite et une concrète. C’est à dire, la séparation de ”quelle” fonctionnalité est fournie de ”comment” et ”ou” celle-ci est offerte. La figure 03 présente la structure fondamentale d’un document WSDL.

La découverte sémantique des services Web géographiques

Page 12

Pour la définition des services un document WSDL utilise les éléments suivants [CHR01]:

• Types: ils définissent des types de données échangées;

• Message: Il définit d'une manière abstraite des données transmises;

• Opération: elle décrit d'une manière abstraite les actions supportées par le service;

• Port type: il représente un ensemble d'opération correspondant chacune à un message

entrant ou sortant;

• Binding (Rattachement): est un protocole de communication et un format de données

échangées pour un port;

• Port: est une adresse d'accès au service;

• Service: il regroupe un ensemble de port.

La relation entre les composants d’un document WSDL est illustrée dans la figure 04. Chaque document WSDL définit un service comme une collection de points finaux ou ports. Chaque port est associé à une liaison spécifique qui définit la manière avec laquelle les messages seront échangés. Chaque liaison établit une correspondance entre un protocole et un type de port. Ce dernier se compose d’une ou plusieurs opérations qui représentent une définition abstraite des capacités fonctionnelles du service. Chaque opération est définie en fonction des messages échangés au cours de son invocation (inputs/outputs) [MEL 04].

Figure 04 : Relation entre les éléments d’un document WSDL

1.2.2.1.2 UDDI: Universal Description, Discovery and Integration

Une fois le service Web décrit par son fournisseur, pour qu’il puisse être utilisé (et réutilisé) par le plus grand nombre de clients, il doit être publié dans un registre public. Nous présentons le registre UDDI qui a un ensemble de spécifications pour la mise en œuvre de registres pour les

Page 13

services Web, couramment utilisé dans l’implémentation de registres internes aux organisations. Il définit comme un annuaire de service accessible sur le Web décrivant les sociétés et les services proposés, aussi bien d'un point de vue fonctionnel que technique, permettant aux utilisateurs de découvrir les services disponibles. Cet annuaire définit comment réagir avec un service et permet une immatriculation mondiale. Il peut être implanté au niveau mondial sur Internet ou au niveau d'entreprise sur intranet. Parmi le panel de registres accessibles via le Web (tels que Web Service

List), nous citons XMethods et RemoteMethods (détaillés dans [LOP08]).

Le protocole UDDI est une plateforme destinée à stocker les descriptions des services Web disponibles, à la manière d’un annuaire de style “Pages Jaunes”. Des recherches sur les services peuvent être effectuées à l’aide d’un système de mots-clés fournis par les organismes proposant les services. UDDI propose également un système de “Pages Blanches” (adresses, numéros de téléphone, identifiants...) permettant d’obtenir les coordonnées de ces organismes. Un troisième service, les “Pages Vertes”, permet d’obtenir des informations techniques détaillées à propos des services et permettent de décrire comment interagir avec les services en pointant par la suite vers une description WSDL [BAG03].

Comme le montre la figure 05, une description UDDI doit contenir quatre catégories de données [OAS02] :

• BusinessEntity (entité d’affaires): information sur le fournisseur du service.

• BusinessService (service d’affaires): information décrivant une famille particulière de services techniques.

• BindingTemplate (modèle de rattachement): information technique sur les points d’accès

aux services et leur implémentation.

La découverte sémantique des services Web géographiques

Page 14

Figure 05: Structures de données “noyau” d’UDDI (extrait de [OAS02])

Le modèle de description UDDI semble très orienté “commerce” (ventes, prestations), donc a priori éloigné des besoins de consultations de traitements géographiques [YAN06]. Les annuaires UDDI existent sous une forme XML. Le modèle de description UDDI est défini dans un schéma XML. Des API sont disponibles pour interroger les annuaires UDDI et y référencer des services Web [OAS02]. Le protocole d'utilisation de l'UDDI contient trois fonctions de base [BEN09]:

• publish pour enregistrer un nouveau service;

• find pour interroger l'annuaire;

• bind pour effectuer la connexion entre l'application cliente et le service.

La relation entre le WSDL et l’UDDI est assurée par les correspondances (interface du service (WSDL) -> tModel (UDDI) et implémentation du service (WSDL) -> Business Service (UDDI)) comme illustré dans la figure 06.

Page 15

1.2.2.1.3 SOAP: Simple Object Access Protocol

SOAP (Simple Object Access Protocol) [SOA07] est un protocole léger destiné à l’échange d’informations structurées dans un environnement distribué. Il utilise des technologies XML pour définir une structure de messages pouvant être échangés sur divers protocoles sous-jacents (p.ex. HTTP, SMTP). Cette structure a été conçue pour être indépendante de tout modèle de programmation et autre sémantique spécifique d’implémentation. Un message SOAP est une transmission unidirectionnelle entre des nœuds SOAP (d’un émetteur vers un récepteur SOAP). Un message SOAP contient deux sous-éléments à l’intérieur de l’élément Envelope externe: un élément

Header (en-tête) et un élément Body (corps) (voir figure 07). Les contenus de ces éléments sont

définis par l’application et ne font pas partie de la spécification de SOAP.

Figure 07 : Structure d'un message SOAP

L'objectif du protocole SOAP est de permettre l'invocation des services Web, qui offrent des opérations métier sur des ports de connexion. Couplé à WSDL, le SOAP fournit à l'application cliente des outils nécessaires pour invoquer des services distants en lui donnant l'illusion qu'ils sont locaux.