These-F Boudali

Ministère de l’enseignement supérieur et de la recherche scientifique
Institut National de formation en Informatique (I.N.I)
Mémoire
En vue de l’obtention du diplôme de Magister
En Informatique
Option : Informatique industrielle
Présenté par :
Fatiha BOUDALI
Thème :
Publication et découverte des web services pour le
domaine du e-learning
Soutenu devant le jury :

M. Rachid CHALAL Président Maître de conférences (INI)
M. Walid Khaled HIDOUCI Examinateur Maître de conférences (INI)
M. Faiçal AZOUAOU Examinateur Docteur (INI)
M. Amar BALLA Rapporteur Maître de conférences (INI)
2007 – 2008
Résumé
La tendance actuelle en environnements d’apprentissage est à l’utilisation croissante

des web services en vue de permettre une interopérabilité entre les plateformes. Un web
service désigne une application mise sur Internet par un fournisseur de service, et accessible
par des clients à travers des protocoles standards. Les descriptions des services sont
enregistrées dans un annuaire dit UDDI.
Actuellement, le nombre de plateformes e-learning à base de web services est de plus

en plus croissant. Ces plateformes sont de différents fournisseurs et de différentes
caractéristiques et fonctionnalités. Par conséquent, leur découverte et localisation deviennent
un défi très important. Les critères de choix et de sélection d’un service d’une plateforme e-
learning dépendent, généralement, du modèle pédagogique adopté et des contraintes
ergonomiques et technologiques.
Notre travail s’inscrit dans cette problématique de prise en compte de ces critères lors
de la découverte des web services afin de donner des résultats convenables et de satisfaire au
mieux l’utilisateur. Donc, pour mieux répondre aux requêtes de découverte, nous proposons
de munir les web services d’une description sémantique de leurs contraintes. Cette description
sémantique est réalisée grâce à l’ontologie DAML-S étendue par une autre ontologie dite
ontologie de qualité d’apprentissage (QA), qui décrit le service en terme de fonctionnalités
pédagogiques fournies et des aspects technologiques. Cependant, vu la diversité des
utilisateurs demandeurs de services, d’autres paramètres doivent être considérés lors de la
découverte, tels que les besoins des utilisateurs, leurs exigences et leurs préférences. A cette
fin, l’élaboration d’une ontologie de profil d’utilisateur est notre deuxième réflexion pour
augmenter le degré de pertinence des résultats de découverte.
Ainsi, nous proposons d’exploiter ces ontologies dans un système pour la publication
et la découverte des web services e-learning.
Mots clés :
e-learning, ontologie, web services, découverte des web services, profil utilisateur, DAML-S.
Abstract
Today’s tendency in learning environments is the increasing use of the web services in
order to allow interoperability between platforms. A web services is an application, put on
Internet, by service supplier, and accessible by the customers through standard protocols. The
services descriptions are recorded in a directory named UDDI.
Currently, the number of web services-based e-learning platforms is more and more
increasing. These platforms are from different suppliers and have different characteristics and
functionalities. Consequently, their discovery and localization becomes a very important
challenge. Selection and choice criteria of the e-learning platform web services depend,
generally, on the adopted teaching model and the ergonomic and technological constraints.
Our work falls under these problems considering of these criteria during a web
services discovery operation. Therefore, for better answering the discovery requests, we
propose to provide a semantic description of the different web services constraints. This
semantic description is achieved with DAML-S ontology, extended by another ontology
named the training quality ontology (TQ), that describes the service in terms of provided
training functionalities and technological aspects. However, due to the diversity of web
services customers, other parameters must be considered during the discovery process, such
as the user's needs, their requirements and preferences. For this purpose, the development of
the user profile ontology is our second reflection to increase the degree of relevance of
discovery results.
Thus, we propose to exploit these ontologies in a system for e-learning web services
publication and discovery.
Key words:
E-learning, ontology, web services, web services discovery, user profile, DAML-S
Remerciements
Je remercie Allah le tout puissant, qui m’a donné la foi, la force et la patience pour
aller jusqu’au bout de ce travail.
Je tiens à remercier, bien sûr, en priorité, mes promoteurs, Monsieur BALLA Amar et
Monsieur AMROUCHE Hakim. Comment, en effet, ne pas souligner, l’aide exceptionnelle
qu’ils m’ont apportée. Leur conseil, leur disponibilité continuelle, leur suivi minutieux de
mon travail et leur soutien, m’ont permis de mener à bien ce travail. Qu’ils veuillent bien
trouver ici témoignage de ma reconnaissance.
Je remercie également les membres du jury pour l’honneur qu’ils m’ont attribué en
acceptant d’évaluer et de juger ce modeste travail.
Je remercie Mesdemoiselles, Souade Adiche et Yasmine Noureddine pour leur aide et

leur travail.
Sans oublier mes amis pour leur aide que pour leur soutien moral aux moments où tout
allait mal, à vous tous merci.
Cette page n’aurait probablement pas pu s’écrire sans l’appui moral des membres de
ma famille. Je les remercie tous, particulièrement ma mère, mes frères et mes sœurs pour
l’amour qu’ils m’ont apporté tous les jours.
Enfin, Que toute personne ayant contribué de près ou de loin à la réalisation de ce

travail par une quelconque forme de contribution trouve ici le témoignage de ma plus
profonde reconnaissance.
Dédicaces
A la mémoire de celui que j’aime tant, et que j’aurais aimé voir présent à ce jour,
…mon très cher regretté père
A celle qui a su sécher mes larmes et me donner la force de continuer…

…. ma très chère mère, « Sans toi ma mère ce travail
n'aurait jamais vu le jour»
Table des Matières
Introduction générale…………………………………………………..…………………….1
Partie I : Etat de l’art …………...………………………….………………….3
Chapitre 1 : Le e-learning…………………….……………………….……………………..3
1 Qu’est – ce que le e-learning ? ........................................................................................... 3

2 Les technologies du e-learning........................................................................................... 4
3 Les plateformes e-learning ................................................................................................. 5
3.1 Les LMS (Learning Management System) ............................................................... 5
3.2 Les LCMS (Learning Content Management System)............................................... 6
3.3 Positionnement des LMS par rapport aux LCMS ..................................................... 6
4 Les acteurs d’une plateforme ............................................................................................. 7
4.1 Apprenant .................................................................................................................. 7
4.2 Enseignant ................................................................................................................. 8
4.3 Administrateur........................................................................................................... 8
5 Modèles d’utilisateurs ........................................................................................................ 8
5.1 PAPI Learners ........................................................................................................... 9
5.2 IMS LIP................................................................................................................... 10
5.3 IMS ePortfolio......................................................................................................... 12
5.4 Synthèse .................................................................................................................. 13
6 Comment choisir une plateforme e-learning ? ................................................................. 13
6.1 Critères de choix d’une plateforme e-learning........................................................ 14
6.2 Comparaison de quelques plateformes e-learning .................................................. 16
6.3 Synthèse .................................................................................................................. 19
7 Vers un e-learning distribué ............................................................................................. 19
7.1 Exemple: l’architecture KnowledgeTree (KT) ....................................................... 20
8 Conclusion........................................................................................................................ 21
Chapitre 2: Les web services………………………………………………………………..22
1 Définition des web services.............................................................................................. 22

2 Caractéristiques des web services .................................................................................... 22
3 Architecture des web services .......................................................................................... 23
4 Le protocole SOAP .......................................................................................................... 25
4.1 Le framework de messagerie SOAP ....................................................................... 25
4.2 Encodage / sérialisation standard pour les objets.................................................... 26
4.3 Invocation de service d’objets distant via SOAP RPC ........................................... 26
4.4 Structure d’un message SOAP ................................................................................ 27
5 Le langage WSDL ............................................................................................................ 27
5.1 Structure d’un document WSDL............................................................................. 27
5.2 Liaisons avec les protocoles de transport................................................................ 28
6 Le standard UDDI ............................................................................................................ 28
6.1 Mécanismes d’accès aux services fournis par UDDI.............................................. 29
6.2 Le modèle de données d’UDDI............................................................................... 30
6.3 L’interface d’UDDI................................................................................................. 31
6.4 L’usage de l’annuaire UDDI................................................................................... 32
7 Relation entre UDDI et WSDL ........................................................................................ 33
8 Application des web services ........................................................................................... 34
8.1 Une application e-learning ...................................................................................... 35
9 Conclusion........................................................................................................................ 37
Chapitre 3: La découverte des web services ………………………………………………39
1 Les ontologies................................................................................................................... 39
1.1 Définition ................................................................................................................ 39
1.2 Les composantes d’une ontologie ........................................................................... 39
1.3 Rôles des ontologies................................................................................................ 40
2 Le web sémantique........................................................................................................... 41
3 Les web services sémantiques.......................................................................................... 42
4 Approches pour les web services sémantiques................................................................. 42
4.1 DAML-S ................................................................................................................. 42
4.1.1 La classe "ServiceProfile" ................................................................................ 43
4.1.2 La classe "ServiceModel" ................................................................................ 46
4.1.3 La classe "ServiceGrounding".......................................................................... 47
4.1.4 Les ressources................................................................................................... 47
4.2 WSDL-S .................................................................................................................. 47
5 Quelques stratégies de découverte ................................................................................... 48
5.1 La stratégie UDDI ................................................................................................... 49
5.2 Découverte des services selon les qualités de services ........................................... 49
5.3 Un modèle pour indexer et découvrir les services e-learning ................................. 50
6 Synthèse des différentes stratégies ................................................................................... 52
7 Conclusion........................................................................................................................ 52
Partie II: Conception et mise en œuvre………….………………………… 54

Chapitre 4: Conception……………………………………………………………………..54
1 Description ontologique des web services e-learning ...................................................... 54

1.1 Choix du DAML-S.................................................................................................. 54
1.2 L’ontologie de qualité d’apprentissage (QA).......................................................... 55
1.2.1 la calsse « Qualité d’apprentissage »................................................................ 56
1.2.2 La classe « informations pédagogiques »......................................................... 56
1.2.3 La classe « informations techniques ».............................................................. 60
1.2.4 La classe « informations financières » ............................................................. 64
1.3 Intégration de l’otologie QA avec DAML-S .......................................................... 65
1.3.1 la classe « interopérabilité » ............................................................................. 65
2 Présentation du système ................................................................................................... 66
2.1 Architecture du système .......................................................................................... 66
2.2 Utilisateurs et fonctions principales du système ..................................................... 68
2.2.1 Cas d’utilisation commun à tous les utilisateurs .............................................. 68
2.2.2 Cas d’utilisation du fournisseur de web service............................................... 69
2.2.3 Cas d’utilisation de l’administrateur ................................................................ 69
2.2.4 Cas d’utilisation de l’enseignant ...................................................................... 70
2.2.5 Cas d’utilisation de l’apprenant........................................................................ 71
2.3 Le module de publication........................................................................................ 72
2.3.1 Description du module ..................................................................................... 72
2.3.2 Fonctionnement du module .............................................................................. 72
2.4 Le module de découverte ........................................................................................ 74
2.4.3 Algorithme de découverte ................................................................................ 77
2.4.4 Filtrage des résultats de découverte selon le profil de l’utilisateur .................. 79
2.4.4.1 L’ontologie du profil utilisateur ................................................................... 79
2.4.4.2 Web service de gestion du profil utilisateur................................................. 83
2.4.4.3 Algorithme de filtrage des résultats de découverte ...................................... 85
2.5 Le module d’invocation de service ......................................................................... 86
3 Conclusion........................................................................................................................ 87
Chapitre 5: Mise en œuvre ……….……………………………………………………….55
1 Technologies et outils de développement ........................................................................ 89

1.1 Editeur d’ontologie.................................................................................................. 89
1.2 Le langage JAVA .................................................................................................... 89
1.2.1 Les technologies des JSP et Servlet ................................................................. 90
1.3 Le serveur Apache Tomcat ..................................................................................... 90
1.4 Technologies des web services ............................................................................... 91
1.4.1 UDDI ................................................................................................................ 91
1.4.2 Plateforme web services................................................................................... 91
2 Implémentation du système.............................................................................................. 91
2.1 Architecture fonctionnelle du système.................................................................... 91
2.2 Les ontologies ......................................................................................................... 93
2.2.1 L’ontologie des services................................................................................... 93
2.2.2 L’ontologie du profil utilisateur ....................................................................... 95
2.3 Les différents modules du système ......................................................................... 96
2.3.1 Le module de publication ................................................................................. 97
2.3.2 Le module de découverte ............................................................................... 103
2.3.3 Le web service de gestion du profil utilisateur............................................... 106
2.3.3.1 Inscription d’un nouvel utilisateur ............................................................. 107
2.3.4 Filtrage des résultats de découverte................................................................ 109
3 Conclusion...................................................................................................................... 111
Conclusion générale………………………..……………………………………………...111
Bibliographie
Annexe A : L’ontologie des services

Annexe B : L’ontologie du profil utilisateur
Liste des Figures
Chapitre 1
Figure 1. 1 : Complémentarité des LCMS/LMS. ......................................................................7

Figure 1. 2 : Le standard PAPI Learner .....................................................................................9
Figure 1. 3 : Les principales structures de données de IMS LIP. ............................................11
Figure 1. 4 : L’architecture KnowledgeTree. ...........................................................................20
Chapitre 2
Figure 2. 1 : Architecture des web services. ............................................................................24
Figure 2. 2 : Etapes d’invocation d’objets distant avec SOAP.................................................26
Figure 2. 3 : Structure d’un message SOAP.............................................................................27
Figure 2. 4 : Mécanismes d’accès aux services de UDDI. ......................................................29
Figure 2. 5 : Modèle de données de l’annuaire UDDI. ...........................................................30
Figure 2. 6 : Relation entre UDDI et WSDL............................................................................34
Figure 2. 7 : Plateforme e-learning comme web services. .......................................................35
Chapitre 3
Figure 3. 1 : Classes de l’ontologie DAML-S. ........................................................................43
Figure 3. 2 : Un modèle pour l’enregistrement et l’invocation de web services......................50
Chapitre 4
Figure 4. 1 : Ontologie de qualité d’apprentissage................................................................... 56
Figure 4. 2 : Ontologie de qualité d’apprentissage – «Informations pédagogiques». .............. 57
Figure 4. 3 : Ontologie de qualité d’apprentissage – le volet « Informations techniques ». .... 61
Figure 4. 4 : Ontologie de qualité d’apprentissage – le volet « Informations financières »..... 64
Figure 4. 5 : Ontologie des services. ........................................................................................ 65
Figure 4. 6 : Architecture de publication, découverte selon le profil utilisateur et invocation de
web services e-learning. ........................................................................................................... 67
Figure 4. 7 : Cas d’utilisation de tous les utilisateurs............................................................... 69
Figure 4. 8 : Cas d’utilisation du fournisseur de web service. ................................................. 69
Figure 4. 9 : Cas d’utilisation de l’administrateur.................................................................... 70
Figure 4. 10 : Cas d’utilisation de l’enseignant........................................................................ 71
Figure 4. 11 : Cas d’utilisation de l’apprenant. ........................................................................ 71
Figure 4. 12 : Architecture du module de publication.............................................................. 72
Figure 4. 13 : Diagramme de séquence du module de publication. ......................................... 73
Figure 4. 14 : Architecture du module de découverte. ............................................................. 75
Figure 4. 15 : Diagramme de séquence du module de publication. ......................................... 76
Figure 4. 16 : l’ontologie de profil d’utilisateur....................................................................... 80
Figure 4. 17 : Architecture du web service de gestion des profils utilisateurs......................... 83
Figure 4. 18 : Architecture du module d’invocation de web service. ...................................... 86
Figure 4. 19 : Diagramme de séquence du module d’invocation............................................. 87
Chapitre 5
Figure 5. 2 : L’ontologie des web services............................................................................... 94

Figure 5. 3 : L’ontologie de profil utilisateur........................................................................... 96
Figure 5. 4 : Interface principale du prototype. ........................................................................ 97
Figure 5. 5 : Interface de publication. ...................................................................................... 98
Figure 5. 6 : Associer un fournisseur à un web service............................................................ 99
Figure 5. 7 : Options avancées de publication (softwares exigés). ........................................ 100
Figure 5. 8 : Options avancées de publication (Ressources et Modalités de test).................. 100
Figure 5. 9 : Ajout d’un fournisseur. ...................................................................................... 102
Figure 5. 10 : Ajout d’une formation. .................................................................................... 103
Figure 5. 11 : Interface de découverte de service................................................................... 104
Figure 5. 12 : Découverte et résultat de découverte de service. ............................................. 106
Figure 5. 13 : Page d’accueil du service de gestion de profil utilisateur................................ 107
Figure 5. 14 : Inscription d’un nouvel utilisateur................................................................... 108
Figure 5. 15 : Introduction des informations de préférences d’un nouvel utilisateur. ........... 109
Figure 5. 16 : Découverte de service avec prise en compte du profil utilisateur. …...........110
Liste des Tableaux

Tableau 1.1 : Comparaison des plateformes.............................................................................18
Introduction générale
La progression rapide des technologies de l’information et de la communication a
donné naissance à une nouvelle forme d’apprentissage dite e-learning, un apprentissage rapide
et efficace, avec un minimum de problèmes d’organisation et de logistique. De nombreuses
solutions logicielles ont été proposées pour la réalisation des environnements e-learning telles
que les LMS (Learning Management Systems) et les LCMS (Learning Content Management
System). Cependant les acteurs (administrateurs, enseignants et apprenants) de ces systèmes
ont présenté des besoins de plus en plus accrus en terme d’adaptation, de parcours selon les
exigences et profils d’utilisateurs, de partage et de possibilité de réutilisation des contenus et
des fonctionnalités. Ce qui a incité l’expansion de ces systèmes vers des environnements
distribués en utilisant souvent les ontologies, le web sémantique et les web services pour
satisfaire les exigences des acteurs.
Le nombre de plateformes e-learning, qui sont basées sur les web services, est de plus
en plus croissant. Un web service peut être défini comme un programme autonome qui
s’exécute sur le web. Un web service est décrit par le langage WSDL. Cette description,
purement syntaxique, est enregistrée dans des registres UDDI afin de faciliter la recherche
(découverte) de web service.
Une plateforme e-learning peut être vu comme un ensemble de web services qui
coopèrent entre eux pour fournir certaines fonctionnalités aux acteurs de la plateforme. Ainsi
c’est possible d’utiliser / réutiliser des services externes qui appartiennent à d’autres
plateformes e-learning. Mais avant d’utiliser / réutiliser ces services, il est nécessaire de les
localiser. Cette localisation (découverte) est une opération importante qui doit être
automatique et efficace.
Le mécanisme de découverte doit dépasser certain nombre de limitations afin d’être
efficace, par exemple la découverte de services selon leurs fonctionnalités, leurs temps
d’exécution et leurs coûts. Ceci n’est pas possible avec les standards UDDI et WSDL, vu
qu’ils offrent une description syntaxique des services. Pour pallier à ces limitations, une
nouvelle génération de web services dite web services sémantiques a été proposée. Les web
services sémantiques sont des web services dotés d’une description sémantique, cette dernière
est réalisée grâce à plusieurs langages et formalismes, entre autre l’ontologie DAML-S, qui
offre, en plus de la description syntaxique, des informations sémantiques sur le
1
fonctionnement de service. Ces informations peuvent être utilisées pour améliorer la qualité
de la découverte.
Les critères de choix d’un service d’une une plateforme e-learning dépendent,
généralement, du modèle pédagogique adopté et des contraintes ergonomiques et
technologiques. Toutefois, DAML-S n’offre pas la possibilité de décrire ces critères. Afin de
soutenir la description de ces critères, nous avons proposé dans ce travail une extension à
DAML-S qui consiste en une ontologie dite ontologie de qualité d’apprentissage (QA). La
pertinence des résultats de découverte dépend aussi des préférences des utilisateurs, de leurs
intérêts, leurs besoins et leurs niveaux d’expertise, etc. A cette fin, l’élaboration d’une
ontologie de profil d’utilisateur est notre deuxième réflexion pour augmenter le degré de
pertinence des résultats de découverte des web services e-learning.
Enfin, nous avons tenté d’exploiter les deux ontologies, ontologies des services et
ontologie de profil utilisateur dans un système pour la publication et découverte des web
services.
Organisation du document
Ce document s’articule autour de deux parties principales :
• La première partie, propose un état de l’art du e-learning et des web services. Dans
cette partie il est question tout d’abord d’introduire le domaine e-learning à travers
quelques formes d’outils e-learning et les modèles de ses acteurs (Chapitre1).
L’évolution de ce domaine et de ses besoins croissant en terme de distribution et de
sémantique nous amène à poursuivre ce chapitre par la présentation des web services
et leurs relations avec le e-learning (Chapitre 2). Nous aborderons par la suite les web
services sémantiques et quelques techniques et approches proposées pour la
découverte et l’invocation des web services (Chapitre 3).
• La seconde partie, présente la conception et la mise en œuvre du système de

publication et découverte des web services e-learning, et traite ainsi de sa modélisation,
à base d’ontologies et de son architecture (Chapitre 4). Elle comprend également les
parties principales de l’implémentation du système (Chapitre 5).
2
Partie I
Etat de l’art
Afin de présenter le contexte de notre travail, cette première partie tente de faire un
récapitulatif sur le e-learning et les web services tout en abordant le thème de publication et
découverte de web services sémantiques.
Chapitres :
1. Le e-learning.
2. Les web services.
3. Découverte des web services.
Chapitre 1
Le e-learning
Sommaire
1 Qu’est – ce que le e-learning ? ........................................................................................... 3

2 Les technologies du e-learning........................................................................................... 4
3 Les plateformes e-learning ................................................................................................. 5
3.1 Les LMS (Learning Management System) ............................................................... 5
3.2 Les LCMS (Learning Content Management System)............................................... 6
3.3 Positionnement des LMS par rapport aux LCMS ..................................................... 6
4 Les acteurs d’une plateforme ............................................................................................. 7
4.1 Apprenant .................................................................................................................. 7
4.2 Enseignant ................................................................................................................. 8
4.3 Administrateur........................................................................................................... 8
5 Modèles d’utilisateurs ........................................................................................................ 8
5.1 PAPI Learners ........................................................................................................... 9
5.2 IMS LIP................................................................................................................... 10
5.3 IMS ePortfolio......................................................................................................... 12
5.4 Synthèse .................................................................................................................. 13
6 Comment choisir une plateforme e-learning ? ................................................................. 13
6.1 Critères de choix d’une plateforme e-learning........................................................ 14
6.2 Comparaison de quelques plateformes e-learning .................................................. 16
6.3 Synthèse .................................................................................................................. 19
7 Vers un e-learning distribué ............................................................................................. 19
7.1 Exemple: l’architecture KnowledgeTree (KT) ....................................................... 20
8 Conclusion........................................................................................................................ 21
Chapitre 1 : Le e-learning
Chapitre 1
Le e-learning
L’apparition de l’informatique a permit l’avènement d’une nouvelle forme
d’enseignement dite ‘e-learning’, qui a devenu actuellement un des moyens pédagogiques
prometteurs. L’objectif principal du e-learning est d’améliorer la qualité de l’apprentissage et
non de se substituer aux modes traditionnels d’enseignement. Les moyens pour atteindre cet
objectif sont multiples, complémentaires et indépendants : accès à des ressources variées,
offres de services de tutorat à distance, outils de communication, résolution d’exercices,
échanges et collaboration à distance. Ces moyens sont exploités pour la mise en application de
nombreux outils à savoir les LMS (Learning Management System).
Ce chapitre fait un tour d’horizon rapide du principe du e-learning et plateforme e-
learning, leur technologie et leur acteur, suivi d’une présentation des principaux modèles
d’utilisateurs, sont également présentés des plateformes concrètes et une étude comparative
dans le but de donner les principaux critères de choix d’une plateforme e-learning, suivi d’une
présentation des solutions e-learning distribuées.
1 Qu’est – ce que le e-learning ?

e-learning est souvent décliné sous la forme «electronic learning», « e-formation » en
français [WAL, 04]. Il définit tout dispositif de formation qui utilise un réseau Intranet,
Extranet ou Internet pour diffuser, interagir ou communiquer dans un environnement distribué,
et accéder à des sources par téléchargement ou en consultation en ligne. Il résulte donc de
l'association de contenus interactifs et multimédia, de supports de distribution (PC, Internet,
intranet, extranet), d'un ensemble d'outils logiciels qui permettent la gestion d'une formation
en ligne et d'outils de création de formations interactives.
Plusieurs terminologies sont utilisées pour désigner le même concept, entre autres :
• Formation A distance (FAD).
• Enseignement A Distance (EAD).
• Formation Ouverte et A Distance (FOAD).
• E – Formation.
• Formation Ouverte.
3
2 Les technologies du e-learning

Le e-learning offre la possibilité d’accéder à distance à des ressources et des services,
ainsi qu'à des collaborations et des échanges, n’importe quand et n’importe où, grâce à une
gamme très vaste de solutions d'apprentissages électroniques telles que le multimédia (qu’est
l’exploitation simultanée de plusieurs médias, son, image, texte sur un même support),
l’Internet et les outils de collaborations. Le multimédia offre deux types de services selon que
les informations sont consultées en local (hors ligne tel que les CD-Rom) ou à distance (en
ligne i.e Internet). [EMN, ]
Voici une liste sélective d'outils qui aident à donner une dimension collaborative et interactive
à l’e-learning. Ces outils peuvent être classés en deux catégories : outils synchrones et outils
asynchrones.
• Outils synchrones : les outils d’interactivité en temps réel :
1. Tableau blanc : c’est une fenêtre graphique et textuelle qui peut être partagée de
façon synchrone (simultanément) par tous les participants à la formation. Il
autorise le partage et l’élaboration de documents en temps réel qui seront visionnés
par les apprenants et modifiables par chacun des participants.
2. Chat : c’est la messagerie instantanée qui permet une communication collective
temps réel afin de vérifier la bonne compréhension des cours…etc.
3. Vidéo conférence : qui permet une communication bilatérale ou collective en
temps réel afin de réaliser des fonctionnalités pédagogiques à savoir : la
présentation de cours, les conférences…etc.
4. Classe virtuelle : les apprenants sont simultanément en ligne avec leur formateur.
Ils échangent entre eux, visionnent les mêmes écrans et peuvent recevoir des
images de vidéoconférence.
5. Voix / IP : c’est le transfert de la voix par voie IP.
• Outil asynchrones : l’interactivité n’est pas en temps réel mais en différé :
1. Transfert de fichier : une fonctionnalité très utile, permet d’envoyer des
documents, des photos, des vidéos,…etc.
2. Forum : qui offre la possibilité de faire une communication collective différée
(une discussion asynchrone) afin de développer, grouper des informations par
thème, confronter les idées…etc.
4
3. Email : c’est les courriers électroniques, ils assurent une communication bilatérale
déférée (consignes, gérer des groupes d’apprenants en envoyant des messages aux
classes, transmission de documents, aide…etc.).
4. La foire aux questions : équivalents ou assimilés : FAQ, Fichier des questions
courantes, Frequently Asked Questions, Questions courantes. Ensemble des
questions les plus fréquemment posées et qui sont regroupées avec leurs réponses,
postées et mises à jour dans la plupart des groupes de news. Avant de poser une
question, il faut toujours regarder si la réponse ne se trouverait pas dans les FAQ.
La foire aux questions a, en particulier, pour but de faciliter l'intégration des
utilisateurs novices dans un groupe de discussion et de diminuer le nombre des
messages diffusés dans le réseau.
3 Les plateformes e-learning

