Institut de la Francophonie
pour l’Informatique

European Schoolnet

Mémoire de fin d’étude
______________

Echange des objets d'apprentissage dans la fédération CELEBRATE

Diplôme d’Études Professionnelles Approfondies (DEPA)
de l'Institut de la Francophonie pour l' Informatique

Préparé par
CHHUOY Bunchheang

Tuteur du stage : M. David MASSART
Bruxelles - 2005

Mémoire de fin d’étude

i


Remerciements
Je tiens tout d’abord à remercier M. Charles DURAND, Directeur de l’Institut de
la Francophonie pour l’Informatique, et tous les professeurs de l’IFI, pour m’avoir
enseigné et donné de bons conseils pendant mes études supérieures au Vietnam.
Je souhaiterais remercier également M. Ulf Lundin, Directeur de l’organisation
European Schoolnet, pour m’avoir offert un stage en Belgique.
Je tiens à remercier vivement tous les membres de European Schoolnet,

particulièrement M. David MASSART, chef de projet, qui m’a accueilli chaleureusement
et m’a proposé le sujet de stage.
Finalement, je tiens à remercier mes parents, mon frère, ma sœur et mes cousins
qui m’ont supporté et encouragé à poursuivre mes études au Vietnam.

Mémoire de fin d’étude

ii


Résumé
Le concept du e-learning et de l'apprentissage par l’Internet est devenu un domaine très
étudié dans le milieu de la recherche en éducation et les technologies éducatives.
L'utilisation des objets d'apprentissage dans le projet de CELEBRATE doit donc fournir
des mécanismes pour la traduction du contenu et également du metadata permettant la
recherche et la récupération dans des développements multiples.
Ce projet développe un système pour supporter le European Learning Network (ELN).
La partie principale de ce réseau est le Brokerage System (BS), auquel les clients
LMS/LCMS se connectent. La majeure partie de la communication entre les clients et le
BS est par l'intermédiaire des messages asynchrones de Java Message Service (JMS).

Abstract
The concept of web-based learning and the use of the Internet in teaching and learning
have received increasing attention over the recent years.
The use of Learning Objects in the CELEBRATE project must therefore provide
mechanisms for translation of learning content and also of the metadata allowing search
and retrieval in multiple developments.
This project is developing a system to support a European Learning Network (ELN). The
backbone of this network is the Brokerage System (BS), to which Client LMS/LCMS
connect. The bulk of the communication between Clients and the BS is via Java

Messaging Service (JMS) asynchronous messages.

Mémoire de fin d’étude

iii


Table de matières
Remerciements.................................................................................................................... ii
Résumé............................................................................................................................... iii
ACRONYMES.................................................................................................................. vii
1 Introduction...................................................................................................................... 1
1.1 Introduction au sujet................................................................................................. 1
1.2 Présentation de la société.......................................................................................... 2
2 Travaux concernés........................................................................................................... 3
2.1 Objet d’apprentissage................................................................................................3
2.2 Méta-données............................................................................................................3
2.3 Types de messages....................................................................................................4
3 Travaux antérieurs........................................................................................................... 8
3.1 Introduction ..............................................................................................................8
3.2 Architecture de CELEBRATE..................................................................................8
3.3 Transmission de messages...................................................................................... 10
4 Travaux encadrés du stage............................................................................................. 13
4.1 Introduction aux problèmes.................................................................................... 13
4.1.1 Recherche des objets d'apprentissage.............................................................. 13
4.1.2 Résolution de l’url d’un objet d’apprentissage................................................ 13
4.1.3 Réponse aux requêtes.......................................................................................14
4.2 Environnement de développement..........................................................................14
4.3 Implémentation....................................................................................................... 14
4.3.1 Implémentation OKI........................................................................................ 15

