Deux outils pour les bibliothèques distribuées

Le but de cet article est d'essayer de situer l'un par rapport à l'autre les protocoles de communication Z39.50 et HTTP. Ces deux protocoles, l'un très lié au milieu des bibliothèques, l'autre plus généraliste, sont en effet susceptibles de jouer un rôle important dans le développement des futures bibliothèques réparties. Après avoir rappelé les caractéristiques essentielles de ces deux protocoles, nous mettons en évidence les principaux points sur lesquels ils diffèrent l'un de l'autre. Nous donnons ensuite quelques exemples de projets où ces protocoles ont été utilisés pour construire des bibliothèques électroniques distribuées. Nous concluons sur la nécessité d'une articulation entre ces deux approches.

This paper aims at putting in perspective two communication protocols, Z39.50 and HTTP (the protocol used by the WWW), likely to play an important role in the design of large internetworked library systems. We first give short overwiews of these protocols and we then try to highlight the key points in what they differ from each another. For the sake of illustration we introduce a few real examples of how they can be used to design distributed libraries and information systems. In conclusion we propose exploring the possibility of a convergence of Z39.50 and HTTP.

Der Zweck dieses Aufsatzes besteht darin, die beiden Verbindungsnormen Z39.50 und HTTP gegeneinander vorzustellen. Die erste, mit den Bibliotheken eng verwandt, und die andere, nicht so spezialisiert, sollen ja fähig sein, eine wichtige Rolle in der Entwicklung der Bibliotheken zu spielen. Nachdem die wesentlichen Eigenschaften dieser beiden Protokolle erwähnt werden, will der Verfasser deren Grundunterschiede ans Licht bringen. Es werden nachher einige Beispiele vorgestellt, die diese Normen beim Aufbau verteilter elektronischer Bibliotheken benutzt haben. Als Abschluß wird demonstriert, daß eine Gliederung dieser beiden Elemente immer mehr unentbehrlich wird.

L’association américaine de normalisation (ANSI, American National Standards Institute) vient de valider la version 3 de la norme Z39.50 (1) 1.

Héritière des grands projets bibliographiques en réseau des années 1980 (par exemple le Linked System Project), cette norme a pour objectif de permettre à un utilisateur d’effectuer des recherches documentaires dans des bases de données distantes à travers une interface unique.La nouvelle version a été approuvée au terme de longs travaux qui ont mobilisé les experts des principales institutions bibliographiques américaines (Bibliothèque du Congrès, OCLC, Melvyl, RLG, etc.) 2. Compte tenu de l’influence exercée par ses promoteurs, elle semble destinée à un grand avenir dans le domaine de l’informatisation des bibliothèques.

Cependant, avec la diffusion très rapide des outils Internet, on peut se demander si elle ne risque pas d’être étouffée par les normes de fait qui sont déjà appliquées tous les jours sur le réseau mondial. Des interfaces universelles existent déjà, par exemple celle des browsers du World Wide Web (Mosaic, Netscape, etc.). Ces outils communiquent à l’aide de protocoles simples mais robustes qui semblent satisfaire la majorité des utilisateurs.

Dans ces conditions, on peut se demander pourquoi l’ANSI juge bon de prôner une nouvelle interface de communication spécifique aux bibliothèques. Sans prétendre répondre à cette question, nous essayons de donner ici quelques éléments de comparaison.

La norme Z39.50

Z39.50 est un protocole de communication dédié aux applications de recherche documentaire. Il permet de spécifier les procédures nécessaires pour effectuer des recherches dans des bases de données distantes et le rapatriement sur un poste local du résultat de ces recherches.

Si l’on se réfère à la division en couches utilisée par l’OSI (Open Systems Interconnection), Z39.50 se situe dans la couche application.

Z39.50 est basé sur le modèle client/serveur. La norme suppose en effet qu’une application cliente établisse une connexion avec une application serveur et qu’elle lui demande des services. La norme Z39.50 utilise plutôt les termes origin et target, qui correspondent respectivement aux portions du client et du serveur uniquement dédiées aux tâches de communication (à l’exclusion par exemple de l’interface utilisateur).

Le client (origin), situé sur un sytème local, initie une connexion avec le serveur et lui envoie des requêtes. Le serveur (target), associé à la base de données distante, répond aux requêtes provenant du client et transfère les enregistrements correspondants.

L’interaction entre le client et le serveur s’effectue à travers un échange de messages normalisés (requête et réponse). Les formats et les procédures à appliquer pour le transfert de ces messages sont également définis dans la norme (Protocol specification).