Une plateforme pédagogique est un logiciel qui assiste la conduite des enseignements
à distance en offrant des fonctionnalités de gestion de contenus, de diffusion et accès à
distance aux cours, de suivi et d’accompagnement des apprenants, de gestion des différents
acteurs (apprenants, enseignants et administrateurs), d’auto apprentissage et autoévaluation,
de télé tutorat,… ceci via l’utilisation des moyens de travail et de communication à savoir :
visioconférence, e-mail, forums, chats, annotations, etc.[KOU,07]
Dans le domaine du e-learning on peut distinguer deux types de plateformes : les LMS
(Learning Managment System) et les LCMS (Learning Content Managment System).
3.1 Les LMS (Learning Management System)

Les LMS sont des systèmes logiciels ou des plateformes développés pour faciliter aux
enseignants la gestion des cours. Ces systèmes permettent la diffusion des contenus
pédagogiques, la gestion centrale de la formation, la gestion des apprenants (l’authentification,
les inscriptions, leurs profils, leurs résultats et leurs progrès entre les différents modules de
formation....), la gestion des autres utilisateurs (les responsables de la formation) et la gestion
des catalogues de cours.
Côté utilisateurs, plusieurs groupes ou profils sont maintenus au niveau d’une plateforme
LMS dont la gestion des droits d’accès pour les différents groupes d’utilisateurs
(administrateurs, formateurs, tuteurs et apprenants,) est une fonctionnalité centrale du système.
La plateforme gère l’affectation des tuteurs / experts à une classe donnée dans le cas où les
apprenants sont accompagnés par des tuteurs ou des experts attachés à un cours.
5
La gestion des apprenants consiste à gérer les demandes de formation, la plupart des
plateformes enregistrent les inscriptions en ligne des apprenants, sur leur initiative ou par
affectation collective. Des listes d’attente sont créées et gérées par la plateforme si les cours
sont associés à des groupes à capacité limitée. Selon la complexité de l’organisation,
l’inscription à une classe peut être soumise à l’autorisation d’un tuteur ou responsable, qui
valide ou non la demande de formation de l’apprenant dont il a la supervision. [LCM, 03]
3.2 Les LCMS (Learning Content Management System)

Les LCMS permettent aux créateurs de cours de créer, stocker, réutiliser, gérer et
distribuer des contenus pédagogiques à partir d’un référentiel unique. Ce référentiel stocke
des grains de savoir (un grain est une entité, numérique, pouvant être utilisée pour
l’enseignement), et une plateforme LCMS permet de les associer et les ordonner afin de
construire un cours cohérent. [LCM, 03]
L’objectif des LCMS est de répondre aux difficultés rencontrées lors de la création des
ressources pédagogiques :
• Le temps de production par l’utilisation des modèles et des outils d’assemblage de
ressources pédagogiques ;
• La réutilisation des ressources existantes ;
• L’intégration des ressources dans les plateformes d’enseignement existantes
(l’interopérabilité avec les LMS).
• La collaboration (les messageries électroniques, les forums de discussion, le « chat »
et les systèmes collaboratifs) lors de la création.
3.3 Positionnement des LMS par rapport aux LCMS

LCMS et LMS deux nouveaux termes, apparus avec l’avènement du web, font référence à
des outils complémentaires, sont des outils très proches. Cependant la distinction entre ces deux
outils n’est pas évidente dans la mesure où les plateformes LMS intègrent souvent en standard
des fonctionnalités de LCMS, et vice versa.
En effet, historiquement les LMS (premières solutions apparues sur le marché du e-learning),
proposaient des applications de création de contenus. Les LCMS peuvent aussi implémenter
des fonctionnalités légères de LMS. [LCM, 03]
Le schéma suivant illustre la distinction et la complémentarité des LMS et des LCMS :
6
Figure 1. 1 : Complémentarité des LCMS/LMS. [LCM, 03]
En réalité, les LMS et LCMS sont souvent retrouvés intégrés dans un même outil. Ceci dans
le but d’éviter les problèmes d’interopérabilité entre les deux outils, notamment en ce qui
concerne la diffusion de contenus sur les plateformes LMS. Une solution LCMS intégrée dans
une solution LMS lui fournit des contenus totalement utilisables.
4 Les acteurs d’une plateforme

Les acteurs du e-learning peuvent être classés, selon leur rôle, en trois catégories
principales : les apprenants, les enseignants et les administrateurs.
4.1 Apprenant
Personne qui utilise une plateforme e-learning pour acquérir des connaissances, s’auto-
évaluer, soumettre des rapports, des projets, participer aux forums de discussion, échanger des
données. L’apprenant peut être un étudiant désirant suivre un certain cours, un employé
d’entreprise ayant besoin d’une formation dans un certain domaine, une personne désirant
perfectionner ses connaissances dans une branche quelconque,...etc. [EMN,]
7
4.2 Enseignant
Le e-learning nécessite plusieurs types d’enseignants, différenciés par leurs rôles. On peut
distinguer quatre types d’enseignants, [OUB, 05] , [EMN, ] :
• Auteur (concepteur) de cours : celui qui développe un cours en utilisant les outils de la
plateforme selon ses objectifs pédagogiques et qui apporte des changements en fonction
des réactions des apprenants ou des tuteurs.
• Orienteur : c’est l’enseignant qui a pour principales tâches, l’élaboration des cursus
des apprenants ou des groupes d’apprenants, l’élaboration des plans de formation, et
gestion du livret des apprenants.
• Tuteur : son rôle est de superviser le déroulement du cours, d’évaluer les apprenants,
de communiquer et d’interagir avec eux, d’animer le groupe ou la communauté
d’apprenants et d’assurer le suivi pédagogique de la formation.
Le tuteur joue un rôle moteur dans la formation. La qualité du suivi permet de garantir
la motivation de l'apprenant et d'éviter qu'il abandonne sa formation en cours de route.
• Evaluateur : son rôle est de créer les tests, de suivre les apprenants et de gérer les
tests d’évaluation.
4.3 Administrateur
On peut distinguer deux types d’administrateurs :
• Administrateur technique : gère la plateforme (installation et maintenance).
• Administrateur institutionnel : gère les inscriptions, gère les comptes, affecte les
droits d’accès pour les acteurs et gère les liens avec les systèmes d’information
externes (scolarité, catalogues, ressources pédagogiques ...etc.).
5 Modèles d’utilisateurs
On a vu qu’une plateforme e-learning peut avoir, selon les besoins, plusieurs rôles et
plusieurs profils d’utilisateurs. La plateforme doit les soutenir tous dans leurs fonctions et
leurs tâches, elle doit faciliter l’expression de leurs besoins et permettre l’obtention des
informations pertinentes lors de leurs accès aux informations.
En conséquence, les plateformes doivent s’adapter à chaque type d’utilisateurs et répondre à
leurs besoins précis. Dans ce contexte, nous allons présenter trois standards, les plus
importants, pour la modélisation de l’apprenant : PAPI, IMS LIP et IMS ePortfolio.
8
5.1 PAPI Learners

PAPI (Public and Private Information) Learner [PAP, 00]1 est un standard, développé
par LTSC de IEEE 2 , qui spécifie les connaissances et caractéristiques des apprenants. Il
contient des éléments pour la sauvegarde des connaissances acquises, des qualifications, des
capacités, des modèles d’apprentissage, des traces et des informations personnelles. Il permet
différentes vue du modèle d’apprenant (étudiant, professeur, parent, école, employer, etc).
General Learning Technology Information
Learner Information
PAPI Learner Performance

Extensions
Learner Relations Info Learner Portfolio Info
Learner Performance Info
PAPI Learner Relations PAPI Learner Portfolio
Extensions Learner Profile Extensions
PAPI Learner Security Information PAPI Learner Preference
Extensions Extensions
Learner Personal Info
Learner Security Info Learner Preference Info
PAPI Learner Personal
Extensions
Figure 1. 2 : Le standard PAPI Learner [PAP, 00]
Six types d’informations sont définis :
• Les informations personnelles (PAPI Learner personal): les informations privées

(nom, adresse et numéro de téléphone) qui ne sont pas directement liées à
l’apprentissage mais principalement à l’administration.
• Les informations relationnelles (PAPI Learner relations) : les informations sur les
relations de l’apprenant avec les autres utilisateurs de la plateforme tels que les autres
apprenants et les tuteurs.
• Les informations sur la sécurité (PAPI Learner security): les informations de
sécurité telles que: le mot de passe, clé privée, clé publique, etc.
1
http://edutool.com/papi
2
LTSC: Learning Technology Standards Committee. IEE : Institute of Electronic & Electrical Engineering.
9
• Les informations de préférence (PAPI Learner preference): les informations qui

peuvent améliorer les interactions homme – machine et permettre l’adaptation
automatique du système d’apprentissage aux besoins de l’apprenant.
• Les informations de performance (PAPI Learner performance): les informations
concernant l’historique de l’apprenant, son travail actuel ou ses objectifs future qui
sont créées et utilisées par le système d’apprentissage pour fournir an apprentissage
optimal.
• Le portfolio (PAPI Learner Portfolio): c’est une collection représentative de travaux
de l’apprenant qui sont envisagés pour l’illustration et la justification de ses capacités
et réalisations.
Ce standard ne décrit pas toutes les informations possible de l’apprenant, mais inclut
seulement les informations minimales nécessaires pour être au maximum portable tout en
permettant l’extension de ces informations.
A coté de PAPI Learner, il existe un autre standard de spécification nommé IMS LIP, que
nous présentons dans la section qui suit.
5.2 IMS LIP

IMS3 LIP (Learner Packaging Package), [IMS, 01]4 [COL, 01]5, est une spécification
d’un modèle de données qui permet la description des informations sur les apprenants. Il est
conçu pour tenir les données des apprenants, y compris leur progrès et leurs récompenses
reçues. En outre, il permet le transfert de ces données entre différents systèmes
d’apprentissage qui sont compatibles avec sa spécification. Il utilise XML pour la
représentation des différentes informations.
IMS LIP définit onze catégories principales (Figure ci-après)
3
IMS (Instructional Management System), créé en 1997, est le consortium dominant aujourd'hui. Il regroupe des
industriels et des acteurs de la formation publique et privée. [JEA, 05]
4
http://www.imsglobal.org/profiles/lipbest01.html
5
http://www.imsproject.org/profiles/lipinfo01.html
10
Figure 1. 3 : Les principales structures de données de IMS LIP. [IMS, 01]
• Identification: les informations de base pour identifier un apprenant tels que son nom,
son adresse, son email, etc.
• Goal: les données sur les objectifs et les ambitions personnels de l’apprenant.
• QCL: reflète les qualifications, les certifications et les diplômes attribués à
l’apprenant.
• Activity: regroupe les informations sur les activités liées au travail et à la formation
d’un apprenant.
• Interest: les données sur les hobbies et les loisirs de l’apprenant.
• Competency: les compétences, les connaissances et les capacités acquises par un
apprenant dans une formation ou dans un travail.
• Accessibility: les préférences de l’apprenant, en terme d’accessibilité aux
informations, tels que la langue, les préférences physiques (la police, par exemple) et
les préférences technologiques (système d’exploitation, par exemple).
• Transcript: permet la description des résultats d’examen de l’apprenant.
• Affiliation: les informations sur les organisations aux quelles l’apprenant adhère.
• SecurityKey: l’ensemble des mots de passe et de clés de sécurité assignés à
l’apprenant pour accéder aux services et informations du système d’apprentissage.
• Relationship: décrit les relations entre les différentes structures de données du modèle.
11
De même que PAPI, IMS LIP est limité. Il ne couvre pas toutes les informations nécessaires
sur l’apprenant pour l’échange d’informations. Ce qui a amené IMS à l’étendre et à donner
une nouvelle spécification qui est IMS ePortfolio.
5.3 IMS ePortfolio

IMS ePortfolio, créée par IMS en 2005 [BRO, 05]6 [EPO, 05]7 [EPM, 05]8 , est une
collection d’information appartenant à l’apprenant, rassemblant les résultats de ses études ou
de ses formations, ses buts, ses expériences professionnelles et tout autre ensemble
d’informations personnalisées qu’un apprenant peut présenter à une école, un employeur ou
une autre entité.
La spécification ePortfolio est fortement reliée à la spécification LIP. Elle vise à définir un
standard pour les ePortfolio, outil de plus en plus utilisé dans les contextes éducatifs de tout
secteur, du primaire à l’université. Cette spécification peut être considérée à première vue
comme un sur-ensemble de la spécification LIP. [JUL, 05] IMS a spécifié dix-huit catégories
pour le ePortefolio dont onze sont celles de IMS LIP (identification, Goal, QCL, Activity,
Iterest, competency, accessibility, transcript, affiliation, relationship, Securitykey). Les autres
catégories sont :
• Assertion: contient un texte correspondant à l’apprenant ou autres parties du Portfolio,
ou d’autres choses signifiées par le Portfolio.
• Other: représentation de n’importe quel autre contenu de classe du Portfolio.
• Participation: définit un groupe de personne qui peut inclure ou ne pas inclure le
propriétaire du Portfolio. Elle peut être utilisée pour représenter un groupe de
personnes qui ont collaborés dans la création d'un produit, ou participés ensemble à
une activité.
• Product : référence les matériels (tous ce qui peut être référencé électroniquement)
produits par le propriétaire.
• Reflexion: représente des réflexions, ou affirmations, sur une partie du Portfolio,
telles que les commentaires et les explications.
• Rubric: représente des conseils sur la façon avec laquelle le Portfolio a été ou doit
être évalué.
• RubricCell: représente l’intersection des dimensions de qualité dans une rubrique.
6
http://www.imsglobal.org/ep/ePortfoliobrochureFR.pdf
7
http://www.imsglobal.org/ep/
8
http://www.imsglobal.org/ep/epv1p0/imsep_infov1p0.html
12
Les spécifications du ePortfolio d'IMS ont été créées pour rendre des ePortfolios
interopérables à travers différents systèmes et établissements.
5.4 Synthèse
PAPI et IMS LIP sont considérés parmi les premiers standards qui collectent des
informations sur les apprenants. Les informations modelées par PAPI sont générales et ne
répondent pas à tous les besoins d’une institution désirant échanger des informations sur ses
apprenants avec d’autres institutions. Le PAPI a été enrichi par IMS en inventant le IMS LIP.
Ce dernier apporte beaucoup d’amélioration par rapport à PAPI, plus précisément, l’élément
« Activity » qui permet de représenter les activités et travaux réalisés par l’apprenant et
l’élément QCL qui permet de spécifier les qualifications de l’apprenant (ou un utilisateur, de
façon générale). Par la suite, IMS étend son LIP pour donner le IMS ePortfolio, qui peut
spécifier plus d’informations sur les apprenants et donne plus de flexibilité d’échange
d’informations.
Les trois standards (PAPI, IMS LIP, ePortfolio) de modélisation des apprenants (ou
utilisateurs) modélisent l’apprenant du point de vue pédagogique (QCL, Activity,…). Ils
visent à améliorer l’interopérabilité entre systèmes d’apprentissage en permettant le transfert
des données d’un apprenant.
6 Comment choisir une plateforme e-learning ?

Actuellement, l’e-learning est essentiellement utilisé en deux secteurs, en
l’occurrence ; les grandes entreprises pour former et actualiser les connaissances de leurs
employés de manière plus rapide et les universités qui offrent des alternatives de formation à
distance.
Pour la mise en application d’une formation e-learning dans une institution donnée certains
points doivent être bien définis et bien suivis en même temps:
Choix pédagogique : choix du modèle pédagogique, du support de cours en présentiel
ou à distance.
Choix technique : se résume en plusieurs tâches : le choix de la plateforme à utiliser,
l’achat de licence d'utilisation (si la plateforme n’est pas gratuite), définition des
objectifs et des modules de la formation, choix des outils d'appui à être utilisés en cas
de production local du contenu ou choix d'un fournisseur de contenu pédagogique,
13
définition du nombre d’apprenants et du nombre de groupes, et de la durée des

formations, définition des comptes, etc.
Ressources externes / Ressources internes : les documents pédagogiques
disponibles sur d’autres médias (CD-ROM, papier) en cas de besoin, infrastructure
technologique (bande passante, équipements de réception de vidéo en cas de besoin…),
support technique, etc.
Les acteurs et leurs rôles : la définition et la répartition des rôles pour les différentes
acteurs : tuteurs et animateurs (soutient le tuteur dans la gestion des groupes, mise à
jour des cours, affichage et publication de fichiers à télécharger.), spécialistes de
contenu, concepteur pédagogique, équipe de production, équipe de logistique (gère les
délais et envoie/reçoit des matériaux avant que les cours démarrent), apprenant (cible
de tous les acteurs décrits), équipe de support (responsable pour la résolution des
problèmes techniques des apprenants.
La réussite d’une formation à distance ne dépend pas seulement de la bonne structuration

et de la bonne préparation des cours mais elle dépend aussi de la plateforme choisie et des
fonctionnalités qu’elle offre. Cependant, avec l’évolution des technologies de la
communication et de l’information, le nombre de plateformes et environnements de formation
a augmenté de manière significative. De ce fait, le choix d'une plateforme e-learning a devenu
une problématique éminemment complexe. Ce choix est souvent institutionnel et guidé par
des éléments politico – stratégiques, mais également techniques, pédagogiques et
organisationnels [AGE, 08].
Dans les deux volets suivants, nous mentionnons les critères de sélection de plateformes
e-learning et nous donnons, brièvement, une comparaison de quelques plateformes existantes.
6.1 Critères de choix d’une plateforme e-learning

Le choix d’une plateforme e-learning, selon [ANN, 07] [ETU, 06] [KOU, 07], [SAB, 05],
dépend des critères pédagogiques, techniques et ergonomiques, parmi ces critères :
• Le type de licence : Open – Source, commerciale, publique ou gratuite9. Ainsi que le coût
de la mise en application de la plateforme, et la vérification des prestations fournies dans
le cas d’une plateforme payante ;
9
Pour plus d’informations sur les licences de logiciels voir «Licences Open Source» Annexe du projet
«Nouvelles Plateformes Technologiques Observatoire Technologique» réalisé par «Patrick Genoud, Giorgio
Pauletto ». 30 juin 2003. Centre des technologies de l’information République et canton de Genève.
14
• Le besoin de maintenance de la plateforme d’un point de vue strictement informatique,

qui devra être géré par les administrateurs techniques (voir également le coût en personnel
de maintenance) ;
• Les aspects de sécurité proposés au sein de la plateforme, à savoir le filtrage des IPs, le
login et mot de passe au niveau des cours, etc ;
• Le nombre maximum d’utilisateurs que pourra supporter la plateforme ;
• La technologie utilisée, du point de vue du langage pour pouvoir éventuellement faire
évoluer le système et sa capacité d’accueil (XML, MySQL, Php…) ;
• Les moyens requis pour consulter la plateforme (browser, OS) ;
• Documentation en ligne de l'installation de la plateforme à l'utilisation par les enseignants
et les apprenants ;
• Adaptabilité et modularité (Plugin) de la plateforme.
• La possibilité de diffuser les cours par de la vidéo soit en temps réel, soit en différé ;
• Création et personnalisation des parcours 10;
• Gestion des contenus par module, session ou formation ;
• Les standards et normes respectés comme SCORM, AICC et LOM.
• Gestion des programmes et des plans de formation ;
• La façon de poster un cours (à partir de documents PowerPoint, PDF,….) ;
• Gestion des individus, des groupes et sous-groupes ;
• La possibilité de mettre en place des exercices d’évaluation tels que les QCM (Questions à
Choix Multiples), les textes à trou, les réponses libres, etc. afin de permettre l'évaluation
des connaissances acquises (enregistrement et transmission au tuteur) ou bien la
réorganisation automatique de parcours pédagogiques en fonction des résultats (renvoi sur
une séquence non assimilée, proposition d'un module complémentaire pour remettre à
niveau les connaissances) ;
• La typologie des outils de communication synchrones (tel que le chat) et asynchrones (tel
que l’email et les forums de discussion);
• Possibilité d’importer et d’exporter des données administratives ;
• Possibilité de communiquer avec d’autres applications, par exemple, un système auteur
externe.
10
La notion de parcours pédagogique permet de composer des séquences pédagogiques à partir de ressources ou
de fonctionnalités installées sur la plate forme. [ETU, 06]
15
• Ergonomie et utilisabilité de la plateforme pour les enseignants comme pour les

apprenants.
Afin de mettre en évidence ces critères nous allons présenter par la suite une brève
comparaison entre quelques plateformes portant sur les points précédents.
6.2 Comparaison de quelques plateformes e-learning

Le nombre de plateformes d’apprentissage à distance ne cesse de croître, ce qui rend
l’établissement d’une étude comparative un travail fastidieux. Pour cela, nous avons recensé
trois plateformes pour notre étude : Moodle, Claroline et WebCT.
Nous donnons, en premier lieu, une brève présentation des trois plateformes retenues et, en
deuxième lieu, le tableau comparatif. La comparaison est réalisée selon les principaux critères
de choix cités dans la section précédente.
• Moodle : Moodle (Modular Object – Oriented Dynamic Learning Environment) est une
plateforme e-learning servant à créer des communautés d'apprenants autour de contenus et
d'activités pédagogiques. Moodle fut créée par Martin Dougiamas et la communauté
Moodle, sa première version est sortie en août 2002. Elle est dotée d'un système de
gestion de contenu (SGC) performant, Moodle a aussi des fonctions pédagogiques ou
communicatives lui permettant de créer un environnement d'apprentissage en ligne. Ces
fonctionnalités permettent de créer des interactions entre pédagogues, apprenants et
ressources pédagogiques formant ainsi un réseau et parfois même une véritable
communauté autour d'un thème choisi par les membres de la plateforme. [MOO, 08].
• Claroline : Claroline est une plateforme d’apprentissage en ligne et de travail collaboratif.
Elle a été initiée en 2001 par l'université de Louvain en Belgique. Elle permet à des
centaines d'institutions à travers le monde (universités, établissements scolaires,
associations, entreprises...) de créer et d'administrer des formations et des espaces de
collaboration en ligne. [CLA, 08]
• WebCT : WebCT est une plateforme d’apprentissage en ligne américaine largement
adoptée par de nombreuses universités et collèges dans le monde. Elle a été développée
par l'informaticien Murray W.Goldberg à l’Université de Colombie – Britannique. Il
développa la première version de WebCT. En 1997, il fonda la société WebCT
technologies éducatives pour garantir le développement du logiciel éducatif.
16
Plateforme Moodle Claroline WebCT

Critère
Version 1.9 1.8.8 4.1
Licence GPL GNU (openSource) GPL(openSource) Propriétaire
Coût 100 à 200 euros
d’hébergement
Langue Plus de 75 Langues 35 Langues Multilingue
Utilisation 200 000 utilisateurs 928 organisations dans 3 650 clients dans plus
enregistrés dans plus de 84 pays de 60 pays.
175 pays
Capacité (cours, 19 223 cours et 41 305 < 25 000 utilisateurs 3200 utilisateurs
utilisateurs) utilisateurs. (Université Marne la
(plateforme tchèque) Vallée, 2005). Mais
capacité illimitée.
Plateforme Unix, Linux, FreeBSD, Linux, BSD, Unix, Windows (98, XP, NT,
Windows, Mac OS X, Windows (9x, Me, Vista), Windows 2000
NetWare NT4, 2000, 2003, XP, ServerMac OS X
Vista) ou Mac OS X Sun Solaris, Linux.
Logiciels Apache, PHP, MySQL, Apache 1.3 ou 2.0 ou SQL Server, Oracle.
PostgreSQL. IIS. Installe son propre
PHP 4.3 ++ configuré serveur apache et sa
avec: mysql, zlib, preg. propre base de données.
Documentation Détaillée en 25 langues, Complète en 5 langues, Disponible

tutoriels disponibles tutoriels
Modularité Très modulaire (plus de Commence à partir de Oui
217 modules) la 1.8.x
Adaptabilité 3 types de présentation de Cours cloisonnés, pas Possibilité de
cours : de copier/ importer des personnalisation
- Thématique (selon le données.
thème) Plusieurs thèmes
- Hebdomadaire (selon un graphiques.
agenda ou du calendrier)
- Informel (selon des
sujets de discussion et
forums).
33 thèmes graphiques
Gestion de SGC Creation et importation Créer, modifier,
Contenu importer, exporter
Standards IMS-LD, SCORM, SCORM 1.2, IMS CP, SCORM, IMS, AICC
AICC, IMS CP IMS/QT2
Parcours Elaborer des parcours compatible avec Parcours personnalisés
17
SCORM 1.2
Teste QCM, questions Exercice compatible QCM, question de
vrai/faux, appariement, avec IMS/QTI correspondance, à
devoirs, etc. réponse courte,
calculée, ouvertes et
paragraphe,
tests chronométrés,
devoirs.
Sécurité HTTPS, RSS, alertes de SSL, authentification Sécurité physique et du
sécurité externe ou par le réseau, et 3 niveaux de
système SSO (Single sauvegarde de données,
Sign On) Shibboleth et SSL, VPN
LCS
Utilisateur et Utilisateur, groupe et Créer plusieurs groupes Gestion des individus et
groupe sous groupe d’utilisateur. de participants des groupes
Acteurs Administrateur Administrateur, Administrateur
Responsable de cours Assistant Assistant
Enseignant d’administration, d’administrateur
Tuteur Créateur de Enseignant
Etudiant cours/formateur, Assistant d’enseignant
Visiteur Tuteur Coordinateur
Apprenant Concepteur
Apprenant
Communication chat, forum, glossaire, Wiki, forum, chat. Pas forum, messagerie,
et collaboration Wiki, atelier, de visioConférence et chat, FAQ, courrier,
sondage, devoir. Pas de tableau blanc tableau blanc.
vidéoConférence. Téléconférence, classe
virtuelle.
Interopérabilité Exportation de cours sous Supporte les formats : Systèmes
archive Zip, importation WAI, SCORM 1.1 & d’informations,
CSV, contenus 1.2, LDAP, SSO, mécanismes
conforme aux SCORM Shibboleth, LCS, d’authentification,
1.2 / AICC, IMS-LD, IMS/QTI, CSS, HTML, systèmes de
incorporation de modules RSS bibliothèques et portails
créés avec des outils Possibilité d’intégration et
auteurs standard, dans ESUP. Environnements
connexion à un serveur Numériques de Travail
de messagerie, CSS, RSS. les plus couramment
utilisés.
Tableau 1.1 : Comparaison des plateformes
18
6.3 Synthèse
Après cette étude comparative, nous constatons qu’il n y a pas de solution ou bien de
plateforme idéale mais plutôt une plateforme qui répond à nos exigences et nos besoins précis.
En effet, chacune des plateformes étudiées (Moodle, Claroline, WebCT) présente des points
forts et des points faibles, par exemple, Moodle donne la possibilité de créer des contenus
conforme à SCORM, IMS LD, AICC et IMS CP, de créer des exercices de différents types
(QCM, apparaiement, etc.) qui ne respecte pas une spécification donnée. Quant à Claroline,
elle intègre seulement SCORM et IMS CP pour les contenus, mais elle peut créer des
exercices conformes à IMS/QTI.
En conséquence, on peut dire que c’est à l’utilisateur de choisir parmi les nombreuses
plateformes disponibles sur le marché, celle qui correspond le mieux à sa situation
organisationnelle, pédagogique et technologique.
Le point commun entre les différentes plateformes est l’aspect centralisé. En
conséquence, il est difficile, voir impossible, d’utiliser des fonctionnalités d’une plateforme à
partir d’une autre plateforme. Pour cela, les plateformes ont évoluées vers des architectures
flexibles et distribuées, dans lesquels les fournisseurs offrent non seulement leurs ressources
mais une variété de services aux utilisateurs. Ces architectures font l’objet de la section
suivante.
7 Vers un e-learning distribué
La majorité des plateformes e-learning ont été des solutions intégrées (centralisées).
En effet, l’intérêt d’avoir un système de gestion et de suivi centralisé est de pouvoir
consolider en temps réel les résultats et les statistiques des différentes formations (temps de
présence, score moyen, temps passé,…etc.). Or les solutions non intégrées fournissent
souvent des fonctionnalités ou des outils supplémentaires plus performants que ceux des
solutions intégrées. Ces solutions visent à réaliser :
• La personnalisation des parcours et des traitements.

