European Schoolnet

Institut de la Francophonie
pour l’Informatique

MEMOIRE DE FIN D’ETUDES

Titre

Construction d’un Gateway SQI pour le réseau
CELEBRATE

Etudiant :

Responsable :

Le Chi Tho, IFI

David Massart, EUN

Bruxelles, avril – septembre 2004


Table des matières

REMERCIEMENTS ..................................................................................................... 4
RESUME...................................................................................................................... 5
ABSTRACT ................................................................................................................. 6
CHAPITRE 1
1.1
1.2

Contexte du travail .................................................................................................................................... 7
Définitions................................................................................................................................................... 7

1.2.1
1.2.2
1.2.3
1.3

INTRODUCTION ................................................................................ 7

Objets d’apprentissage .......................................................................................7
Métadonnées d’objets d’apprentissage ..............................................................7
Dépôts d’objets d’apprentissage ........................................................................9

Problématique ............................................................................................................................................ 9

CHAPITRE 2

LA SPECIFICATION SQI................................................................. 11

2.1

Travaux concernés................................................................................................................................... 11

2.2

Framework pour l’interopérabilité entre dépôts d’objets d’apprentissage ..................................... 11

2.3


Spécification SQI ..................................................................................................................................... 12

2.3.1
2.3.2
CHAPITRE 3

Introduction ......................................................................................................12
Les méthodes de SQI .......................................................................................13
GATEWAY POUR CELEBRATE..................................................... 16

3.1

Le réseau CELEBRATE......................................................................................................................... 16

3.2

Gateway pour CELEBRATE................................................................................................................. 16

CHAPITRE 4

IMPLEMENTATION ......................................................................... 19

4.1

Cas d’utilisation ....................................................................................................................................... 19

4.2

Architecture générale et implémentation ............................................................................................. 21


CHAPITRE 5

CONCLUSION ................................................................................. 27

ANNEXES.................................................................................................................. 28
REFERENCES .......................................................................................................... 33
2


3


Remerciements
Je tiens à remercier sincèrement M.David Massart de m’avoir encadré, de m’avoir soutenu
tout au long de mon stage.
Je tiens aussi à remercier M. Ulf Lundin, directeur de European Schoolnet, pour la gentillesse
qu’il m’avoir apportée.
Je remercie vivement les membres de European Schoolnet de m’avoir accueilli avec bras
ouverts.
J’exprime ma reconnaissance aux professeurs et aux personnes de l’Institut de la
Francophonie pour l’Informatique, de m’avoir apporté des connaissances et de l’aide.
Ma reconnaissance s’adresse aussi à ma famille et mes amis. Leurs encouragements ont
contribué énormément à l’achèvement du stage.

4


Résumé
Avec l’épanouissement du marché de la formation en-ligne, de nombreux dépôts d’objets

d’apprentissage ont vu le jour. Ces dépôts stockent une grande quantité de ressources
pédagogiques comme cours, tutoriels, livres électroniques, … dont la création est souvent très
coûteuse. L’échange et la réutilisation de ces ressources sont donc devenus une néccessité
indispensable qui a suscité des recherches sur l’interopérabilité entre dépôts.
Malheureusement, ces dépôts emploient très souvent des formats de données propriétaires.
De même, ils exposent leurs ressources à travers des protocoles d’accès plus ou moins
différents, ce qui empêche l’interopérabilité entre eux.
Notre travail, encadré dans le projet CELEBRATE, consiste à réaliser un gateway (porte
d’echange) en se basant sur la spécification SQI (Simple Query Interface – Interface Simple
de Requêtes). SQI , une spécification élaborée sous les auspices de « CEN/ISSS Workshop on
Learning Technologies », est une tentative qui définit un ensemble de APIs ( Application
Programming Interface) dans le but d’assurer l’échange et la recherche des objets
d’apprentissage via une interface d’accès simple. Ce gateway permettra à d’autres dépôts
d’objets d’apprentissage de découvrir les ressources de CELEBRATE ou inversement.
Mots clés : e-formation, métadonnées d'objets d'opprentissage, interopérabilité,
objets d'apprentissage, Simple Query Interface, LOM

5


