- Tous les cours
- Conditions d'utilisation
- À propos de ces cours
- Contact

# Cours de XML - Quelques mots sur les Services Web

version 1.11, dernière mise à jour le 12 septembre 2005.

Chercher dans le cours :

## Table des matières (TdM)

1. I. Généralités
   1. Introduction
   2. Qu'est-ce qu'un service Web?

1. II. Trouver un service Web
   1. Universal Description, Discovery and Integration - UDDI
   2. Web Service Description Language - WSDL

1. III. Accéder à un service Web
   1. XML Remote Procedure Calling - XML-RPC
      1. Principe
      2. Exemple et limitations
   2. Simple Object Access Protocol - SOAP
      1. Principe
      2. Exemple et limitations

1. IV. Utiliser un service Web: récapitulation et inconvénients
   1. Comment choisir un service Web
   2. Les inconvénients

Retour au menu

## Contenu du cours

### I. Généralités

#### 1. Introduction

Les services Web sont un mot à la mode, et sont actuellement promus par, entre autres, Sun, Oracle, HP, Microsoft et IBM. Mot nouveau, mais concept ancien car il s'agit ni plus ni moins que de déporter le traitement de données d'un poste client, vers un poste serveur sur lequel "tourne" l'application.

>Retour à la TdM

Alors que voici quelques années, l'utilisation du réseau pour un tel débit de données était encore problématique, il n'en est plus tout à fait de même aujourd'hui. Trois raisons pourraient inciter à opter pour un tel traitement déporté :

1. la machine distante peut être en possession des données, la nôtre non ;

2. la machine distante peut disposer d'une puissance de calcul supérieure (attention, cela ne suffit pas : il faut également tenir compte de la rapidité du débit entre les deux machines)

3. la machine distante dispose de logiciels plus adaptés au traitement des données.

>Retour à la TdM

Par le passé, de nombreuses solutions propriétaires ont coexisté. Il était également possible de développer "au coup par coup" des solutions adaptées à des situations particulières. Heureusement, des efforts de standardisation ont été récemment entrepris.

>Retour à la TdM

#### 2. Qu'est-ce qu'un service Web?

C'est le fait de mettre des ressources à disposition (gratuite ou non) sur Internet, via un protocole d'échanges standardisé, pour des programmes écrits dans des langages quelconques.

Cela nécessite :

- un encodage (toujours `XML`) ;

- un transport (souvent `HTTP`) ;

- une organisation des requêtes et des réponses.

>Retour à la TdM

La procédure de fonctionnement d'un service Web est la suivante :

1. le service Web définit un format pour les requêtes et les réponses ;

2. un ordinateur demandeur effectue une requête ;

3. le service Web effectue une action, et renvoie la réponse à l'ordinateur demandeur.

>Retour à la TdM

Un service Web peut par exemple :

- récupérer un cours de bourse

- faire une demande automatiquement mise à jour d'un prix ;

- accéder à un calendrier universel faisant les conversions entre calendriers internationaux et connaissant, pour chaque pays, les dates des jours fériés ;

- traduire un passage

- valider un numéro international de code postal...

Les possibilités sont donc nombreuses.

>Retour à la TdM

Pour pouvoir utiliser un service Web, plusieurs étapes sont nécessaires :

- il faut savoir le trouver...

- ... puis connaître la méthode pour y accéder...

- ... enfin savoir l'utiliser correctement.

Nous allons successivement examiner ces trois étapes.

>Retour à la TdM

### II. Trouver un service Web

La première étape est de savoir où trouver un service Web, ensuite de savoir précisément ce qu'il fait. Pour cela, il existe un annuaire, UDDI, et un protocole de description, WSDL.

#### 1. Universal Description, Discovery and Integration - UDDI

IBM, Microsoft et Ariba se sont entendus pour développer le projet UDDI. Il s'agt d'une sorte d'annuaire, disponible à http://www.uddi.org, où il est possible de référencer un service Web, gratuitement (ce service pouvant lui-même être payant pour son utilisateur).