• Le bon classement des ressources pédagogiques ce qui permet de faciliter la recherche.
• L’adaptation des contenus et des liens selon les besoins des utilisateurs (enseignant,
apprenant) du système.
• La création de composants pédagogiques.
• L’échange, le partage et la réutilisation des ressources pédagogiques.
19
• Une multitude de relations entre les individus: many to many, one to one, many to one.
7.1 Exemple: l’architecture KnowledgeTree (KT)

KnowledgeTree ; l’une des premières solutions e-learning distribuées ; est une
architecture distribuée pour le e-learning adaptatif basée sur la réutilisabilité des activités
éducatives intelligentes. Elle considère les trois acteurs principaux du processus
d’apprentissage : fournisseurs de contenu et de service, fournisseurs de cours et les apprenants.
[BRU, 04]
Figure 1. 4 : L’architecture KnowledgeTree. [BRU, 04]
L’architecture assume la présence, de quatre éléments : Le portail d’apprentissage

(Learning portal), qui fournit une interface de création et d’affectation de cours pour les
enseignants et une interface d’exécution pour les apprenants ; le serveur d’activité, qui
s’occupe des besoins des fournisseurs de contenu et de services, il est basé sur la réutilisation
de contenu et de service; le service d’ajoutant de valeur qui ajoute certaines fonctionnalités
variables aux contenus et services telles que l’ordonnancement adaptatif et l’annotation ; et le
serveur de modèle d’apprenant qui collecte des informations sur les apprenants à partir des
portails et serveurs d’activité et fournit ces informations aux portails adaptatifs et aux serveurs
d’activités, afin d’adapter l’ensemble des documents didactiques aux besoins des apprenants.
KT est une architecture ouverte et flexible, elle permet la présence de plusieurs
portails, des serveurs d’activités et des serveurs de modèle d’apprenant. Avec cette
architecture, l’enseignant développe des cours en utilisant un seul portail et plusieurs serveurs
d’activités et services. L’apprenant travail avec le portail servant le cours, mais interagit avec
20
plusieurs activités d’apprentissage servies directement par différents serveurs d’activités. Le

serveur de modèle d’apprenant fournit une base pour la surveillance de résultat et
l’adaptativité dans un contexte distribué.
8 Conclusion
Il existe aujourd’hui de nombreux projets de recherche et de développement dans le
domaine du e-learning. Les plates-formes existantes se ressemblent par leurs fonctionnalités.
Cela est dû surtout au fait que les organismes de standardisation LOM, IMS, SCORM
concentrent leurs efforts sur la structuration et la réutilisation des documents pédagogiques (la
réutilisation des objets pédagogique). Par contre, les problèmes du contenu de ces objets et la
réutilisation des fonctionnalités des applications qui les animent ne sont pas bien traités.
Ce qui a impliqué l’apparition des outils e-learning basés sur les environnements distribués
qui visent à réaliser des systèmes complets supportant toutes les fonctionnalités assurant
l’interopérabilité entre les systèmes et la réutilisation de fonctionnalités, tel que l’architecture
KnowledgeTree, qui est basée sur des activités d'apprentissage intelligentes, réutilisables et
distribuées en même temps, et qui adresse le développement des composants et leur
réutilisation dans les systèmes éducatifs et la prise en charge personnalisée des apprenants.
Le e-learning actuel commence à devenir distribué en offrant des fonctionnalités

flexibles et réutilisables. Ces dernières sont exploitées souvent à l’aide des technologies des
web services, que nous allons présenter dans le chapitre qui suit.
21
Chapitre 2
Les web services
Sommaire
1 Définition des web services.............................................................................................. 22

2 Caractéristiques des web services .................................................................................... 22
3 Architecture des web services .......................................................................................... 23
4 Le protocole SOAP .......................................................................................................... 25
4.1 Le framework de messagerie SOAP ....................................................................... 25
4.2 Encodage / sérialisation standard pour les objets.................................................... 26
4.3 Invocation de service d’objets distant via SOAP RPC ........................................... 26
4.4 Structure d’un message SOAP ................................................................................ 27
5 Le langage WSDL ............................................................................................................ 27
5.1 Structure d’un document WSDL............................................................................. 27
5.2 Liaisons avec les protocoles de transport................................................................ 28
6 Le standard UDDI ............................................................................................................ 28
6.1 Mécanismes d’accès aux services fournis par UDDI.............................................. 29
6.2 Le modèle de données d’UDDI............................................................................... 30
6.3 L’interface d’UDDI................................................................................................. 31
6.4 L’usage de l’annuaire UDDI................................................................................... 32
7 Relation entre UDDI et WSDL ........................................................................................ 33
8 Application des web services ........................................................................................... 34
8.1 Une application e-learning ...................................................................................... 35
9 Conclusion........................................................................................................................ 37
Chapitre 2 : Les web services
Chapitre 2
Les web services

Le web se présente actuellement comme un espace immense d’informations, dans
lequel l’individu aura certainement besoin des machines pour l’aider à les retrouver ; or la
structure actuelle du web ne facilite pas cette tâche.
Le web contient des vastes bases de données avec plusieurs buts et de multiples
sources non homogènes. Ceci prouve qu’il est nécessaire d’améliorer l’accessibilité à cette
importante masse d’informations, et de disposer d’outils plus sophistiqués pour une meilleure
recherche et organisation au sein du web.
Les web services fournissent une nouvelle manière de développer des applications conformes
aux besoins de l’Internet, et ils semblent être la solution la plus adaptée pour assurer
l’interopérabilité, qui permet de transmettre les données entre les différentes applications
d’une organisation comme l’entreprise, la société ou l’individu ; ainsi la technologie des web
services permet de réaliser le traitement de ces données, et gérer les liaisons entre les
différentes applications.
1 Définition des web services
Un web service est un ensemble de protocoles et de normes informatiques utilisés pour

échanger les données entre les applications. C’est un composant logiciel représentant une
fonction applicative (ou un service applicatif). Il peut être accessible depuis une autre
application (un client, un serveur ou un autre web service) à travers le réseaux Internet en
utilisant les protocoles de transports disponibles. Ce service applicatif peut être implémenté
comme une application autonome ou comme un ensemble d’applications (liées ensemble par
une infrastructure d’intégration). [SOF, 07]
2 Caractéristiques des web services

Selon [CER, 02], plusieurs acteurs définissent les web services par des caractéristiques
technologiques distinctives, les plus importantes sont :
22
• Un web service est une application logicielle qui est reconnue par un URI : URI
est la façon d’identifier un point de contenu sur le web comme un document tel qu’un
texte, audio ou vidéo. L’URI le plus connue est l’adresse d’une page web, le web
service est donc accessible en spécifiant son URI, c’est-à-dire que le web service est
caractérisé par un seul objet et une seule fonctionnalité, c’est un prolongement de la
programmation orientée objet et à partir de cela, on peut faire la construction d’une
application logicielle très large comportant plusieurs fonctionnalités, afin de
sélectionner les fonctionnalités qui sont recherchées par les URI spécifiques.
• Capacité des interfaces et liaisons (bindings) d’être publiées, localisées et
invoquées via le langage XML : les principales tâches d’un web service sont : la
publication dans un registre, la localisation en interrogeant ce registre qui l’héberge et
l’invocation par un ou plusieurs web services après sa localisation. Ces tâches sont
réalisées en utilisant le langage XML.
• Capacité d’interagir avec les composantes des logiciels via des éléments XML
avec l’utilisation des protocoles Internet standards : un web service est créé pour
être interrogé par d’autres logiciels contrairement à une page web, ou à une autre
application qui n’utilise pas les web services. L’interopérabilité est basée sur
l’utilisation du XML et des protocoles Internet standards, tels que, le HTTP qui est le
protocole du web, le SMTP qui est le protocole du courrier électronique,…etc.
• Composante logicielle légèrement couplée à interaction dynamique : un web service
avec un programme qui l’invoque est appelé le consommateur de web service, et qui
sont indépendants l’un de l’autre. Si une modification est à faire sur le consommateur,
on n’a pas besoin de connaître la machine, le langage de programmation, le système
d’exploitation ou autres paramètres, afin d’établir à nouveau une communication entre
le web service et son consommateur. Le consommateur possède une fonctionnalité qui
consiste à faire une localisation et une invocation du web service, au moment de
l’exécution du programme de web service, de manière automatique.
3 Architecture des web services

L’architecture de référence des web services vise trois objectifs importants :
l’identification des composants fonctionnels, la définition des relations entre ces composants
et l’établissement d’un ensemble de contraintes sur chaque composant de manière à garantir
23
les propriétés globales de l’architecture. [PAT, 04], [SOF, 07] L’architecture de référence
comporte les trois éléments suivants :
• Le fournisseur de service : c’est le propriétaire du service. D’un point de vue

technique, il est constitué par la plateforme d’hébergement du service.
• Le client : c’est le demandeur de service. Techniquement, il est constitué par

l’application qui va rechercher et invoquer un service. Une application cliente peut
être elle-même un web service
• L’annuaire des services : c’est un registre de descriptions de services offrant des
facilités de publication de services pour les fournisseurs de services ainsi que des
facilités de recherche de services pour les clients.
Ces trois éléments de l’architecture interagissent entre eux selon trois types d’opérations : les
opérations de publication, de recherche et de liens.
Figure 2. 1 : Architecture des web services. [PAT, 04]
Le fournisseur de services définit la description de son service et la publie dans un annuaire

de service UDDI qui peut être public ou privé. Le client utilise les facilités de recherche
disponibles au niveau de l’annuaire pour retrouver et sélectionner un service donné. Il
récupère ensuite les informations nécessaires sous format WSDL, à partir de la description du
service sélectionné, lui permettant de se connecter au fournisseur du service et d’interagir
avec l’implémentation du service considéré. La communication entre le demandeur de service
et le fournisseur est assurée par le SOAP et les autres protocoles de communication. Le
demandeur de service envoie une requête SOAP vers le fournisseur de service, cette requête
est véhiculée par le HTTP jusqu’au fournisseur. Ensuite le web service du fournisseur de
24
service renvoie sa réponse au demandeur sous la forme d’un document XML via SOAP et
HTTP.
Plusieurs standards ont été proposés pour assurer l’interaction entre les trois opérations
précédentes (publication, recherche et lien), entre autre nous citons les standards suivants :
• Le SOAP (Simple Object Access Protocol) est un protocole d’échange inter
application indépendant de toute plateforme, basé sur le langage XML. Un appel de
service SOAP est un flux ASCII encadré dans des balises XML et transporté dans le
protocole HTTP.
• Le WSDL (Web Services Description Language) introduit une grammaire commune
pour la description des services. Il donne la description au format XML des web
services en précisant les méthodes pouvant être invoquées, et le point d’accès (URL,
port, etc..).
• Le UDDI (Universal Description, Discovery and Integration) normalise une solution
d’annuaire distribué de web services, il fournit l’infrastructure de base pour la
publication et la découverte des web services. UDDI se comporte lui-même comme un
web service dont les méthodes sont appelées via le protocole SOAP.
4 Le protocole SOAP
Le protocole SOAP est l’un des produits du W3C, il assure des appels de procédures à
distance (RPC). Il assure l’interaction entre les web services en permettant le transport de
paquets de données sous format XML, ceci à l’aide du HTTP1, SMTP2 et POP3.
Il comporte trois composantes principales qui sont : un framework de messagerie, un standard
d’encodage et le mécanisme RPC. [HUB, 03]
4.1 Le framework de messagerie SOAP

Le framework de messagerie SOAP requiert que le message SOAP soit composé d’une
enveloppe qui contient un Header et un Body. Le Header comporte les métas – données du
message et le Body comporte le corps du message lui-même.
1
HTTP : HyperText Transfer Protocol.
2
SMTP : Simple Mail Transfer Protocol (Protocole simple de transfert de courrier), est un protocole de
communication utilisé pour transférer le courrier électronique vers les serveurs de messagerie électronique.
3
POP : Post Office Protocol (le protocole du bureau de poste), est un protocole qui permet de récupérer les
courriers électroniques situés sur un serveur de messagerie électronique.
25
4.2 Encodage / sérialisation standard pour les objets

Le standard d’encodage / sérialisation permet l’encodage des objets dans des messages
SOAP d’une manière standard ainsi que leurs décodage de manière standard au niveau du
destinataire.
4.3 Invocation de service d’objets distant via SOAP RPC

SOAP permet à l’aide de XML, la réalisation d’un appel RPC. XML n’est pas utilisé
pour transporter des documents mais pour véhiculer des appels de procédure et leur résultat.
Les différentes étapes d’invocation d’un objet distant sont illustrées dans le schéma suivant :
Message de Objet
requête distant
4
1
3
2
Client Serveur
SOAP SOAP
5
6
Message de
réponse
Figure 2. 2 : Etapes d’invocation d’objets distant avec SOAP. [HUB, 03]
1. Le client SOAP crée un document XML qui contient les informations nécessaires pour
invoquer les services d’un objet distant. Ensuite ce document est inséré dans une
enveloppe SOAP avant d’être transmis sous forme d’une requête HTTP.
2. Le message est transmis via une connexion HTTP.
3. Le message est reçu et analysé par le serveur SOAP, ensuite envoyé à l’objet distant.
4. L’objet fait le traitement de la requête et envoie la réponse au serveur SOAP.
5. La réponse est envoyée, sous forme d’un document SOAP, au client via le HTTP.
6. Le client reçoit la réponse, ouvre l’enveloppe et envoie le résultat au demandeur initial.
26
4.4 Structure d’un message SOAP

La structure générale d’un message SOAP est la suivante :
SOAP Enveloppe L’enveloppe (obligatoire) contient

le nom du message et le nom de
SOAP Header domaine
Entrée de Header
L’entête (optionnel) utile dans le
cas où le message doit être traité
Entrée de Header par plusieurs intermédiaires
SOAP Body
Entrée de Body Le corps (obligatoire) comporte

les données qui seront traitées
par le destinataire final.
Entrée de Body
Figure 2. 3 : Structure d’un message SOAP. [HUB, 03]
5 Le langage WSDL
C’est un langage de description des web services en format XML, il repose
essentiellement sur les mécanismes de SOAP, HTTP et MIME4 pour l’invocation d’objets
distants. Les services réseaux sont décris par une grammaire XML comme des ensembles de
points finaux d’accès aux réseaux ou aux ports. WSDL est extensible afin de permettre la
description de points finaux et leurs messages indépendamment des formats de messages ou
protocoles réseaux utilisés réellement pour communiquer. [HUB, 03]
Un port peut être défini par l’association d’une adresse réseau et une liaison réutilisable, un
web service est un ensemble de ports. Une liaison réutilisable est le protocole concret et les
spécifications de format de données pour un type de port particulier.
5.1 Structure d’un document WSDL

WSDL peut faire la description d’un web service à l’aide de six éléments principaux
qui sont, [HUB, 03] :
4
MIME : Multipurpose Internet Mail Extensions, est un standard Internet qui étend le format de données des
courriels pour supporter des textes en différents codage de caractères autres que l'ASCII.
27
• types : fournissent les définitions des types de données utilisées pour décrire les
messages échangés.
• message : représente une définition abstraite de la donnée en cours de transmission.
Un message comporte des parties logiques, chacune étant associée avec une définition
dans un système de type.
• portType : est un ensemble d’opérations abstraites. Chaque opération se réfère à un
message d’entrée et à des messages de sortie. Les portTypes sont utilisés pour définir
les traitements offerts par un web service.
• binding : spécifie un protocole réel et les spécifications de format de données pour les
opérations et les messages définis par un type de port donné.
• port : spécifie une adresse pour une liaison définissant un simple point terminal de
communication.
• service : est utilisé pour agréger un ensemble de ports associés.
5.2 Liaisons avec les protocoles de transport

Une liaison définie un format de message et les détails d’un protocole pour les
opérations et les messages définis par un portType particulier. Une liaison spécifie exactement
un protocole et non pas une information d’adresse. [HUB, 03]. Il peut y avoir n’importe quel
nombre de liaisons pour un portType donné, à savoir :
• Liaison SOAP.
• Liaisons HTTP GET et POST
• Liaison MIME.
6 Le standard UDDI
L’annuaire UDDI permet aux utilisateurs de faire la publication la découverte et
l’invocation des applications (des web services). En effet, UDDI peut contenir des
informations sur les fournisseurs et les services qu’ils publient. L’inscription d’un fournisseur
de services à l’annuaire UDDI lui permet de se présenter et présenter ses services, l’adoption
de cet annuaire par les fournisseurs permet l’accélération des échanges surtout les échanges
commerciaux de type B2B L’enregistrement des web services dans un annuaire UDDI
s’effectue auprès d’un opérateur en accédant au site web de ce dernier à partir d’un navigateur
ou d’un outil intégré à un environnement de développement. Des recherches précises peuvent
28
s’effectuer dans l’annuaire par catégorie de fournisseurs en utilisant des standards de

taxinomie et d’identification de fournisseurs. [HUB, 03], [ERI, 04]
Les données capturées dans l’UDDI sont divisées en trois catégories [HUB, 03], [ERI, 04] :
• Pages blanches : le référentiel comporte des informations sur les fournisseurs de
services telles que le nom et les coordonnées du fournisseur.
• Pages jaunes : le référentiel comporte des critères de catégorisation de services, les
critères de catégorisation s’appuient sur des standards de classification de fournisseur,
les services sont décrits par des documents au format WSDL. Un fournisseur peut
disposer de plusieurs entrées dans l’annuaire pour l’ensemble des différents services et
produits qu’il publie.
• Pages vertes : le référentiel comporte des informations techniques (WSDL) détaillées
sur les services fournis telles que les informations sur les processus métier, les
descriptions de services et les informations de liaison sur les services.
6.1 Mécanismes d’accès aux services fournis par UDDI

La communication (requêtes / réponses) avec un annuaire UDDI repose sur le
protocole de transport SOAP.
Demandeur de Invoque Fournisseur de service

service web service web web
Requête SOAP
Document WSDL
Rechercher la
définition WSDL
Requête SOAP
Recherche de Enregistrer le
service web service web
Enregistrement
Requête SOAP UDDI Requête SOAP
Figure 2. 4 : Mécanismes d’accès aux services de UDDI. [HUB, 03]
Un enregistrement UDDI est comparable au service DNS, il a deux types de clients : les
fournisseurs de services et les utilisateurs de ces services. UDDI comporte des pages qui
29
fournissent des informations sur les fournisseurs (nom, coordonnées,…etc.) et des pages qui
comportent la description, au format WSDL, des web services. Un fournisseur peut disposer
de plusieurs entrées dans l’annuaire pour l’ensemble de services qu’il propose, et des pages
qui disposent d’informations techniques détaillées sur les produits proposés.
UDDI est un modèle de données permettant de décrire un web service, la définition
d’une interface permettant de manipuler ce modèle de données et la mise à disposition de la
communauté de UDDI sous forme d’un service universel gratuit est nécessaire.
6.2 Le modèle de données d’UDDI

Le modèle de données UDDI est défini sous forme de schéma W3C XML Schéma, ce
schéma XML comporte cinq structures de données principales ; [HUB, 03], [ERI, 04] :
businessEntity publisherAssertion
Information about the party Information about the

who publishes information relationship between parties,
about family of services asserted by one or both parties
<tModels>
serviceEntity
Descriptions of specifications
Descriptive information for services.
about a particular web
services
<bindingTemplate>
Technical information about

service entry point and
construction specification
Figure 2. 5 : Modèle de données de l’annuaire UDDI. [RAH, 05]
30
• BusinessEntity : chaque businessEntity est identifiée par une «businessKey». Les

«businessEntities» sont en quelque sorte les pages blanches d’un annuaire UDDI, elles
comportent des informations sur les fournisseurs de services ayant publié des services
dans l’annuaire. On y trouvera notamment le nom de l’organisation, ses adresses
(physiques et web), des éléments de classification, une liste de contacts, ...etc.
• ServiceEntity : ce sont en quelque sorte les pages jaunes d’un annuaire UDDI, qui
décrivent de manière non technique les services proposés par les différents
fournisseurs. On y trouvera essentiellement le nom et la description textuelle des
services ainsi qu’une référence à l’organisation proposant le service et un ou plusieurs
«bindingTemplates».
• BindingTemplate (coordonnées des services) : ce sont des informations qui
concernent le lieu d’hébergement du service, elles donnent les coordonnées des
services. UDDI permet de décrire des web services HTTP, mais également des
services invoqués par d’autres moyens (SMTP, FTP, fax, téléphone,...etc.). Elles
contiennent notamment une description, la définition du « point d’accès » (suivant les
cas, une URL, un numéro de téléphone, ...) et les éventuels « tModels » associés.
• tModel (descriptions techniques des services) : ce sont des informations qui
concernent le mode d’accès au services, ce sont les descriptions techniques des
services. UDDI n’impose aucun format pour ces descriptions qui peuvent être publiées
sous n’importe quelle forme et notamment sous forme de documents textuels
(XHTML par exemple). C’est à ce niveau que WSDL intervient comme le vocabulaire
de choix pour publier des descriptions techniques de services.
• publisherAssertion : assertions contractuelles entre partenaires dans le cadre des
échanges d’exécution d’un service.
6.3 L’interface d’UDDI

L’interface UDDI est définie sous forme de documents UDDI et implémentée sous
forme de web service SOAP. Elle est composée des modules suivants :
• Interrogation : cette interface permet de rechercher des informations dans un
répertoire UDDI et de lire les différents enregistrements enregistrés suivant le modèle
de données UDDI.
• Publication : cette interface permet de publier des informations dans un répertoire
UDDI conformément à son modèle de données.
31
• Sécurité : cette interface est utilisée pour obtenir et révoquer les jetons
d’authentification nécessaires pour accéder aux enregistrements protégés dans un
annuaire UDDI.
• Contrôle d’accès et propriété : cette interface permet de transférer la propriété
d’informations (qui est à l’origine attribuée à l’utilisateur ayant publié ces
informations) et de gérer les droits d’accès associés.
• Abonnement : cette interface permet à un client de s’abonner à un ensemble
d’informations et d’être avertis lors des modifications de ces informations. Tous les
répertoires UDDI doivent gérer un avertissement par polling (le client interroge le
serveur pour savoir si des modifications ont eu lieu sur les données auxquelles il est
abonné). Une fonctionnalité optionnelle est également prévue permettant au client de
communiquer au serveur la définition d’un web service sur lequel il souhaite être
prévenu en cas de modification.
• Réplication interne (noeuds d’un même annuaire) : à côté des interfaces
utilisateurs que nous venons de voir, UDDI définit également l’interface permettant de
synchroniser les noeuds d’un même annuaire UDDI.
• Réplication externe (interrogation, publication, abonnement) : La réplication
externe par duplication d’informations entre différents annuaires UDDI n’a pas donné
lieu à la définition d’une interface spécifique mais se fait en utilisant les interfaces
d’interrogation (pour la lecture dans un annuaire), publication (pour la publication
dans un autre annuaire) et éventuellement abonnement (pour pouvoir propager les
modifications ultérieures).
6.4 L’usage de l’annuaire UDDI

L’annuaire UDDI permet la description, la publication et la découverte des web services:
1. La publication de services : un web service peut être publié en publiant sa
description, après sa production bien sur. Cette description peut être générée
manuellement ou automatiquement à l’aide des outils qui peuvent générer des parties
WSDL et de créer des entrées dans UDDI à partir de méta données par exemple.
Un UDDI peut être de plusieurs types et leurs utilisations dépendent du domaine des
services à publier, à savoir :
• Nœud UDDI pour une application interne : les nœuds UDDI se trouvent
derrière le firewall, avec ce type de nœud on a plus de contrôle sur
32
l’enregistrement, l’accessibilité, la disponibilité et les spécifications de

publication lors de la publication de service.
• Nœud portail UDDI : il se trouve à l’extérieur du firewall du fournisseur de
service ou entre les firewall. Sur ce type de nœud on publie des web services
pour les partenaires externes tout en implémentant des mécanismes d’accés
sélectifs selon le profil des utilisateurs.
• Nœud catalogue du partenaire avec UDDI : les web services peuvent être
publiés sur un nœud du catalogue du partenaire avec UDDI (deriére le firewall).
Le partenaire est choisi avec une autorisation d’accés spécifique.
• Nœud de place de marché UDDI : il s’agit de relations inter entreprises et de
contrôle du partage de l’information entre systèmes d’information.
2. La découverte de services : c’est la recherche et la localisation d’un web service
particulier dans un annuaire de services décrivant le nom du fournisseur, l’objectif de
chaque service,…etc. Donc il s’agit de l’acquisition des descriptions de web services
et leur utilisation.
3. L’invocation de services : le client peut invoquer un service une fois sa description
est reçue. En exploitant les informations de cette description, le client peut générer des
requêtes SOAP pour invoquer le service.
7 Relation entre UDDI et WSDL

Le WSDL contient deux parties : la description de l’interface du service et la
description de l’implémentation du service. La description de l’interface d’un service
correspond aux informations techniques du service, c’est en quelque sorte une classe abstraite
qui sera utilisée pour implémenter un ou plusieurs autres services. Elle regroupe : types,
import, message, portType et binding. La description de l’implémentation du service
correspond aux informations relatives à l’endroit où est publié le service. Elle regroupe :
documentation, import, service et port.
UDDI permet de prendre en charge n’importe quel langage de description des web services,
grâce à son model de donnée extensible. Une description WSDL d’un web service peut être
traduite dans UDDI grâce à la combinaison de « BusinessService », « BindingTemplate » et
de « tModel » tel que indiqué dans la figure ci – après :
33
Figure 2. 6 : Relation entre UDDI et WSDL. [RAH, 05]
Le « port » du WSDL est représenté par « bindingTemplate » de UDDI. La relation entre