Abstract
With the development of the e-learning market, numerous learning object repositories have
appeared. These repositories store a great number of educational resources such as courses,
tutorials, electronic books,… of which the creation is often expensive. The exchange and reuse of those resources have thus become an inevitable neccessity and have inspired research
works in the area of interoperability between learning repositories. Unfortunately, learning
repositories usually use proprietary data formats. Moreover, they expose their resources via
different access protocols, which impedes the interoperability between them.
Our work, realised in the context of the CELEBRATE project, consists in implementing a
gateway based on the SQI specification ( SQI-Simple Query Interface ). SQI, a specification
elaborated under the auspices of « CEN/ISSS Workshop on Learning Technologies », is an

effort that defines a set of APIs (API - Application Programming Interface) aiming at
ensuring the exchange and search of learning objects via a simple acces interface. This
gateway allows other learning object repositories to discover the resources of CELEBRATE
or vice versa.
Index Terms: E-Learning, Repository Interoperability, Learning Object,
Learning Object Metadata, Simple Query Interface, LOM

6


Introduction

Chapitre 1 Introduction
1.1

Contexte du travail

CELEBRATE ("ContExt eLEarning with BRoAdband TEchnologies") est un projet de 5
millions d’euros qui s’étend sur une période de 30 mois et qui entre dans le cadre du
programme Technologies de la société de l’information de la Commission européenne [1].
L’objectif principal du projet est de créer un réseau européen d’apprentissage qui relie des
établissements scholaires en assurant l’échange et la recherche des ressources pédagogiques
entre eux. Chaque établissement est considéré comme un dépôt contenant des ressources. On
adopte une approche distribuée : les ressources sont éparpillées dans un dépôt central ou dans
les dépôts dans le réseau. Au cœur du réseau est un système de courtage ( brokerage system )
auquel les clients se connectent. Le système de courtage sert à acheminer les requêtes en
provenance d’un client à des dépôts appropriés ou renvoyer les résultats.
Toutefois, CELEBRATE n’est malheureusement pas le seul système de ce genre. Il existe
d’autres systèmes comme ARIADNE Knowledge Pool System, PROLEARN Repository
Portal, EDUTELLA Smart Space for Learning,... Il est nécessaire donc de se mettre d’accord

sur une interface commune pour que ces systèmes « parlent la même langue » et se fassent
comprendre l’un par l’autre. A cette fin, la spécification SQI est née.
Ce stage se concentre sur l’analyse, la conception et l’implémentation d’une interface d’accès
selon la spécification SQI. De plus, sa réalisation aide à détecter les imperfections de SQI et
alors contribue à l’améliorer parce que SQI est encore en phase de développement.
1.2

Définitions

Il convient d’aborder quelques notions de base concernant SQI.
1.2.1 Objets d’apprentissage
Selon la définition de IEEE-LSTC [2], un objet d’apprentissage est « entité numérique ou non
qui peut être utilisée, réutilisée ou référencée pendant des activités d’apprentissage assistées
par ordinateur ». Les objets d’apprentissage peuvent être considérés comme des briques, et en
combinant ces briques on arrive à construire une maison. C’est de cette façon que les
documents pédagogiques sont établis : ils sont une composition d’objets d’apprentissage. La
forme d’un objet d’apprentissage peut être très variée: un texte, une image, un questionnaire,
une vidéo, ... Un objet d’apprentissage idéal se montre comme une entité autonome, ce qui
n’empêche pas qu’il fonctionne bien en étant incorporé à un tout. L’objectif principal de la
conception des objets d’apprentissage est de faciliter leur migration entre différentes
documents, différents contextes. Par exemple une séquence vidéo de deux minutes peut aussi
bien servir dans un cours d’informatique que dans le cadre d’un test, mais aussi cette
séquence peut être insérée dans différentes plateformes [3].
1.2.2 Métadonnées d’objets d’apprentissage
En général, métadonnées sont des données sur des données. En formation en ligne, les
métadonées permettent de décrire la sémantique des diverses ressources pédagogiques et
7


Introduction

