Cette création est mise à disposition par Gilles Chagnon sous un contrat Creative Commons.
Cours précédent : Plus loin que les formulaires HTML: XForms
Liste des fichiers associés à ce fichier HTML :
version 1.11, dernière mise à jour le 12 septembre 2005.
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.
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é :
la machine distante peut être en possession des données, la nôtre non ;
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)
la machine distante dispose de logiciels plus adaptés au traitement des données.
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.
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.
La procédure de fonctionnement d'un service Web est la suivante :
le service Web définit un format pour les requêtes et les réponses ;
un ordinateur demandeur effectue une requête ;
le service Web effectue une action, et renvoie la réponse à l'ordinateur demandeur.
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.
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.
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 .
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.).
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.
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.
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.
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...
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).
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.
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".
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.
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.
A la date d'écriture de ce cours (mai 2004), quatre freins bloquent encore le développement de ces outils.
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 ;
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 ;
les services Web ne sont pas encore très répandus ; il est donc encore peu probable de trouver l'objet de sa recherche ;
enfin, et cela est lié à la remarque précédente, ce qui est rare est cher... même si certains services Web sont gratuits.
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...
Cette création est mise à disposition par Gilles Chagnon sous un contrat Creative Commons.
Cours précédent : Plus loin que les formulaires HTML: XForms
Liste des fichiers associés à ce fichier HTML :
Cette création est mise à disposition par Gilles Chagnon sous un contrat Creative Commons.