« service » et ses ports en WSDL est exactement reflétée par la relation entre
« businessService » et son « bindingTemplates » dans l’UDDI. Les éléments « type »,
« message », « portType » et « binding » du WSDL sont représentés par le tModel de UDDI.
En résumé : UDDI est un standard pour faciliter la collaboration entre partenaires dans
le cadre d’échanges commerciaux, le cœur d’UDDI est un annuaire qui contient des
informations techniques et administratives sur les fournisseurs et les web services qu’ils
publient. Donc l’annuaire UDDI permet de publier et découvrir des informations qui
concernent un fournisseur et ses web services.
8 Application des web services

Les technologies des web services sont de plus en plus appliquées à un large spectre
d’applications, en effet, elles permettent l’interopérabilité entre divers logiciels fonctionnant
sur diverses plateformes. Ils sont utilisés dans de nombreux domaines à savoir : le e-
commerce, la finance, la télécommunication, domaine médicale, l’e-learning,…etc. Dans
notre cas on s’intéresse à ce dernier domaine, pour cela nous présentons ici un exemple
d’environnement d’apprentissage à base de web services.
34
8.1 Une application e-learning

Dans [GOT, 03] le système d’apprentissage est vu comme un ensemble d’activités qui
peuvent être modelées comme processus et comme web services, à savoir la création de
contenu, la configuration de contenu dans des cours, la gestion des LO (Learning Object), la
mise à jour de contenu, la gestion et l’enregistrement d’apprenant, l’adaptation de contenu,
profil et suivi d’apprenant, le test des connaissances acquises, …etc.
En se basant sur le principe des web services, tous les LOs, classes, et cours, qui peuvent être
stockés sur différents serveurs, enregistrent leurs offres dans un annuaire central avec une
information additionnelle sur le contenu du matériel d’apprentissage. La plateforme peut
appeler un web service, qui est enregistré dans l’annuaire, pour utiliser ses fonctionnalités. La
figure suivante montre le principe :
Contenu d’Apprentissage
LO1 Meta
donnée
Etudiant / Client
LO2 Meta
donnée
Internet LO3 Meta

donnée
Cours E-
Learning Meta
donnée
Présentation de Contenu 1
Présentation de Contenu 2
Suivi d’apprenant
UDDI
Création de Contenu
-----------
Web services
Figure 2. 7 : Plateforme e-learning comme web services. [GOT, 03]
35
Les systèmes traditionnels importent les objets d’apprentissage (LOs) vers leur propre base de
données afin de les utiliser, mais avec ce système l’utilisation des LOs a, aussi, devenu
dynamique. Ceci permet au système d’éviter le problème de la non disponibilité des LOs. Un
annuaire de contenu central est employé afin de permettre aux auteurs de réduire la charge de
travail en offrant la possibilité de créer des cours en réutilisant le contenu des autres auteurs.
Avec ce système, on trouve deux types différent de web services, internes et externes. Les
web services externes sont fournis par d’autres fournisseurs et sont stockés sur les systèmes à
distance. Ils sont enregistrés dans un annuaire UDDI, qui fournit toutes les informations
nécessaires pour utiliser la fonctionnalité du service à distance dans la plateforme. Les web
services internes sont fournis par le système lui-même et peuvent être utilisés par
l’intermédiaire du serveur existant de la plateforme. Ils sont également enregistrés dans
l’annuaire UDDI pour être utilisés par d’autres systèmes, les fichiers WSDL correspondant
sont aussi engendrés.
Dans le système, les acteurs principaux sont les lecteurs et les auteurs ; les autres
incluent les entraîneurs et les administrateurs. Les auteurs (qui peuvent être des professeurs ou
des concepteurs) créent le contenu, qui est stocké sous la commande d’un système de gestion
d’apprentissage (LMS) et typiquement dans une base de données. Le contenu existant peut
être mis à jour et il peut également être échangé avec d’autres systèmes. Les lecteurs (ou
client) peuvent consulter ce contenu selon leurs profils et leurs besoins.
L’auteur peut choisir, en effectuent une recherche dans l’annuaire UDDI, un service pour la
création de contenu. Le système appelle le service trouvé, et l’auteur peut créer le contenu à
l’aide du module choisi. A la fin de la création, l’auteur doit enregistrer le nouveau LO à
l’annuaire de contenu central et le stocker sur un serveur. En fin de compte, l’auteur peut
choisir de créer un autre LO ou accomplir une tâche différente comme créer des cours à partir
des LOs existants. Ce processus peut être divisé en deux sous – processus, à savoir la création
d’un LO et la publication de ce LO, les deux actions peuvent être mises en application en tant
qu’un web service atomique.
Pour le lecteur, il a besoin juste d’un web browser pour utiliser le système et il ne connaît pas
quelle partie de la plateforme fait partie du serveur du système et quelle partie est juste un
web service inclus.
Chaque présentation de matériel est une recherche dans l’annuaire de contenu, un appel du
LO, et un appel du web service correspondant pour présenter le matériel au lecteur.
36
9 Conclusion
Les web services ont pour objectif l’interopérabilité entre applications via le web en
vue de rendre le web plus dynamique. Ils facilitent l’accès aux applications et les échanges de
données entre entreprises. Ils poursuivent un vieux rêve de l’informatique distribuée où les
applications pourraient s’interopérer à travers le réseau, indépendamment de leur plateforme
et de leur langage d’implémentation.
Un système e-learning peut être vu comme une collection d’activités ou de processus,
ses fonctionnalités peuvent être découpées en un certain nombre de fonctions autonomes qui
peuvent alors être réalisées séparément sous la forme d’applications autonomes ou de services,
ceci par l’utilisation de la technologie des web services.
La mise à disposition de ces services permet la réutilisation du contenu et des fonctionnalités
d’une une plateforme e-learning, elle permet de donner une nouvelle forme aux plateformes e-
learning, une forme décentralisée.
Les diverses solutions e-learning qui utilisent les web services utilisent les annuaires
UDDI, ces dernières n’offre pas des informations riches pour la recherche des web services.
D’où la nécessité de rajouter une couche sémantique à ces services. Le web sémantique et les
ontologies sont les outils utilisés pour cette tâche, cela fait l’objet du chapitre suivant.
37
Chapitre 3
Découverte des web services
Sommaire
1 Les ontologies................................................................................................................... 39
1.1 Définition ................................................................................................................ 39
1.2 Les composantes d’une ontologie ........................................................................... 39
1.3 Rôles des ontologies................................................................................................ 40
2 Le web sémantique........................................................................................................... 41
3 Les web services sémantiques.......................................................................................... 42
4 Approches pour les web services sémantiques................................................................. 42
4.1 DAML-S ................................................................................................................. 42
4.1.1 La classe "ServiceProfile" ................................................................................ 43
4.1.2 La classe "ServiceModel" ................................................................................ 46
4.1.3 La classe "ServiceGrounding".......................................................................... 47
4.1.4 Les ressources................................................................................................... 47
4.2 WSDL-S .................................................................................................................. 47
5 Quelques stratégies de découverte ................................................................................... 48
5.1 La stratégie UDDI ................................................................................................... 49
5.2 Découverte des services selon les qualités de services ........................................... 49
5.3 Un modèle pour indexer et découvrir les services e-learning ................................. 50
6 Synthèse des différentes stratégies ................................................................................... 52
7 Conclusion........................................................................................................................ 52
Chapitre 3 : Découverte des web services
Chapitre 3
Découverte des web services

Les web services sont des applications modulaires qui fournissent un modèle simple
de programmation et de déploiement d’applications, basées sur des normes et s’exécutant au
travers de l’infrastructure web. Les web services réalisent des fonctionnalités allant des
simples requêtes aux processus métiers sophistiqués. Ils sont significatifs seulement si les
utilisateurs peuvent trouver des informations suffisantes pour leurs exécutions.
Les web services sont basés sur plusieurs standards à savoir le standard UDDI
(Universal Description, Discovery and Integration) qui est la définition d’un ensemble de
services soutenant la description et la découverte des entreprises, organismes, d’autres
fournisseurs de web services, les web services qu'ils rendent disponible et les interfaces
techniques qui peuvent être employées pour accéder à ces services. Donc les web services
deviennent significatifs à l’aide d’UDDI.
Les web services assurent, à travers UDDI, la publication et la découverte des applications
(des web services). La réalisation de ces tâches, de manière manuelle, est clairement
fastidieuse, notamment pour la tâche de découverte dont l’utilisateur doit chercher
manuellement le service pertinent qui répond à ses besoins dans une grande gamme de
services. Les solutions d’automatisation de cette tâche devenaient de plus en plus
indispensables. Et c’est dans ce contexte que sont nés les premiers concepts d’automatisations
de la découverte, ces concepts consistent, pour la plupart de temps, à ajouter de la sémantique
aux web services.
A cette fin, nous présentons dans ce chapitre l’un des concepts clé de la sémantique qui
est l’ontologie suivie par le web sémantique, ensuite la notion des web services sémantiques,
et quelques stratégies de découverte avec une synthèse de ces stratégies.
38
1 Les ontologies
1.1 Définition
Afin de décrire ce qu'est une ontologie, de nombreuses définitions ont été proposées.
Parmi les plus répondues, on citera :
Selon [GRU, 93] : "Une ontologie est une spécification explicite d'une conceptualisation".
Cette définition s'appuie sur deux dimensions :
• « conceptualisation » correspond au «modèle abstrait » d'une partie du monde réel,
sur lequel doit travailler le système considéré. Qui se présente comme un ensemble de
définitions de concepts munis de propriétés et de relations entre ces concepts.
• « spécification explicite » signifie que le modèle en question doit être décrit de façon
non ambiguë dans un langage. Ce langage peut être une langue naturelle (ex : français,
anglais) ou un langage formel (ex : logique du 1er ordre, réseau sémantique).
Selon [BOR, 97] : "une ontologie est définie comme étant une spécification formelle d’une
conceptualisation partagée”. On entend par :
• « explicite » : signifie que l’ensemble des concepts utilisés et leurs contraintes
d’utilisation sont définis d’une façon explicite ;
• « formel » : précise que l’ontologie construite doit être lisible par un ordinateur ;
• le terme « partagée » montre qu’une ontologie fournit un vocabulaire conceptuel
commun et une compréhension partagée par la communauté visée.
En informatique, une ontologie est un ensemble structuré de concepts. Les concepts sont
organisés dans un graphe dont les relations peuvent être :
• Des relations sémantiques ;
• Des relations de composition et d'héritage (au sens objet).
L’objectif d’une ontologie est d’avoir une compréhension entre les personnes et les logiciels
ce qui est très utile surtout pour des applications distribuées telles que le web.
1.2 Les composantes d’une ontologie

Les connaissances exprimées par les ontologies sont véhiculées à l'aide de cinq
éléments: Concepts, Relations, Fonctions, Axiomes et Instances [GOM, 99].
39
• Concepts: Ils sont également appelés termes ou classes de l'ontologie. Un concept est
un constituant de la pensée (un principe, une idée, une notion abstraite)
sémantiquement évaluable et communicable [BEN, 05]. Les concepts peuvent être
classifiés selon plusieurs dimensions: niveau d'abstraction (concret ou abstrait),
atomicité (élémentaire ou composé) et niveau de réalité (réel ou fictif).
• Relations: Elles servent à exprimer les associations existant entre les concepts
présents dans le segment analysé de la réalité. Elles regroupent les associations
suivantes : sous – classe – de (spécialisation, généralisation), partie – de (agrégation
ou composition); associé – à, instance – de, est – un, etc. Les relations permettent
d'apercevoir la structuration et l'interrelation des concepts, les uns par rapport aux
autres.
• Fonctions: Elles représentent des cas particuliers de relation où un élément (le nième)
est défini en fonction des n-1 éléments précédents.
• Axiomes: Constituent des assertions, admises comme vraies, à propos des abstractions
du domaine traduit par l'ontologie.
• Instances: Elles constituent la définition extensionnelle de l'ontologie; ces objets

véhiculent les connaissances (statiques, factuelles) à propos du domaine du problème.
1.3 Rôles des ontologies

Dans cette partie nous allons décrire le rôle des ontologies, notamment pour les
applications du domaine du e-learning. [BEN, 05], [RAN, 00]
Les raisons d’utilisations des ontologies peuvent être :
• La communication : pour une application e-learning ils existent trois types de
communication : communication acteur – système (un acteur peut être un enseignant,
un administrateur ou bien un apprenant), communication acteur – acteur, et
communication entre les différents modules du système.
Souvent, la communication entre les acteurs de l’application pose des problèmes. En
effet, les acteurs ne sont pas du même domaine (par exemple un acteur informaticien
et un autre non) donc ils ne parlent pas forcément un même langage, d’où l’intérêt de
créer une ontologie qui contient un vocabulaire convivial et précis pour la
communication entre eux. Une fois l’ontologie pour la communication acteur – acteur
est définie, elle peut être utilisée dans la communication acteur – système ainsi que
dans la communication entre les modules du système.
40
• La réutilisation et le partage des informations pédagogiques : les ontologies

facilitent la réutilisation des objets pédagogiques par d’autres systèmes, elles
permettent, aussi, le partage des objets pédagogiques entre les personnes ou les
modules d’un système.
• L’interopérabilité : elle facilite la communication entre systèmes, elles permettent de
soutenir la conception des systèmes de formation e-learning.
• L’indexation et la recherche d’information : les ontologies peuvent être utilisées
comme méta – descripteur pour décrire le contenu sémantique associé aux objets.
• Les connaissances du domaine : le processus d’acquisition de connaissances, lors de
la construction d’une formation e-learning, peut être amélioré par l’utilisation des
ontologies qui offrent une meilleure organisation des objets pédagogiques et des
connaissances du domaine.
• La spécification de notion : les ontologies peuvent être utilisées comme moyen de
spécification des notions à appréhender et des relations entre notions d’une formation
e-learning.
2 Le web sémantique
Le web sémantique, proposé par le W3C, est une infrastructure visant à rendre le
contenu sémantique des ressources web interprétables non seulement par l'homme mais aussi
par les programmes dont le but est d’avoir une meilleure coopération entre humains et
machines. Cette infrastructure permet l’exploitation de connaissances formalisées en plus du
contenu informel actuel du web, elle permet de localiser, d’identifier et de transformer des
ressources de manière robuste tout en renforçant l’esprit d’ouverture du web avec sa diversité
d’utilisateurs. Le web sémantique n’est pas un web distinct mais bien un prolongement du
web que l’on connaît, dans lequel une signification clairement définie est attribuée à
l’information, ce qui permet une collaboration plus étroite entre machines et humains.
Le web sémantique vise à satisfaire les fonctionnalités avancées pour l’interaction utilisateur
– utilisateur, utilisateur – machine et machine – machine. Il permet le partage des ressources
et le raisonnement sur le contenu de ces dernières. Afin de rendre la recherche et la sélection
d’information facile aux programmes chargés de ces fonctionnalités, les documents sont
structurés à l’aide de méta données ou d’annotations ou d’ontologies. [BEN, 05], [ABE, 05],
[BOU, 04]
41
3 Les web services sémantiques

Les standards des web services sont le langage de description de web service WSDL et
l’annuaire UDDI. Les web services sont décrits en utilisant le WSDL et publiés dans les
enregistrements d’UDDI. Le mécanisme de découverte soutenu par UDDI n'est pas assez
puissant pour la découverte automatisée, ceci est dû au manque de sémantique dans le procédé
de découverte et le fait qu'UDDI n'utilise pas les informations des descriptions de service
pendant la découverte. Ceci rend UDDI moins efficace, malgré qu'il fournisse une interface
pour une recherche basée sur les mots clé.
Les web services sémantiques visent à faire une combinaison entre le web sémantique
et la technologie des web services afin de permettre une interaction automatique et dynamique
entre les systèmes. Ceci par le développement des annotations sémantiques des web services
en utilisant des ontologies partagées et par l’utilisation de ces annotations pour la découverte
des services. [CHR, 05] [KAA, 03]
Afin d’automatiser le procédé de découverte, diverses initiatives ; qui consiste à
ajouter de la sémantique à WSDL et à UDDI ; ont vu le jour, entre autres DAML-S et WSDL-
S qu’on va présenter dans la section qui suit.
4 Approches pour les web services sémantiques
4.1 DAML-S
Selon [DAL,] [DAV, 03], DAML-S est un langage de description sémantique de web
services, il est constitué d’une ontologie lui permettant de décrire les web services. Il permet
l’automatisation de nombreuses tâches à savoir : la découverte et la sélection d'un service qui
consistent à mettre en correspondance un demandeur de service avec un fournisseur qui
répond à ce service, l'invocation de ce service qui permet de réaliser l'appel effectif du service
découvert, l'inter opération et la composition de services qui autorisent la composition des
services simples afin d'obtenir un service complexe qui répond aux exigences d'un client et la
surveillance de l’évolution du processus qui sert à surveiller l'état d'accomplissement et de
déroulement du service.
DAML-S définit une ontologie particulière qui permet la description des propriétés des web
services et de les rendre disponibles au monde. Il comporte quatre éléments principaux qui
sont :
42
Figure 3. 1 : Classes de l’ontologie DAML-S. [DAL,]
4.1.1 La classe "ServiceProfile"

Elle permet l’annonce et la découverte de web service, elle décrit le service en fonction de ce
qu'il fait. Elle comporte :
1. une description du service (nom,..) et de son fournisseur (nom, adresse physique,
adresse web,…).
2. une description du comportement fonctionnel du service (les entrées/sorties, les pré
conditions nécessaires au bon déroulement, les effets du service sur le monde,…..).
3. une description des attributs fonctionnels utiles à la sélection automatique des services
(le temps de réponse, le coût du service,…).
Cette classe fournit des superclasses de chaque type de la description à niveau élevé du
service. Elle n’exige aucune représentation des services, mais elle exige l’information de base
pour lier n’importe quel instance de profil avec une instance de service.
Il y a une relation bidirectionnelle entre un service et un profil, de sorte qu'un service puisse
être lié à un profil et un profil à un service. Ces relations sont exprimées par les propriétés :
• presents : décrit une relation entre une instance de service et une instance de profil,
elle indique que le service est décrit par le profil.
• presentedBy: c’est l'inverse de présents; elle indique qu'un profil donné décrit un
service.
1. Description, contacts et nom de services

Un profil de service peut avoir au plus un nom de service, une description, et un ou plusieurs
items d’informations de contact.
43
• serviceName : se rapporte au nom du service qui est offert. Il peut être utilisé comme
identifiant du service.
• textDescription : fournit une courte description du service. Il récapitule ce que le
service offre, il décrit ce que le service exige pour fonctionner et il indique n'importe
quelle information additionnelle que le compilateur du profil veut partager avec les
récepteurs.
• contactInformation : indique une personne ou toute autre entité que le fournisseur du
service veut partager avec le lecteur. Chaque item d'information de contact est une
instance de la classe Actor décrit ci-dessous.
2. Actor : cette classe fournit des informations sur le fournisseur ou le demandeur de service ;
spécifiquement, elle fournit les informations suivantes :
• name : c’est le nom de l’acteur, il peut être le nom d’une personne ou d’une
compagnie.
• title : titre du contact, département de service ou autre information.
• phone : numéro de téléphone qui peut être utilisé pour recueillir l'information au
service.
• fax : qui peut être utilisé pour rassembler des informations au service.
• email : qui peut être utilisé pour recueillir l’information au service.
• physicalAddress : l’adresse physique.
• webURL : URL du site web de produit ou de compagnie.
3. Description de fonctionnalité: elle concerne les spécifications des fonctionnalités fournies
par le service et des conditions qui doivent être satisfaites pour avoir un bon résultat.
• input : elle indique une entrée du service. Elle prend comme valeur une instance de
ParameterDescription (voir ci-dessous) qui spécifie une identification de l'entrée, une
valeur et une référence à l'entrée correspondante dans le modèle de processus.
• output : elle spécifie une sortie du service. Elle prend comme valeur une instance de
ParameterDescription qui indique une identification de la sortie, une valeur et une
référence à la sortie correspondante dans le modèle de processus.
• precondition : désigne une condition préalable du service. Elle prend comme valeur
une instance de ParameterDescription qui indique une identification de la condition
préalable, une valeur et une référence à la condition préalable correspondante dans le
modèle de processus.
44
• effect : spécifie un des effets du service. Il prend comme valeur une instance de
ParameterDescription qui spécifie un identifiant de l’effet, une valeur et une référence
de l’effet correspondant dans le modèle processus.
4. ParameterDescription : cette classe fournit des valeurs aux entrées et aux sorties. Elle
collecte en une classe le nom de l'entrée ou de la sortie qui peut être utilisée comme
identifiant, sa valeur et la référence à l'entrée ou à la sortie correspondante dans le modèle de
processus.
• parameterName : fournit le nom de l’entrée ou la sortie, qui peut être juste un littéral
ou l’URI du paramètre de processus.
• restrictedTo : fournit une restriction sur les valeurs de l’entrée ou de la sortie.
• refersTo : une référence à l’entrée ou à la sortie dans le modèle de processus.
5. Les attributs de profil :En plus de la description fonctionnelle des services, il y a d'autres
aspects des services tels que les garanties de qualité qui sont fournies par le service, la
classification possible du service et d’autres paramètres additionnels.
• serviceParameter : est une liste extensible de propriétés qui peuvent accompagner

une description de profil. La valeur de la propriété est une instance de la classe
ServiceParameter.
• serviceCategory : se rapporte à une entrée dans quelques ontologies ou taxonomies
des services. La valeur de la propriété est une instance de la classe ServiceCategory
• QualityRating : utilisée pour indiquer l’estimation d’un service en utilisant un certain
système d’estimation. L'estimation d'un service fournit au client potentiel des
informations sur la qualité du service fourni.
6. Paramètres de service :
• serviceParameterName : c’est le nom du paramètre actuel, qui peut être un littéral ou
une URI.
• sParameter : indique la valeur du paramètre dans l’ontologie.
7. Estimation de qualité:
• ratingName: le nom du service d’estimation.
• rating : la valeur de l’estimation dans un service d’estimation donné.
8. Catégorie de service: décrit des catégories de service selon une certaine classification.
• categoryName : c’est le nom de la catégorie actuelle, qui peut être littérale ou une
URI du paramètre de processus.
45
• taxonomy : la référence au schéma de taxonomie. Elle peut être une URI de la

taxonomie, ou une URI où réside la taxonomie, ou le nom de la taxonomie.
• value : pointe une valeur dans une taxonomie spécifique.
• code : pour chaque type de service enregistre le code associé à la taxonomie.
4.1.2 La classe "ServiceModel"

Elle explique comment le service (processus) fonctionne. Elle possède une sous classe
nommée "ProcessModel" qui comporte deux types d’ontologies : une ontologie de contrôle de
processus et une ontologie de processus.
1. Ontologie de processus : elle définit trois sous-types de processus : atomique, simple et
composite.
• Un processus atomique peut être invoqué par le client de façon directe à l’aide de
message, et n’a aucun sous processus. Un Grounding est nécessaire afin de permettre
aux clients de construire leurs messages.
• Un processus simple ne peut pas être directement invoqué par le client. Il peut être
utilisé pour fournir une vue d’un certain processus atomique (le processus simple est
realizedBy le processus atomique) ou une représentation simplifiée d’un certain
processus composé (processus simple l'expandsTo le processus composé).
<daml:Class rdf:ID="SimpleProcess">
<daml:subClassOf rdf:resource="#Process"/>
</daml:Class>
<rdf:Property rdf:ID="realizedBy">
<rdfs:domain rdf:resource="#SimpleProcess"/>
<rdfs:range rdf:resource="#AtomicProcess"/>
<daml:inverseOf rdf:resource="#realizes"/>
</rdf:Property>
<rdf:Property rdf:ID="expandsTo">
<rdfs:domain rdf:resource="#SimpleProcess"/>
<rdfs:range rdf:resource="#CompositeProcess"/>
<daml:inverseOf rdf:resource="#collapsesTo"/>
</rdf:Property>
• Un processus composite est décomposable en d'autres processus (composites ou non

composites).
46
2. Ontologie de contrôle de processus : l’instanciation d’un processus représente un

processus complexe qui s’exécute. Pour surveiller et commander l’exécution d’un processus,
un modèle pour interpréter les instanciations de processus est nécessaire, ce modèle doit être
capable de fournir:
• Les règles de correspondance pour les différentes propriétés d’états d’entrée (entrées,
pré conditions) aux propriétés d’états de sortie correspondantes.
• Un modèle de dépendances temporelles ou d’états.
• Des représentations de messages qui concernent l’état d’exécution de processus
atomiques et composites.
4.1.3 La classe "ServiceGrounding"

Avec DAML-S, le ServiceProfile et le ServiceModel sont considérés en tant que
représentations abstraites; seulement le ServiceGrounding traite le niveau concret des
spécifications. Afin de faciliter l’accès au service, il établie une correspondance entre une
spécification concrète et une spécification abstraite définie en DAML-S par les effets des pré
conditions d’entrées / sorties pour un "ServiceModel".
Le rôle central du Grounding de DAML-S est de montrer comment les entrées et les sorties
(abstraites) d'un processus atomique doivent être réalisées concrètement comme messages.
4.1.4 Les ressources

Les ressources nécessaires pour l’exécution d’un service sont définies dans une ontologie.
Les ressources peuvent être caractérisées par :
• les types de ressource, tels que le carburant.
• La marque de ressource, telle que le carburant dans le réservoir de gaz d'une voiture
particulière.
• La quantité, ou capacité, de la marque de ressource à n'importe quel instant donné, tel

que les cinq gallons de carburant dans le réservoir de la voiture en ce moment.
4.2 WSDL-S
Le WSDL-S est le langage WSDL augmenté d’un ensemble de fonctionnalités
d’annotation sémantique pour les fichiers WSDL. Il définit un modèle sémantique pour
47
capturer les termes et les concepts utilisés pour décrire et représenter la connaissance. La
sémantique est ajoutée en deux étapes : la première consiste à faire référence, dans la partie
définition WSDL, à une ontologie dédiée au service à publier ; la deuxième consiste à annoter
les opérations de la définition WSDL de sémantique. [KOP, 05], Quatre rôles du modèle
sémantique sont distingués :
• InputSemantics : le sens des paramètres d’entrées.
• OutputSemantics : le sens des paramètres de sortie.
• Precondition : un ensemble d’états sémantiques qui doivent être vrais afin d’invoquer
une opération avec succès.
• Effect : un ensemble d’états sémantiques qui doivent être vrais après qu’une opération
accomplisse son exécution.
WSDL-S utilise l’extensibilité de WSDL et fournit les cinq éléments et attributs suivants :
• ModelReference: un attribut pour lequel la valeur d’URI désigne un concept dans le
modèle sémantique des web services et spécifie qu’il y a une correspondance one-to-
one entre le propriétaire de l’attribut et le concept référencé. Ce concept peut être
utilisé par lui-même dans un élément d’un schéma XML ou une déclaration de type
pour faire un lien direct avec un concept d’ontologie. Il peut être, ainsi, utilisé en tant
que Precondition ou Effect.
• SchemaMapping : un attribut pour lequel l’URI indique une correspondance entre
les concepts d’ontologie.
• Precondition et effect: sont des éléments similairement structurés, ils sont utilisés
pour spécifier les pré et post conditions d’une opération donnée. les conditions sont
spécifiées par une référence au modèle sémantique (réutilisation de l’attribut
modelReference) ou par l’écriture de la condition comme valeur de l’attribut
expression des deux éléments.
• Category : un élément qui fournit un pointeur vers certaine catégorie de taxonomie. Il
peut être utilisé dans une interface de WSDL.
5 Quelques stratégies de découverte