donc favoriser leur découverte et recherche. Un autre intérêt des métadonnées est de
permettre à divers outils, divers systèmes de comprendre une ressource et de la réutiliser.
Il nous faut aborder le standard LOM (Learning Object Metadata – Métadonnées d’objet
d’apprentissage) qui concerne l’implémentation du gateway mentionné ci-dessus.
Le Standard LOM (Learning Object Metadata)
Le standard LOM est une création du groupe LTSC (Learning Training System Committe) au
sein de l’association IEEE (Institute of Electrical and Electronics Engineers). Il précise
d’abord la syntaxe et la sémantique des métadonées éducatives et puis il spécifie les
descripteurs, les attributs concrètes permettant la réalisation d’une fiche descriptive à partir
d’une ressource pédagogique ( on dit un binding en anglais ). Les descripteurs sont classés en
neuf catégories.

Figure 1.1 Learning Object Metadata (Source: [4])

8


Introduction
Voici une brève description des neuf catégories de descripteurs :
•
•
•
•
•
•
•
•
•

General : détermine les caractéristiques générales à savoir l’identifiant, la langue, le

titre,….
Lifecycle : spécifie les caractéristiques du cycle de vie comme par exemple le numéro
de version, la date de création, date d’expiration, ….
Meta-metadata : des indications sur les attributs
Technical : définit les aspects techniques tel que le format, la taille, ….
Educational : concerne les spécificités pédagogiques d’un document, tel que son type,
son niveau ou son public cible.
Rights : spécifie les droits de la propriété intellectuelle et les conditions d’utilisation
tel que le copyright, le coût…
Relation : précise les liens entre des documents.
Annotation : permet d’ajouter des annotations, des commentaires et des informations
supplémentaires.
Classification : permet de localiser un document dans un système de classification.

1.2.3 Dépôts d’objets d’apprentissage
Par une vue générale, un dépôt d’objets est une collection des objets. Normalement, ces
objets sont identifiés et référencés à travers des métadonnées. Les services de base d’un dépôt
sont :le stockage, l’exposition et la livraison des objets.
Ces objets peuvent aussi bien être stockés dans un seul endroit que dispersés dans un système
distribué. Dans le deuxième cas, le dépôt devrait se manifester comme un point d’accès
unique même si les objets sont stockés sur des serveurs à divers endroits, ce qui donne à
l’utilisateur un accès transparent au dépôt.
1.3

Problématique

Grâce à de nombreux dépôts d’objets d’apprentissage créés récemment, les utilisateurs ont
accès à une ressource éducative énorme. Toutefois, il n’est pas toujours facile de trouver les
objets dont on a besoin car ils se cachent dans des systèmes fermés ou propriétaires. Ces
systèmes utilisent souvent des formats de données et des interfaces d’accès propriétaires. Cela

rend ces systèmes disparates : il manque l’interopérabilité entre eux.
On peut citer cinq raisons principales qui rendent l’interopérabilité entre des dépôts d’objets
d’apprentissage nécessaire [6]:
•

La création des objets d’apprentissage est coûteuse.

•

L’annotation des objets d’apprentissage est coûteuse.

•

Une fois que les objets d’apprentissage sont créés, l’éditeur s’intéresse souvent
à les disséminer.

•

Les dépôts d’objets d’apprentissage n’ont pas assez d’objets d’apprentissage.

•

Les utilisateurs veulent choisir les objets à partir d’un grand nombre de dépôts.

Selon [5], l’interopérabilité est “ la capacité de deux ou plusieurs systèmes ou composantes
d’échanger informations et d’utiliser les informations échangées ». Ainsi, l’interopérabilité
9


Introduction

concerne deux aspects : la réutilisation et l’échange des données. Pour assurer la réutilisation
des données, on a besoin une sémantique commune afin qu’un système puisse
« comprendre » les données provenant de l’autre. Le deuxième aspect est garanti en
employant des protocoles communs qui rendent possible l’échange des données.

10


La Spécification SQI

Chapitre 2 La Spécification SQI
2.1

Travaux concernés