L'ensemble est développé dans le cadre d'Oasis, un consortium d'entreprises dont le but est de promouvoir le développement des nouveaux formats, notamment `XML`, dans des échanges standardisés entre entreprises (ce consortium travaille par exemple sur un format de facture, des fichiers de documentation -DocBook-, etc.).

>Retour à la TdM

#### 2. Web Service Description Language - WSDL

Ce format, écrit en `XML`, a pour but de décrire, de manière normalisée, des API (Application Programming Interfaces). Il s'appuie sur les schémas XML. Il s'agit d'un langage très complexe, car il a été pensé dans le but de pouvoir être adaptable à n'importe quel Service Web -y compris ceux qui existaient avant la généralisation des protocoles actuels.

Le W3C, qui en est à l'origine, a mis à disposition la recommandation officielle sur son site.

>Retour à la TdM

Il permet de décrire notamment

- le fournisseur du service Web ;

- les informations que ce dernier peut donner ;

- le format des requêtes...

Il existe une autre application de ce format. Comme la description d'un service Web répond à une forme standardisée, il est possible d'en tirer automatiquement une documentation, plus lisible pour un être humain, sous la forme d'un WSDL simplifié (Simplified WSDL).

On peut également envisager l'écriture de clients analysant seuls, automatiquement, le fichier `WSDL` et en déduisant le format d'échanges et le protocole à utiliser pour "discuter" avec le Service Web.

>Retour à la TdM

### III. Accéder à un service Web

Il existe plusieurs formats concurrents pour définir le format de données en entrée et sortie d'un service Web. Nous allons aborder XML-RPC et, plus récent, SOAP.

#### 1. XML Remote Procedure Calling - XML-RPC

##### a. Principe

XML-RPC est le plus simple des formats d'échange. Le principe de base est le suivant :

- sur le poste client, une bibliothèque encode les paramètres de la requête en `XML` ;

- sur le poste serveur, une (autre) bibliothèque les décode et les transmet à l'application.

La procédure inverse a lieu lors de l'envoi de la réponse à la requête vers le poste client. En définitive, le programmeur n'a jamais besoin de coder lui-même le format de sortie en `XML`, puisque, dans le cadre du langage de programmation qu'il utilise, des fonctions se chargent des opérations à sa place. Il n'en voit que le résultat final.

Le transfert des données se fait selon le protocole HTTP.

Il existe des bibliothèques en Perl, C, Python, Java, VB/.Net, PHP...

>Retour à la TdM

##### b. Exemple et limitations

Par exemple, Adam's Names, qui est une sorte de "WhoIs" pour les sites hébergés dans plusieurs îles du Pacifique, utilise ce protocole.

Le système a malheureusement des limites. En théorie, par exemple, les seuls transferts autorisés se font sous le format ASCII, même si des extensions -non officielles- autorisent les transferts en Unicode. De plus, ce format n'est pas normalisé par un organisme indépendant et neutre (comme le W3C).

>Retour à la TdM

#### 2. Simple Object Access Protocol - SOAP

##### a. Principe

Il s'agit du protocole actuellement le plus en vogue -il est promu par le W3C lui-même et Microsoft, et la première recommandation date de juin 2003.

Le principe est le même : le programmeur ne voit jamais le fichier `XML` que son poste émet ou reçoit, car tout est géré par une bibliothèque de fonctions et procédures dont il ne perçoit que le résultat final, avec le format habituel de son langage de programmation favori.

Des bibliothèques `SOAP` existent pour Perl, C, C#, Python, Java, VB/.Net, PHP, même Ada...

`SOAP` permet d'utiliser le même typage de données que celui des schémas XML, des tableaux, des structures... bref, il est plus complet (et donc plus complexe...) que `XML-RPC`.

>Retour à la TdM

##### b. Exemple et limitations

L'exemple suivant illustre une requête `SOAP` simple, demandant à un serveur si un code postal est valable dans le Royaume Uni :