On entend par découverte dynamique la possibilité de localiser automatiquement un
web service qui répond à des besoins particuliers. On peut dire qu’il s'agit d'un mécanisme,
basé sur des algorithmes et des techniques de raisonnement qui exploitent la sémantique des
services, permettant à un utilisateur de découvrir automatiquement quels sont les services qui
correspondent à ses besoins. [PAT, 04]
48
Pour réaliser la découverte des web services plusieurs techniques ont été proposées.
Ces techniques diffèrent par le langage de description de service utilisé et l’algorithme de
découverte appliqué.
5.1 La stratégie UDDI

Avec cette stratégie la découverte des services est basée sur les mots clés. Une requête
constituée de mots clés est envoyée par le client. Cette requête est ensuite comparée avec les
mots clés de UDDI. Le résultat de cette comparaison est un ensemble de description de
services qui vont être affichés au client. Ce dernier choisi, par la suite, le service qui répond
au mieux à ces besoins.
5.2 Découverte des services selon les qualités de services

[SHU, 03] propose un modèle de découverte de services où, en plus des conditions
fonctionnelles, la qualité de service est prise comme contrainte pendant la recherche d’un web
service. Ce modèle est illustré dans la Figure 3.2, il comporte quatre éléments qui sont :
• Le fournisseur de service : offre le service en l’enregistrant dans l’annuaire UDDI,
• Le consommateur de service : à travers ce dernier peut découvrir et invoquer les
services,
• L’annuaire UDDI, avec ce modèle, diffère d’un annuaire UDDI normal en ayant des
informations sur la description fonctionnelle du web service et des informations sur les
QdS associées à ce service.
• Et le certificateur : vérifie les revendications de qualité du service pour un web service
avant son enregistrement.
49
Figure 3. 2 : Un modèle pour l’enregistrement et l’invocation de web services. [SHU, 03]
Le fournisseur de service communique, en premier lieu, la QdS de son service au certificateur.

Ce dernier vérifie les revendications et certifie ou pas la revendication. Les résultats sont, par
la suite, envoyés au fournisseur avec l’information d’identification de certification. Ces
résultats sont ainsi enregistrés au niveau du dépôt du certificateur identifié par l’ID de
certification. L’accès au dépôt du certificateur est possible grâce à un ensemble de web
services fournis par le certificateur.
Après que la certification de QoS est publiée, le fournisseur peut alors enregistrer la
description fonctionnelle du service et la qualité de service certifiée associée au service dans
UDDI. Ce dernier communique avec le certificateur pour vérifier l'existence de la certification.
Si vérification réussie, il enregistre alors le service dans son dépôt.
Le consommateur recherche dans UDDI un web service avec la fonctionnalité exigée avec la
possibilité d’ajouter des contraintes de QoS à l'opération de recherche. S’il y avait des
services avec des fonctionnalités semblables, alors les conditions de qualité de service
imposeraient une recherche plus fine. S'il n'y a aucun service avec les qualités exigées, une
réaction est donnée au consommateur pour qu’il réduise les contraintes de qualité de service
ou le compromis entre les qualités souhaitées.
5.3 Un modèle pour indexer et découvrir les services e-learning

[OUS, 05] propose un modèle de méta – données pour l’indexation et la recherche des
services e-learning. Il propose la description et la classification des services e-learning selon
50
trois dimensions : en tant que ressources d’apprentissage, comme services qui contribuent
et aident les chercheurs et en tant que service général. Ils peuvent être employés par des
clients (des étudiants ou des enseignants) pour interroger et découvrir des services par
l'intermédiaire des pages jaunes comme UDDI ou Trader15. Il a utilisé les ontologies et la
représentation de connaissances pour classer et stocker les caractéristiques des services.
1. Ressource d’apprentissage : une ressource est décrite par : le Titre, le Créateur du
contenu de la ressource, le Sujet de la ressource (les mots clés ou les phrases qui décrivent le
sujet ou le contenu de la ressource), une Description textuelle du contenu de la ressource (y
compris le résumé dans le cas d’un article et d’objet et une description de contenu dans le
cas d’une ressource visuelle), Editeur de la ressource (la personne ou l’organisation
créateur additionnel), la Date, la Langue du contenu, le Format (text/html, JPEG image,.. )
et les Droits d’utilisations.
2. Ressource de recherche: leur investigation consiste à décrire les services qui contribuent
et aident les chercheurs à collaborer, travailler ensemble et pour échanger les informations
dans leurs activités de recherches. Elle comporte les éléments suivants :
• Le domaine de recherche: qui est identifié par l’Index (les mots clés qui décrivent
le domaine de recherche), les Références (ensemble de papier, document et URLs qui
sont utiles dans ce domaine de recherche), les Liens vers d’autres domaines et sujets
liés à ce domaine de recherche, et une Description textuelle du domaine de recherche.
• Un chercheur peut être décrit par: les informations personnelles (nom, email, TEL,
site web, CV), le Titre (ingénieur, professeur, ...), Domaine de recherche, domaine
d’enseignement, les publications, et le département auquel le chercheur est attaché.
• Un département peut être décrit par: le Nom (du département et l’université ou
l’organisation à laquelle est attaché), l’Adresse physique du département, Description,
domaine de recherche, liste des chercheurs attachés au département, les groupes
constituant le département, et le type du service (peut être une ressource
d’apprentissage, un programme, un document,...).
3. Service: le service au sens général peut être décrit par :
• Fournisseur et localisation: les informations du fournisseur (nom, adresse,..) et
localisation du service (adresse de la compagnie, URL,..) ;
15
Le trader est un service qui permet aux objets et aux services de se retrouver dans les systèmes distribués en se
basant sur leurs propriétés (caractéristiques ou index). C’est un annuaire de type pages jaunes qui permet à un
service ou objet d'être découvert via une description basée sur des propriétés (caractéristiques).
51
• Canaux de demande et de livraison: avec lesquels l’utilisateur peut communiquer

avec le service ;
• Payement et évaluation: c’est le processus de vente défini par le fournisseur afin de
collecter le prix du service à partir des consommateurs ;
• Environnement: les caractéristiques de l’environnement utilisé pour exploiter le
service tel que la bande passante ;
• Système de livraison: comme la Visio–conférence dans le cas des ressources
d’apprentissage ;
• Outils d’aide: tel que le chat qui aide les clients à utiliser les services.
6 Synthèse des différentes stratégies

Dans le contexte des web services, la fonctionnalité de découverte désigne une
recherche, dans l’annuaire UDDI, des services qui répondent au mieux aux exigences et
conditions de la requête de l’utilisateur. Initialement, les web services étaient décrit de façon
syntaxique (les descriptions WSDL), l’opération de découverte était basée sur des techniques
basées sur la recherche de mot-clé (la stratégie UDDI), par la suite la description a été
enrichie par les « qualités de service » du service et la découverte consiste à trouver le service
pertinent en satisfaisant les critères de fonctionnement ainsi que les critères de qualités de
services indiqués par le client.
Nous remarquons que, les deux premières stratégies sont basées sur des descriptions
générales des services (UDDI et UDDI + QoS). Cependant, le modèle de méta données de
[OUS, 05] offre une tentative de descriptions des services e-learning.
7 Conclusion
Les web services sémantiques visent à faire une combinaison entre le web sémantique
et la technologie des web services afin de permettre une interaction automatique et dynamique
entre les systèmes. L’annuaire UDDI reste toujours l’entité qui serve d’appui à la découverte
de web service pour les applications clientes.
Avec l’avènement des web services sémantiques, de nouvelles approches de découverte dites
approches de découverte sémantique ont été proposées, ces dernières donnent de bons
résultats comparés aux anciennes approches (les approches syntaxiques).
A travers l’étude des différentes approches, [DAV, 03] [OUS, 05] [SHU, 03], proposées pour
réaliser la découverte et l’invocation des web services, nous avons remarqué que les web
52
services renforcés par les descriptions sémantiques commencent à trouver leurs applications
dans de nombreux domaines entre autre le e-learning.
Notre étude et analyse des plateformes e-learning au niveau du chapitre 1, notamment

des critères de choix d’une plateforme e-learning, nous a permis d’identifier d’autres données
et informations sur les plateformes e-learning qui peuvent améliorer la description des web
services e-learning et donc d’améliorer l’opération de découverte. Ainsi l’étude des différents
types d’acteurs du e-learning et de leurs rôles et tâches nous a permis de dégager les besoins
qui les stimulent à chercher des services, parmi ces besoins on trouve:
• Un utilisateur enseignant souhaite mettre ses cours à disposition sur le web (avec des
annotations adéquates) pour permettre leur consultation par d’autres enseignants ou
par des apprenants ou des chercheurs sur le domaine.
• Un utilisateur enseignant cherche des ressources pédagogiques à consulter ou à utiliser
comme base d’un cours qu’il souhaite construire.
• Un utilisateur apprenant cherche un cours sur un thème donné pour un niveau donné.
• Un chercheur cherche un cours sur un thème donné pour s’instruire sur ce sujet et
l’exploiter éventuellement dans ses recherches.
• Une institution souhaite constituer une formation pour ses membres.
• Les membres d’une institution consultent individuellement ou collectivement une
formation offerte par leur institution.
• Un enseignant donne à distance un cours individuel ou collectif reposant sur une
ressource pédagogique accessible par les étudiants connectés sur le web.
• Un groupe de chercheurs veut mettre à disposition d’autres chercheurs les recherches
faites.
A cette fin nous proposons, dans ce qui suit, une approche pour la publication et la
découverte des web services pour le domaine du e-learning, plus particulièrement une
description des différents critères de choix de plateformes e-learning tout en essayant de
répondre aux besoins des différents acteurs.
53
Partie II
Conception et mise en
œuvre
Après avoir passé en revue les concepts relatifs au e-learning, aux web services et aux
ontologies et web sémantique, nous proposons, dans cette seconde partie, une approche pour
la publication et la découverte des web services e-learning basée sur des descriptions
sémantiques des web services en se basant sur l’ontologie DAML-S.
Chapitres :
4. Conception.
5. Mise en oeuvre.
Chapitre 4
La conception
Sommaire
1 Description ontologique des web services e-learning ...................................................... 54

1.1 Choix du DAML-S.................................................................................................. 54
1.2 L’ontologie de qualité d’apprentissage (QA).......................................................... 55
1.2.1 la classe « Qualité d’apprentissage »................................................................ 56
1.2.2 La classe « informations pédagogiques »......................................................... 56
1.2.3 La classe « informations techniques ».............................................................. 60
1.2.4 La classe « informations financières » ............................................................. 64
1.3 Intégration de l’otologie QA avec DAML-S .......................................................... 65
1.3.1 La classe « interopérabilité »............................................................................ 65
2 Présentation du système ................................................................................................... 66
2.1 Architecture du système .......................................................................................... 66
2.2 Utilisateurs et fonctions principales du système ..................................................... 68
2.2.1 Cas d’utilisation commun à tous les utilisateurs .............................................. 68
2.2.2 Cas d’utilisation du fournisseur de web service............................................... 69
2.2.3 Cas d’utilisation de l’administrateur ................................................................ 69
2.2.4 Cas d’utilisation de l’enseignant ...................................................................... 70
2.2.5 Cas d’utilisation de l’apprenant........................................................................ 71
2.3 Le module de publication........................................................................................ 72
2.4 Le module de découverte ........................................................................................ 74
2.4.3 Algorithme de découverte ................................................................................ 77
2.4.4 Filtrage des résultats de découverte selon le profil de l’utilisateur .................. 79
2.4.4.1 L’ontologie du profil utilisateur ................................................................... 79
2.4.4.2 Web service de gestion du profil utilisateur................................................. 83
2.4.4.3 Algorithme de filtrage des résultats de découverte ...................................... 85
2.5 Le module d’invocation de service ......................................................................... 86
3 Conclusion........................................................................................................................ 87
Chapitre 4 : Conception
Chapitre 4
La Conception
Actuellement, de nombreux web services e-learning ont été développés en constituant

un environnement d’apprentissage distribué, le nombre de ces web services est encore en
évolution.
Dans ce monde grandissant et foisonnant des web services e-learning, la recherche d’un web
service devient une tâche délicate et difficile. En effet, c’est vraiment difficile pour un
utilisateur de chercher le service qui répond à ses besoins dans des dizaines de service, voir
même des centaines de services. A cette fin la définition d’un mécanisme de découverte
automatique a devenu une nécessité qu’on ne peut pas dépasser.
Les critères de choix d’une plateforme e-learning dépendent, généralement, du modèle

pédagogique adopté et des contraintes ergonomiques et technologiques. Afin de soutenir la
découverte flexible et automatique des web services e-learning, nous allons proposer une
solution qui consiste en une description sémantique des principaux critères que doivent
vérifier les plateformes e-learning ce qui a nécessité une analyse approfondie et une
classification des plateformes [voir chapitre 1].
Dans ce chapitre, nous allons parler tout d’abord des insuffisances du DAML-S pour la
description des web services e-learning et de l’ontologie ajoutée à DAML-S, ensuite nous
allons présenter l’architecture du système proposé avec ses différents modules (publication,
découverte et invocation).
1 Description ontologique des web services e-learning
1.1 Choix du DAML-S

Dans ce travail, on utilise DAML-S, qui est une ontologie qui nous permet de faire une
description sémantique des web services. En effet, la classe « ServiceProfile » décrit le
fournisseur du service ainsi que les caractéristiques du service (nom, URL, catégorie…).
54
Les consommateurs de services e-learning présentent des exigences sur les aspects
technologiques (tels que le soft exigé, niveau de sécurité, …etc.) et sur les aspects
pédagogiques (tels que les ressources, l’évaluation, la collaboration,…etc.) de ces services, ce
qui oblige les fournisseurs de services à publier leurs services tout en mentionnant leurs
caractéristiques technologiques et pédagogiques. Donc, la plupart des aspects des web
services e-learning, tels que la découverte, la sélection, la composition ou l’invocation sont
étroitement liés à ces deux éléments (les aspects technologiques et pédagogiques).
Cependant, DAML-S n’offre pas la possibilité de décrire un service en terme d’aspects
technologiques et pédagogiques. Donc on peut dire que l’ontologie DAML-S ne fournie pas
une description parfaite qui considère toutes les conditions d’utilisations des web services e-
learning.
Afin de prendre en considération les caractéristiques technologiques et pédagogiques des
services, en plus des descriptions fonctionnelles, une ontologie va être ajoutée à DAML-S, qui
va être nommée ‘ontologie de Qualité de l’Apprentissage’ (QA).
1.2 L’ontologie de qualité d’apprentissage (QA)

Les plateformes e-learning peuvent être distinguées selon les fonctionnalités
pédagogiques assurées par chacune, en quelque sorte selon la qualité de la formation fournie
par chacune des plateformes. En conséquence la qualité de la formation est un facteur très
important lors du choix d’un outil e-learning. Les caractéristiques technologiques et
financières en tant qu'élément de la description de service e-learning constituent un facteur
particulièrement important pour le choix des services. En effet, les services sont offerts par
différents fournisseurs avec différents niveaux de qualités et de prix, en outre les
consommateurs de services présentent des exigences sur les qualités et les prix.
Donc une description des plateformes e-learning selon les caractéristiques pédagogiques,
technologiques et financières s’est avérée nécessaire afin de faciliter le choix d’un outil. Pour
cela nous allons définir une ontologie que nous indiquons par « ontologie de qualité
d’apprentissage (QA) » ; qui décrit un outil e-learning en terme de ces critères.
Cette ontologie aura le schéma suivant :
55
Qualité
d’apprentissage
Informations
Informations
pédagogiques
financières
Informations
Est techniques
Figure 4. 1 : Ontologie de qualité d’apprentissage.
1.2.1 La classe « Qualité d’apprentissage »

C’est la classe principale de l’ontologie, elle relie les différentes classes décrivant les
qualités d’un web services.
1.2.2 La classe « informations pédagogiques »

Généralement, une plateforme e-learning assume les fonctionnalités principales
suivantes : la gestion des ressources d’apprentissage, l’accès à distance à ces ressources, la
gestion des acteurs (administrateurs, enseignants, apprenants) et de leur suivi et évaluation, la
gestion des moyens de collaboration et de communication entre les différents acteurs et la
possibilité d’adaptation des cours aux besoins des utilisateurs. Sur la base de ces principales
fonctionnalités, nous mentionnons les critères pédagogiques de sélection des plateformes e-
learning, ceci à travers la sous ontologie « Informations pédagogiques » schématisée ci-après :
56
Administration Informations
Formation
pédagogique pédagogiques
Collaboration
Type Réalise
Acteur
Ressource
Synchrone Asynchrone
Réalisé par
Conforme Tâche
avec
Standard Test Contenu
A pour
Est
Modalité
Figure 4. 2 : Ontologie de qualité d’apprentissage – «Informations pédagogiques».
1. La classe « Collaboration »
Comme son nom l’indique ça concerne les différents outils pour la collaboration et la
communication entre les acteurs d’une plateforme (enseignant – enseignant, enseignant –
apprenant, apprenant – apprenant). Ces différents outils peuvent être classés en deux types :
• Outil synchrone : indique si le service utilise des outils d’interactivité en temps réel
tels que : les tableaux blanc, le chat, les vidéos conférence, les classes virtuelles, le
transfert de la voix par voie IP, …etc.
• Outil asynchrone : décrit les outils de communication asynchrone à savoir : le
transfert de fichier, le forum, email, …etc.
2. La classe « Ressource »
Englobe tous les aspects de gestion des ressources pédagogiques au niveau de la plateforme,
ces aspects sont :
57
• Format : indique le format de représentation de la ressource (PDF, HTML, image,.).

• Date de création : la date de création de la ressource.
• Date de MAJ : la dernière date de mise à jour de la ressource.
• Volume : le volume de la ressource.
• Création : englobe toutes les fonctionnalités d'élaboration des ressources
pédagogiques permettant à l'auteur de définir les unités d'apprentissages et leurs liens
et de les diffuser au niveau du système tout en spécifiant leur domaine et leur
discipline.
• Mise à jour : la mise à jour des contenus déjà crées par modification et par
suppression.
• Partage : c’est le partage coopératif en temps réel et en différé des ressources
pédagogiques afin de permettre l'utilisation d'une ressource qui n'est pas physiquement
présente sur une machine.
• Téléchargement : la possibilité de télécharger les ressources pédagogiques.
• Import / export : c’est la possibilité d’importation / d’exportation de ressources de /
vers la plateforme.
• Parcours : la définition des parcours d’apprentissage types pour les apprenants.
• Propriété : un champ à utilisation libre pour ajouter d’autres propriétés ou
informations sur les ressources.
Une ressource présente un contenu d’un cours ou bien un test. Pour cela nous avons conçu les
deux classes suivantes :
3. La classe « Contenu »
Les informations qui décrivent le contenu des ressources pédagogiques sont :
• Titre : indique le nom de la ressource.
• Sujet : représente un texte qui décrit le contenu de la ressource.
• Auteur : c’est l’auteur de la ressource.
• Droit : indique les droits d’utilisation de la ressource (utilisation, distribution et
modification).
• Région : indique la région dans laquelle la ressource est disponible.
• Langue : le langage du contenu de la ressource.
58
4. La classe « Test »
Cette classe décrit tout ce qui concerne le suivi et l’évaluation des apprenants afin de les aider
dans les matières qui font objet de difficultés et de juger les résultats obtenus. Elle comporte
les attributs suivants :
• Trace : garde la trace des tests et des évaluations.
• Fiabilité des réponses : niveau de fiabilité des réponses des tests.
• Fiabilités des évaluations : niveau de fiabilité des évaluations.
Les tests peuvent être classés en plusieurs modalités, pour cela la classe « modalité » a été
définie.
5. La classe « Modalité »
C’est la modalité de présentation des tests en quelque sorte il s’agit les types de tests (QCM,
texte à trou,…) qui peuvent être effectués au niveau de la plateforme.
• Modalité : le nom du type de test.
• Temps : c’est la durée maximale du test.
• Disponibilité : la disponibilité du test.
• Evaluation : c’est la manière d’évaluation du test : évaluation automatique en ligne,
manuelle par les enseignants ou autoévaluation qui permet à l’individu de s’évaluer
individuellement, en utilisant des tests dont les résultats ne sont pas sauvegardés (des
tests non corrigés).
• Action : les actions effectuées avec le test tel que l’inscription du résultat de test dans
le carnet de note de l’apprenant et l’envoi d’un message contenant le test à
l’enseignant.
• Essais : indique est ce que le test autorise plusieurs essais ou non.
• Affichage des résultats : cet attribut précise est ce que l’affichage des résultats est
différé ou immédiat.
• Affichage des réponses : précise si les réponses correctes sont affichées ou non.
• Statistiques : les statistiques sur la progression de la classe.
6. La classe « Standard »
Décrit les standards respectés par les ressources. Un standard est décrit par :
• Nom : le nom du standard.
• Constructeur : celui (organisme, entreprise, consortium, etc.) qui a crée le standard.
• Version : la version du standard.
59
7. La classe «Type_acteur »
Décrit les différents types d’acteurs gérés par la plateforme.
• Type d’acteur : le nom du type d’acteur.
• Groupe : possibilité de création et gestion de groupe pour ce type d’acteur.
• Description : une description du rôle de l’acteur.
8. La classe « Tâche »
Cette classe recouvre les fonctionnalités offertes pour le type de l’acteur, tel que la création et
l’affectation de test pour les enseignants.
• Tâche : le nom de la tâche.
9. La classe « Formation »
Elle décrit les informations sur les formations réalisées avec le web service, telles que : le titre
de la formation, son objectif, le public visé, date début et date fin, le coût….etc.
10. La classe « Administration pédagogique »
Recouvre toutes les fonctionnalités de gestion pédagogique de formation.
• Plan : la gestion des plans de formation. Un plan de formation est un ensemble de
modules pédagogiques ou de groupes de modules qu’est caractérisé par une
planification précise.
• Domaine : la gestion des domaines de la formation.
• Inscription : la gestion des inscriptions à une formation donnée.
• Niveaux : la gestion des niveaux d’apprentissage.
1.2.3 La classe « informations techniques »

Cette classe, comme son nom l’indique, englobe toutes les informations techniques sur le web
service.
60
Informations
techniques
Administration
Adaptation
technique
Langue
Aide
Sécurité Matériel
Caractéristiques
techniques Logiciel
Soft Soft
Serveur Client
Est
Figure 4. 3 : Ontologie de qualité d’apprentissage – le volet « Informations techniques ».
1. La classe « Adaptation »
L’adaptation est la possibilité de changement du système afin qu’il s’adapte aux exigences des
utilisateurs. Elle se définit par les attributs suivants :
• Façon d’adaptation : indique si la façon d’adaptation est automatique ou manuelle.
• Type d’adaptation : si elle se fait par rapport à l’individu ou par rapport à un groupe
d’individu.
2. La classe « Langue »
Elle indique est ce que le web service est multilingue, chaque instance de cette classe indique
une langue du service.
61
3. La classe « Sécurité »
Concerne le niveau et le type de la sécurité proposée au sein du web service. Elle définit si le
service offre les mécanismes de sécurité suivants :
• Authentification : la vérification de l’identité d’une entité (personne, un
ordinateur,…) afin d’autoriser son accès à des ressources pédagogiques (web service,
un cours…).
• Confidentialité: la protection contre l’accès aux informations par des entités tierces
indésirables.
• Contrôle d’intégrité : la vérification que les données n’ont pas été modifiées par une
entité tierce.
• Contrôle d’accès : vérifie que toute entité n’accède qu’aux services et informations
pour lesquelles elle est autorisée.
• Non répudiation : c’est la protection contre la contestation d’envoi et de réception de
données lors d’une communication.
4. La classe « Caractéristiques techniques »
Cette classe décrit les informations technologiques du web service. Ces informations se
résument dans les propriétés suivantes :
• Date de mise à jour : la date de la dernière mise à jour de la plateforme.
• Version : la version de la plateforme.
• Débit : c’est le débit de communication, qu’est la largeur de bande passante exigée
pour utiliser les services de la plateforme.
• Performance: la vitesse d’exécution d’une requête (le temps de réponse).
• Disponibilité: la probabilité que le service peut répondre aux requêtes des utilisateurs.
• Capacité: nombre maximum d’utilisateurs (d’accès Internet simultané) que pourra
supporter la plateforme.
• Nb cours : nombre maximal de cours qui peuvent être gérés par la plateforme.
• Fiabilité : la fiabilité est une valeur probabiliste, on a deux types :
1. La fiabilité de l’institution d’éducation : elle indique est ce que
l’institution est connue par le respect des décisions.
2. La fiabilité du réseau : c’est le degré de fonctionnement du service en
présence d’entrées exceptionnelles pour une période donnée. C'est-à-dire à
quel point le réseau résiste aux désastres.
62
5. La classe « Logiciel »
Décrit les outils soft (système d’exploitation, navigateur et autres logiciels) exigés pour faire
fonctionner la plateforme, dont les propriétés sont :
• Désignation : indique le nom du logiciel.
• Version : la version du logiciel.
• Description : une description textuelle qui peut contenir d’autres informations sur le
logiciel telle que le nom du fournisseur, la configuration du logiciel,…
6. La classe « Soft du client »
Les logiciels exigés au niveau des postes clients.
7. La classe « Soft du serveur »
Les logiciels exigés au niveau du poste serveur.
8. La classe « Matériel »
Cette classe décrit le matériel avec lequel la plateforme peut fonctionner. Elle a les attributs :
• Désignation : le nom du matériel.
• Capacité : la capacité du matériel.
• Description : un texte qui décrit le dispositif matériel.
9. La classe « Aide »
Les services offerts qui ont pour but l’explication de l'utilité et du mode d’emploi de chaque
fonctionnalité :
• Aide en ligne : possibilité d’offrir l’aide en ligne.
• Assistance TEL: la disponibilité de l’assistance téléphonique pour régler les
problèmes des utilisateurs de la plateforme.
• Technicien : disponibilité de techniciens qui se déplacent pour l’installation ou la
maintenance de la plateforme.
• Documentation : disponibilité de la documentation sur la plateforme.
10. La classe « Administration technique »
Englobe les fonctionnalités de gestion de la plateforme qui sont offertes pour un
administrateur technique. Cette classe a comme attribut :
• Compte : c’est la gestion des comptes utilisateurs et des comptes groupes – utilisateur.
• Droit : la gestion de l’affectation des droits d’accès aux différentes fonctionnalités de
la plateforme, la gestion des droits des cours en contrôlant l’accès en consultation et en
modification des différents cours, et la diffusion des cours selon les demandes des
utilisateurs.
63
1.2.4 Les informations financières