Digital Repository Interoperability (DRI): Il s’agit d’une spécification de l’IMS. Elle
propose recommendations pour les fonctionnalités d’interopérabilité les plus communes d’un
dépôt
qui
sont
«rechercher/exposer»,
«ramasser/exposer»,
«alerter/exposer»,
«soumettre/stocker», «demander/délivrer». Elle laisse pourtant implémenteurs trop d’options
à choisir pour effectivement régler l’interopérabilité.
Z39.50: C’est un protocole principalement utilisé dans des systèmes de bibliothèques. Il a son
propre langage de requête qui se base sur un ensemble d’attributs prédéfinis ainsi que sur des
syntaxes de jeu de données. Les récentes technologies web comme XML ou XQUERY ne
sont pas présentes dans Z39.50. Des efforts sont en cours pour y incorporer XML comme
format commun des échanges de données.

SRW (Search/Retrieve Web Service protocol) vise à promouvoir l’interopérabilité entre bases
de données réparties et ressources par l’utilisation d’un framework commun. SRW emploie le
langage de requête assez puissant CQL. SRW ne supporte que des requêtes synchones.
Edutella est un réseau paire-à-paire pour le partage de ressources éducatives. Les ressources
dans les dépôts sont décrites en RDF. Edutella emploie le langage de requête QEL approprié
à ressources décrites en RDF. Les requêtes asynchones sont supportées par un méchanisme
« écouteur de résultats» qui est aussi utilisé dans SQI.
EduSource est un projet qui suit IMS Digital Repository Specification. Il emploie un langage
de requête propriétaire ECL (EduSource Communication Language ).
Ariadne propose une interface de requête basée sur service web. Cette interface ne s’intéresse
qu’à des requêtes synchrones.
2.2

Framework pour l’interopérabilité entre dépôts d’objets d’apprentissage

CEN/ISSS a proposé un framework pour l’interopérabilité entre dépôts d’objets
d’apprentissage [5]. Ce framework spécifie un ensemble d’interfaces fournissant les services
pour construire un réseau de noeuds éducatifs. Dans ce framework, les services sont divisés
en deux couches : les services noyau et les services d’application. Les services noyau
s’impliquent dans l’identification des dépôts d’objets d’apprentissage, dans l’authentification
des utilisateurs et des dépôts, ou dans la gestion des sessions. En se situant au-dessus des
services noyau, les services d’application sont ceux qui vraiment apportent l’interopérabilité.
Quelques services dans cette couche sont service de fourniture, service de requête, service de
contrat, service de livraison, …

11


La Spécification SQI
Interopérabilité


Services noyau

Services d’application

…

…

Identification

Authentification

Fourniture

Gestion des sessions

Contrat

Livraison

Requête

Figure 2.1: framework pour l’interopérabilité entre dépôts d’objets d’apprentissage

Les services de deux couches fonctionnent en se reposant sur un service de messagerie
comme XML-RPC, RMI, SOAP, … Le service de messagerie a recours lui-même aux
protocoles réseau comme HTTP, TCP/IP, SMTP, … pour transférer les données.

Semantic

Modèle
sémantique
Model
Applications ((e.g.
Requête,…)
Query)
Core Services
Services
noyau
(Gestion des sessions, authentification, …)

