• Aucun résultat trouvé

1.1 Services Web multimédia

1.1.2 Services Web mis en œuvre selon le protocole SOAP

L’architecture des SW selon le protocole SOAP est typiquement constituée de trois entités indépendantes et réparties : Le fournisseur, le registre et le client, tels que montrés sur la figure 1.1.

1.1. SERVICES WEB MULTIMÉDIA 5 L’intégration des trois entités est assurée par les langages et les protocoles suivants : • XML est un langage populaire facile à interpréter par l’homme et par la machine.

XML permet de représenter les données d’une manière standard et indépendante de plate-formes.

• SOAP est un protocole de communication entre les applications sur le Web. SOAP est fondé sur XML et HTTP,

• WSDL est un langage fondé sur XML pour décrire l’interface d’un service Web de façon abstraite [114]. WSDL est nécessaire pour l’identification, la description, la découverte et l’exploitation d’un service Web.

• UDDI (en anglais, Universal Description, Discovery and Integration) [112] est un registre de SW qui sert à promouvoir les descriptions en WSDL des services. L’UDDI offre un API permettant aux clients et aux fournisseurs de manipuler les descriptions de services.

Une fois un service implémenté, le fournisseur procède à le promouvoir pour des clients potentiels. Un scénario de création et d’exploitation d’un service Web se présente comme suit :

1. Le fournisseur implémente son service Web selon les interfaces standardisées pour le Web. Il publie une description de son service en WSDL qui est déposée dans le registre UDDI. Une fois cette phase terminée, le service est disponible et prêt pour des clients potentiels.

2. Le registre est une entité intermédiaire entre le fournisseur de services et le client. Il fait la promotion des descriptions WSDL des SW. Le registre classifie le nouveau service dans ses répertoires (bases de données) afin de faciliter les recherches effectuées par des clients, à savoir que l’UDDI est publique et accessible à travers le Web.

3. Le client désirant utiliser un service Web, effectue une recherche selon des mots- clés pertinents dans un registre UDDI, à l’aide d’un API spécifique de ce dernier. Le registre lui envoie une liste des descriptions de tous les SW correspondants.

4. Le client choisit l’un des services retrouvés dans l’UDDI et commence à exploiter le service en envoyant directement des messages (requêtes) SOAP à l’aide des informations fournies par le document WSDL. À noter que toutes les communi- cations entre les 3 joueurs : fournisseur, client et UDDI, se font en SOAP qui est transporté sur HTTP.

Le protocole SOAP permet la communication entre des applications sur le Web. Étant basé sur XML et le protocole de transport HTTP, SOAP [42] offre des caractéristiques intéressantes qui se résument comme suit :

• Il facilite l’échange de messages entre les applications sur des plates-formes multiples, vu qu’il est transporté sur HTTP, déjà supporté à travers le Web. SOAP sert à encoder des messages et à définir des messages RPC en XML. Un message SOAP est composés de deux parties : le contenu et l’en-tête sous forme XML. Les applications communiquent généralement entre elles à l’aide du RPC (Remote Procedure Call), ce qui impose une barrière de compatibilité et de sécurité puisque RPC pourrait être bloqué par plusieurs serveurs et proxies. Par contre, HTTP est supporté par tous les serveurs et les applications Web.

• SOAP ne dépend ni des systèmes d’exploitation ni des technologies particulières des langages de programmation.

WSDL [115] est un langage fondé sur XML servant à décrire les interfaces de services offerts par des fournisseurs de SW, ce qui permet aux clients de découvrir ces services en effectuant des recherches selon des critères diversifiés. WSDL est inspiré de SOAP et de NASSL (en anglais, Network Accessible Service Specification Language) d’IBM [114]. WSDL et SOAP étant fondés sur XML, ils utilisent des namespaces afin d’ajouter des informations supplémentaires dans le but de définir leurs éléments standards. Ces éléments standards sont ainsi interprétés d’une manière spécifique. L’interaction entre SOAP et WSDL peut être résumée comme suit : WSDL offre un mécanisme décrivant un ensemble d’appels de fonctions (opérations) à distance sous forme d’un port accessible par un échange de messages SOAP [130].

WSDL décrit les SW de deux manières : abstraite et concrète. WSDL 2.0 décrit les SW à l’aide de termes et d’éléments spécifiques, en particulier nous avons les éléments suivants :