Cette classe comporte trois classes principales (voir figure ci – dessous):
Informations
financières
Coût Administration
financière
Licence
Est
Figure 4. 4 : Ontologie de qualité d’apprentissage – le volet « Informations financières ».
1. La classe « Coût »
Recouvre les coûts affectés au financement des formations, de façon direct ou indirect, dans
l’institution. Elle comporte deux attributs :
• Coûts d'investissement : coût non récurent, par exemple, équipement d’une salle de
formation.
• Coûts de fonctionnement : les coûts requis pour faire fonctionner le service tels que
les salaires des tuteurs afin de suivre les apprenants,…etc.
• Coût étudiant : le coût par étudiant.
• Coût cours : le coût par cours.
• Coût logiciel : coût des autres logiciels nécessaire pour le fonctionnement de la
plateforme (une estimation).
2. La classe « Licence »
Le type et coût de la licence de la plateforme.
• Licence : c’est le nom de la licence.
• Coût : le coût de la licence.
• Durée : la période pendant laquelle la licence est valide.
3. La classe « Administration financière »
Recouvre tout ce qui concerne les recettes et les dépenses de la formation.
• Contrat : la gestion des contrats.
• Payement : la gestion des payements.
64
1.3 Intégration de l’otologie QA avec DAML-S

Dans cette partie nous présentons le schéma complet de l’ontologie décrivant les web
services e-learning, que nous avons construit par l’intégration et l’assemblage de notre
ontologie de qualité d’apprentissage (QA) avec l’ontologie DAML-S. La figure ci-dessous
illustre cette ontologie:
Service
Supporte
Presents Communique
A pour
ServiceProfile
Interopérabilité
QA
Figure 4. 5 : Ontologie des services.
L’ontologie comporte l’ontologie de qualité d’apprentissage (QA), une partie de DAML-S (la
classe « Service » et la classe « ServiceProfil ») avec un autre élément que nous avons jugé
nécessaire dans la description des services, cet éléments est : l’interopérabilité du service avec
d’autres services.
Pour DAML-S, nous avons exploité seulement une partie de cette ontologie : la classe
« Service » que nous avons enrichi par d’autres propriétés et la classe « ServiceProfil », car
les autres classes (serviceGrounding et serviceModel) visent à définir les services comme un
ensemble de processus, rappelons que notre objectif est la description des caractéristiques et
des qualités de plateformes, à base de web services, afin de les publier et de les retrouver par
la suite et non pas de les modéliser sous forme de processus.
1.3.1 L’interopérabilité
L’interopérabilité est la capacité d’utiliser, dans une plateforme, des composants
d’enseignement développés dans une autre plateforme et la possibilité d’intégration avec des
outils externes tel que LDAP1. Cette classe décrit les services avec lesquels le service en
question peut communiquer. Elle comporte les deux propriétés suivantes :
1
Lightweight Directory Access Protocol.
65
• Service : indique le service avec lequel le service en question peut communiquer,

c’est une instance de la classe service.
• Description : c’est une brève description qui peut être utilisée pour décrire le type de
relation entre les services (les services se complètent, sont équivalent…) ou pour
décrire la configuration entre les deux services,...etc.
Après cette présentation de la description des web services e-learning à travers l’ontologie
des services, nous proposons maintenant d’exploiter cette ontologie dans un système de
publication, découverte et invocation des services. Ce système est présenté dans la partie
suivante.
2 Présentation du système
Ce projet est né de la constatation que de nombreuses plateformes e-learning à base de
web services ont été réalisées et les utilisateurs de ces plateformes avaient besoin d’aides,
principalement, pour chercher des web services qui répondent à leurs besoins.
Ces aides existent maintenant depuis de nombreuses années grâce à la généralisation des
UDDI, de WSDL, puis le web sémantique aujourd’hui.
L’étude des besoins des utilisateurs de plateforme e-learning, nous a amené à concevoir une
ontologie pour la description des web services du e-learning et à proposer un système pour la
publication, la découverte et l’invocation de ces services dont l’architecture et les différents
modules sont représentés ci après.
2.1 Architecture du système

L’objectif de notre système est d’assurer la publication, la découverte et l’invocation
des web services sémantiques dans le domaine du e-learning. Pour réaliser cet objectif, le
système consiste, en plus des composants usuels des web services (l’annuaire, WSDL,..), en
une description sémantique des services e-learning, un module pour la publication des web
services, un module pour la découverte et recherche de services, un module d’invocation de
web services.
Dans le but de donner des résultats de recherche plus précis, nous envisageons à utiliser le
profil utilisateur pendant le processus de découverte. Pour cela, le web service de gestion des
utilisateurs et profils utilisateurs a été ajouté.
L’architecture du système est illustrée dans le schéma ci-après :
66
Utilisateurs
Publication Découverte Invocation de Utilisateur et

service web profil
utilisateur
Ontologie des services

web (DAML-S + QA) Ontologie de
UDDI Profil utilisateur
Figure 4. 6 : Architecture de publication, découverte selon le profil utilisateur et

invocation de web services e-learning.
67
Nous allons détailler dans les parties qui suivent le rôle des différents modules du
système, nous proposons de modéliser leurs fonctionnements ainsi que les fonctionnalités qui
doivent être fournies à l’utilisateur grâce aux diagrammes UML.
Nous allons commencer par délimiter notre système et définir les fonctionnalités principales
dont il doit disposer ainsi que les différents types d’utilisateurs qui les effectuent.
2.2 Utilisateurs et fonctions principales du système

Les besoins fonctionnels couverts par le prototype peuvent être regroupés en quatre grandes
familles :
• La publication des web services ;
• La découverte (recherche) des web services ;
• L’invocation des web services ;
• Et la gestion de profil utilisateur.
Les utilisateurs représente le rôle humain dans notre système, leurs interactions avec le
système sont représentées sous forme de cas d’utilisation dans ce qui suit.
Les utilisateurs dans notre système peuvent être classés selon deux grandeurs : utilisateurs
web services (fournisseur et consommateur de web service) et principaux utilisateurs de
plateforme e-learning (administrateur, enseignant et apprenant). Puisque notre système a pour
tâches principales la publication et la découverte de web service, on a essayé de différencier
les rôles des utilisateurs selon la grandeur web services, ensuite selon la grandeur plateforme
e-learning. Cette différentiation est réalisée comme suit:
• Le fournisseur de service, qui peut être un administrateur ou un enseignant.
• Le consommateur de service, il peut être un administrateur, un enseignant ou un
apprenant.
2.2.1 Cas d’utilisation commun à tous les utilisateurs
Ce diagramme représente les cas d’utilisations d’un utilisateur quelconque, autrement dit, les
fonctionnalités que doit fournir le système à tous ses utilisateurs. Ces fonctionnalités sont :
• La recherche de web service : tous les utilisateurs peuvent interroger le système afin
de trouver des web services.
• La recherche de fournisseur : tous les utilisateurs peuvent chercher des fournisseurs.
68
• L’invocation de web service : l’invocation des web service est faisable par n’importe
quel type d’utilisateur.
• La gestion du profil : chaque utilisateur peut gérer (création et modification) son profil.
Figure 4. 7 : Cas d’utilisation de tous les utilisateurs.
2.2.2 Cas d’utilisation du fournisseur de web service
Ce diagramme représente les cas d’utilisations d’un fournisseur de web service.
Figure 4. 8 : Cas d’utilisation du fournisseur de web service.
2.2.3 Cas d’utilisation de l’administrateur
Les fonctionnalités que doit fournir le système à l’administrateur sont décrites comme suit :
69
• La gestion des utilisateurs : cela consiste en l’inscription ou la création d’un nouvel

utilisateur et la suppression d’un utilisateur.
• La gestion du profil : cela pour consulter le profil, effectuer d’éventuelles
modifications sur le profil d’un utilisateur ainsi que des recherches sur le profil.
Figure 4. 9 : Cas d’utilisation de l’administrateur.
2.2.4 Cas d’utilisation de l’enseignant

Le module de gestion des profils utilisateurs doit fournir à l’enseignant les fonctionnalités
suivantes :
• Initialisation du profil : après la création du compte de l’enseignant par
l’administrateur, un profil vierge est créé et attribué à ce compte. L’enseignant se
charge d’initialiser son profil en remplissant les champs dont il a le droit de remplir ou
de modifier.
• Consultation du profil : l’enseignant peut consulter son profil pour y vérifier les
données de certains champs, il peut aussi accéder aux profils de ses apprenants.
• Modification du profil : l’enseignant a le droit de modifier les données de certains
champs de son profil, ou alors de ceux de ses apprenants en apportant des
modifications manuelles à la partie évaluation par exemple.
• Recherche dans le profil : l’enseignant peut effectuer certaines recherches ou
interrogations sur les profils des apprenants de la plateforme, et ceci se fait s’il veut
avoir certaines informations bien précises sur les apprenants afin de mieux les suivre.
70
Figure 4. 10 : Cas d’utilisation de l’enseignant.
2.2.5 Cas d’utilisation de l’apprenant

Le module de gestion des profils utilisateurs doit fournir à l’apprenant les fonctionnalités
suivantes :
• Initialisation du profil : après la création du compte de l’apprenant par l’administrateur,
un profil vierge est créé et attribué à ce compte. L’apprenant se charge d’initialiser son
profil en remplissant les champs dont il a le droit de remplir ou de modifier.
• Consultation du profil : L’apprenant peut consulter son profil pour voir les notes qu’il
a eu dans les évaluations qu’il a effectué, ou bien juste pour vérifier les données de
certains champs de son profil.
• Modification du profil : l’apprenant a le droit de modifier les données de certains
champs de son profil telles que ses centres d’intérêts, ses buts, ses dispositifs, etc.
Figure 4. 11 : Cas d’utilisation de l’apprenant.
71
2.3 Le module de publication
2.3.1 Description du module

Ce module est dédié aux fournisseurs de service voulant publier leurs services
proposant ainsi la possibilité d’effectuer les publications de service, en déposant des
descriptions WSDL des services au niveau de l’annuaire UDDI et des descriptions
sémantiques au niveau de l’ontologie dédiée à la description sémantique, ainsi que l’ajout de
fournisseurs de services, en déposant leurs informations au niveau de l’ontologie.
L’architecture de ce module est la suivante :
Informations sur le fournisseur
Création des descriptions

du fournisseur
Fournisseur
DAML-S +
QA
Informations
sur le service Création des descriptions du
service
UDDI
Informations
sur WSDL
Figure 4. 12 : Architecture du module de publication.
2.3.2 Fonctionnement du module

Pour une représentation claire et précise des fonctionnalités fournies, nous aurons
recours au diagramme de séquence (ou de scénario). Ce diagramme offre une représentation
dynamique du système. Il montre pas à pas le séquencement des actions constituant le
processus de publication.
72
Figure 4. 13 : Diagramme de séquence du module de publication.
Le procédé de publication de service est le suivant :

• Le fournisseur introduit ses informations (le nom, adresse, l’URL, ….) ;
• Le module de publication récupère les informations du fournisseur ;
• Ajoute le fournisseur dans l’ontologie définie précédemment par l’instanciation de la
classe correspondante ;
• Le fournisseur introduit les informations nécessaires sur le service à publier (le nom,
l’URL, description, informations pédagogiques, coût, version,….) ;
• Le module de publication récupère les informations du service afin de générer, par la
suite, les descriptions sémantiques et les descriptions WSDL ;
• Instancier la classe « Service » ainsi que les classes correspondantes aux informations
introduites par le fournisseur ;
• Ajouter une entrée « serviceEntity » dans UDDI.
73
• Extraire les informations techniques à partir du fichier WSDL afin d’inscrire le WSDL
en tant que tModels ;
• Ajouter une entrée tModels dans UDDI.
2.4 Le module de découverte

Les utilisateurs de web services doivent pouvoir trouver rapidement un service offrant
les fonctionnalités désirées. Une étape préliminaire à l’utilisation d’un web service est sa
découverte. C’est par le mécanisme de découverte, que les utilisateurs peuvent localiser et
interroger les services.

Ce module est réservé aux consommateurs de services, il assure la recherche des
services qui répondent, le plus, à leurs besoins.
Une fois que des services ont été décrits et stockés dans l’ontologie et dans l’annuaire UDDI,
il est possible de rechercher ces services en utilisant des requêtes introduites par l’utilisateur,
qui est l’approche adoptée par la plupart des moteurs de recherche, à savoir Google. Deux
niveaux de recherche sont possibles :
• un niveau simple avec lequel la recherche se fait sur le nom et la description du
service seulement,
• et un niveau avancé avec lequel l’utilisateur précise les aspects de recherche, en
quelque sorte les classes de l’ontologie au niveau desquelles va être effectuée la
recherche.
Un aspect important du procédé de découverte est le filtrage des résultats de découverte selon
les besoins et préférences du demandeur de service. Pour cela, le demandeur s’authentifie
auprès du web service de gestion de profil, qui se chargera de découvrir les préférences du
demandeur et de les présenter au module de découverte afin qu’il filtre les résultats trouvés.
74
Résultat de
découverte
Requête(Q) Réception et Filtrage

découpage de des
Q résultats
DAML-S +
Consommateur QA
Préférences de
l’utilisateur
Aspects de
recherche
Identification Service web

du profil
de l’utilisateur
utilisateur
Figure 4. 14 : Architecture du module de découverte.
D’autres opérations sont assurées par ce module telle que la recherche d’un fournisseur, la
recherche d’une formation et de référence. Puisque ces opérations sont assez classiques et ne
présentent pas d’intérêt particulier; elles ne seront donc pas détaillées ici. La recherche des
services est plus intéressante, elle doit être décrites avec précision puisqu’il s’agit de l’un des
thèmes principaux de ce mémoire.

Avec notre mécanisme de découverte, la requête de l’utilisateur passe par plusieurs
phases de traitements avant d’être envoyée à l’ontologie. Afin d’illustrer ces différentes
phases, on présente le diagramme de séquence ci – après :
75
Figure 4. 15 : Diagramme de séquence du module de publication.
Le fonctionnement de l’opération de découverte est le suivant :

• Le demandeur du service introduit sa requête,
• Il précise les aspects de recherche,
• Le système de découverte récupère la requête,
• Ensuite, il la découpe et précise les classes cibles de la recherche selon les aspects et
conditions indiqués par le demandeur,
• Il lance la recherche dans l’ontologie,
• Si le demandeur souhaite que le système lui affiche seulement les résultats
convenables à son profil, alors il doit s’authentifier auprès du web service de profil, ce
dernier récupère ses préférences et les présentes au module de filtrage qui procède au
filtrage des résultats. Ensuite, le résultat de recherche est envoyé avec la requête au
web service du profil afin de garder l’historique des requêtes de chaque utilisateur.
• Sinon, le système affiche les résultats directement.
76
2.4.3 Algorithme de découverte
L’algorithme de découverte consiste à découper la requête de l’utilisateur en un

ensemble de mots ou de critères en vue de les utiliser pendant la recherche. Ainsi, l’utilisateur
indique les aspects de recherche à partir desquels l’algorithme définit les classes qui vont être
utilisées pendant la recherche, sinon une seule classe va être utilisée, qui est la classe
« ServiceProfil ». Par la suite, le système parcours tous les services et vérifie s’ils répondent
aux différents critères. En vue d’afficher les résultats selon l’ordre d’importance, un poids est
associé à chaque service trouvé, ce poids est incrémenté de 1 à chaque fois que le service
répond à un critère.
L’algorithme suivant illustre les différentes étapes d’exécution de l’opération de recherche de
web services:
77
R : requête ;
C : ensemble des critères de recherche ;
A : ensemble des aspects de recherche ;
CL : ensemble des classes cibles de la recherche ;
S : ensemble des services trouvés ;
P : les poids affectés aux services trouvés ;
Entrée
R Requête de l’utilisateur;
A Aspects de recherche sélectionnés par l’utilisateur ;
Début
//********** Découpage de la requête
C découper (R) en un ensemble de mots ;
//******* La recherche dans l’ontologie

Charger l’ontologie ;
CL la classe « ServiceProfil »
Pour tous les Aj
Si Aj est sélectionné : CL CL + classes correspondantes ;
Fpour
Pour toutes les instances de la classe « Service »
Pi 0 ;
Pour tous les critères (C)
Pour toutes les instances des classes de CL du service courant
Si CLj vérifie le critère Ck
Si Pi==0 : S S + service courant ;
Pi Pi+1 ; Fsi
Fpour
Fpour
i++ ;
Fpour
Afficher (S) selon l’ordre décroissant des Poids (P).
Afin de donner des résultats plus adaptés au profil de l’utilisateur demandeur de

service, l’algorithme de découverte comportera une autre phase, qui est la phase de filtrage.
Cette dernière est l’objet de la partie suivante.
78
2.4.4 Filtrage des résultats de découverte selon le profil de l’utilisateur

Le profil utilisateur peut être définit comme toute structure qui permet de modéliser et
stocker les données caractérisant l'utilisateur. Ces données représentent les informations
personnelles, les centres d’intérêts, les préférences et les besoins en informations de
l’utilisateur ou un groupe d’utilisateurs.
Le processus de découverte automatique des web services e-learning doit pouvoir identifier
ces données qui caractérisent les utilisateurs. Pour qu’il puisse aider ce dernier à chercher les
services pertinents.
La construction d’une ontologie décrivant le profil d’utilisateur offre des facilités de
recherche intéressantes au processus de découverte. A cette fin, on a définit une ontologie
pour le profil utilisateur. La partie ci-après illustre cette ontologie.
Pour exploiter cette ontologie, on a conçu un système de gestion de profil sous forme d’un
web service. On a opté pour la forme web service, afin d’être utilisé par d’autres systèmes e-
learning à savoir système d’adaptation, système d’évaluation,…etc.
2.4.4.1 L’ontologie du profil utilisateur

Avec cette ontologie le profil utilisateur est décrit selon plusieurs grandeurs : les
informations personnelles qui permettent de l’identifier, les données de préférences et centres
d'intérêts de l'utilisateur, ainsi que les données sur l’environnement de travail de
l’utilisateur,…etc.
79
Identité Info_ démog Contacts
Est
Sécurité Est Est But
Info_
Souhaite personnelles
avoir A pour
Est caractérisé
par
Education A l’éducation
Effectue Activité
Compétences A les Utilisateur A Requêtes

compétences l’historique
A les
qualifications A les
intérêts
Intérêts
Qualifications
A exercé
A les
préférences Est
Profession
Possède Mot clé
Est
Préférences
Dispositif
DCL
Est Est
Est Est
Contenant Contenu
Logiciel Matériel
Figure 4. 16 : l’ontologie de profil d’utilisateur
1. La classe « Utilisateur »
C’est la classe centrale de l’ontologie.
80
2. La classe « Info_personnelles »
Cette grandeur comporte les informations personnelles de l’utilisateur classées en trois sous
classes :
• La classe « Identité » : comme son nom l’indique, comprenne l’identité de
l’utilisateur (le nom, le prénom, mot de passe et l’identifiant).
• La classe « Contacts » : les informations permettant de contacter l’utilisateur
(l’adresse, l’email, numéro de téléphone et numéro de carte bancaire).
• La classe « Info_démog » : comprend d’autres informations concernant l’utilisateur
(la date de naissance, le genre, situation familiale, langue maternelle).
Indique les aspects de sécurité (authentification, confidentialité, contrôle d’intégrité, contrôle
d’accès, non répudiation) souhaités par l’utilisateur.
4. La classe « Education »
Les informations concernant le niveau d’éducation atteint par l’utilisateur. Elle englobe les
attributs suivants :
• Domaine d’éducation : indique le domaine d’éducation de l’utilisateur
• Niveau d’éducation : indique le niveau atteint dans l’éducation (primaire, collège,
lycée, universitaire).
• Organisation d’éducation : le nom de l’organisation au sein de laquelle l’utilisateur a
suivi son éducation.
5. La classe « Compétences »
Les domaines maîtrisés par l’utilisateur.
• Domaine : le domaine dans lequel l’utilisateur a une expérience ou une certaine
compétences.
• Outils : définit les outils que l’utilisateur maîtrise.
6. La classe « Qualifications »
Les domaines où l’utilisateur est qualifié. Elle comporte une sous classe :
• La classe « DCL » : Diplômes, Certifications et les Licences obtenus par l’utilisateur.
Chaque qualification est définie par : le titre, le nom de l’organisation qui a attribué la
qualification à l’utilisateur, la date de l’obtention de la qualification et le niveau de la
qualification.
81
7. La classe « Préférences »
Les données caractérisant les ressources cherchés ou manipulés par l’utilisateur selon ses
préférences.
Les préférences peuvent être vues comme une présélection virtuelle qui réduit la masse
d’informations à prendre en compte, ils peuvent être comparées à la notion de vue en base de
données.
• La classe «Contenant » : les données relatives à la forme des ressources que préfère
avoir l’utilisateur du point de vue format, volume maximal, date de création de la
ressource et la dernière date de mise à jour.
• La classe «Contenu » : les données relatives aux ressources que préfère avoir
l’utilisateur à savoir : le sujet, les droits d’utilisation de la ressource, la licence (libre,
payante), la langue, les régions où il souhaite que ses ressources soient disponibles.
8. La classe « Profession »
Elle comporte les informations qui caractérisent tous les postes occupés par l’utilisateur.
• Domaine : le domaine de profession exercé par l’utilisateur.
• Grade : indique le grade du poste occupé par l’utilisateur.
• Organisation : l’organisme au sein duquel l’utilisateur a exercé la profession.
• Expérience : l’expérience atteinte par l’utilisateur dans la profession (à noter que
l’unité de mesure diffère selon le domaine de la profession : heures, années,…).
• Période : la période durant laquelle la profession a été exercée.
9. La classe « Dispositif »
Décrit les dispositifs matériels et logiciels que possède l’utilisateur.
• Matériel : les informations relatives aux dispositifs d’entré / sortie ainsi que d’autres
équipements disponibles chez l’utilisateur. Chaque dispositif est caractérisé par sa
désignation, sa description ainsi que sa capacité.
• Logiciel : les données relatives au système d’exploitation, au navigateur et aux autres
logiciels manipulés par l’utilisateur. Chaque dispositif est caractérisé par sa
désignation, sa description et par sa version.
10. La classe « Intérêts »
Les centres d’intérêts de l’utilisateur que se soit dans le domaine de formation ou dans
d’autres domaines. Comporte le nom du domaine et une priorité attribuée à ce domaine.
11. La classe « Requêtes »
L’historique des requêtes déjà formulées par l’utilisateur.
82
12. La classe « Activités »

Ce que fait l’utilisateur au moment de la connexion (consulter un cours, faire un exercice ou
autres).
13. La classe « But »
L’objectif que veut atteindre l’utilisateur à la fin de sa formation.
• Le type : c’est le type du but visé par l’utilisateur (professionnel, éducationnel,
personnel).
• Description : une description verbale du but.
• Statut : l’état de réalisation du but.
• Priorité : la priorité attribuée au but.
14. La classe « Mots clé »
Indique les concepts appartenants à un domaine d’intérêt donné. Un mot clé est défini par sa
description et sa priorité.
2.4.4.2 Web service de gestion du profil utilisateur

L’ontologie décrite précédemment est gérée par un web service dont l’architecture est
montrée ci après :
Figure 4. 17 : Architecture du web service de gestion des profils utilisateurs.
83
Le web service de gestion de profil est conçu de manière à ce qu’il puisse être invoqué par
n’importe quel autre web service, et pour ce faire on a essayé de recenser les fonctionnalités
qu’il peut intégrer, ces fonctionnalités sont décrites dans des sous modules ou sous systèmes
comme suit :
• Sous module d’initialisation du profil : c’est le sous module qui permet le

remplissage d’une partie du profil pour la première fois, cette tâche s’effectue
manuellement par l’utilisateur qui peut être enseignant ou apprenant. L’initialisation
ne concerne pas tous les champs du profil, en effet il y a des champs à remplir
obligatoirement, il y a des champs optionnels et il y a des champs qui s’alimentent
automatiquement au fur et à mesure de l’exploitation de la plateforme tels que les
champs concernant les évaluations et les historiques des requêtes de recherche.
• Sous module de modification du profil : c’est le sous module qui permet d’effectuer
des mises à jours ou modifications sur le profil. Ces mises à jour sont autorisées selon
des privilèges attribués par l’administrateur de la plateforme. Par exemple les
enseignants ou les apprenants peuvent effectuer des modifications sur leurs buts, leurs
préférences, leurs dispositifs…etc. Notons qu’il y a des informations qui ne peuvent
pas être modifiées telles que les informations sur le nom, prénom, genre, date de
naissance.
La mise à jour peut s’effectuer manuellement et directement par l’utilisateur, ou alors

de manière automatique et implicite par une autre application, telle que l’application
de découverte des web services qui se charge de mettre à jour automatiquement la
partie du profil concernant l’historique des requêtes.
• Sous module de consultation du profil : l’administrateur peut consulter les profils

des autres utilisateurs à travers ce sous module. L'enseignant peut aussi consulter les
profils des apprenants pour voir leur état d'avancement. Quand à l’apprenant il ne peut
consulter que son propre profil préalablement à une éventuelle modification.
• Sous module de recherche dans le profil : c’est le module qui permet l’interrogation
de l’ontologie du profil. Cette interrogation peut se faire à travers une interface de
recherche offerte de façon adaptée aux différents utilisateurs : administrateur,
84
enseignant ou apprenant ; chacun selon le type de requête qu’il peut effectuer sur le
profil.
Effectuer une recherche sur le profil peut avoir plusieurs utilisations. Ça peut avoir un
but statistique ou de vue globale pour l’administrateur sur n’importe quel point du
profil, par exemple l’administrateur peut effectuer une requête du type « sélectionner
tous les utilisateurs qui ont un but professionnel dans cette formation», ou alors
« sélectionner tous les utilisateurs qui appartiennent à une certaine tranche d’âge », etc.
La recherche pour l’enseignant, peut avoir un but statistique concernant le niveau

atteint par les apprenants et ainsi avoir une vu globale sur leur état d’avancement ou
sur leurs lacunes.
Pour l’apprenant, il peut faire une recherche sur son profil seulement préalablement à
une modification.
2.4.4.3 Algorithme de filtrage des résultats de découverte

Pour réaliser le filtrage des résultats trouvés, le système de découverte invoque le web
service de gestion de profil afin d’authentifier l’utilisateur et de récupérer ses préférences. Le
poids d’un service est incrémenté du nombre de préférences vérifiées. Un service est enlevé
de l’ensemble des résultats s’il ne répond à aucune préférence.
Le filtrage des résultats se fait comme suit :
//******* Filtrage des réultats de Recherche selon le profil