<env.Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope">
<env.Body>
<m:ValidatePostcodeResponse m:env:encodingStyle="http://www.w3.org/2001/06/soap-encoding" xmlns:m="http://www.lesiteduserviceweb.com/Postcode">
<PostCode>WC1A8GH</PostCode>
<Country>UK</Country>
</m:ValidatePostcodeResponse >
</env.Body>
</env.Envelope>

En réponse, le serveur enverra le même type d'"enveloppe" ; mais le corps du message (`<env:Body>`) se limitera à l'élément `<Valid>Yes</Valid>`.

Une des limitations principales de ce format est, par sa nature `XML`, son côté "usine à gaz".

>Retour à la TdM

### IV. Utiliser un service Web: récapitulation et inconvénients

#### 1. Comment choisir un service Web

Reprenons notre exemple de recherche de code postal, et plaçons-nous dans la peau du développeur d'une application, qui doit entre autres (mais ce n'est pas là sa fonction première) vérifier la validité de codes postaux pour une trentaine de pays.

Les données ne sont peut-être pas gratuites ; développer un tel module dans l'application peut de surcroît prendre un temps non négligeable. La solution peut être un service Web.

Il suffit alors de regarder un annuaire -UDDI- pour constater si un tel service Web existe. Si oui, on vérifie (grâce au fichier `WSDL`) que le service fait bien ce qu'on désire qu'il fasse, puis on peut prendre contact avec la compagnie qui le propose, vérifier sa solvabilité, la fiabilité de sa connexion réseau, enfin acheter éventuellement le service si cela s'avère plus rentable.

>Retour à la TdM

Une fois que l'on a décidé d'avoir recours à un service Web, l'essentiel est fait. Il suffit alors de lire la spécification précise du service (une étape qui peut être automatisée si le service est décrit avec `WSDL`), et d'écrire le client en faisant appel aux fonctions et bibliothèques disponibles pour son langage de programmation favori (par exemple, VB.Net).

Du côté du développeur d'un service Web, une profonde réflexion doit avoir lieu en préalable à toute mise à disposition du service au public, notamment sur une définition rigoureuse et stable de l'interface (il serait malvenu de demander à tous les clients de mettre à jour leurs programmes, sous le simple prétexte qu'une balise a légèrement changé de nom...), mais aussi sur les inévitables questions de sécurité et de confidentialité des échanges.

>Retour à la TdM

#### 2. Les inconvénients

A la date d'écriture de ce cours (mai 2004), quatre freins bloquent encore le développement de ces outils.

1. les transferts se font en `XML`. Or un tel fichier est assez gros (par rapport, par exemple, à un fichier binaire), et pour peu que le service soit un tant soit peut complexe, les échanges peuvent être lents ;

2. la lenteur de ces échanges vient de l'utilisation du réseau. Cela signifie que si une partie importante du code d'une application dépend d'une requête à un service Web, et que le réseau, pour une raison quelconque, est paralysé, l'application sera dans l'incapacité de fonctionner correctement. Il y a donc une très forte dépendance de contraintes extérieures pas forcément contrôlables ;

3. les services Web ne sont pas encore très répandus ; il est donc encore peu probable de trouver l'objet de sa recherche ;

4. enfin, et cela est lié à la remarque précédente, ce qui est rare est cher... même si certains services Web sont gratuits.

>Retour à la TdM

Certains services Web sont néanmoins d'ores et déjà accessibles :

- Google propose des services de recherche

- Amazon offre gratuitement l'accès à son service Web...

>Retour à la TdM

## Historique de ce document

- Le 12 septembre 2005, version 1.11. Corrections typographiques.
- Le 13 juillet 2005, version 1.10. Réécriture des exemples.
- Le 25 juin 2004, version 1.01. Corrections typographiques.
- Le 19 mai 2004, version 1.00. Création du cours

## Bibliographie

### De l'auteur (G. Chagnon)

- XML, publié par Pearson Education en septembre 2007. Livre de cours et exercices écrit en collaboration avec Florent Nolot (Université de Reims). Consulter la fiche sur Eyrolles. Consulter la fiche sur Amazon.

## Conditions d'utilisation et licence

Cette création est mise à disposition par Gilles Chagnon sous un contrat Creative Commons.

Retour au menu