Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

eZHumanCAPTCHACode reload
retour

Trois protocoles pour les services web

Trois protocoles pour les services web

Il existe principalement trois protocoles standards pour mettre en œuvre des services web : XML-RPC, REST et SOAP.

Soulignons tout d’abord qu’en matière de middleware – comme dans d’autres domaines d’ailleurs – on recherche un compromis entre la perfection théorique du protocole et sa simplicité. C’est ainsi que CORBA, un middleware d’interopérabilité des années 90, n’a pas eu le succès escompté, car manquant de légèreté. Les architectes du web, en particulier, privilégient la simplicité et la performance (voir par exemple la défense des Plain Old Java Objects sur les EJB) et il est fréquent que le marché leur donne raison.

XML-RPC

XML-RPC est historiquement le premier des protocoles de services web, défini dès 1998.

Il est construit sur HTTP, et s’appuie sur une mise en forme Xml de tous les paramètres de l’invocation du service, et de la réponse, selon une syntaxe générique très simple.

Les variables supportent une dizaine de types, tels que int, float, double, string, date-time, boolean, ainsi que des types plus complexes, matrices et structures.

Considérons un exemple d’appel XML-RPC :

 

Ici, on appelle un service « getDeptName » qui retournera le nom d’un département en fonction de son numéro. Ce service accepte un paramètre unique : le numéro du département, ici le 27.

Et voyons sa réponse :

 

Ici le service a fourni une réponse constituée d’une simple chaîne de caractères : « Creuse ».

On constate sur cet exemple que, tant dans la requête que dans la réponse, la modélisation de l’information est générique, n’utilisant que des balises <param>, <value>, etc, et non pas une syntaxe adaptée à la sémantique du service. C’est un choix simplifiant, mais limitant. Typiquement, il n’est pas possible de valider la syntaxe d’une requête, ou bien d’une réponse, autrement que dans le service lui-même.

REST

REST est un modèle d’échange basé également sur HTTP, le protocole du web. Il n’utilise que les verbes standards du HTTP : GET, POST, PUT, DELETE.

REST est un protocole sans état. Le fait qu’il soit basé sur HTTP le rend très facile à mettre en œuvre dans une infrastructure web, puisqu’il ne demande rien d’autre qu’un serveur web ordinaire. Autrement dit : n’importe quelle application web, quel que soit le langage, peut implémenter un service REST.

Chaque service REST est accédé au moyen d’une URI, qui comprendra l’indication du service et ses paramètres, par exemple :

 

Ici, on invoque un service LireCompte de l’application « Woozweb.com », le service fournit des informations relatives à un compte utilisateur, dont l’identifiant est spécifié.

Notons que la syntaxe du REST en lecture masque parfois l’aspect « invocation d’une fonction », pour une logique davantage orientée « accès à une ressource ». Dans cette voie, l’URI précédente pourra devenir simplement :

 

On voit que c’est sensiblement plus simple qu’un appel XML-RPC.

Cette simplicité, et la relative lisibilité des interfaces, le rend également très simple à tester, que ce soit « à la main », en saisissant des URIs, ou bien au moyen d’un outil de test ou d’un robot.

REST est un protocole qui vise la performance, et à ce titre il est plus adapté aux plateformes web, en particulier par rapport à SOAP. C’est par ailleurs un protocole « cachable », c'est-à-dire que le résultat d’un GET (lecture) présentant les mêmes paramètres, donc la même URI, pourra être considéré valable pendant la durée de vie spécifiée, exactement à la manière d’une page web.

Voyons maintenant les formats de réponse.

En fait, REST ne donne pas de règle concernant le format de réponse. Dans certains cas, un service REST peut fournir différentes représentations possibles de sa réponse, et c’est le client qui spécifie la représentation demandée, en renseignant l’attribut « accept » du header HTTP, par exemple accept=text/html, ou bien accept=text/xml.

Mais ce n’est pas vraiment recommandé. Plutôt que de faire des services multi-interfaces, on préfèrera construire des services purement « orientés machines », pour lesquels on choisira évidemment une représentation Xml, ou dans quelques cas JSON pour s’interfacer directement à un client en Ajax. Et l’on pourra ensuite construire une couche d’interface par-dessus ce service « orienté machine », couche d’interface qui peut être en forme de service REST également.

Notons que ni REST ni XML-RPC n’exposent leurs interfaces, c'est-à-dire ne fournissent un moyen, pour un programme client, de découvrir les spécifications de l’interface. En interne à une plateforme, c’est une limitation peu contraignante, les développeurs peuvent lire les spécs. Mais il est vrai que dans une approche SOA généralisée, ouverte sur l’extérieur, la publication du service et l’exposition de ses interfaces sont importantes. Dans les faits toutefois, il est pratiquement impossible de construire un programme client qui ait l’intelligence requise pour (a) découvrir les services proposés et leurs interfaces, (b) choisir un service approprié, (c) construire une requête adaptée à l’interface de ce service, et (d) analyser la réponse et utiliser les informations fournies. L’exposition des interfaces n’est pas tant tournée vers des programmes aussi intelligents, elle est plutôt destinée à s’intégrer à des processus et outils de développement.

SOAP