Invoquer le service web du profil ;
Identifier l’utilisateur ;
S’il existe : Préférences Récupérer les préférences de l’utilisateur ;
FinInvocation
Pour tous les services trouvés (S)

Pour toutes les préférences
Si le service (Si) répond à la préférence : Pi Pi+1 ;
Fpour
Si le service (Si) ne répond à aucune préférence : S S – le service (Si) ;
Fpour
Afficher (S) selon l’ordre décroissant des Poids (P).
85
2.5 Le module d’invocation de service

Après la phase de recherche, le service trouvé doit être invoqué.

Une fois q’une liste de service est découverte, elle est automatiquement envoyée au
consommateur, par la suite ce dernier choisit le service à invoquer. Le service choisi va être
invoqué par le programme en récupérant les informations nécessaires à partir de sa description
WSDL et en se connectant à ce service, ensuite le consommateur interagit directement avec le
serveur du service en invoquant ses opérations et ses méthodes.
Résultat de Module de
découverte découverte
Récupération des
Choix d’un Chercher informations
(S) techniques pour
service (S) UDDI l’invocation
Consommateur
Etablissement de
la connexion
Interrogation du service Le service choisi

(S)
Figure 4. 18 : Architecture du module d’invocation de web service.
86

L’opération d’invocation est décrite dans le diagramme de séquence suivant :
Figure 4. 19 : Diagramme de séquence du module d’invocation.
Une fois que le demandeur a choisi un service, le système recherche le service dans l’annuaire
(serviceEntity) à partir de son nom. Si le service est trouvé, le programme d’invocation
recherche son tModel afin de récupérer les informations techniques sur les méthodes et les
interfaces du service. Dans le cas où ces dernières sont récupérées avec succès, l’interaction
en temps réel entre le demandeur et le service va être initialisée.
3 Conclusion
La découverte des web services e-learning nécessite une description sémantique ou
bien une description ontologique des services afin de pouvoir décrire leurs fonctionnalités,
leurs méthodes de fonctionnement, leurs qualités, …etc.
Le DAML-S peut décrire les services en terme de fonctionnalités et de méthodes de
fonctionnement, cependant d’autres exigences de description tels que les caractéristiques
87
techniques et les fonctionnalités pédagogiques ne sont pas concevables avec DAML-S, ce qui
nous a amené à lui ajouter une extension nommée ontologie de qualité d’apprentissage.
La découverte nécessite, aussi, une connaissance préalable des préférences et des conditions
de connexion de l’utilisateur effectuant la recherche. Pour ceci l’élaboration d’une ontologie
de profil utilisateur a été le deuxième pas vers la construction d’un système de découverte
capable de délivrer des informations selon les préférences de l’utilisateur.
Dans ce chapitre, nous avons présenté la modélisation de notre système de publication et
découverte de web services. Nous nous proposons de concrétiser notre système, en réalisant
les différentes ontologies et les différentes fonctionnalités (publication, découverte et
invocation). Le chapitre 5 en fait l’objet.
88
Chapitre 5
Mise en œuvre
Sommaire
1 Technologies et outils de développement ........................................................................ 89

1.1 Editeur d’ontologie.................................................................................................. 89
1.2 Le langage JAVA .................................................................................................... 89
1.2.1 Les technologies des JSP et Servlet ................................................................. 90
1.3 Le serveur Apache Tomcat ..................................................................................... 90
1.4 Technologies des web services ............................................................................... 91
1.4.1 UDDI ................................................................................................................ 91
1.4.2 Plateforme web services................................................................................... 91
2 Implémentation du système.............................................................................................. 91
2.1 Architecture fonctionnelle du système.................................................................... 91
2.2 Les ontologies ......................................................................................................... 93
2.2.1 L’ontologie des services................................................................................... 93
2.2.2 L’ontologie du profil utilisateur ....................................................................... 95
2.3 Les différents modules du système ......................................................................... 96
2.3.1 Le module de publication ................................................................................. 97
2.3.2 Le module de découverte ............................................................................... 103
2.3.3 Le web service de gestion du profil utilisateur............................................... 106
2.3.3.1 Inscription d’un nouvel utilisateur ............................................................. 107
2.3.4 Filtrage des résultats de découverte................................................................ 109
3 Conclusion...................................................................................................................... 111
Chapitre 5 : Mise en œuvre
Chapitre 5
Mise en œuvre
Après avoir présenté le rôle des différents modules qui constituent notre système dans
la partie dédiée à la conception. Nous donnons, dans ce chapitre, une idée de l’environnement
de mise en œuvre du prototype, une architecture fonctionnelle du système et détaillons
l’implémentation de ses modules tout en mettant en évidence le rôle de chaque ontologie.
1 Technologies et outils de développement

Pour implémenter le prototype, nous avons dû faire un choix concernant les outils de
développement. Nous citons dans cette section ces outils tout en mentionnant les raisons qui
nous ont amenés à les utiliser.
1.1 Editeur d’ontologie

L’implémentation de nos ontologies s’est effectuée à travers l’éditeur d’ontologies
Protégé 3.2. Plusieurs raisons ont motivé notre choix :
• Protégé est un éditeur d’ontologies open source et gratuit.
• Protégé possède une interface modulaire, ce qui permet son enrichissement par des
modules additionnel (plugins).
• Protégé permet l’édition et la visualisation d’ontologies.
• Protégé est fourni avec une API écrite en JAVA, qui permet de développer des
applications pouvant accéder aux ontologies de Protégé et de les manipuler.
1.2 Le langage JAVA

Notre choix du langage de programmation s’est porté sur le langage JAVA et cela pour
diverses raisons :
• JAVA est un langage orienté objet simple ce qui réduit les risques d’incohérence.
• JAVA est portable et multi – plateforme.
• JAVA possède une riche bibliothèque de classes.
89
• Il existe une API (Interface de programmation d’applications) JAVA fournie avec

l’éditeur d’ontologies Protégé ce qui permet d’accéder à l’ontologie à partir de notre
application.
Nous avons réalisé notre application java en utilisant JDK 1.5.0 avec l’IDE1 Eclipse 3.2.
1.2.1 Les technologies des JSP et Servlet

Les pages JSP sont composées du code HTML statique et du code écrit en Java pour les
parties dynamiques de la page. Nous avons opté pour les technologies JSP et Servlets pour les
raisons suivantes:
• Comme il s'agit d'une technologie basée sur Java, JSP profite de tous ce qu'offre ce
langage pour le développement et le déploiements d'applications.
• Grâce aux API normalisées pour les JSP et à la portabilité du code compilé Java, on
n'est pas limité à un seul type de plateforme ni de serveur web utilisé.
• JSP n'est pas rattaché à un éditeur particulier.
• Les Servlets sont indépendantes du serveur web.
• Les Servlets s'exécutent dans un moteur de Servlet utilisé pour établir le lien entre la
Servlet et le serveur web. Ainsi le programmeur n'a pas à se soucier de détails
techniques tels que la connexion au réseau et la mise en forme de la réponse HTTP.
• Les Servlets ont la capacité de supporter le multi – tâches.
1.3 Le serveur Apache Tomcat

Le serveur d’application Apache Tomcat (version utilisée 5.5) joue le rôle de conteneur
JSP/Servlet qui permet à sa connexion avec un serveur web de délivrer du contenu dynamique
aux clients. Les raisons ayant motivé ce choix sont :
• Apache Tomcat est un logiciel open source.
• Apache Tomcat permet l’implémentation rapide des dernières spécifications des
JSP/Servlet.
• Apache Tomcat est connu pour ses larges utilisations dans la communauté
JAVA/J2EE, il est ouvert et portable.
• Apache Tomcat est considéré comme stable et sécurisé.
1
IDE : Integrated Development Environment, un environnement de développement intégré, est un programme
regroupant un éditeur de texte, un compilateur, des outils automatiques de fabrication et souvent un débogueur.
90
1.4 Technologies des web services
1.4.1 UDDI
L’annuaire UDDI utilisé est JUDDI (la version 0.9rc4), qu’est une implémentation
open source réalisée par la fondation apache. JUDDI propose le stockage des données sur un
grand nombre de bases de données relationnelles ou bien sur une base xml. Le serveur de base
de données qu’on a utilisé est MySQL dans sa version 5.0.26-win32. UDDI4J est l’API java
utilisée pour exploiter les données JUDDI.
1.4.2 Plateforme web services

Pour la plateforme de web services, on a utilisé Axis (la version 1.4) proposé par la
fondation Apache qui est une implémentation du protocole SOAP pour Java. Axis permet
d’implémenter de manière transparente des web services écris en java au sein du serveur
d’application J2EE Apache Tomcat et de les déployer. Il en résulte une plateforme web
hybride supportant à la fois des requêtes HTTP et des requêtes SOAP.
La plateforme se veut donc à la fois un serveur web délivrant des pages HTML
dynamiquement au moyen de Servlets et de JSP et une plateforme d’hébergement de web
services.
2 Implémentation du système
Cette partie décrit les détails d’implémentation de notre prototype. Nous commençons
d’abord par la présentation de l’architecture fonctionnelle du système, l’implémentation des
différentes ontologies, et nous montrons ensuite comment ces ontologies sont exploitées par
les différents modules du prototype.
2.1 Architecture fonctionnelle du système

L'architecture fonctionnelle est chargée de la définition des caractéristiques majeures
du système : outils utilisés, les différents modules, ainsi que de l'organisation de ses éléments.
Nous avons choisi, lors de la conception de notre système de séparer les différentes tâches qui
le constituent sous forme de modules présentés par des programmes indépendants, pour une
raison évidente de flexibilité. Les différents modules mis en évidence sont: module de
publication, module de découverte, module d’invocation et web service de gestion de profil.
Le schéma ci-après résume dans son global l’architecture fonctionnelle de notre système:
91
Choix du service à invoquer
Service
Système de Interface d’invocation (JSP) web LMS
Invocation
Interface de découverte (JSP)

découverte
(Servlet) (SOAP)
Recherche Système d’invocation (Servlet)
Préférences du consommateur (SOAP / XML)

Services trouvés Service web
API JAVA LCMS
API JAVA
Consommateur
Ontologie des
WSDL
Réseau de communication
web services
Réseau de communication
JUDDI
Authentification du consommateur
Système de publication
Interface de publication (JSP)

Gestion de (Servlet)
profil (java)
Interface (JSP)
Gérer API JAVA API JAVA Publication

API JAVA
Utilisateurs profil
Descriptions +
WSDL Ontologie des
Ontologie du
WSDL
web services Fournisseur
profil
utilisateur
JUDDI
Figure 5. compte du profil utilisateur. : Architecture fonctionnelle

- du système
2.2 Les ontologies

La conception des ontologies de description des web services et du profil utilisateur
était l’une des étapes les plus importantes de notre projet. On entame maintenant la mise en
œuvre de ces ontologies.
2.2.1 L’ontologie des services

Pendant l’étape de conception nous avons essayé de concevoir une ontologie qui
permettrait de recenser et d’organiser en concepts tous les aspects de choix et de sélection des
web services e-learning. Ceci en démarrant d’une solution qui existe dans le monde des web
services, qui est l’ontologie DAML-S. Nous avons exploité une partie de cette ontologie : la
classe « Service » et la classe « ServiceProfil », du fait que les classes (serviceGrounding et
serviceModel) visent à définir les services comme un ensemble de processus, alors que notre
objectif est la description des caractéristiques et qualités de plateformes à base de web
services. Nous avons essayé d’intégrer notre ontologie avec la partie de DAML-S de telle
façon à garantir une description complète des services.
On donne ci – après une figure qui représente cette ontologie des services :
93
Figure 5. 1 : L’ontologie des web services.
L’ontologie est organisée, selon les principaux critères que nous avons jugés importants à
prendre en considération lors du choix d’une plateforme e-learning à base de web service,
comme suit :
• Les informations générales sur le service telles que le nom, l’URL,…
• Les informations sur le fournisseur du service, ainsi que les références du service ;
94
• Les informations pédagogiques, qui englobent les informations sur les fonctionnalités
pédagogiques telles que la possibilité de créer des cours, de créer des tests, ainsi que
les informations sur les ressources pédagogiques, dans le cas d’une plateforme
fonctionnelle, telles que les formations et les cours.
• Les informations techniques telles que la version du logiciel, la sécurité et les logiciels
exigés pour le fonctionnement de la plateforme ;
• Et les informations financières, à savoir les coûts, la licence….
2.2.2 L’ontologie du profil utilisateur

Nous avons conçu une ontologie pour le profil utilisateur afin de garder les
préférences de l’utilisateur, et d’utiliser ces informations dans la recherche des web services.
En plus des préférences, l’ontologie contient d’autres informations telles que les informations
personnelles, les compétences, les qualifications, … qui servent à identifier l’utilisateur et à
utiliser notre ontologie dans d’autres système e-learning (la création des cours, le suivi et
évaluation,…etc.).
95
Figure 5. 2 : L’ontologie de profil utilisateur.
A travers cette ontologie de profil utilisateur, nous avons essayé d’organiser tous les types
d’information qui peuvent influencer et améliorer la recherche de ressources pédagogiques de
façon générale, et la recherche de web services de façon spéciale. Ces informations sont
organisées dans des classes et des hiérarchies telles que indiquées dans la figure ci-dessus.
Cette ontologie est munie d’un web service pour qu’elle puisse être interrogée et manipulée à
distance par n’importe qu’elle autre web service ou programme d’une plate forme e-learning.
2.3 Les différents modules du système

Notre application est dédiée aux utilisateurs de plateformes e-learning à base de web
services (administrateur, enseignant ou apprenant) proposant ainsi un certain nombre de
fonctionnalités nécessaires dans la gestion des web services.
96
Au lancement de l’application, la page d’accueil s’affiche. Via cette page on peut accéder aux
différentes fonctionnalités du système. Ces fonctionnalités sont de trois types : publication
(groupe numéro 1 dans la figure ci – après), recherche (groupe numéro 2 dans la figure c –
après) et gestion de profil utilisateur (groupe numéro 2 dans la figure ci – après).
Figure 5. 3 : Interface principale du prototype.
2.3.1 Le module de publication

Nous avons décrit dans le chapitre précédent (conception) les tâches principales de ce
module. Nous décrivons ici comment nous avons réalisé ce module.
97
Publication de service
La publication d’un web service avec notre prototype nécessite tout d’abord
l’introduction des informations sur le service. Ces informations peuvent être introduites via
deux interfaces : une première interface pour les principales informations sur le services, et
une deuxième interface pour les informations détaillées sur le service.
Figure 5. 4 : Interface de publication.
Les principales informations sur le service sont : le nom (désignation) du service, URL,
WSDL, description, les types d’opérations sur les ressources pédagogiques (création,
importation, partage,…etc.), les informations techniques et ergonomiques (version, date de
mise à jours, sécurité, adaptation,…etc.), les informations sur les fonctionnalités
d’administration et de gestion (gestion des comptes, gestion des droits d’accès, niveaux…),
les informations sur le coût et la licence du service et le fournisseur du service.
On peut créer un nouveau fournisseur ou bien associer un fournisseur qui existe tel que
indiqué dans la figure ci-dessous :
98
Figure 5. 5 : Associer un fournisseur à un web service.

La publication du service peut être effectuée à ce niveau, en cliquant sur le bouton « Ajouter »
ou bien après l’ajout des informations avancées. Pour passer aux informations avancées sur le
service, il suffit de cliquer sur le lien « Options avancées » (voir la Figure 5.5). À ce niveau
on peut définir:
• Les ressources pédagogiques disposées sur la plateforme (cours, exercices…), ceci
concerne particulièrement les plateformes fonctionnelles.
• Les modalités de test (qcm,..) qui peuvent être créées par le service.
• Les standards respectés par les ressources du service.
• Les profils d’acteurs (administrateur, enseignant…) gérés par le service.
• Les tâches des acteurs.
• Les formations produites par la plateforme, ceci dans le cas d’une plateforme
fonctionnelle.
• Les outils de collaboration et de communication (forum, chat,…).
• Le multilinguisme du service (langues considérées par le service).
• Les logiciels exigés (coté client et coté serveur) pour faire fonctionner le service.
• Le matériel exigé pour faire fonctionner le service.
• Les références (clients) du service.
99
Figure 5. 6 : Options avancées de publication (softwares exigés).
On peut associer plusieurs ressources, modalités de test et logiciels,…. Au service à publier.
Figure 5. 7 : Options avancées de publication (Ressources et Modalités de test).
100
Après avoir introduit les informations du service, on valide l’ajout par le bouton « Ajouter »,
une fois validé le programme procède à :
1. L’ajout du service au niveau de l’annuaire :
• Ajouter une entrée tModel pour sauvegarder le fichier WSDL,
• Ajouter une entrée serviceEntity afin d’ajouter le service dans l’annuaire,
• Ajouter une entrée bindingTemplate afin de relier le tModel ajoutée avec son
serviceEntity.
2. L’ajout du service au niveau de l’ontologie :
• Charger la base de connaissance par « Project.loadProjectFromFile » et
« getKnowledgeBase() »,
• Instancier la classe « Service »,
• Instancier la classe « ServiceProfil », attribuer le nom, la description et l’URL
du service aux Slot correspondants dans l’instance ajoutée.
• Relier l’instance ajoutée de la classe « Service » avec l’instance ajoutée de la
classe « ServiceProfil »,
• Dans le cas d’un nouveau fournisseur, le programme ajoute une instance de la
classe « Acteur », sinon il récupère le nom de l’instance du fournisseur choisi.
• Relier l’instance du « ServiceProfil » avec celle du fournisseur, c.a.d donner
une valeur au Slot « Information_contact ».
• Selon le reste des informations introduites par l’utilisateur, instancier les autres
classes de l’ontologie, par exemple, si un modèle de test est ajouté alors la
classe « Modèle » va être instanciée et reliée à l’instance du service.
Ajout d’un fournisseur

L’ajout d’un fournisseur peut être effectué à partir de l’interface principale en cliquant sur
« ajouter fournisseur », sinon à partir de l’interface de publication de service en cliquant sur le
lien « Nouveau » (Voir Figure 5.6).
La fenêtre ci après montre les informations qu’on introduit pour ajouter le fournisseur :
101
Figure 5. 8 : Ajout d’un fournisseur.

De même que le service, l’utilisateur introduit les informations sur la fournisseur et valide
l’ajout par le bouton « Ajouter », le procédé d’ajout est le suivant :
1. Création d’une instance de la classe « Acteur » ;
2. Dans le cas où cette fenêtre est appelée à partir du programme d’ajout de service, alors
envoyer le nom de l’instance ajoutée à ce programme, ceci afin faire le lien avec la
classe « Service ».
Ajout d’une formation

L’ajout d’une formation se fait à l’aide de l’interface suivante :
102
Figure 5. 9 : Ajout d’une formation.
L’utilisateur introduit les informations sur la formation et valide l’ajout par le bouton
« Ajouter », le programme procède alors à :
3. La création d’une instance de la classe « Formation » ;
4. Relier la classe ajoutée avec la classe du service choisi ;
5. Relier la classe ajoutée avec la classe de l’organisateur de la formation (la classe
« Acteur » dans l’ontologie);
6. Relier la classe ajoutée avec la classe de l’enseignant choisi.
2.3.2 Le module de découverte

Ce module offre la possibilité de faire une recherche des web services qui ont été déjà
publiés, à l’aide de l’interface suivante :
103
Figure 5. 10 : Interface de découverte de service.
La recherche peut être simple ou avancée selon le choix de l’utilisateur de l’application :

1. La recherche simple : l’utilisateur introduit la requête et lance sa recherche.
2. La recherche avancée : l’utilisateur introduit la requête, spécifie les aspects de
recherche et lance sa recherche. Plusieurs aspects de recherche sont possibles, à
travers lesquels l’utilisateur guide le programme de découverte pour définir les classes
cibles de la recherche et pour trouver les services souhaités. Voici la liste de ces
aspects avec les classes correspondantes dans l’ontologie des services:
• Opérations sur les ressources pédagogiques (la classe « Ressource ») ;
• Les ressources (la classe « Contenu »);
• Les standards (la classe « Standard »);
• Modalité de test (la classe « Modalité »);
• Types d’acteur supportés (la classe « Type_acteur);
104
• Gestion et administration (les classes « Administration_technique »,

« Administration_pédagogique » et « Administration_financière »);
• Outils de collaboration (les classes « Synchrone » et « Asynchrone »);
• Langues (la classe « Langue ») ;
• Sécurité (la classe « Sécurité ») ;
• Matériels et logiciels exigés (les classes « Soft_serveur » et « Soft_client »);
• Informations techniques (la classe « Information_technique »);
• Aide (la classe « Aide »);
• Adaptation (la classe « Adaptation »);
• Coûts et licence (les classes « Coût » et la classe « Licence »);
• Concepteur de service (la classe « Acteur »);
• Clients du service (la classe « Acteur ») ;
• Autres (les classes « Catégorie_service », « Paramètre_service »).
Au lancement de la recherche, l’application prépare l’environnement de recherche et se
connecte à l’ontologie des services pour la collecte des informations comme suit :
1. Récupération de la requête de l’utilisateur et découpage de la requête en un ensemble
de mots;
2. Récupération des aspects de recherche mentionnés par l’utilisateur afin de définir les
classes qui vont être ciblées par la recherche ;
3. Demande de connexion à l’ontologie (Project.loadProjectFromFile et
getKnowledgeBase ) ;
4. Parcours de toutes les instances de la classe « Service » avec les classes associées qui
ont été définies comme cibles de recherche et vérification si elles répondent aux
critères de recherche.
5. Récupération des résultats.
Exemple 1 : Recherche sans prise en compte du profil utilisateur
Si on introduit la requête « service gratuit + qcm + authentification » le système nous

affiche quatre services comme résultat de recherche ; uLearn, ACCOLAD, CLAROLINE,
GANESH 3; tel que indiqué dans la figure ci – après :
105
Figure 5. 11 : Découverte et résultat de découverte de service.
Les services trouvés sont affichés avec une petite description. Pour voir la description
détaillée d’un service, il suffit de cliquer sur le lien « Détails » juxtaposé à la description du
service.
2.3.3 Le web service de gestion du profil utilisateur

Rappelons que l’objectif principal pour lequel ce service a été conçu est la
récupération des préférences de l’utilisateur afin de faire le filtrage pendant l’opération de
recherche de services. Ainsi que son utilisation dans les autres services de la plateforme e-
learning à savoir : la gestion des utilisateurs, la création des parcours, le suivi, …etc.
Nous allons présenter les méthodes utilisées par le module de découverte, avec les principales
fonctionnalités du web service.
1. La méthode « AuthentifierUtilisateur » : comme son l’indique, c’est une méthode qui
s’occupe de l’authentification de l’utilisateur. Elle a comme entrée : le login, le mot de
passe et le type de l’utilisateur, et comme sortie une chaîne de caractère qui va
contenir le nom de l’instance de l’utilisateur dans le cas favorable (utilisateur trouvé)
sinon la valeur « null ».
106
2. La méthode « PréférenceUtilisateur » : elle récupère les préférences de l’utilisateur.

Elle a comme entrée : le nom de l’instance de l’utilisateur et le nom de la classe (la
préférence concerné). Et comme sortie un tableau qui contient les noms des Slots de la
classe avec les valeurs des slots.
3. La méthode « garderRequêteUtilisateur » : elle consiste à sauvegarder la requête de
l’utilisateur afin de garder son historique.
Le lancement du service de gestion de profil se fait à l’aide du bouton « Gestion de profil »

dans la page d’accueil du système globale , une fois lancé, la page ci – après s’affiche :
Figure 5. 12 : Page d’accueil du service de gestion de profil utilisateur.
Le système offre trois modes d’accès : soit en tant qu’apprenant, ou en tant qu’enseignant
sinon en tant qu’administrateur. Ce dernier a le privilège d’effectuer des opérations de gestion,
à savoir la suppression d’un utilisateur, l’activation ou le blocage d’un utilisateur,…etc.
l’enseignant à le privilège par rapport à l’apprenant de consulter le profil de ses apprenants.
2.3.3.1 Inscription d’un nouvel utilisateur

L’inscription se fait en cliquant sur le lien « m’inscrire maintenant » dans la page
principale du service, ceci implique l’affichage du formulaire suivant :
107
Figure 5. 13 : Inscription d’un nouvel utilisateur.
A ce niveau l’utilisateur introduit ses principales informations : l’identité, les informations de

contact et les informations démographiques. Les autres informations peuvent être ajoutées en
lançant une modification de l’utilisateur.
Il peut ajouter ces autres informations par la suite, via d’autres interfaces. Prenant comme
exemple les logiciels utilisés tel indiqué dans la figure ci après :
108
Figure 5. 14 : Introduction des informations de préférences d’un nouvel utilisateur.
2.3.4 Filtrage des résultats de découverte

Dans le cas d’une recherche selon le profil utilisateur, le web service de gestion de profil
va être invoqué pour authentifier l’utilisateur et récupérer ses préférences. Pour cela, trois
méthodes sont invoquées:
1. La méthode « AuthentifierUtilisateur » pour authentifier l’utilisateur ;
2. La méthode « PréférenceUtilisateur» pour récupérer les préférences de l’utilisateur ;
3. Et la méthode « garderRequêteUtilisateur » pour sauvegarder la requête de
l’utilisateur.
Les résultats trouvés vont être filtrés selon les préférences de l’utilisateur ; prenant comme
exemple de préférence les softwares utilisés par l’utilisateur pour illustrer l’opération de
filtrage:
Pour tous les services trouvés

Pour toutes les valeurs de la classe « Soft_serveur » et la classe « Soft_client »
Si le soft courant appartient aux préférences de l’utilisateur alors
Augmenter le poids du service.
Fsi
Fpour
Si aucun soft ne correspond aux préférences de l’utilisateur alors enlever le
service de l’ensemble des résultats;
Fpour
109
Exemple 2: Recherche de service avec prise en compte du profil utilisateur

L’utilisateur « a_boudali » inscrit précédemment, qui préfère le IIS comme software, lance la
même requête introduite précédemment « service gratuit + qcm + authentification » (exemple
1) tout en cochant l’option « utiliser mon profil pendant la recherche »
Figure 5. 15 : Découverte et résultat de découverte de service avec prise en compte du

profil utilisateur.
Au lancement de la recherche une fenêtre apparaît pour authentifier l’utilisateur. Le

