Les Web services sont des technologies basées sur les standards du Web qui permettent à des applications de dialoguer entre elles. Il fournissent un cadre pour trouver, décrire et exécuter ces applications.

Les caractéristiques des Web services.

Web based : les Web services sont basés sur les protocoles et les langages du Web, en particulier HTTP et XML (tout comme le Web lui-même s’appuie sur les protocoles d’Internet en particulier TCP/IP : c’est une « couche » supplémentaire).

Self-described, self-contained : le cadre des Web services contient en lui-même toutes les informations nécessaires à l’utilisation des applications, sous la forme de trois fonctions : trouver, décrire et exécuter. Il est donc nécessaire pour faire fonctionner un cadre de Web services de disposer d’un annuaire des applications disponibles, d’une description du fonctionnement de l’application, et d’avoir accès à l’application elle-même.

Modular : les Web services fonctionnent de manière modulaire et non pas intégrée. Cela signifie qu’au lieu d’intégrer dans une seule application globale toutes les fonctionnalités, on crée (ou on récupère) plusieurs applications spécifiques qu’on fait intéropérer entre elles, et qui remplissent chacune une de ces fonctionnalités.

Les perspectives

La longévité et la fiabilité d’un système qui vise à fonctionner de manière distribuée se mesurent à l’ampleur de l’implémentation qui est faite du système par l’industrie.

Nous en sommes actuellement à ce stade pour les Web services. Il existe des formats et des protocoles dont le succès montre qu’ils tendent à se détacher et à devenir des standards de fait pour les Web services : il s’agit du triplet SOAP-WSDL-UDDI. Ces trois technologies constituent l’architecture étendue des Web services, actuellement en discussion pour être adoptée comme standard par le W3C.

Il s’agit bien d’une architecture étendue pour les Web services, pas de la seule architecture possible. C’est certainement le cadre le plus large, le plus stable mais aussi le plus complexe pour faire fonctionner des Web services.
On oppose en général cette architecture basée sur SOAP à celle qui utilise REST . REST consiste à utiliser le protocole HTTP simple plutôt que d’avoir recours à une enveloppe SOAP (on verra ce concept d’enveloppe plus loin). Les défenseurs de REST mettent en avant la simplicité d’utilisation et le fait de ne s’appuyer que sur l’existant, ce qui est selon eux un gage d’intéropérabilité. Les défenseurs de SOAP au contraire pensent que c’est la stabilité et la fiabilité d’un système riche et adaptable à toutes situations qui, malgré la complexité qui en résulte, sont les mieux à même de défendre cette intéropérabilité.

L’architecture étendue des Web services

On désignera donc par « architecture étendue » le cadre de Web services qui repose sur SOAP, WSDL et UDDI. Tous trois sont des technologies basées sur XML, ce qui permet en théorie aux applications de Web services de les utiliser de manière autonome (sans intervention humaine) d’un bout à l’autre des opérations.
Cette architecture fonctionne comme une lettre à la poste (vraiment !):

• on dispose d’un annuaire des Web services réalisé grâce à la technologie UDDI. Cet annuaire contient plusieurs types d’informations. Les pages blanches regroupent les informations de contact et d’adresse du service. Les pages jaunes proposent un classement thématique standardisé des différents types de services disponibles. Enfin, des pages techniques décrivent plus en détail le fonctionnement des applications et indiquent comment appeler le fichier WSDL.
• Les fonctionnalités de chaque application et le langage qu’elle comprend sont décrites par un fichier WSDL . WSDL permet donc de savoir pourquoi et comment on peut dialoguer avec l’application cible : quelles informations ou quels services rechercher, quel langage et quelles commandes utiliser, etc.
• SOAP est une enveloppe : on l’utilise pour y mettre le message que l’on souhaite faire parvenir à l’application cible. L’application utilise à son tour une enveloppe SOAP pour renvoyer la réponse. On peut mettre ce que l’on veut dans cette enveloppe, pourvu que ce soit du XML et que ce soit conforme à ce qui est décrit dans le fichier WSDL associé.

Exemple d’application

Une entreprise par exemple Google ou Amazon, décide de créer un Web service. Elle publie son API , c’est-à-dire un fichier WSDL, une application qui permet de l’exploiter, et la documentation qui l’accompagne (des exemples, des tutoriels, etc.). Il peut aussi d’accompagner d’une licence qui définit les conditions d’utilisation (nombre de requêtes autorisées par jour, demande de compte utilisateur…). Un développeur créée ensuite une application capable de dialoguer avec cette API. La nouvelle application intègre les fonctionnalités de l’ancienne.

Cela permet ensuite de créer des outils capables d’interagir avec différents Web services et de proposer des fonctionnalités intégrées. Par exemple Amazon light 4.0 : cette interface utilise l’API d’Amazon pour rechercher un document dans la base d’Amazon.
Elle combine ensuite différentes API (pas forcément en SOAP dans ce cas précis) pour proposer une batterie de services une fois qu’on a trouvé un document intéressant :