Le protocole SOAP est le descendant de XML-RPC, auquel il ajoute quelques qualités, en premier lieu la diversité des protocoles sous-jacents, qui peuvent être SMTP, HTTP, ou bien des protocoles de type MOM, Message Oriented Middleware. C’est donc le plus compatible avec un fonctionnement asynchrone, même si on peut créer des interfaces REST vers un MOM.

SOAP se distingue aussi de XML-RPC par la représentation des données. Elle est aussi basée sur XML, mais peut utiliser des formats plus complexes ainsi que des namespaces spécifiques, ce qui permet une représentation sémantique des données, ainsi qu’un contrôle de conformité intégré.

Un exemple de format de requête :

 

On observera en particulier l’introduction d’un namespace spécifique à l’application, ici « m : », dont la définition est donnée en référence, http://www.smile.fr/xmlns/woozweb.

Et sa réponse:

 

De la même manière ici, le prix n’est pas juste un entier, c’est une variable de type m:Availability.

On observe aussi, sur cet exemple, que tout cela est un peu verbeux, mais c’est le prix à payer pour la flexibilité, l’extensibilité, et l’interopérabilité.

Il faut souligner toutefois que cette syntaxe des messages n’est pas à gérer par le programmeur lui-même. C’est le bénéfice de la standardisation : les outils de développement prennent en charge le plus gros du travail. Ainsi dans de très nombreux environnement, transformer une méthode ordinaire en un service SOAP est pratiquement immédiat et transparent.

SOAP est un protocole plus complet et plus complexe que les précédents. Il requiert un serveur spécifique, par exemple AXIS de Apache, et non un simple serveur web. Il est en général moins performant que REST.

SOAP est en particulier peu approprié pour des échanges internes à une plateforme, et convient davantage aux interfaces externes. Il est vrai – on l’a souligné plus haut – que l’on ne sait pas toujours quelles interfaces que l’on croyait internes seront un jour à exposer en externe.

Services et interfaces

Dans les débuts du web, on ne s’adressait pratiquement qu’aux humains. Il arrivait parfois que des « machines », i.e. des programmes, aient besoin de l’information fournie par des sites ou applications web. Les machines se faisaient alors passer pour des humains, à la manière de Kelkoo allant collecter des informations de prix dans les pages web des sites marchands. Cette technique, de screen scraping, ou web scraping, ce qui signifie « gratter les pages web » pour y trouver des données, était laborieuse, instable et fragile. Le moindre changement de charte graphique obligeait à reconfigurer la collecte.

Ce besoin d’utilisation du web par des machines et non par des humains s’est étendu, et aujourd’hui, un principe de base des architectures web est que n’importe quel service devrait pouvoir être appelé par un programme.

 

Ce qui peut se représenter sur le schéma suivant :

image028

Dans le périmètre du bas, nous avons une application web, avec des services internes REST, tous purement orientés machines (text/xml). Et au dessus de ces services on construit une couche d’interface, avec des services orientés humains.

L’application web moderne est donc construite en deux couches (au moins) :

  • Une couche services, aux interfaces « orientées machines »
  • Une couche interfaces, habillant la couche services, à destination des humains.

La couche service est généralement REST ou bien SOAP.

C’est en particulier le modèle retenu par les progiciels modernes, qui se généralise depuis quelques années :

  • Les progiciels encapsulent totalement leurs données – il est donc interdit d’accéder à leur base de données.
  • Ils fournissent des services
  • Ils peuvent être utilisés aussi bien par des humains que par des programmes.

Il faut le souligner, c’est la condition d’une réelle capacité à intégrer ces progiciels au reste du système d’information. S’il s’agit d’une application de RH, elle exposera des services permettant d’accéder au dossier d’un employé, de créer un employé, de modifier le poste ou le salaire, etc.

C’est aussi ce qui permet de totalement refondre la couche interface d’un progiciel, que ce soit pour une utilisation requérant une ergonomie spécifique, ou bien simplement pour une harmonisation graphique.

MOM open source – Apache ActiveMQ

Il existe un petit nombre d’outils MOM de qualité en open source. On peut citer ActiveMQ de Apache, JBoss Messaging, maintenant de Redhat, ou encore Joram, de ObjectWeb, ou encore Glassfish Open Message Queue, de SUN.

Lorsque Apache propose un bon produit, il s’impose souvent. Intéressons nous donc plus particulièrement à ActiveMQ.

ActiveMQ présente des APIs pour pratiquement tous les langages et environnements : C, C++, C# / .Net, Delphi, Flash / ActionScript, JavaScript, Perl, PHP, Python, etc.

ActiveMQ offre aussi des interfaces REST pour l’émission et la réception de messages, ce qui est facile à interfacer dans n’importe quel environnement, mais n’offre pas la richesse d’une interface de type JMS. La publication d’un message utilise un POST http, et la lecture un GET ou un DELETE.

La persistance des messages peut s’appuyer sur n’importe quelle base de données, accédée en JDBC, avec par défaut Apache Derby, qui est une base full-java. Depuis la version 5, la persistance est assurée par défaut sur un message store spécifique, AMQ Message Store, qui est plus rapide qu’une base de données, car spécialisé sur sa mission plus simple.