programme lance la recherche et affiche les résultats indiqués dans la figure ci-dessus. On
explique les résultats par :
• Le nombre de services trouvés a diminué de 4 à 2,
• Les deux services éliminés, uLearn et GANESHA 3, ne répondent pas aux préférences
l’utilisateur.
• L’ordre des services a changé, on a CLAROLINE au début de liste, ceci s’explique par le
changement du poids du service.
110
3 Conclusion
Dans ce chapitre, nous avons procédé à la réalisation de notre prototype, qui est un
système pour la publication et la découverte des web services e-learning. On a montré à
travers ce système l’intérêt de l’utilisation des ontologies pour la description des services et
leurs apports à la recherche de ces services, ainsi que l’intérêt de la prise en compte du profil
utilisateur pendant le processus de découverte. On a montré que l’annuaire UDDI et notre
ontologie se complètent pour décrire les services. En effet, notre ontologie préserve les
informations sur les fonctionnalités offertes et sur les caractéristiques nécessaires pour la
sélection d’un service, quant à l’annuaire, il préserve les informations WSDL nécessaires à
l’invocation du service.
111
Conclusion générale
Les technologies des web services ont bouleversé le monde de l’apprentissage à

distance. Le nombre des web services e-learning continuera à croître dans les années à venir
vu les avantages qu’offrent ces technologies qui deviennent prometteurs, comme en
témoignent l’interopérabilité et la réutilisation de fonctionnalités. La recherche manuelle de
ces services devient une tâche difficile à réaliser. L’automatisation de cette tâche peut
apporter alors, une solution à ce problème et permettre une recherche plus facile et plus
efficace. Dans cette optique, plusieurs approches ont été développées, et la recherche dans ce
domaine continue de proposer de nouvelles solutions qui tentent de répondre aux spécificités
des plateformes e-learning.
L’objectif de notre travail, est donc de mener une étude des web services et des
plateformes e-learning, pour développer une solution dont la finalité est la découverte des web
services e-learning, une étude comparative des plateformes e-learning et des critères de
sélection d’une plateforme a été donc effectuée, ainsi q’une étude du domaine des web
services et ses tendances et solutions actuelles pour la découverte. Pour ceci, plusieurs
solutions et approches ont été proposées.
Ces solutions consistent, généralement, en l’ajout de descriptions sémantiques des services,
tel que le DAML-S qui est une ontologie pour la description des web services. Cependant, ces
solutions ne répondaient pas parfaitement au besoins et exigences de description des services
e-learning.
La phase la plus importante de notre travail, est donc de proposer une description des
services e-learning en essayant de partir de solutions existantes et tentant de donner une
description plus complète.
Dans ce travail, nous avons proposé de décrire les différents paramètres et critères de
choix d’un web service e-learning à travers une ontologie : ontologie des services. Ensuite,
autour de cette ontologie, nous avons conçu et implémenté un système pour la publication et
la découverte des services.
Nous avons, ainsi, proposé de gérer le profil utilisateur en concevant une ontologie pour le
profil utilisateur et en développant un système pour la gérer. Vu l’importance et l’utilisation
112
du profil par tous les types de système e-learning, nous l’avons réalisé sous forme d’un web
service afin qu’il puisse être utilisé dans un système d’apprentissage complet.
Nous avons implémenté un algorithme de découverte, qui est basé sur une requête introduite
par l’utilisateur, un ensemble d’aspects de recherche ainsi spécifié par l’utilisateur et un
ensemble de préférences de l’utilisateur récupéré par le service de gestion de profil. Comme
résultats, l’algorithme donne un ensemble de services, qui sont présentés à l’utilisateur selon
leurs importances.
L’algorithme donne des résultats assez satisfaisants, et améliore nettement le degré de
pertinence en filtrant les résultats de découverte selon le profil utilisateur demandeur de
service.
Notre système représente un système prototype, il peut être donc modifié et étendu
afin de le rendre plus souple et capable de gérer des cas réels de publication et de découverte,
supportant ainsi l’invocation des web services.
Nous envisageons à étendre la solution pour supporter la composition des web services
e-learning en ajoutant plus de description si nécessaire, en implémentant le présent système
sous forme d’un web service et en implémentant un système de composition.
113
Bibliographie
Bibliographie
[ABE, 05] Marie-Hélène Abel
«Ontologies pour le Web Sémantique et le e-learning», La Journée
thématique « Web sémantique pour le e-learning », Du 30 mai à 03 juin
2005
[AGE, 08] Agence Wallonne des Télécommunications: le portail des Technologies
de l'Information et de la Communication (TIC), Mars 2008.
[ANN, 07] Anne Durand, Marie LEPROUST, Hélène VANDERSTICHEL
« Etude comparative de plateformes de formation à distance dans le cadre
du Projet @2L », octobre 2007
[BEN, 05] BENAYACHE Ahcene
« construction d’une mémoire organisationnelle de formation et
évaluation dans un contexte E-Learning : le projet MEMORAE », Thèse
de Doctorat, l’université de technologie de Compiegne, 2005
[BOR, 97] Borst W. N.
«Construction of Engineering Ontologies », In Center for Telematica and
Information Technology, University of Tweenty, Enschede, NL. 1997
[BOU, 04] BOUTEMEDJET Sabri
« Web Sémantique et e-learning », 2004
[BRO, 05] http://www.imsglobal.org/ep/ePortfoliobrochureFR.pdf
[BRU, 04] Peter Brusilovsky
« KnowledgeTree: A Distributed Architecture for Adaptive E-Learning»,
ACM 1-58113-912-8/04/0005, 2004.
[CER, 02] Ethan Cerami,
« Web Services Essentials », Livre, édition O'Reilly, février 2002.
[CHR, 05] Chris Preist
«A Conceptual Model and Technical Architecture for Semantic Web
Services», HP Laboratories, Bristol, UK. Article 2005.
[CLA, 08] http://www.claroline.net/
[COL, 01] Colin Smythe, Frank Tansey and Robby Robson
«IMS Learner Information Package Information Model Specification »,
Mars 2001
http://www.imsproject.org/profiles/lipinfo01.html
[DAL, ] Dallons Gautier
« DAML-S : interactions, critique et évaluation. », Institut d'informatique
des FUNDP, Namur, Belgique
[DAV, 03] David Martin
«DAML-S: Semantic Markup for Web Services », The DAML Services
Coalition, 2003-05-05
[EMN, ] Emna Ben Romdhane Hatem Skik
« E-learning : élément de réflexion autour d’une expérience en ”blended
learning” développée dans le milieu universitaire », ESC Tunis Assistant
– ESCE Tunis
[EPO, 05] http://www.imsglobal.org/ep/
[EPM, 05] http://www.imsglobal.org/ep/epv1p0/imsep_infov1p0.html
[ERI, 04] Eric van der Vlist
« LE TRIPTYQUE SOAP/WSDL/UDDI » Web Services Convention,
Juin 2004
[ETU, 06] « Etude comparative de plates-formes LMS », 2006
[GOM, 99] Gomez Pérez A., Benjamins V.R.
« Overview of Knowledge Sharing and Reuse Components: Ontologies
and problem-Solving Methods ». Proceeding og the IJCAI-99, workshop
on Ontologies and problem-Solving Methods (KRR5), Stockholm
(Suède), pp.1.1-1.15. 1999
[GOT, 03] Gottfried Vossen & Peter Weterkamp
« E-Learning as Web Services », Un article 2003.
[GRU, 93] Gruber T.
«A Translation Approach to Portable Ontology Specifications »,
Knowledge Acquisition, 5(2): pp. 199-220. 1993
[HUB, 03] Hubert Kadima & valérie Monfort
« Les web services », Livre, Edition DUNOD 2003
[IMS, 01] Colin Smythe, Frank Tansey and Robby Robson
« IMS Learner Information Package Best Practice & Implementation
Guide », Mars 2001
http://www.imsglobal.org/profiles/lipbest01.html.
[JEA, 05] Jean-Philippe PERNIN
« Panorama des normes et standards », LIUM - Université du Mans, LE
MANS. 2005
[JUL, 05] Julien Contamines
« Intégration des normes, standards, et spécifications dans les SABC »,
Télé-université du Québec, août 2005.
[LCM, 03] Ministère de la Jeunesse, de l’Education
« Etude des outils de gestion de ressources », conseil Business Interactif,
29/07/03
[MOO, 08] http://moodle.org/
[KAA, 03] Kaarthik Sivashanmugam, Kunal Verma, Amit Sheth, John Miller
«Adding Semantics to Web Services Standards », Large Scale Distributed
Information Systems (LSDIS) Lab Department of Computer Science,
University of Georgia Athens, GA 30602. Article 2003
[KOP, 05] Jacek Kopecký
«D30v0.1 Aligning WSMO and WSDL-S » , 05 / 08 / 2005
[KOU, 07] B. Kouninef, M. Djelti, S.M. Rerbal
« Conception et réalisation d’une plateforme e-learning avec migration au
m-learning », Article de l’Institut des télécommunications d’Oran.
[OUB, 05] Lahcen OUBAHSSI
« Conception de plates-formes logicielles pour la formation à distance,
présentant des propriétés d'adaptabilité à différentes catégories d'usagers
et d'interopérabilité avec d'autres environnements logiciels », Thèse de
doctorat, 2005, Université René Descartes – Paris V.
[OUS, 05] Oussama Kassem Zein, Yvon Kermarrec, Serge Garlatti, Jean-louis
Tetchueng, Sylvain Laubé
«A Metadata Model for Web Services Applied to Index and Discover E-
Learning Services», 2005
[PAP, 00] LTSC de l’IEEE
«Draft Standard for Learning Technology — Public and Private
Information (PAPI) for Learners (PAPI Learner) », 2000
http://edutool.com/papi
[PAT, 04 ] Patrick Kellert et Farouk Toumani
« Les Web services sémantiques », Article 2004
Laboratoire LIMOS - UMR (6158) du CNRS ISIMA - Campus des
Cezeaux - B.P. 125 63173 AUBIERE Cedex
[RAH, 05] Rahee Ghurbhurn
« Introduction aux Web Services », Master Web Intelligence, 2005
[RAN, 00] Sylvie Chabert-Ranwez
« Composition Automatique de Documents Hypermédia Adaptatifs
à partir d'Ontologies et de Requêtes Intentionnelles de l'Utilisateur »
Thèse de Doctorat de l’université de Montpellier II, 2000
[SAB, 05] Sabrina Menasri.
« Tableau comparatif de plateformes d’enseignement en ligne (e-learning)
utilisées dans un contexte universitaire », Septembre 2005
[SHU, 03] Shuping Ran
« A Model for Web Services Discovery With QoS » article 2003
CSIRO Mathematical and Information Sciences, Canberra, ACT 2601,
Australia
[SOF, 07] Web services
http://www.softeam.fr/technologies_web_services.php, 2007
[WAL, 04] Walid Kassem, Ahmad Mounajed, Nadia Saadoun
« Etat de l’art du E-Learning ». Projet du module : management et NTIC
2004
Annexes
Annexe A
L’ontologie des web services
: Slot de la classe
: Slot hérité d’une superclasse
1. La classe « Acteur »
Superclasses : aucune
Sous classes : aucune
Rôle : concrète
Slot Name Type Cardinality
Adresse_physique_acteur String 0:1
Fax_acteur String 0:1
Mail_acteur String 0:1
Nom_acteur String 1:1
Note_acteur String 0 :1
Orchestre Formation 0 :*
Titre_acteur String 0:1
Type {Fournisseur, client} 0 :1
Téléphone_acteur String 0:1
URL_acteur String 0:1
2. La classe « Catégorie_service»
Rôle : concrète
Code String 0:1
Nom_catégorie String 1:1
Taxonomie String 0:1
3. La classe « Enseignant »
Rôle : concrète
Adresse_physique_enseignant String 0:1

Enseigne Formation 0 :*
Fax_ enseignant String 0:1
Mail_ enseignant String 0:1
Nom_ enseignant String 1:1
Produit Contenu 0:*
Titre_ enseignant String 0:1
Téléphone_ enseignant String 0:1
URL_ enseignant String 0:1
4. La classe « Estimation_qualité»
Rôle : concrète
Nom_estimation String 1:1

Valeur_estimation String 0:1
5. La classe « Interopérabilité »
Rôle : concrète
Communique Service 0:*

Description_interoperabilité String 0:1
6. La classe « Paramètre_service»
Superclasses : Profil_service
Rôle : concrète
Nom_paramètre String 1:1

sParamètre String 0:1
7. La classe « Profil_service »
Sous classes : aucune.
Rôle : concrète
Catégorie Catégorie_service 0:1

Description_service String 0:1
Estimation Estimation_qualité 0:1
Information_contact Acteur 0:1
Nom_service String 0:1
Paramètre Paramètre_service 0:1
URL_service String 0:1
8. La classe « Qualité_apprentissage»
Sous classes : Information_pédagogique, Information_technique,
Information_financière
Rôle : abstraite
9. La classe « Information_financière »
Superclasses : Qualité_apprentissage
Sous classes : Coût, Licence, Administration_financière
Rôle : concrète
10. La classe « Administration_financière »

Superclasses : Information_financière
Rôle : concrète
Contrat {oui, non} 0:1
Payement {oui, non} 0:1
11. La classe « Coût »

Rôle : concrète
Coût_autre_logiciel String 0:1

Coût_fonctionnement String 0:1
Coût_investissement String 0:1
12. La classe « Licence »

Rôle : concrète
Coût_licence String 0:1
Durée String 0:1
Nom_licence String 1:1
13. La classe « Information_pédagogique »

Sous classes : Ressource, Type_acteur, Administartion_pédagogique, Collaboration
Rôle : concrète
14. La classe « Administration_pédagogique »

Superclasses : Information_pédagogique
Rôle : concrète
Domaine {oui, non} 0:1
Inscription {oui, non} 0:1
Niveaux {oui, non} 0:1
Plan {oui, non} 0:1
15. La classe « Collaboration »

Sous classes : Asynchrone, synchrone
Rôle : concrète
Description_outil_collaboration String 0:1

Nom_outil_collaboration String 0:1
16. La classe « Asynchrone »

Superclasses : Collaboration
Rôle : concrète

17. La classe « Synchrone »

Superclasses : Collaboration
Rôle : concrète
18. La classe « Formation »

Rôle : concrète
Contenu_formation String 0:1
Date_début_formation String 0:1
Date_fin_formation String 0:1
Durée_formation String 0:1
Enseignée_par Enseignant 0:1
Libellé_formation String 1:1
Objectif_formation String 0:1
Prérequis_formation String 0:1
Public_visé String 0:1
Réalisée_avec Service 0:*
Tarif_formation String 0:1
19. La classe « Ressource »

Sous classes : Test, Contenu
Rôle : concrète
Conforme_avec Standard 0:*

Création {oui, non} 0:1
Date_création_ressource String 0:1
Date_MAJ_ressource String 0:1
Export {oui, non} 0:1
Format String 0:1
Import {oui, non} 0:1
MAJ {oui, non} 0:1
Parcours {oui, non} 0:1
Partage {oui, non} 0:1
Produite_par Acteur 0:*
Téléchargement {oui, non} 0:1
Volume String 0:1

Superclasses : Ressource
Rôle : concrète
Droit_utilisation String 0:1
Format String 0:1
Langue_contenu String 0:1
MAJ {oui, non} 0:1
Région String 0:1
Sujet String 0:1
Titre_contenu String 0:1
Volume String 0:1
21. La classe « Test »

Superclasses : Ressource
Sous classes : Modalité
Rôle : concrète
Fiabilité_réponse String 0:1
Fiabilité_évaluation String 0:1
Format String 0:1
MAJ {oui, non} 0:1
Trace {oui, non} 0:1
Volume String 0:1
22. La classe « Modalité »

Superclasses : Test
Rôle : concrète
Action String 0:1
Affichage_réponse {oui, non} 0:1
Affichage_résultat {oui, non} 0:1
Disponibilité String 0:1
{automatique, auto-évaluation,
Evaluation 0:1
manuelle}
Fiabilité_réponse String 0:1
Fiabilité_évaluation String 0:1
Format String 0:1
MAJ {oui, non} 0:1
Nom_modalité String 1:1
Plusieurs_essais {oui, non} 0:1
Statistique String 0:1
Temps String 0:1
Trace {oui, non} 0:1
Volume String 0:1
23. La classe « Type_acteur »

Rôle : concrète
Création_groupe_type_acteur {oui, non} 0:1
Description_type_acteur String 0:1
Nom_type_acteur String 1:1
Réalise Tâche 0:*
24. La classe « Information_technique »

Sous classes : Adaptation, Langue, Sécurité, Caractéristique_technique, Matériel,
Aide, Logiciel, Administration_technique.
Rôle : concrète
25. La classe « Adaptation »

Superclasses : Information_technique
Rôle : concrète
Adaptation_automatique {oui, non} 0:1
Adaptation_manuelle {oui, non} 0:*
Adaptation_par_groupe {oui, non} 0:1
Adaptation_par_individu {oui, non} 0:*
26. La classe « Administration_technique »

Rôle : concrète
Compte {oui, non} 0:1

Droit_accès {oui, non} 0:1
27. La classe « Aide »

Rôle : concrète
Assistance_TEL {oui, non} 0:1

Documentation {oui, non} 0:1
Technicien {oui, non} 0:1
URL_aide String 0:1
28. La classe « Caractéristique_technique »

Rôle : concrète
Date_MAJ_service String 0:1
Disponibilité_service String 0:1
Débit String 0:1
Fiabilité String 0:1
Nb_cours String 0:1
Nb_utilisateur String 0:1
Performance String 0:1
Scalabilité String 0:1
Version String 0:1
29. La classe « Langue »

Rôle : concrète
Nom_langue String 0:1

Sous classes : Soft_serveur, Soft_client
Rôle : concrète
Description_logiciel String 0:1

Désignation_logiciel String 0:1
Version_logiciel String 0:1
31. La classe « Soft_client »

Superclasses : Logiciel
Rôle : concrète

32. La classe « Soft_serveur »

Superclasses : Logiciel
Rôle : concrète
33. La classe « Matériel »

Rôle : concrète

Capacité_matériel String 0:1
Description_matériel String 0:1
Designation_matériel String 0:1

Rôle : concrète
Authentification {oui, non} 0:1
Confidentialité {oui, non} 0:1
Contrôle_accès {oui, non} 0:1
Contrôle_intégrité {oui, non} 0:1
Non_répudiation {oui, non} 0:1
35. La classe « Service »

Rôle : concrète
A_pour_profil Profil_service 0:1

A_pour_qualité_apprentissage Qualité_apprentissage 0:*
Conçu_par Concepteur_service 0:*
Description_service String 0:1
Nom_service String 0:1
Supporte Interoperabilité 0:*
URL_service String 0:1
Utilisé_par Client_service 0:*
Utilisé_pour Formation 0:*
36. La classe « Standard »

Rôle : concrète
Concepteur_standard String 0:1
Nom_standard String 0:1
Version_standard String 0:1
37. La classe « Tâche »

Rôle : concrète
Description_tâche String 0:1

Nom_tâche String 1:1
Réalisée_par Type_acteur 1:*
Annexe B
L’ontologie de profil utilisateur
1. La classe « User »
Rôle : Concrète
a_don_perso Instance de Donnee_Personnel 3:3

a_education Instance de Education 0:1
a_exerce Instance de Profession 0:*
a_l'historique Instance de Requete 0:*
a_les_competences Instance de Compétence 0:*
a_les_interets Instance de Interet 0:*
a_les_preferences Instance de Préference 0:*
a_les_qualifications Instance de Qualification 0:*
a_pour_but Instance de But 0:1
date_type_user String 0:1
effectue_activite Instance de Activite 0:1
etat_user {Bloqué, Actif} 0:1
nouveau_inscrit {oui, non} 0:1
possede_dispositif Instance de Dispositif 0:*
souhaite_avoir_secur Instance de Securite 0:1
suit_unit_appr Instance de Unit_apprentissage 0:*
{Administrateur, Enseignant,
type_user 0:1
Apprenant}
2. La classe « Activité »
Rôle : concrète
type_activite String 0:1
3. La classe « Dispositif »
Sous classes : Logiciel, Materiel
Rôle : abstraite
description String 0:1
designation String 0:1
Superclasses : Dispositif
Rôle : concrète
version_log String 0:1
5. La classe « Materiel »
Superclasses : Dispositif
Rôle : concrète

capacite_mat String 0:1
6. La classe « Compétence »
Sous classes : Outil_Maitrise
Rôle : concrète

domaine_expertise String 0:1
7. La classe « Outil_maitrise »
Superclasses : Compétence
Rôle : concrète

descript_outil_maitrise String 0:1
design_outil_maitris String 0:1
domaine_expertise String 0:1
vers_outil_maitrise String 0:*
8. La classe « Education »
Rôle : concrète

domaine_edu String 0:1
niveau_edu String 0:1
organisme_edu String 0:1
9. La classe « Qualification »
Sous classes : DCL
Rôle : concrète
domaine_qualif String 0:1
10. La classe « DCL »

Superclasses : Qualification
Rôle : concrète
date_qualif String 0:1
domaine_qualif String 0:1
niveau_qualif String 0:1
organisme_qualif String 0:1
titre_qualif String 0:1
11. La classe « Préference »

Rôle : abstraite
Cette classe ne contient aucun slot.

Superclasses : Préference
Rôle : concrète
fraicheur String 0:1
{Français, Anglais, Espagnol, Arabe,
langue 0:1
Alemand, Chinois}
13. La classe « Contenant »

Superclasses : Préference
Rôle : concrète
date_creation String 0:1
droit_utilisation_res {Consultation, Modification} 0:1
{Texte, PDF, PowerPoint, Vidéo,
format 0:1
Audio}
licence {Libre, Payant} 0:1
priorite_contenant String 0:1
region {Algérie, France} 0:1
volume_max String 0:1
14. La classe « Interet »

Sous classes : Mot_Cle
Rôle : concrète
domaine_interet String 0:1
priorite_interet String 0:1
15. La classe « Mot_Cle »

Superclasses : Interet
Sous classes : Mot_Cle
Rôle : concrète
description_mot_cle String 0:1
domaine_interet String 0:1
priorite_interet String 0:1
priorite_mot_cle String 0:1
16. La classe « Profession »

Rôle : concrète
domaine_profession String 0:1
experience_profession String 0:1
grade_profession String 0:1
organisme_profession String 0:1
periode_profession String 0:1
17. La classe « Securite »

Rôle : concrète
authentification String 0:1
confidentialite String 0:1
controle_acces String 0:1
Contrôle_intégrité String 0:1
non_repudiation String 0:1
18. La classe « Requete »

Rôle : concrète
date_req String 0:1
description_req String 0:1
ws_req String 0:1
19. La classe « Unite_apprentissage »

Rôle : concrète

nom_unite_app String 0:1
type_unite_app String 0:1
20. La classe « Evaluation »

Rôle : concrète
nom_eval String 0:1
refererence_eval String 0:1
21. La classe « But »

Rôle : concrète
description_but String 0:1
statut_but {atteint, en-cours, non-atteint} 0:1
{Professionnel, Educationnel,
type_but 0:1
Personnel}
22. La classe « Donnee_Personnel »
Rôle : abstraite
Cette classe ne contient aucun slot.
23. La classe « Identite »

Superclasses : Donnee_Personnel
Rôle : concrète
login String 0:1
mot_d_pass String 0:1
nom String 0:1
prenom String 0:1
24. La classe « Contact »

Rôle : concrète
adresse String 0:1
carte_bancaire String 0:1
mail String 0:1
{Algérie, France, Suisse, Maroc,
pays 0:1
Tunisie}
telephone String 0:1
ville String 0:1
25. La classe « Demographie »

Rôle : concrète
date_naissance String 0:1
genre {Homme, Femme} 0:1
{Français, Anglais, Arabe, Espagnol,
langue_maternelle 0:1
Allemand, chinois}
situation_familiale {célibataire, marié} 0:1

These-F Boudali

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

These-F Boudali

Hochgeladen von

Copyright:

Verfügbare Formate

Ministère de l’enseignement supérieur et de la recherche scientifique

Institut National de formation en Informatique (I.N.I)

Option : Informatique industrielle

Soutenu devant le jury :

La tendance actuelle en environnements d’apprentissage est à l’utilisation croissante

Actuellement, le nombre de plateformes e-learning à base de web services est de plus

Je remercie Mesdemoiselles, Souade Adiche et Yasmine Noureddine pour leur aide et

Enfin, Que toute personne ayant contribué de près ou de loin à la réalisation de ce

A celle qui a su sécher mes larmes et me donner la force de continuer…

Partie I : Etat de l’art …………...………………………….………………….3

1 Qu’est – ce que le e-learning ? ........................................................................................... 3

Chapitre 2: Les web services………………………………………………………………..22

1 Définition des web services.............................................................................................. 22

Chapitre 3: La découverte des web services ………………………………………………39

Partie II: Conception et mise en œuvre………….………………………… 54

1 Description ontologique des web services e-learning ...................................................... 54

Chapitre 5: Mise en œuvre ……….……………………………………………………….55

1 Technologies et outils de développement ........................................................................ 89

Annexe A : L’ontologie des services

Figure 1. 1 : Complémentarité des LCMS/LMS. ......................................................................7

Figure 5. 2 : L’ontologie des web services............................................................................... 94

Liste des Tableaux

• La seconde partie, présente la conception et la mise en œuvre du système de

1 Qu’est – ce que le e-learning ? ........................................................................................... 3

1 Qu’est – ce que le e-learning ?

2 Les technologies du e-learning

3 Les plateformes e-learning

3.1 Les LMS (Learning Management System)

3.2 Les LCMS (Learning Content Management System)

3.3 Positionnement des LMS par rapport aux LCMS

Le schéma suivant illustre la distinction et la complémentarité des LMS et des LCMS :

Figure 1. 1 : Complémentarité des LCMS/LMS. [LCM, 03]

4 Les acteurs d’une plateforme

5.1 PAPI Learners

General Learning Technology Information

PAPI Learner Performance

Figure 1. 2 : Le standard PAPI Learner [PAP, 00]

Six types d’informations sont définis :

• Les informations personnelles (PAPI Learner personal): les informations privées

• Les informations de préférence (PAPI Learner preference): les informations qui

5.2 IMS LIP

Figure 1. 3 : Les principales structures de données de IMS LIP. [IMS, 01]

5.3 IMS ePortfolio

6 Comment choisir une plateforme e-learning ?

définition du nombre d’apprenants et du nombre de groupes, et de la durée des

La réussite d’une formation à distance ne dépend pas seulement de la bonne structuration

6.1 Critères de choix d’une plateforme e-learning

• Le besoin de maintenance de la plateforme d’un point de vue strictement informatique,

• Ergonomie et utilisabilité de la plateforme pour les enseignants comme pour les

6.2 Comparaison de quelques plateformes e-learning

Plateforme Moodle Claroline WebCT

Documentation Détaillée en 25 langues, Complète en 5 langues, Disponible

Tableau 1.1 : Comparaison des plateformes

7 Vers un e-learning distribué

• La personnalisation des parcours et des traitements.

7.1 Exemple: l’architecture KnowledgeTree (KT)

Figure 1. 4 : L’architecture KnowledgeTree. [BRU, 04]

L’architecture assume la présence, de quatre éléments : Le portail d’apprentissage

plusieurs activités d’apprentissage servies directement par différents serveurs d’activités. Le

Le e-learning actuel commence à devenir distribué en offrant des fonctionnalités

1 Définition des web services.............................................................................................. 22

Les web services

1 Définition des web services