4.3.1.2.1 Recherche d’objets d'apprentissage....................................................... 20
4.3.1.2.1.1 Construction de message LOMQueryRequest................................20
4.3.1.2.1.2 Construction de message LOUseAuthorizeRequest....................... 21
4.3.1.2.1.3 Construction de message LOUseExecuteRequest.......................... 22
4.3.1.2.2 Analyse de méta-données...................................................................... 22
4.3.1.2.2.1 Analyse de méta-données du message CheckedLOMQueryResult23
4.3.1.2.2.2 Analyse de méta-données du message
CheckedLOUseAuthorizeResult........................................................................23
4.3.1.2.2.3 Analyse de méta-données du message LOUseExecuteResult........ 24
4.3.2 Implémentation SQI.........................................................................................25
4.3.2.2.1 Envoie de message.................................................................................28
4.3.2.2.2 Réception de message............................................................................ 29
4.3.3 FireClient......................................................................................................... 30
4.3.3.1 Introduction...............................................................................................30
4.3.3.2 Architecture du système............................................................................31
4.3.3.3 Implémentation......................................................................................... 32
5 Résultat et évaluation du travail..................................................................................... 39
5.1 Résultat et évaluation du projet CELEBRATE...................................................... 39
5.1.1 Aspect technique..........................................................................................39
5.1.2 Aspect utilisation......................................................................................... 39
Mémoire de fin d’étude

iv


5.2 Résultat et évaluation du projet FIRE.....................................................................40
6 Conclusion..................................................................................................................... 41
Annexe A : Les messages LOMs....................................................................................... 42
Annexe B : Les diagrammes de classes............................................................................. 48
Annexe C : Les interfaces graphiques............................................................................... 52

Références.......................................................................................................................... 57

Mémoire de fin d’étude

v


Table of figures
Figure 1 : L’utilisation de message LOMQueryRequest, CheckedLOMQueryRequest,
LOMQueryResult et CheckedLOMQueryResult................................................................ 5
Figure 2 : L’utilisation de message LOUseAuthorizeRequest,
CheckedLOUseAuthorizeRequest, LOUseAuthorizeResult et
CheckedLOUseAuthorizeResult..........................................................................................6
Figure 3 : L’utilisation de message LOUseExecuteRequest et LOUseExecuteResult........ 7
Figure 4 : Architecture de CELEBRATE............................................................................ 9
Figure 5 : Système Brokerage et ses clients.......................................................................10
Figure 6 : Recherche des objets d'apprentissage dans la fédération.................................. 11
Figure 7 : Accès à un objet à distance................................................................................12
Figure 8 : Différentes classes et interfaces définies dans le module Repository............... 17
Figure 9 : Différent composants du système......................................................................19
Figure 10 : Exemple de message LOMQueryRequest.......................................................21
Figure 11 : Exemple de message LOUseAuthorizeRequest.............................................. 22
Figure 12 : Exemple de message LOUseExecuteRequest................................................. 22
Figure 13 : Démarche de message LOUseAuthorizeRequest............................................24
Figure 14 : Démarche de requête LOUseExecuteRequest.................................................24
Figure 15 : Diagramme de classes de SQI......................................................................... 25
Figure 16 : Différent composants du système développé sous SQI...................................27
Figure 17 : Architecture du système FIRE........................................................................ 31
Figure 18 : La démarche de la création des critères de recherche..................................... 36
Figure 19 : La démarche de la récupération du résultat de la recherche............................37

Figure 20 : Diagramme de paquetages de l’implémentation de OKI................................ 48
Figure 21 : Diagramme de paquetages de l’implémentation SQI......................................49
Figure 22 : Diagramme de classes de l’implémentation SQI............................................ 50
Figure 23 : Diagramme de classes du FireClient............................................................... 51
Figure 24 : Interface graphique pour le démo Oki-ElnClient dans le projet CELEBRATE
............................................................................................................................................52
Figure 25 : Interface graphique pour le démo SQIElnClient dans le projet CELEBRATE
............................................................................................................................................53
Figure 26 : Formulaire de saisir pour démarrer le service dans le projet FIRE.................54
Figure 27 : Formulaire de saisir des critères de recherche fédéré dans le projet FIRE..... 55
Figure 28 : Page de résultats de la recherche pour le projet FIRE.....................................56

Mémoire de fin d’étude

vi


ACRONYMES
AJAX........................................Asynchronous JavaScript and XML.......................
API........................................... Application Program Interface................................
BS............................................. Brokerage System...................................................
CELEBRATE...........................Context eLearning with Broadband Technologies.
CVS.......................................... Concurrent Versions System...................................
ELN.......................................... European Learning Network...................................
EUN..........................................European Schoolnet................................................
IEEE......................................... Institute of Electrical and Electronics Engineer......
FIRE......................................... Federation of Internet Resources for Education.....
JAX-RPC..................................Java API for XML-based Remote Procedure Call..
JAXB........................................Java Architecture for XML Binding.......................
JAXP........................................ Java API for XML Processing................................