• Elle utilise l’API d’Amazon pour trouver le document puis pour fournir les mêmes services qu’Amazon (acheter en ligne, ajouter à sa « wishlist »)
• elle utilise l’API de Gmail pour envoyer un mail, en récupérant le titre du document dans le titre du message et le lien dans le corps du message ;
• elle utilise l’API de Blogger pour créer directement une entrée de blog comportant le titre de l’ouvrage et le lien (je suppose n’ayant pas de compte blogger)
• elle utilise l’API de del.icio.us pour permettre de partager le lien dans ce logiciel en ligne de « social bookmarking »
• elle utilise l’API de Google et en particulier l’indexation de Worldcat par celui-ci pour la fonction « library lookup », qui permet de retrouver directement l’item dans le catalogue de sa bibliothèque (à condition d’habiter en Australie, aux USA et dans quelques autres pays).
• elle recherche des liens en relation avec le document, notamment le résumé dans Google print et les « related links » dans Google et Yahoo.
• etc…

Cet outil illustre parfaitement, dans une logique poussée à l’extrême, les possibilités ouvertes par les Web services dans un domaine orienté objet/document.

Applications en bibliothèque

Un travail a été mené depuis quelques années pour faire évoluer la norme Z3950 vers les technologies Web en utilisant les Web services. Deux cadres d’application ont été développés :

• SRW qui utilise SOAP comme format d’envoi des requêtes et de réponse,
• SRU qui se base sur REST. On utilise alors une série de verbes pour effectuer des commandes, exactement comme pour l’OAI.

La Library of Congress a expérimenté l’utilisation de SRW et SRU pour améliorer son interface Z3950. Pour cela elle a travaillé avec la société IndexData et son logiciel TAZ.

Notons que Index Data fait partie de VIEWS , un groupement de vendeurs de SIGB et d’organisations liées aux bibliothèques (Dynix, Fretwell-Downing, Index Data, Muse Global, OCLC et VTLS) dont l’objectif est de favoriser la collaboration entre partenaires économiques des bibliothèques pour améliorer l’interopérabilité des interfaces grâce aux Web services. Ce groupe est également soutenu par l’oragnisme de normalisation américain NISO.

Les bibliothèques utilisent déjà un certain nombre d’outils qui fonctionnent sur un mode assimilable à REST (requêtes HTTP GET et POST et envoi de documents en XML) comme l’OAI-PMH. Aux yeux de certains, ces outils peuvent être assimilés à des Web services (même s’ils ne font pas partie de l’architecture étendue des Web services).
Je ne reviens pas ici sur les applications possibles de l’OAI en bibliothèque.

En fait, les Web services devraient intéresser les bibliothèques de plusieurs points de vue :

• l’intégration des applications (en interne et en partenariat),
• l’accès au document
• les services au public.

Du point de vue de l’intégration des applications, les Web services représentent une solution d’interopérabilité simple et fiable, en train de devenir un standard de fait. On devrait songer à des solutions comme SRW (qui s’appuie sur SOAP) pour remplacer Z3950 dans l’interrogation distribuée des bases. Si on a plusieurs bases différentes pour différents types de documents, les Web services peuvent être une solution pour mettre en place une interrogation commune sur bases distribuées, transparente pour l’utilisateur, sans modifier ni intégrer les applications.

Du point de vue de l’accès au document, outre la possibilité d’intégrer des métadonnées comme on le fait avec le protocole OAI et avec SRU/SRW, on peut aussi intégrer les applications elles-mêmes. On peut ainsi partager des données grâce à des échanges en temps réel, mais également exploiter directement ce qui relève des applications développées : moteur de recherche, interface de consultation, et pourquoi pas les contenus eux-mêmes et des ontologies pour les décrire (voir sur ce dernier point, par exemple, l’API de SKOS).

Du point de vue de l’usager, les Web services ouvrent la porte à l’intégration de la bibliothèque dans un certain nombre de fonctions en ligne, surtout des fonctions sociales dont l’importance est croissante. Ils permettraient de donner à l’usager des outils simples pour intégrer la bibliothèque aux outils qu’il utilise couramment sur le Web : suivre les nouveautés avec RSS, relier directement les données du catalogue à celles de Google ou d’Amazon… Aller dans le sens d’une intégration des contenus aux dépends des formats, en suivant la tendance actuelle.

Ma principale source est l’ouvrage The Semantic Web : A Guide to the Future of XML, Web Services, and Knowledge Management. Une recherche dans votre moteur préféré vous donnera de nombreux liens vers des articles plus techniques, notamment (il faut bien le reconnaître) ici. Merci à T. et F. pour leurs encouragements qui sont à l’origine du plus long billet de l’histoire de ce blog !