Web services et bibliothèques

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 !

10 réflexions sur “Web services et bibliothèques

  1. Merci pour toutes ces infos! Je sais maintenant beaucoup mieux ce qu’on apelle les web services. Merci aussi pour l’article paru dans la revue Biblioacid concernant figoblog. Intéressant et motivant tout ça!

  2. Bravo pour ce long billet, fouillé et pro. Un bel ajout à ce blog !
    Sinon je ne connais pas franchement la gestion de bibliothèque, mais j’ai déjà pu utiliser les web services au sens SOAP/WSDL/UDDI dans d’autres domaines (SI géographiques, portails web financiers et systèmes multi-agents). Il y a pleins d’inconvénients connus aux WS, mais dans l’ensemble je suis assez fan de cette technologie. Par contre, sans remettre en cause l’ensemble, je pense que l’aspect UDDI tel qu’il a été imaginé est une vaste blague…
    Le principe est beau : quand un programme a besoin de quelque chose qu’il ne sait pas faire, il se connecte tout seul comme un grand à un annuaire UDDI pour chercher un autre programme qui saura, il trouve comment communiquer avec, et puis il lui délègue le boulot.
    Malheureusement, dans la réalité on en est franchement très loin. Au mieux UDDI est utilisé comme annuaire interne dans des grosses boîtes, pour faciliter le boulot des développeurs. Les gens continuent à spécifier « en dur » les services qu’ils veulent utiliser. Du point de vue technique, c’est un peu trop léger en pouvoir de description (même si ça peut s’améliorer avec des trucs du style RDF & co.), et il manque surtout le décisionnel pour implémenter ce genre de comportements. Sans même parler de l’utilité de le faire ! (à mon avis il y a pas grand monde qui a besoin de logiciels qui ne savent pas a priori ce qu’ils doivent faire).
    Je pense que ça rejoint un peu l’éternel problème des ontologies, du web sémantique, & co. C’est une idée superbe, conceptuellement on est capable de construire des trucs de fou qui peuvent décrire le monde entier (j’exagère un peu :-)), mais on n’a pas encore vraiment imaginé les applications pour les exploiter, ni même mis au point les algorithmes pour le faire.
    Est-ce que c’est un point qui est abordé dans ton ouvrage source ? Je ne sais pas, c’est un aspect des WS qui a peut-être évolué depuis quelques temps.
     
    P.S. : au fait merci pour le lien spécial vers mon post Halloween. Je l’avais pas encore vu, ça me fait super plaisir ;-)

  3. Merci, vous êtes chous ;-) Nimwendil : je pense que ta précision sur UDDI est utile. Elle montre qu’il faut aller au-delà de l’idée pure et sortir un peu du conceptuel. Sur ce je vous quitte pour le week-end, on en reparle à mon retour !

  4. Bonjour Manue,

    Merci beaucoup pour ces billets qui sont aussi riches qu’intéressants.

    Il est vrai que les web services deviennent de plus en plus incontournables et par ailleurs intégrés et proposés par nos fournisseurs, que ce soit vis à vis des outils utilisés sur le web ou d’autres utilisés au sein même de notre établissment (interfaçage entre le SID et le SIG avons-nous entendu par exemple).

    Je profite de cette fin de semaine pour te souhaiter un très bon week-end,

    Th.

  5. Une réserve aussi quant à la possibilité d’implémentation en bibliothèque au delà de la recherche (SRU/SRW), en particulier dans le domaine de l’intégration dans tout le workflow des bibliothèques.
    En gros ce qui est couvert par VIEWS.
    Le problème étant que les vendors peuvent proposer des Web Services en théorie, mais pas si les bibliothécaires ne modélisent pas leurs processus: l’interaction avec le fournisseur de la notice est comme çi, l’interaction avec le logiciel de compta est comme ça, etc.

  6. Je suis tout à fait d’accord avec toi Nicolas. Le principal problème pour l’adoption des WS en bibliothèques est la nécesité de modéliser et spécifier. C’est pour cela que des protocoles déjà spécifiés, comme OAI ou SRU/SRW, sont si séduisants. Mais on pourrait aussi imaginer que la modélisation/ spécification des systèmes informatiques devienne demain une compétence essentielle des bibliothécaires (au moins certains – ceux qui se disent « system librarians »), qui pourraient dès lors s’affranchir un peu plus des modèles imposés par les fournisseurs. Non ? Au fait bravo pour le site d’Angers, il est très joli et très bien modélisé

  7. bon article, mais y aurait-il la possibilité de trouver un tuto en francais, sur l’integration d’un flux xml dans un site en php, et ce pour utiliser l’api d’amazon !

    car aucun site francais ne le démontre clairement par A+B mais seulement donnant des grandes phrases très vagues !!!

  8. Je pense également que les Web Services et services REST sont d’une grande utilité et je trouive que cette article le tésume assez bien. C’est aussi extraordianaire le nombre d’articles, de normes et d’organismes qui s’intéressent au sujet… Mais existe-t-il des listes ou annuaires où on peut avoir les Web ou REST services disponnibles, qu’ls soient payants ou gratuits, afin d’y accéder.

  9. j’ai bien lu tout ce que vous avez écrit et je trouve qu’il est riche en informations mais si vous pouviez me monter comment créer son propre annuaire uddi et publier dessus un service précis sa serait aimable de votre part. sachant que je veux utiliser ce dernier comme projet de fin d’études. merci d’avance

Les commentaires sont fermés.