JMS...........................................Java Message Service.............................................
JWSDP..................................... Java Web Services Developer Pack........................
LCMS....................................... Learning Content Management System..................
LMS..........................................Learning Management System...............................
LO.............................................Learning Object......................................................
LOM......................................... Learning Object Metadata.......................................
OKI...........................................Open Knowledge Initiative.....................................
SPARK..................................... SPecial Application for Retrieving Knowledge......
SQI........................................... Simple Query Interface...........................................
URL..........................................Uniform Resource Locator.....................................
VLE.......................................... Virtual Learning Environment................................
XML......................................... Extensible Markup Language.................................
XSD..........................................XML Schema Definition.........................................

Mémoire de fin d’étude

vii



1 Introduction
1.1 Introduction au sujet
Selon le programme d’étude de l’Institut de la Francophonie pour l’Informatique
installé à Hanoi, la capitale du Vietnam, afin de pouvoir obtenir le Diplôme d’Etude
Professionnelle Approfondie (DEPA), les étudiants doivent réaliser un stage de fin
d’étude à l’étranger qui a pour l’objectif de les familiariser à leur vie professionnelle
future. Dans mon cas, ce stage a été effectué à European Schoolnet en Belgique.
Mon travail au cours du stage concerne une partie du projet CELEBRATE. Le
mot CELEBRATE est l’acronyme de « Context eLearning with Broadband
Technologies ». Ce projet avait pour but de démontrer la meilleure utilisation de

technologies à bande large dans l'éducation. Il était coordiné par European Schoolnet et
est financé par le programme « Information Society Technologies » (IST) de la
commission européenne.
Le projet concernait le développement et l’accès à des objets d'apprentissage
numériques multilingues à travers l’Europe.
Pour réaliser ce but, European Schoolnet a installé un Brokerage System (BS)1 qui
permet de connecter des espaces numériques de travail (Learning Management System –
LMS) pour former un European Learning Network (ELN).
Le projet a essayé de favoriser l'apprentissage numérique des élèves des écoles
secondaires et primaires pour acquérir des qualifications principales, tel que le travail de
collaboration, la créativité, la communication interculturelle et la résolution de
problèmes.
Sur le portal de CELEBRATE, des exemples d’objets d’apprentissage sont
disponibles. Environ 1350 d’objets développés durant le projet ont été évalués par 775
professeurs répartis dans 319 écoles de six pays.
1

Système centralisé des échanges de méta-données

Mémoire de fin d’étude

1


J’ai également travaillé sur le développement de pages web qui font une partie du
projet FIRE. Il est actuellement la combinaison de SQI et CELEBRATE pour le rendre
facile à implémenter. La bibliothèque de Java appelé SPARK est nécessaire pour le
développement, il est utilisé pour établir des connexions entre des systèmes au FIRE.
Pour plus d'informations sur ce projet, vous pouvez le trouver à l'adresse



1.2 Présentation de la société
Mon stage de fin d’étude se déroule pendant six mois dans l’organisation
European Schoolnet (EUN)2. Le stage a duré du 29 mars 2005 au 26 septembre 2005.
European Schoolnet est une association internationale de plus de 26 ministères de
l'éducation européens, dont le but est de développer l’apprentissage pour des écoles, des
professeurs et des élèves à travers l'Europe.
Le but du consortium EUN est de développer une politique européenne commune
d'implantation et d'utilisation des TIC (Technologie de l’Information et de la
Communication) pour des approches pédagogiques innovatrices.
Ceci est réalisé par la communication et l'échange d'information dans toute l'école
en utilisant des technologies innovatrices, et en agissant en tant que passerelle entre
réseaux d’écoles nationales et régionales.
Leurs activités sont déterminées par les besoins des membres constitutifs de
l’organisation en collaboration avec la commission européenne.

Localisation
Le bureau de l’EUN se situe au coeur de la zone européenne de Bruxelles à
l’adresse Nº 61, rue de Trèves, 1040 Bruxelles, Belgique

2

Pour information détaillée, visitez le site

Mémoire de fin d’étude

2


2 Travaux concernés