Operation est une association de messages avec une certaine séquence (en anglais,

pattern) d’échange de messages.

Interface sert à regrouper des opérations sans être reliée à un moyen de transport.

Binding spécifie les détails du transport pour les interfaces.

Service regroupe des points terminaux qui implémentent une interface commune.

1.1. SERVICES WEB MULTIMÉDIA 7 La notion de namespaces est souvent utilisée dans le contexte de SW pour décrire l’emplacement des documents standardisés qui réglementent le format d’un document WSDL (comme un schéma XML).

La balise principale dans un document WSDL 2.0 est appelée Definitions dans laquelle se trouvent d’autres composants catégorisés comme suit :

• Des composants WSDL représentés par les éléments : interfaces, bindings (relieurs) et services.

• Des composants spécifiques appelés composants d’un système-type (en anglais, type system components) représentant les déclarations reliées à un système-type. C’est-à-dire que ce sont des déclarations d’éléments reliés au service et à sa mise en œuvre. Ces composants sont représentés par l’élément types.

Les propriétés du composant principal Definitions d’un document WSDL se résument comme suit :

• {interfaces} représentent un ensemble d’éléments de type interface2. Elles cor-

respondent à tous les éléments ayant le nom <interface> (sous-éléments de definitions) et leurs définitions qui sont incluses ou importées.

• {bindings} représentent un ensemble d’éléments de type binding. Elles cor- respondent à tous les éléments ayant le nom <binding> (sous-éléments de definitions) et leurs définitions sont incluses ou importées.

• {services} représentent un ensemble d’éléments de type service. Elles cor- respondent à tous les éléments ayant le nom <service> (sous-éléments de definitions) et leurs définitions soient incluses ou importées.

• {element declarations} représentent un ensemble de définitions d’éléments nommés dans un document WSDL. Elles correspondent à tous les éléments ayant le nom <types>(sous-éléments de definitions) et leurs définitions importées.

Par exemple, les lignes suivantes représentent un squelette d’un document WSDL : <definitions>

<binding

name="xs\ ! :NCName"

interface="xs\ ! :QName"’ > <documentation />’

[ <fault /> | <operation /> | <feature /> | <property /> ]* </binding>

</definitions>

2Une interface regroupe des éléments de type operation qui décrivent l’échange de messages d’un

Dans un document WSDL, les éléments sont, soit inclus explicitement, soit importés depuis un URI de façon implicite en utilisant une référence. Les sous-éléments qui ont un targetNamespace sont inclus sous un même composant (élément parent comme définitions). C’est-à-dire que l’attribut targetNamespace regroupe un ensemble de définitions de composants, d’éléments et de sous-éléments reliés.

Les lignes suivantes montrent la description en WSDL d’un service Web (agence de voyage TicketAgent) [115]. L’attribut targetNamespace décrit l’URI qui définit les sous-éléments dans le document WSDL. L’élément operation décrit deux opérations, réclamer une liste de vols et réserver un billet, qui sont reliées avec une seule interface. Les déclarations du service se trouvent sur un URI dans l’élément types :

<’xml version="1.0" encoding="UTF-8"’> <wsdl :definitions targetNamespace="http ://example.org/TicketAgent.wsdl20" xmlns :xsTicketAgent="http ://example.org/TicketAgent.xsd" xmlns :wsdl="http ://www.w3.org/2004/03/wsdl" xmlns :xs="http ://www.w3.org/2001/XMLSchema" xmlns :xsi="http ://www.w3.org/2001/XMLSchema-instance"

xsi :schemaLocation="http ://www.w3.org/2004/03/wsdl wsdl20.xsd">

<wsdl :types> <xs :import schemaLocation="TicketAgent.xsd" namespace="http ://example.org/TicketAgent.xsd"/> </wsdl :types> <wsdl :interface name="TicketAgent"> <wsdl :operation name="listFlights" pattern="http ://www.a.org/wsdl/in-out">

<wsdl :input element="xsTicketAgent :listFlightsRequest"/> <wsdl :output element="xsTicketAgent :listFlightsResponse"/> </wsdl :operation>

<wsdl :operation name="reserveFlight"

pattern="http ://www.a.org/wsdl/in-out">

<wsdl :input element="xsTicketAgent :reserveFlightRequest"/> <wsdl :output element="xsTicketAgent :reserveFlightResponse"/> </wsdl :operation>

</wsdl :interface> </wsdl :definitions>