La version 3 définit de nombreux services qu’il serait fastidieux d’énumérer ici. Le cœur de la norme est constitué par quatre opérations de base : Init, Search, Retrieve, Close.

Init et Close décrivent l’établissement et la fermeture de la connexion entre le client et le serveur.

Les opérations Search et ont donné leur surnom aux normes Z39.50 et ISO 10162/10163, souvent appelées normes SR.

Le service Search permet à l’origine d’interroger des bases de données distantes par l’intermédiaire du serveur et de recevoir les résultats de cette recherche.

L’utilisateur saisit une requête sur son système local. Le client traduit cette requête dans un formalisme indépendant de toute base de données et compris par tous les serveurs conformes à la norme Z39.50 3. La requête traduite est envoyée à un serveur Z39.50 associé à la base de données que l’utilisateur souhaite consulter. A réception de cette requête, le serveur la traduit dans une syntaxe compréhensible par la base de données et la soumet à cette dernière. Les résultats de la recherche sont ensuite communiqués au client par le serveur. Le client (et l’utilisateur) n’ont ainsi pas à se soucier de la structure et de la syntaxe propres à chacune des bases de données auxquelles ils veulent accéder.

Le résultat de la recherche crée sur le serveur un result set qui peut être référencé par le client pendant toute la durée de la connexion.

Le service Present permet à l’origine de demander le transfert sur le poste local des enregistrements correspondant à un result set donné.

Le protocole HTTP

HTTP, Hypertext Transfer Protocol (2), est le protocole de communication utilisé par les outils du World Wide Web (WWW). C’est un protocole dédié au transfert d’informations , non à l’interrogation des bases de données. Basé sur un paradigme requête/réponse, il définit le contenu et le format des messages échangés au cours d’une transaction entre un client WWW et un serveur WWW.

Le Web a déjà fait l’objet de nombreuses présentations dans la presse professionnelle. Nous nous limiterons donc ici à une brève description fonctionnelle.

L’utilisateur qui utilise un poste client (souvent appelé browser compte tenu des origines hypertextuelles de WWW) consulte un document contenant des références hypertextuelles. En sélectionnant une de ces références, il provoque une connexion entre le client et le serveur distant qui possède ce document. Dans la plupart des implémentations actuelles, la connexion est établie par le client avant chaque requête et fermée par le serveur après l’envoi de la réponse.

Les requêtes émises par le client spécifient des « méthodes » à appliquer à des « ressources » désignées par des identificateurs Internet nommés URI (Uniform Resource Identifier) (7).

Dans le cas de transfert de document évoqué plus haut, c’est la méthode GET suivie de l’URI du document qui est envoyée au serveur lorsque l’utilisateur sélectionne une référence hypertextuelle.

Le protocole prévoit également d’autres méthodes pour la mise à jour de serveurs à distance, l’invocation de scripts sur le serveur, la création de liens, etc. Seules certaines de ces fonctionnalités supplémentaires sont implémentées sur les clients les plus courants.

Quelques éléments de comparaison

Z39.50 propose des mécanismes sophistiqués pour l’établissement et la libération de la connexion. Des procédures d’identification et d’authentification sont prévues par la norme. Les services disponibles, les ressources, les jeux de caractères à utiliser, la taille des messages peuvent être négociés avant que l’échange ne commence entre le client et le serveur.

En ce qui concerne la recherche, la norme Z39.50 définit des ensembles d’attributs très complets correspondant aux applications de bibliothèque (attribute set ‘bib1’).

Par ailleurs, le result set produit par une question peut être référencé et servir d’opérande dans des questions posées ultérieurement Le fait qu’il gère une véritable session donne au client Z39.50 une certaine « intelligence ».

Cette « intelligence » du client est encore perceptible dans la façon dont les résultats sont affichés. L’affichage des résultats est sous le contrôle du client : des résultats de recherche venant de plusieurs serveurs différents peuvent être affichés de façon strictement identique. Cette caractéristique distingue également le client Z39.50 du client WWW.

En ce qui concerne le transfert des résultats de la recherche, des procédures de segmentation sophistiquées ont été définies pour supporter le transfert de documents volumineux. Ce point est à souligner : bien qu’issue du monde des bibliothèques, la norme Z39.50 n’a pas été prévue pour rechercher uniquement des références bibliographiques. Elle a été conçue pour permettre l’accès à des bases contenant tout type d’informations, y compris des documents primaires.

Comparé à la norme Z39.50, HTTP est un protocole de communication très simple, dédié avant tout au transfert de documents et non à la consultation de bases de données. Un document est demandé par l’utilisateur. Dès qu’il est transféré, la connexion est interrompue. Si l’on veut un autre document situé sur le même serveur, il faut une nouvelle connexion.