2.1 Objet d’apprentissage
Avant de détailler le projet CELEBRATE, il est nécessaire de bien comprendre le
concept d’objet d’apprentissage (Learning Object) et ses avantages. Le mot “objet
d’apprentissage” est devenu commun dans le monde de l’apprentissage assisté par
l’ordinateur, mais sa définition change en fonction du contexte. Un objet d’apprentissage
est une ressource au format numérique qui fournit une expérience d'étude d'une certaine
sorte. Des données appelées “méta-données” sont associées à la formation, évaluation et
contenu. Ces données permettent d’individualiser des contenus selon les profils. Des
objets d'apprentissage peuvent être comparés comme des ressources logées dans une
bibliothèque physique.
Un objet d’apprentissage a cinq caractéristiques importantes :
●

Découvrable (peut être trouvé en faisant une recherche)

●

Interopérable (plusieurs systèmes peuvent communiquer sans ambiguïté et opérer
ensemble)

●

Contextualisable (peut avoir un niveau existent dans un contexte ou peut être
adapté à une variété de contextes)

●

Editable (peut être modifié)

●


Réutilisable (peut être utilisé plusieurs fois)

2.2 Méta-données
Une méta-donnée est une manière formelle et structurée de description de LO.
Une bonne méta-donnée permet des résultats utiles et appropriés à la recherche. Il est
aussi un mécanisme utilisé pour la gestion des objets d’apprentissage et des droits de
ressources numériques.

Mémoire de fin d’étude

3


L’utilisation de méta-données dans CELEBRATE a pour but de permettre les
échanges

d’informations

de

ressources

numériques

entre

les

partenaires


de

CELEBRATE. Il est destiné à la lisibilité de l’homme et de la machine.
Les méta-données décrites dans cette application permettent différentes
utilisations des objets d'apprentissage comme :
●

Gestion

●

Recherche

●

Interopérabilité technique
Et la description des propriétés de chaque objet d’apprentissage individuel inclus :

●

Attribut éducatif

●

Droits numériques

●

Caractéristiques techniques

Les méta-données utilisées dans ce système sont au format IEEELOM.

2.3 Types de messages
La communication entre les LMS/LCMS et le BS se fait par échange de
messages. Un message est un flux de données représenté sous forme XML et caractérisé
par un type et un contenu. Les types de message utilisés sont :
●

LOMQueryRequest : ce type de message est utilisé par LMS/LCMSs pour
rechercher les méta-données (LOMs) des dépots de méta-données du ELN. Il est
envoyé au BS.

●

CheckedLOMQueryRequest : Les LOMQueryRequests sont contrôlés par le BS
avant d’être diffusés aux ELN Clients. Les LOMQueryRequests qui passent le
contrôle du BS deviennent des CheckedLOMQueryRequests.

Mémoire de fin d’étude

4


●

LOMQueryResult : ce type de message contient les résultas des requêtes LOM.
Ces résultats sont envoyés par LMS/LCMSs au BS en réponse aux messages
CheckedLOMQueryRequest.

●


CheckedLOMQueryResult : Les LOMQueryResults sont contrôlés par le BS.
Les

CheckedLOMQueryResults

acceptés

deviennent

des

CheckedLOMQueryResults et sont envoyés au LMS/LCMS qui a envoyé le
LOMQueryRequest initial.

2. CheckedLOMQueryRequest

1. LOMQueryRequest
Brokerage
System

LMS/LCMS

LMS/LCMS

4. CheckedLOMQueryResult

3. LOMQueryResult

Figure 1 : L’utilisation de message LOMQueryRequest, CheckedLOMQueryRequest,

LOMQueryResult et CheckedLOMQueryResult
●

LOUseAuthorizeRequest : ce type de message est utilisé par un LMS pour
demander à un autre LMS l’autorisation d’utiliser un de ces LOs.

●

Checked LOUseAuthorizeRequest : ce type de message est utilisé pour
contrôler

la

permission

LOUseAuthorizeRequests

d’échange

accepté

par

le

entre
contrôle

LMS/LCMSs.
de


BS

Les

deviennent

CheckedLOUseAuthorizeRequests.
●

LOUseAuthorizeResult : ce type de message contient un « agreement »
décrivant les conditions du LO demandé. C’est le résultat de la requête
d’autorisation. Ces résultats sont envoyés par LMS/LCMSs au BS en réponse aux
messages de type CheckedLOUseAuthorizeRequest.

Mémoire de fin d’étude

5


●

Checked LOUseAuthorizeResult : LOUseAuthorizeResults sont contrôlés par le
BS.

Les

CheckedLOUseAuthorizeResults

acceptés


deviennent