Service
Messaging
de messagerie
Service
(e.g.
SOAP,XML
XML-RPC
, JRMI, …
…)
(e.g.
SOAP,
RPCs, JRMI,
Network Architecture
Architecture
Réseau
(e.g.
SMTP;
TCP/IP,
… ) …

(e.g.HTTP,
HTTP,
SMTP;
TCP/IP,
Figure 1.2 : Les couches dans le framework pour l’interopérabilité entre dépôts d’objets d’apprentissage

2.3

Spécification SQI

2.3.1 Introduction
La spécification SQI est née dans le cadre des travaux du framework pour l’interopérabilité
entre dépôts d’objets d’apprentissage ci-dessus mentionné. Elle introduit une interface
12


La Spécification SQI
couvrant trois services : authentification, gestion des sessions (service noyau) et requête (
service d’application ).
SQI supporte aussi bien les requêtes synchrones que celles asynchrones car elle a comme but
de faciliter l’interopérabilité entre des systèmes pouvant être extrêmement hétérogènes. La
mode de requête asynchrone se montre appropriée quand il s’agit de faire une requête à un
réseau hétérogène paire-à-paire où la possibilité que des systèmes concernés sont
« suspendus » est très forte. La mode synchrone est utile lorsqu’on fait des requêtes de façon
locale, c’est à dire des requêtes client-serveur simple.
D’ailleurs, SQI est neutre en termes de langages de requête et de formats des résultats. En
réalité, les dépôts stockent les métadonnées utilisant divers types de support comme base de
données, système de fichiers, ... avec les formats de métadonnées différents (eg X ML,
RDF,…). Les deux systèmes impliqués dans une requête (le système « source » et le système
« cible ») doivent avant tout se mettre d’accord sur les langages de requête et sur les formats

des résultats. Ceci nous offre une façon très flexible de changer le langage de requête et le
format de résultats en cours d’exécution. Il faut quand même que les dépôts possèdent des
« wrappers » pour traduire entre les formats.
SQI est conçu pour être extensible. Pour cela, les auteurs ont choisi l’approche de minimiser
le nombre des paramètres dans les méthodes. Par conséquent, le nombre des méthodes
devient grand. On n’a heureusement pas à appeler toutes les méthodes définises dans SQI
pour achever une requête. Dans ce cas, les valeurs défauts sont utilisées.
Figure 3 montre les étapes d’une requête où le dépôt A recherche des ressources au dépôt B.
Dans ce scénario, on s’intéresse à l’échange des données plutôt qu’à la gestion des sessions.
Tout d’abord, le dépôt « source » A formule une requête en langage de requête commun et
l’envoie au dépôt « cible » B. Ensuite, B traduit la requête en langage de requête local et
l’exécute. Lors que les résultats ( au format local ) sont produits, B les renvoie à A en les
traduisant au format de résultats commun. Les composants « wrapper » servent de traducteurs
entre les langages de requête et les formats de résultats.
Learning Repository B
(Target)

Learning
Repository A
(Source)
Common Query
Language
Results in
Common Format

Simple Query
Interface
Component

Wrapper


Wrapper

Simple Query
Interface
Component

Local Query
Language
Results in
Local Format

Learning
Object
Metadata

Figure 2.3 : Communication entre deux dépôts de SQI. (Source : [7])

2.3.2 Les méthodes de SQI
Implémentée à la cible et
appelée par la source

Implémentée à la source et
appelée par la cible

Configuration des requêtes
setQueryLanguage

X
13



La Spécification SQI
setResultsFormat

X

setMaxQueryResults

X

setMaxDuration

X

Interface de requête synchrone
setResultsSetSize

X

synchronousQuery

X

getTotalResultsCount

X

getAdditionalQueryResults


X

Interface de requête asynchrone
asynchronousQuery

X

setSourceLocation

X

queryResultsListener

X

Gestion des résultats
getResourceDescription

X

Gestion des sessions
createSession

X

createAnonymousSession

X

destroySession


X

Les méthodes sont catégorisées en 5 groupes : gestion des sessions ,configuration des
requêtes, interface de requête synchrone, interface de requête asynchrone, et gestion des
résultats.
L’établissement d’une connexion entre la source et la cible se fait grâce à createSession ou
createAnonymousSession qui créent une session. La source doit fournir à la cible nom
d’utilisateur et mot de passe ou d’autres crédentiels en vue de créer une session. Cette façon
d’identifier une source permet la cible, d’une part, de refuser les sources inconnues et d’autre
part, d’établir une politique de requêtes. Une fois créée, une session peut être utilisée dans
plusieurs requêtes. Lors que la source appelle destroySession la session est supprimée. Si la
source n’appelle pas destroySession, la session est supprimée après une durée de time-out La
source peut préciser la durée de time-out, le défaut pour time-out est 30 minutes.
Les méthodes du groupe configuration des requêtes servent à préciser la valeur de divers
paramètres impliqués dans une session comme le langage de requêtes, le nombre des résultats
dans un jeu de résultats, la durée maximale d’une requête, le format des résultats.
Dans le cas d’une requête synchrone, la méthode synchronousQuery est invoquée. Le nombre
maximum des résultats dans un jeu de résultat est limité par setResultsSetSize. La méthode
getTotalResultsCount donne le nombre total des résultats tandis que le reste des résultats à la
cible sont retirés lors que la source appele getAdditionalQueryResults.
Les résultats d’une requête asynchrone sont retournés à la source quand la cible appele
queryResultsListener. La méthode setSourceLocation est utilisée afin que la cible connaisse la
14


La Spécification SQI
localisation de la source.

15



Gateway pour CELEBRATE

Chapitre 3 Gateway pour CELEBRATE
3.1

Le réseau CELEBRATE

Comme mentionné dans chapitre 1, CELEBRATE est un réseau européen de nœuds
éducatifs. Un nœud éducatif ici est en fait un système de gestion de contenus pour
l’apprentissage. Au cœur du réseau se trouvent un serveur de messagerie (messaging server)
et un système de courtage (brokerage system) dont le role est d’acheminer les requêtes vers
de bons destinataires. Chaque nœud se muni d’un ELN Client qui est une couche logiciele
servant à connecter au système de courtage. Les étapes d’une requête peuvent être résumées
comme suit :
-

Un nœud (on dit « la source » ) soumet une requête au serveur de messagerie.

-

Le serveur de messagerie transite la requête vers le système de courtage.

-

Le système de courtage valide cette requête et l’envoie ensuite aux nœuds
appropriés.

-


Ces nœuds éxecutent la requête et envoient les résultats au système de
courtage.

-

Le système de courtage passe ces résultats à la source.

LMS/LCMS

LMS/LCMS

ELN Client

ELN Client

Messaging
Server

LMS/LCMS

Central Repository

ELN Client

ELN Client

ELN Client
Brok. System


Figure 3.1: La recherche d’objets d’apprentissage dans le réseau CELEBRATE

3.2

Gateway pour CELEBRATE

Il existe actuellement en Europe ( et dans le monde ) plusieurs réseaux de nœuds éducatifs par
16


Gateway pour CELEBRATE
exemple ADRIADNE, ELENA, EDUTELLA, CELEBRATE, …. chacun ayant ses propres
formats de ressources, sa propre façon d’échanger les métadonnées et données. Le gateway
du CELEBRATE a vu le jour avec comme l’objectif primaire d’offrir une interface entre
CELEBRATE et ces dépôts. Les fonctionnalités du gateway construit sont :
-

exposer une interface conforme à la spécification SQI qui permet à
d’autre dépôts d’objets d’apprentissage de chercher et récupérer des
ressources éducatives de CELEBRATE.

-

chercher des objets d’apprentissage dans divers dépôts d’objets
d’apprentissage lorsque une requête provient du CELEBRATE.

-

permettre à l’administrateur du gateway de configurer les paramètres
de fonctionnement.


On pourra arriver à établir un réseau énorme comportant plusieurs réseaux de nœuds
éducatifs. La figure 3.2 montre cette idée : ARIADNE, ELENA et CELEBRATE se
connectent en possédant chacun une interface SQI.

ELENA

ARIADNE

.

Figure 3.2: Un réseau d’hôtes SQI

Au point de vu de CELEBRATE, le gateway est considéré comme un membre de réseau qui
utilise l’interface ELN client pour se connecter au système de courtage à travers le serveur de
messagerie (fig.3.3).

17


Gateway pour CELEBRATE

Dépôt
SQI

CELEBRATE

Gateway

Serveur de

messagerie

Dépôt

SQI

SQI

ELN Client

Dépôt
SQI

Dépôt
SQI
ELN Client
Brok. System
Serv. Central

(SQI: Simple Query Interface)
Figure 3.3: Gateway est un client du réseau CELEBRATE

18


Implementation

Chapitre 4 Implementation
4.1


Cas d’utilisation

Il y a trois types d’acteurs qui interagissent avec le gateway :
-

Administrateur du gateway(Gateway Administrator)

-

Système de courtage (Brokerage System)

-

Un hôte SQI (An SQI Host)

Acteur : administrateur du gateway
L’administrateur se charge de configurer le gateway en précisant plusieurs paramètres qui
affectent son fonctionnement, à savoir le nombre maximum de connexions simultanées au
gateway, le nombre maximum de requêtes simultanées en provenance de CELEBRATE, la
localisation du listener du gateway. Il peut aussi ajouter ou supprimer un hôte SQI dans la
liste de hôtes SQI à connecter. L’ouverture, la clôture de connexion à CELEBRATE, le
démarrage et l’arrêt du gateway doivent être réalisés manuellement par l’administrateur.

Acteur : Système de courtage
Lorsqu’un membre du CELEBRATE envoie une requête au système de courtage, cette
requête sera renvoyée à d’autres membres y compris le gateway. Le gateway ensuite transite
la requête aux hôtes SQI qui apparaîssent dans une liste de hôtes disponibles à connecter.
Le système de courtage peut aussi retourner les résultats d’une requête au gateway. Ces
résultats sera retournés par le gateway vers le bon hôte sousmettant la requête.


19


Implementation

Acteur : Un hôte SQI
Un hôte SQI interagit avec le gateway par les méthodes définies dans SQI telles que: créer
une session, spécifier le format de résultats, spécifier le time-out d’une requête,…etc.

20


Implementation
4.2

Architecture générale et implémentation

Les modules du gateway correspondent bien aux cas d’utilisation. On va examiner en détail
les fonctionnalités de chacun de ces modules.

Gateway
Admin

administrator

configuration
file

E
L

N

Brokerage
System

C
l
i
e
n
t

C
o
n
n
e
c
t
i
o
n

Core

SQI

S QI

SQI


S
Q
I

SQI

Translation

Module : ELN Client
Il s’agit d’un paquet ElnClient fourni par CELEBRATE. Il sert à faciliter la connexion au
système de courtage. Les mécanismes de gestion de sessions, de formulation de messages, de
traitement de messages, … sont cachés dans ce paquet. Il est fourni sous forme des fichiers
.jar spécifiques de Java.
Module : Admin
Ce module permet à l’administrateur de configurer les paramètres du gateway en les stockant
dans un fichier de configuration XML. Il gère également la connexion au système de courtage
ainsi que celle à des hôtes SQI. L’administrateur administre le gateway à l’aide d’une
interface web écrit en JSP et Servlet. l’accès au fichier de configuration se fait à l’aide des
packages JAXB (java architecture for XML binding), JAXP (java architecture for XML
processing) fournis par Sun.

21


Implementation

Navigateur

Pages jsp, servlet


JAXB,JAXP

Fichier de
configuration

Module : Connection
Il s’agit d’un module qui s’occupe de l’établissement des connexions à des hôtes SQI en
utilisant le protocole SOAP. SOAP (Simple Object Access Protocol) est un protocole de
messagerie dont les messages sont écrits en XML. C’est un protocole simple pour éxecuter
les appels de méthodes de type RPC( Remote Procedure Call). Dans le cas de SQI, chaque
hôte possède un fichier WSDL (Webservice Description Language) qui définit ses méthodes
SQI. L’implémentation du gateway a recours au package JAX-RPC (Java API for XMLBased RPC) fourni par Sun pour générer le client SOAP.
A noter que le fichier WSDL décrivant les méthodes SQI est actuellement propre à chaque
hôte et il est souvent généré de façon automatique par une plateforme. Lorsqu’un nouveau
hôte implémente SQI, les autres hôtes doivent récupérer le fichier WSDL et puis implémenter
des classes pour pouvoir se connecter a ce nouveau hôte. Cela ne semble pas raisonable et
pratique au niveau de la réalisation. Les auteurs de l’SQI, en souhaitant faciliter la
programmation et l’extension des hôtes, envisagent à rédiger une description commune de
l’interface SQI, c’est-à-dire un fichier wsdl commun.

un hôte SQI
CELEBRATE
SQI Gateway
Fichier WSDL

générer
client

SOAP

Client

XML

Web services
(SOAP Server)

SOAP

Module : SQI
Ce module implémente toutes les méthodes de SQI qui seront déployées comme des services
web avec un fichier de description. Les classes de support, les classes « runtime » ainsi que le
fichier wsdl sont générées par l’outil de développement SUN ONE Application Server 7. Un
autre hôte peut implémenter l’interface décrit dans ce fichier wsdl et se connecter au gateway.
22


Implementation

CELEBRATE
SQI Gateway

Généner
server

Web services
(SOAP Server)

un hôte SQI
SOAP


SOAP
Client

Fichier WSDL

Module : Core
Ce module a pour but de gérer les sessions et acheminer les messages. On va voir le détail des
classes ci-dessous.

Classe « TimeoutCollectableStorage » et classe « TimeoutCollector »:

Ces classes implémentent un mécanisme pour détruire les objets qui dépassent une durée de
« timeout ». TimeoutCollectableStorage stocke dans une liste les objets susceptibles d’être
détruits. Chaque objet est attribué un marqueur de temps qui permet à connaître son état de
validité au niveau de temps. TimeoutCollector examine cet état de « timeout » selon lequel
elle décide de supprimer l’objet ou pas.
23


Implementation
Classe « MessagesList»

Cette classe stocke les requêtes en provenance du système de courtage. Elle implémente
l’interface «TimeoutCollectableStorage ». Il s’agit d’une file d’attente où les requêtes sont
traitées l’une après l’autre. Une fois que les résultats pour une requête sont récupérés au
niveau du gateway, cette requête servira à identifier le client et sera libérée. Si aucun résultat
n’est retourné après un certain temps, la requête se trouve dans l’état de « timeout » et sera
détruit.
Classe « SessionsManager »:


Comme
la
classe
« MessagesList »,
cette
classe
implémente
l’interface
«TimeoutCollectableStorage » et stocke les sessions créées par plusieurs hôtes SQI en
utilisant le même mécanisme de détruire les sessions selon « timeout ».

Classe « GatewayBSListener »:

C’est une implémentation concrète de l’interface IncomingMessageListener. Elle a pour rôle
de recevoir les messages du système de courtage dont le traitement est délégué à une instance
de «MessageHandler ».
Classe « MessageHandler»:

Cette classe s’occupe de traiter plusieurs types de messages arrivant au gateway.
Classe « QuerySender»:

«QuerySender» est utilisé par « MessageHandler » pour envoyer une requête à des hôtes SQI
en mode synchrone ou asynchrone selon les modes supportés à chaque hôte.
Classe « AbstractSQIHost»:

Cette classe abstraite représente un hôte SQI avec les méthodes SQI.
Classe « Gateway»:

24



Implementation
Les informations sur le gateway ainsi que les états du gateway sont gardés dans l’instance de
cette classe. Car elle est conçue selon le design pattern « Singleton », elle n’a au plus qu’une
instance à tout moment. Le fonctionnement du gateway dépend des informations stockées
dans l’instance de cette classe. Par exemple, lorsque le nombre de messages dans
« MessagesList » atteint le nombre maximum de messages défini dans « Gateway », le
gateway ne traitera plus les requêtes du système de courtage.
Module : Translation
Ce module se charge de transformer les requêtes et les résultats en utilisant des feuilles de
transformation et des classes de support en Java.
Transformation de requêtes:

Dans la version actuelle, le format VSQL(Very Simple Query Interface) est utilisé comme le
format de requêtes commun. VSQL compose d’une liste de mots-clé qui pourra être appliqués
dans la recherche. Un exemple de VSQL :
<simpleQuery>
<term>search term 1</term>
<term>search term 2</term>
</simpleQuery>
Le format de requêtes de CELEBRATE (appelé “filter”) se montre plus compliqué. Il s’agit
d’une combination récursive des opérateurs « and », « or », « not » avec des indicateurs de
champs dans la recherche [1].

CELEBRATE
Filter
(xml instance)

Transformation

de requêtes

VSQL
(xml instance)

Transformation de résultats:

Le modèle commun de LOM proposé par SQI est IEEE 1484.12.1. A CELEBRATE,
CELEBRATE Metadata Application Profile v1.1 est utilisé. Chaque modèle s’accompagne
d’un binding XML. Ces deux modèles de LOM ont des différences qu’on doit régler dans la
transformation. Les différences se manifeste sur deux niveaux :
Au niveau de modèle de données

-

les éléments obligatoires : dans LOM de CELEBRATe, il y a des éléments
obligatoires. Dans LOM de IEEE, il n’y a accun élément obligatoire.

-

nouveaux éléments dans le modèle LOM de CELEBRATE

-

différences de vocabulaires
25