Il n’est pas question ici de réutiliser le résultat d’une recherche antérieure (result set). Aucun ensemble spécifique d’attributs (attribute set) n’est non plus défini.

Cependant, HTTP est très souple. Grâce à un mécanisme d’invocation de script particulièrement simple, le client peut envoyer des paramètres au serveur et demander à ce dernier d’effectuer des opérations qui vont au-delà du simple transfert de documents au coup par coup, par exemple des recherches documentaires.

En ce qui concerne le transfert proprement dit, HTTP gère efficacement la plupart des formats de documents existants (les types MIME).

La simplicité et la souplesse de HTTP ont permis au WWW de se développer très rapidement. C’est aussi ce caractère simpliste qui pourrait à terme freiner son essor 4.

Cependant, malgré les différences importantes qui viennent d’être évoquées ces protocoles ont pu être utilisés dans le cadre d’applications de bibliothèques distribuées dont nous donnons ci-après quelques exemples.

L’évolution vers les systèmes distribués

Dans un système informatique distribué, l’utilisateur accède à des ressources et à des données éparpillées géographiquement, tout en ayant l’impression d’interagir avec un système logique unique.

On a déjà dit dans la section précédente qu’un des atouts de Z39.50 était sa capacité à masquer l’hétérogénéité géographique et structurelle des systèmes (hétérogénéité des interfaces ; hétérogénéité des langages de requête). Cette norme semble donc constituer un outil de choix pour réaliser un catalogue collectif « logique » ou « virtuel » (il ne s’agit ici que des aspects consultation). Une première expérience a été réalisée en Irlande, en 1994, dans le cadre du système IRIS. Utilisant Z39.50, le système IRIS permet, à travers une interface unique, d’effectuer des recherches bibliographiques dans les catalogues de six bibliothèques universitaires irlandaises utilisant des systèmes informatiques différents.

Le client Z39.50 présente à l’utilisateur une vision complètement unifiée de tous les catalogues. Par ailleurs, une recherche peut être lancée en parallèle sur plusieurs serveurs.

Notons que le système IRIS a été conçu à l’origine pour permettre la fourniture rapide de documents. Dès qu’il a localisé un ouvrage, l’utilisateur peut, sans sortir du système, en effectuer la commande.

Implémenté dans le cadre du Computer Science Technical report project (CSTR), le protocole Dienst (8) est utilisé pour donner accès par le réseau aux rapports de recherche en informatique, produits par les principales universités américaines. Il peut être vu comme une spécialisation de HTTP : des messages spécifiques à la recherche documentaire sont encapsulés dans HTTP et permettent au client Dienst de demander des services documentaires aux serveurs distants, dont l’ensemble constitue une véritable bibliothèque virtuelle. Les deux services principaux sont :

– Index : ce service permet au client d’obtenir des méta-informations sur un ou des documents stockés sur les serveurs Dienst (auteur, titre, nombre de pages, formats disponibles, etc.) ;

– Repository : ce service permet d’obtenir les documents eux-mêmes. Les critères de recherche sont ceux de la RFC 1357 et, comme le système maintient une vue à la fois de la structure physique et de la structure logique des documents, il est possible de demander une page ou une section d’un document plutôt que le document complet.

Combiner les avantages des deux systèmes

Au terme de cette présentation schématique, nous voudrions insister sur les quelques points suivants.

A l’heure actuelle, Z39.50 est un protocole spécialisé, difficile à mettre en œuvre, mais adapté à la construction de systèmes d’informations répartis complexes. Lié à des systèmes de circulation, à des services de dépouillement de sommaires, il ouvre également des perspectives intéressantes dans le domaine de la fourniture de documents. D’une manière générale, il peut aider le monde des bibliothèques à faire ses premiers pas dans la marche irréversible vers les systèmes distribués.

HTTP est un protocole généraliste, fruste mais simple à mettre en œuvre. Il n’est pas adapté à des tâches documentaires complexes, mais peut être étendu et est utilisé tous les jours par des millions d’utilisateurs.

Dans ces conditions, l’idéal serait de combiner les avantages des deux systèmes en permettant d’accéder à des serveurs Z39.50 à partir d’un client Web. C’est l’orientation à moyen terme que semblent prendre de grandes institutions américaines (Bibliothèque du congrès, Stanford, OCLC, MIT, etc.).

A long terme tout dépend de la façon dont évolueront les protocoles Internet...

Juillet 1995