CheckedLOUseAuthorizeResults et sont envoyés au LMS/LCMS qui envoie le
LOUseAuthorizeRequest correspondant. Ils contiennent un « token » qui identifie
l’ agreement contenu dans le LOUseAuthorizeResult. Cet agreement est stocké
par le BS et ne parvient pas au LMS/LCMS.

Brokerage System
CheckRequestT ype

1.LOUseAuthrorizeRequest

2.CheckedLOUseAuthrorizeRequest

4.CheckedLOUseAuthrorizeResult
3.LOUseAuthrorizeResult

LMS/LCMS

LMS/LCMS

Figure 2 : L’utilisation de message LOUseAuthorizeRequest,
CheckedLOUseAuthorizeRequest, LOUseAuthorizeResult et
CheckedLOUseAuthorizeResult
●

LOUseExecuteRequest : ce type de message est envoyé au BS pour demander la

localisation d’un objet d’apprentissage. Il contient le token correspondant à

l’agreement obtenu pour cet objet.
●

LOUseExecuteResult : ce type de message est envoyé par le BS au LMS/LCMSs

à répondre au message LOUseExecuteRequest correspondant. Il contient la
localisation de l’objet (url). Cette localisation est renvoyée par le BS après
vérification et mise à jour de l’agreement correspondant au token contenu dans le
LOUseExecute Request.

Mémoire de fin d’étude

6


Brokerage System
CheckRequestT ype

1. LOUseExecuteRequest
2. LOUseExecuteResult

LMS/LCMS

LMS/LCMS

Figure 3 : L’utilisation de message LOUseExecuteRequest et LOUseExecuteResult
Tous les messages sont définis dans des schémas XSD3 accessible à l’adresse
Les messages non valides sont refusés par le
Brokerage System qui retourne un message d’erreur.


3

XML Schema Definition qui spécifie comment décrire des éléments dans un document XML

Mémoire de fin d’étude

7


3 Travaux antérieurs
3.1 Introduction
CELEBRATE se compose d’un groupe de partenaires ayant des Learning
Management Systems (LMS), Learning Content Management Systems (LCMS), ou des
dépôts de ressources. Presque tous les LMSs et LCMS ont leur propre dépôt d’objets
d'apprentissage.
La première mission de CELEBRATE fût d’implémenter et d’explorer des idées
autour de la fédération des LMSs, des LCMSs et des dépôts. CELEBRATE implémente
une fédération qui peut rechercher dans les dépôts de chacun et de partager parmi les
partenaires.

3.2 Architecture de CELEBRATE
Avant d’aller plus loin, il est nécessaire de bien comprendre l’architecture fédérée
du projet CELEBRATE. CELEBRATE est une vraie fédération ayant des partenaires
résidant dans différents pays. Elle a besoin d'une manière de régler les services, de gérer
de manière numérique les droits associés aux objets échangés, de gérer des rapports
(tracking and reporting) et de former un agreement entre les partenaires.
Elle travaille sur un modèle Brokerage en utilisant le Java Message Service (JMS)
comme technologie de base. En plus de JMS, on utilise le protocole SOAP (Serial Object
Access Protocol) pour implémenter la connexion RPC pour la sécurité des échanges
(OASIS), et la connexion persistant.

Les composants principaux comprennent le Brokerage, et des clients. Les clients
peuvent agir en tant que fournisseurs, offrant des contenus et des services à la fédération,
ou consommateurs, consommant des contenus et des services de la fédération, ou tous en
tant que fournisseur et comommateur en même temps. En fait, les clients sont : LMS,
LCMS's ou dépôts d’objets d'apprentissage qui incluent un module d'interface spécifique
de CELEBRATE appelé European Learning Network Client (ELN Client).

Mémoire de fin d’étude

8


Tout d’abord, un client établit sa propre identité et crée une connexion persistante
sécurisée avec le Brokerage System en utilisant des services web SOAP. Une fois la
connexion est établie, les échanges se font à l’aide de messages asynchrone JMS.
Le BS est introduit dans ce système dans le but de pouvoir communiquer entre
plusieurs réseaux de fournisseurs de ressources (par exemple : Point à Point, Edutella,
Ariadne…)

Figure 4 : Architecture de CELEBRATE
Ce schéma montre comment les applications sont reliées par le système
Brokerage.

Les clients du Brokerage sont de type LMS, LCMS et dépôt d’objets

d'apprentissage. Une fois une connexion persistante établie, toute la communication par
message se fait via le Brokerage. Puisque le Brokerage joue le rôle d’intermédiaire dans
les échanges entre les clients, il est possible d’appliquer la gestion de règles et déterminer
quel client doit recevoir des messages et sous quelle forme.


Mémoire de fin d’étude

9


Ce système n’est pas une simple application Client/Serveur où il n’y a qu’une
seule direction (seule le client peut envoyer des requêtes au serveur), mais c’est une
double direction (client et serveur se communiquent par des messages JMS).

3.3 Transmission de messages
Dans CELEBRATE, fournisseurs et demandeurs sont des Learning Management
Systems (LMS). Un LMS fournit à ses utilisateurs (étudiants et professeurs) l'accès à un
ensemble d’objets d'apprentissage locaux.
Le système CELEBRATE est construit sur un modèle fédéré. Les LMSs sont
reliées entre eux par un BS qui contrôle tous les échanges entre les LMSs. Chaque LMS a
son propre dépôt qui contient ses objets locaux et contrôle ses utilisateurs locaux. Un
LMS peut jouer un rôle comme fournisseur (donner l’accès à son dépôt local pour les
membres de fédération), ou demandeur (accéder aux objets des autres membres), ou tous
les deux rôles.
Le BS est utilisé pour retransmettre des requêtes d’un LMS à tous les autres de la
fédération et assurer que les résultats correspondants arrivent à la destination.

Figure 5 : Système Brokerage et ses clients

Mémoire de fin d’étude

10


Sachant que le CELEBRATE est un modèle fédéré. La recherche d’objets

d'apprentissage d’un client peut entraîner les autres membres de la fédération.
Voici le modèle de fonctionnement de la recherche.

Figure 6 : Recherche des objets d'apprentissage dans la fédération
•

(1), (2) et (3) : retransmettre la requête de l’utilisateur à tous les membres de la
fédération.

•

(4) et (4’) : résultats de la requête.

•

(5) et (6) : retransmettre le résultat à l’utilisateur qui a effectué la demande.
Au niveau de la coopération, l’accès à distance est souvent utilisé.
Voici un modèle de l’accès à un objet à distance

Figure 7 : Accès à un objet à distance

Mémoire de fin d’étude

11


•

(1) et (2) : retransmettre la requête.


•

(3) et (4) : négocier avec le fournisseur.

•

(5) : enregistrer l’agreement dans le BS et informer le demandeur.

•

(6), (7) et (8) : valider pour les prochains accès

Mémoire de fin d’étude

12


4 Travaux encadrés du stage
4.1 Introduction aux problèmes
4.1.1 Recherche des objets d'apprentissage
Rappelons que la recherche est dans la fédération, de cette manière, la requête est
une fois créés mais peut être envoyé aux plusieurs fournisseurs de dépôt des objets
d'apprentissage. Chaque fournisseur peut avoir sa propre architecture de structurer des
objets et différents types de réseaux d’éducation. C’est la raison pour laquelle, chaque
requête doit passer le Brokerage System et doit être sous une forme commune (par
exemple : format XML). Le Brokerage System diffuse la requête à tous les fournisseurs
coopérés à fin de récupérer tous les résultats de chaque fournisseur au demandeur.
Sachant que le résultat arrive de manière asynchrone, il faut fixer la valeur
timeout pour le temps d’attendre de résultats.


4.1.2 Résolution de l’url d’un objet d’apprentissage
Le résultat de l’url permet d’apprenant d’atteindre son l’objet d’apprentissage
préféré. En général, le « remoteplay » est utilisé parmi les autres types d’accès4.
Puisqu’il existe plusieurs fournisseurs, et chacun produit ses propres métadonnées qui peuvent être différent des autres. On peut distinguer deux types de métadonnées dans cette étape. Le premier type contient l’url de l’objet dans le méta-données
de message CheckedLOMQueryResult, le deuxième type contient l’id de l’objet et id de
fournisseur qui sont nécessaire pour la récupération de l’url.
Dans le premier cas, l’url est obtenu après l’analyse de message
CheckedLOMQueryResult.
Dans le deuxième cas, il est nécessaire d’effectuer deux opérations à fin de
pouvoir récupérer la localisation. Ses deux étapes sont :
•

Récupération d’agreement

•

Récupération d’url en donnant l’agreement

4

Les types d’accès disponibles sont « play », « download » et « remoteplay ». Dans chacun des cas, l’url
retourné est différent l’un à l’autre.

Mémoire de fin d’étude

13


4.1.3 Réponse aux requêtes
ELN fonctionne non seulement comme un client mais aussi comme un

fournisseur de dépôt d’objet d’apprentissage. Au cas où ce système reçoit des requêtes de
type CheckedLOMQueryRequest ou CheckedLOUseAuthorizeRequest, il fait la
recherche dans la base de données locale. Dans mon cas, la recherche locale qui dépend
de la structure de base de données de chaque fournisseur de dépôt, l’implémentation a
besoin seulement l’interface qui devrait être implémenté plus tard selon le comportement
de chaque fournisseur.
Le domaine qui reste à explorer sera l’implémentation de deux interfaces (OKI et
SQI) qui ont le même but, mais chacune utilise sa propre spécification.

4.2 Environnement de développement
Au cours du développement, nous avons utilisé :
●

Langages de programmation : Java (J2SDK 1.5 et JWSDP 1.5)

●

Editeur : Together for Eclipse

●

CVS

●

Système d’exploitation : Ms. WindowsXP

●

Eventuellement utiliser XML Spy pour vérifier le format d’un fichier XML.


4.3 Implémentation
L'utilisation d'une norme et d'une interface ouverte est une condition forte afin de
permettre autant de systèmes d'étude de rechercher et accéder aux ressources d'objets
d’apprentissage.
Le détail de chaque implémentation est donné ci-dessous.

Mémoire de fin d’étude

14


4.3.1 Implémentation OKI
4.3.1.1 Introduction
OKI est une abréviation du Open Knowledge Initiative. Il est un projet de
développement d'un système flexible et ouvert pour soutenir la formation en ligne sur
l’Internet. OKI fournit les spécifications détaillées et un modèle d'implantation
fonctionnelle d'une architecture et d'une interface de programmation (API) adaptées aux
systèmes de gestion de l'apprentissage et au développement d'outils éducatifs.
OKI est défini de manière abstraite qui la rend neutre et adaptable aux
technologies existantes et à avenir. Cependant OKI fournit une API de Java pour utiliser
comme un modèle d’objet orienté. Cet API est un open source et disponible à l’adresse
/>Les avantages de OKI
Grâce à la définition claire des points d'interopérabilité, l'architecture permet aux
composants d'un environnement d’apprentissage complexe d'être développés et mis à jour
indépendamment les uns des autres. Ceci présente des avantages importants :
●

Modularité : la modularité rend la technologie plus stable, plus fiable, et permet à
des composants d'être mis à jour sans déstabiliser d'autres parties de

l'environnement.

●

Evolutif : un seul composant peut être remplacé ou mis à jour sans exiger la
modification des autres composants

●

Standardisé : l'architecture offre une base standard pour le développement de
logiciel de technologie d'étude. Ceci réduit la complexité de développement et
permet des composants spécialisés à intégrer dans des grands systèmes

Mémoire de fin d’étude

15


OKI OSID (Open Service Interface Definition) a définit plusieurs modules. La
version courante contient :
●

●

●

Services communs


Authentication




Authorization



SQL



Logging



Shared



Filing



Dictionary



Hierarchy




Agent



ID

Services extensibles


User Messaging



Scheduling



Workflow

Services éducatifs


Course Management



Repository




Assessment



Grading

Parmi les produits spécifiés dans OKI, le module repository convient bien à
l’implémentation de la gestion des objets d'apprentissage. Ce produit gère le stockage et
la recherche des documents numériques.
La spécification détaillée peut être trouvée sur Internet à l’adresse


Mémoire de fin d’étude

16


Figure 8 : Différentes classes et interfaces définies dans le module Repository
Le paquetage Repository se compose de 14 classes, dont la plus part sont des
interfaces.
Commençons par la classe Repository, cette classe représente une ressource
d’objets d'apprentissage, elle gère la création, la suppression et particulièrement la
recherche des objets d'apprentissage. Ensuite, la classe Asset est considère comme un
objet qui peut être un document texte, html, music ou vidéo, etc. En général, elle contient
des informations utiles pour les apprenants comme titre, descriptions et les mots clés, etc.
Selon la spécification de OKI, ses valeurs ne sont pas directement mises dans la classe
Asset. Elles sont dans l’attribut « value » de la classe Part. Puis, la classe Record nous
permet de distinguer des différentes catégories des informations. La classe Part est
finalement utilisée pour contenir des valeurs.


Mémoire de fin d’étude

17