Rapport 2 X

Découverte et sélection des web services dans le
cadre du e-Learning selon le profil utilisateur
ATMANI Hocine
SEFSAFI Soumia
2008/2009
Ministère de l’enseignement supérieur et de la recherche
scientifique
Ecole nationale Supérieure d’Informatique (ESI)
Oued-Smar, Alger
Mémoire de fin d’études

Pour l’obtention du diplôme d’ingénieur
d’état en informatique
Option : Systèmes d’information
Thème
Découverte et sélection des web services dans le
cadre du e-Learning selon le profil utilisateur
Réalisé par Encadré par

- ATMANI HOCINE - M. H. AMROUCHE
- SEFSAFI SOUMIA - M. A.BALLA
Promotion : 2008/2009
Ecole nationale Supérieure d’Informatique (ESI)
Découverte et sélection des web services dans le cadre du e-

Learning selon le profil utilisateur
ATMANI Hocine
SEFSAFI Soumia
Ecole national Supérieure d’Informatique (ESI)
MEMOIRE PRÉSENTÉ EN VUE DE L'OBTENTION

DU DIPLÔME D’INGENIEUR D’ETAT EN INFORMATIQUE
(SYSTEMES D’INFORMATION)
JUIN 2009
©ATMANI Hocine, SEFSAFI Soumia, 2009.

Dédicaces
En signe d’amour de gratitude et de respect je dédie ce modeste travail :
A mes très chers parents qui sans leur aide ce travail n’aura pas vu le jour :
Mon cher père qui a voulu me voir réussir et à qui je dois beaucoup,
Ma chère maman qui a toujours su être à mes cotés, maman que dieu te
protège,
A la mémoire de mes chers grands parents Cherif et Khedoudja,
A mon frère Sidali qui m’a soutenu et aidé durant mes années d’études,
A mes sœurs Souad, Mouna et Kahina,
A mon amie et binôme Soumia qui par son savoir faire et son sens
de l’humour a facilité la naissance de ce travail,
ainsi que sa famille,
A tous mes amis de la cité et ceux du village qui m’ont

toujours soutenu et encouragé et avec
qui j’ai passé de bons moments.
Qu’ils m’excusent de ne pas pouvoir les citer au risque
d’oublier quelqu’un,
HOCINE
III
Dédicaces
Je dédie ce modeste travail :
A mes très chers parents qui m’ont couvert d’amour, de soutient qu’ils trouvent
dans ce mémoire le fruit de leur travail :
Mon papa que je ne remercierai jamais assez pour tout ce qu’il a fait pour
moi, que dieu le garde à jamais,
Ma maman qui m’abreuve d’amour et d’affection intarissable, source de

mon bonheur et ma raison d’être,
A mes chers grand- parents que dieu les protège, ainsi que mes oncles et tantes,
A mon unique frère Mustapha,
A ma sœur et amie Assia et notre p’tite et adorable sœur Noufida,
A celui qui m’a supportée pendant neuf mois de travail, et qui a su

par son enthousiasme et sa bonne humeur
mener à bien ce mémoire, mon ami et binôme
Hocine ainsi que sa famille que j’aime beaucoup,
A toutes mes amies de l’enfance, et celles de l’ESI en

particulier fairouz,
SOUMIA
IV
Remerciements
Louange à Allah tout puissant qui nous a guidés pour l’accomplissement

de ce modeste travail.
Nous tenons à remercier particulièrement M.BALLA Amar pour sa

gentillesse et la confiance qu’il nous a accordée pour la réalisation de ce
mémoire.
Un grand merci à M.AMROUCHE Hakim qui nous a encadrés au cours

de ces neufs mois durant lesquels son aide précieuse, ses conseils et orientations
nous ont été d'un précieux apport afin de mener à beau et à bien ce travail que
nous espérons être dignes de la confiance qu'il a placée en nous.
Notre reconnaissance va tout naturellement à Mlle BOUDALI Fatiha

pour son orientation et ses minutieux conseils qui nous ont aidés pour la
réalisation de notre travail.
Nous aimerons exprimer notre gratitude aux personnes qui nous ont fait
l'honneur de participer au jury de ce mémoire.
Enfin nous adressons nos sincères remerciements à toute personne qui

nous a soutenus et encouragés au cours de la réalisation de notre projet.
V
Résumé
Actuellement, le nombre de plateformes e-Learning à base de Web services est de plus
en plus croissant. Par conséquent, leur découverte devient un défi très important. Pour rendre
le mécanisme de découverte plus efficace, la technologie des Web services sémantiques a été
proposée par exemple l’utilisation des ontologies telle que DAML-S et afin de soutenir la
description des critères ergonomiques et technologiques d’une plateforme e-Learning, une
extension a été rajoutée à DAML-S dans un travail effectué par Mlle Boudali dans le cadre
d’un mémoire de magistère à l’INI.
Notre projet s’inscrit dans la continuité de ce travail et consiste à concevoir et réaliser un

prototype pour la publication et la découverte de services Web dans le cadre du e-Learning et
leur adaptation selon le profil de l’utilisateur à l’aide des ontologies. En effet, vu la diversité
des utilisateurs et des conditions dans lesquelles ils accèdent aux services Web, d’autres
paramètres doivent être considérés lors de la découverte, tel que le type du dispositif utilisé,
les préférences de l’utilisateur, etc. Tous ces paramètres forment le profil de l’utilisateur.
Mots-clés
E-Learning, Web services, Web services sémantique, WSDL, DAML-S, Ontologie.
VI
Abstract
Currently, the number of e-learning platforms based on Web services is increasingly
growing. Consequently, their discovery becomes a very important challenge. To make the
discovery mechanism more effective, the technology of semantic Web services was proposed
for example the use of the ontology DAML-S and in order to support the description of the
ergonomic and technological criteria of the platform, an extension has been added to DAML-
S in a work by Miss BOUDALI under a report of magister.
Our project is a continuation of this work and consists to design and construct a prototype for
the publication and the discovery of Web services in e-Learning and their adaptation
according to user's profile using ontology. Indeed, considering the diversity of the users and
the conditions in which they reach the Web services, other parameters must be considered
during the discovery, such as the type of the device used, the preferences of the user, etc. All
these parameters form the user profile.
Keywords
E-Learning, Web services, Web services semantics, WSDL, DAML-S, Ontology.
VII
Sommaire
Introduction générale .............................................................................................................. 1
Première partie
Etat de l'art
Chapitre I : E-learning
1. Introduction .......................................................................................................................... 3
2.Définition du e-learning ........................................................................................................ 3

2.1. Définition1 .................................................................................................................. 3
2.2. Définition2 .................................................................................................................. 4
3. Les technologies du e-Learning ........................................................................................... 4

3.1. Outils synchrones ...................................................................................................... 4
3.1.1. Classes virtuelles et visioconférences .................................................................. 4
3.1.2. Télévision interactive (webcasting) ..................................................................... 4
3.1.3. Chat ...................................................................................................................... 5
3.2. Outils asynchrones .................................................................................................... 5

3.2.1. Forum ................................................................................................................... 5
3.2.2. Foire aux questions............................................................................................... 5
3.2.3. Transfert de fichier ............................................................................................... 5
4. Les plateformes e-Learning ..................................................................................................... 5

4.1. Les Learning Management Systems (LMS)............................................................ 5
4.2. Les Learning Content Management Systems (LCMS) .......................................... 6
4.3. Comparaison entre LMS et LCMS.......................................................................... 7
5. Les acteurs d’une plateforme .................................................................................................. 8

5.1. Le formateur .............................................................................................................. 8
5.2. L’apprenant ............................................................................................................... 8
5.3. L’administrateur ....................................................................................................... 8
6. Le Profil utilisateur ................................................................................................................. 9

6.1. Définition ........................................................................................................................ 9
6.2. Le contenu du profil utilisateur ................................................................................... 9
6.2.1. Le modèle PAPI ..................................................................................................... 10
6.2.2. Instructional Management Systems (IMS) ............................................................. 11
6.2.2.1. Le modèle IMS LIP ......................................................................................... 12
6.2.2.2. IMS ePortfolio ................................................................................................. 14
6.2.3. Synthèse ................................................................................................................. 14
7. Conclusion ........................................................................................................................... 15
VIII
Chapitre II : Les Web services
Introduction ............................................................................................................................ 16
I. Les Web services ................................................................................................................. 17
1. Définition d’un Service Web ............................................................................................. 17
2. Architecture des Web services............................................................................................... 17
3. Le XML et les trois standards SOAP, WSDL et UDDI .......................................................... 20
3.1. XML.............................................................................................................................. 20
3.2. SOAP (Simple Object Access Protocol) .................................................................... 21
3.3. Description WSDL (Web Services Description Language) ....................................... 22
3.4. Référentiel UDDI (Universal Description, Discovery and Integration) ................. 25
4. Applications des services Web .......................................................................................... 29
4.1. Application e-Learning ............................................................................................... 29
5. Conclusion ........................................................................................................................... 31
II. Le Web sémantique ........................................................................................................... 32
1. Définition ............................................................................................................................. 32
2. Langages pour le Web sémantique ................................................................................... 33
2.1. RDF (Resource Description Framework) ................................................................... 34
2.2. OWL (Web Ontology Language) ................................................................................ 35
3. Les ontologies ...................................................................................................................... 37
3.1. Définition ...................................................................................................................... 37
3.2. Les composants de l’ontologie .................................................................................... 37
4. Conclusion ........................................................................................................................... 39
III. Les services Web sémantiques ........................................................................................ 40
1. Présentation des services Web sémantique ...................................................................... 40
2. Objectifs des services Web sémantique ............................................................................ 41
2.1. La découverte automatique des services Web .......................................................... 41
2.2. Invocation automatique de services Web .................................................................. 41
2.3. Composition automatique de services Web .............................................................. 41
2.4. Surveillance automatique de l’exécution de services Web ...................................... 42
3. Une architecture étendue pour les services Web ............................................................. 42

4. DAML-S ............................................................................................................................... 44
4.1. Interaction avec WSDL .............................................................................................. 45
5. Conclusion ........................................................................................................................... 47
Conclusion ............................................................................................................................... 48
IX
Chapitre III : La découverte des Web services
1. Introduction ........................................................................................................................ 49
2. Les mécanismes de découverte .......................................................................................... 49

2.1. Approches basées sur des descriptions syntaxiques des services Web ............... 50
2.1.1. L’approche UDDI .............................................................................................. 50
2.2. Découverte dynamique des services ....................................................................... 50

2.2.1. Approche DAML-S ............................................................................................ 51
2.2.1.1. Les critiques de DAML-S ......................................................................... 52
2.2.2. La découverte des services web selon la qualité de services ............................. 52
3. Quelques travaux de découverte des services Web sémantiques ................................... 53

I. Un prototype et un algorithme pour la découverte de services Web ..................... 54
II. Un modèle de métadonnées pour l'indexation des services e-Learning ............... 57
III. Un algorithme de découverte des services e-Learning ......................................... 60
4. La comparaison des approches étudiées .......................................................................... 63
5. Conclusion ........................................................................................................................... 64
Deuxième partie
Conception et mise en œuvre
Chapitre IV : Conception du système
1. Introduction ........................................................................................................................ 65
2. Objectifs du système........................................................................................................... 65
3. Insuffisance de DAML-S dans le cadre du e-Learning ................................................... 66

3.1. L’ontologie de qualité d’apprentissage (QA) ............................................................ 66
3.2. Intégration de l’otologie QA avec DAML-S.............................................................. 67
4. L’ontologie du profil utilisateur ........................................................................................ 68
5. Architecture du système .................................................................................................... 69
6. Les Diagrammes UML représentatifs du système .......................................................... 70

6.1. Inscription des utilisateurs ......................................................................................... 71
6.2. Gestion des utilisateurs ............................................................................................... 71
6.3. Gestion des profils ...................................................................................................... 73
6.4. Recherche des services Web ....................................................................................... 75
6.5. Publication des services Web ..................................................................................... 76
X
7. Algorithme de découverte des Web services .................................................................... 78
8. Algorithme de sélection des résultats selon le profil utilisateur ..................................... 81
9. Conclusion ........................................................................................................................... 83
Chapitre V : Mise en œuvre du système

1. Introduction ........................................................................................................................ 84
2. Environnement de développement ................................................................................... 85

2.1. Le langage Java ........................................................................................................... 85
2.2. La technologie jsp et servlets ...................................................................................... 85
2.3. Apache Tomcat ............................................................................................................ 85
2.4. Eclipse 3.2 ..................................................................................................................... 86
2.5. Protégé 3.2 .................................................................................................................... 86
2.6. JUDDI 0.9rc4 et l'API UDDI4J .................................................................................. 86
3. Les ontologies ...................................................................................................................... 87
4. Implémentation de l’application EAsyLearn .................................................................. 89
4.1. Architecture Modèle/Vue/Contrôleur ....................................................................... 89
4.2. Implémentation des modules de l'application .......................................................... 90
4.2.1. Le contrôleur .......................................................................................................... 90
4.2.2. Les modèles ............................................................................................................ 90
4.2.3. Vues de l’application .............................................................................................. 91
5. Déploiement de l’application EAsyLearn ........................................................................ 92
6. Les interfaces de l’application ........................................................................................... 93
7. Conclusion ........................................................................................................................... 97
Conclusion et perspectives ................................................................ 98

Bibliographie .................................................................................... 100
Annexes
Annexe A : L’ontologie Qualité d’apprentissage
Annexe B : L’ontologie Profil Utilisateur
Annexe C : Le modèle MVC
XI
Liste des tableaux
Table 1 : Règles de correspondance entre DAML-S et WSDL. ............................................. 46
Table 2 : Architecture de mesure pour US. ............................................................................. 61
Table 3 : Comparaison des travaux de découverte .................................................................. 63
Liste des figures

Figure 1 : Le rôle du LMS et du LCMS dans la diffusion de contenus éducatifs pour le Web 6
Figure 2 : Couvertures fonctionnelles des LMS et des LCMS. ................................................ 7
Figure 3 : Représentation de la proposition de standard PAPI Learner ..... Erreur ! Signet non
défini.
Figure 4 : Architecture des Web services....................................... Erreur ! Signet non défini.
Figure 5 : Couches technologiques des services Web. .................. Erreur ! Signet non défini.
Figure 6 : Schéma d’un message SOAP.................................................................................. 21
Figure 7 : Architecture WSDL. ...................................................... Erreur ! Signet non défini.
Figure 8 : Structure UDDI.............................................................. Erreur ! Signet non défini.
Figure 9 : Modèle de données de l’annuaire UDDI. ............................................................... 27
Figure 10 :Capture d'écran de la page Business_Search.aspx................................................. 29
Figure 11 :Les activités e-Learning comme services Web. ........... Erreur ! Signet non défini.
Figure 12 : Les couches du Web Sémantique. ............................... Erreur ! Signet non défini.
Figure 13 : Exemple de graphe RDF. ............................................. Erreur ! Signet non défini.
Figure 14 : Un exemple d’ontologie. ............................................. Erreur ! Signet non défini.
Figure 15 : Evolution vers les services Web sémantique. ...................................................... 40
Figure 16 : Pile des Web services sémantiques.............................. Erreur ! Signet non défini.
Figure 17 : Classes principales de l'ontologie DAML-S. ............... Erreur ! Signet non défini.
Figure 18 : Vue d’ensemble des fonctionnalités de D2CP. ..................................................... 55
Figure 19 : L’architecture de découverte des services e-Learning. Erreur ! Signet non défini.
Figure 20 : Ontologie de qualité d’apprentissage. .................................................................. 66
Figure 21 : Ontologie des services. ......................................................................................... 67
Figure 22 : Architecture du système. ...................................................................................... 69
Figure 23 : Diagramme des cas d’utilisation........................................................................... 70
Figure 24 : Diagramme de séquence d’inscription des utilisateurs......................................... 71
Figure 25 : Diagramme de séquence «validation des utilisateurs». ........................................ 72
Figure 26 : Diagramme de séquence de «suppression des utilisateurs». ................................ 73
Figure 27 : Diagramme de séquence de «consultation de profil». .......................................... 74
Figure 28 : Diagramme de séquence « modification du profil »............................................. 75
Figure 29 : Diagramme de séquence de découverte des services Web. .................................. 76
Figure 30 : Diagramme de séquence de publication de services Web. ................................... 77
Figure 31 : L'ontologie des services ........................................................................................ 87
Figure 32: L'ontologie profil utilisateur. ................................................................................. 88
Figure 33 : Schéma de déploiement de l'application EAsyLarn ............................................. 92
Figure 34 : Interface principale de l’application. .................................................................... 93
Figure 35 : Interface de recherche. .......................................................................................... 94
Figure 36 : Interface résultat de la recherche. ......................................................................... 95
Figure 37 : Interface de recherche multicritère. ...................................................................... 96
XII
Figure 38 : Interface de résultat de recherche. ........................................................................ 96
XII
Introduction générale
L’introduction des nouvelles Technologies de l’Information et de la Communication
"TIC" dans la formation a fait apparaitre un nouveau mode d’apprentissage appelé le e-
Learning. Il s’agit d’une évolution rapide des technologies pour l’apprentissage, rendue
possible par le développement planétaire de l’Internet. Ce mode d’apprentissage est basé sur
l’accès des formations en ligne, interactives et parfois personnalisées, diffusées par
l’intermédiaire d’un réseau -Internet ou Intranet- ou d’un autre média électronique. Cet accès
permet de développer les compétences des apprenants, tout en rendant le processus
d’apprentissage indépendant du temps et du lieu. Une plateforme E-Learning peut être
considérée comme un ensemble de Web services, qui constituent une infrastructure
technologique distribuée faite pour assembler des systèmes hétérogènes en un seul et même
modèle logique à travers un réseau et qui coopèrent entre eux pour fournir certaines
fonctionnalités aux acteurs de la plateforme.
En quelques mois, les Web Services sont devenus le nouveau point de convergence
technologique de l'ensemble des acteurs du marché de l'informatique, grâce à la disponibilité
immédiate d’outils et de standards permettant la découverte et l’invocation automatisées des
fonctions métiers via un échange de messages informatisés (SOAP, UDDI, WSDL).
Cependant ces mêmes standards, largement utilisés actuellement, ne permettent de décrire les
fonctionnalités des Web Services que de manière syntaxique ce qui rend leur découverte
moins efficace. La nouvelle génération du Web dite Web services sémantiques a pour
ambition de lever cette difficulté. Les ressources du Web seront plus aisément accessibles
aussi bien par l’homme que par la machine, grâce à la représentation sémantique de leurs
contenus. Les services Web sémantiques sont des services Web dotés de descriptions
sémantiques et cela est réalisé grâce à plusieurs langages et formalismes, entre autres
l’ontologie DAML-S. DAML-S offre, en plus de la description syntaxique, des informations
sémantiques sur le fonctionnement du service. Ces informations peuvent être utilisées pour
améliorer la qualité de la découverte.
Appliqué au domaine du e-Learning, DAML-S ne décrit pas les critères ergonomiques
et technologiques des services Web et pour bien décrire ces critères une extension a été
ajoutée à DAML-S dans le cadre d’un mémoire de Magister, cette extension consiste en une
ontologie de qualité d’apprentissage (QA) et notre projet s’inscrit dans la continuité de ce
travail.
1
Vu la diversité des utilisateurs et des conditions dans lesquelles ils accèdent aux
services Web, d’autres paramètres doivent être considérés lors de la découverte, tel que le
type du dispositif utilisé, les préférences de l’utilisateur, etc. Tous ces paramètres forment le
profil de l’utilisateur pour ce faire nous allons utiliser une ontologie profil utilisateur.
Organisation du document
Ce document est composé de deux parties : la partie état de l’art et la partie conception et
mise en œuvre du système.
• La première partie, propose un état de l’art concernant les notions du l’e-Learning et
des Web services. Cette partie comprend trois chapitres :
Le premier chapitre traite le domaine du e-Learning, les plateformes et les différents
types d’acteurs. Ainsi que la notion du profil utilisateur.
Le second chapitre porte sur la notion des Web services : il présente l’architecture et
les différents standards ainsi que l’application des Web services dans le domaine du e-
Learning. Il présente aussi les différents langages du Web sémantique, les services
Web sémantique et précise l’importance des ontologies.
Le troisième chapitre se focalise sur les différentes techniques de découverte des Web
services ainsi que quelques prototypes de découverte.
• La deuxième partie, décrit la conception et l'implémentation de notre application
"EAsyLearn". Elle se compose de deux chapitres :
Le premier chapitre porte sur la conception du système et traite sa modélisation, à base

d’ontologies ainsi que son architecture.
Le deuxième chapitre traite l’implémentation et la mise en œuvre de notre application.
Il décrit les outils de développement et illustre les principales fonctionnalités du
système.
2
Partie I
Etat de l’Art
Chapitre I
Le E-Learning
Chapitre I E-Learning
1. Introduction
Les nouvelles Technologies de l’Information et de la Communication "TIC"
améliorent profondément nos façons de nous informer, de communiquer et de nous former.
Cette émergence technologique fait apparaître un nouveau mode d’apprentissage connu sous
le nom de l’e-Learning. Il constitue un processus d'apprentissage à distance s'appuyant sur des
ressources multimédias, qui permet à une ou plusieurs personnes de se former à partir de leur
ordinateur.
Son but principal est bien d’améliorer la qualité de l’apprentissage et non de se substituer aux
modes d’apprentissages traditionnels.
La première partie de ce chapitre traite la définition du E-Learning, acteurs et intervenants et
les principales plateformes existantes. Dans la deuxième partie nous aborderons la notion du
profil utilisateur.
2. E-Learning
L'apprentissage en ligne ou e-Learning, étymologiquement l'apprentissage par des
moyens électroniques, peut être caractérisé selon plusieurs points de vue: économique,
organisationnel, pédagogique, technologique.
Afin de mieux comprendre la notion du e-Learning, nous citons ici deux définitions que l’on
trouve communément dans la littérature.
Définition 1
«le e-Learning est un mode d'apprentissage basé sur l'utilisation des nouvelles
technologies, permettant l'accès à des formations en ligne, interactives et parfois
personnalisées, diffusées par l'intermédiaire d'internet, d'un intranet ou autre média
électronique, afin de développer les compétences, tout en rendant le processus
d'apprentissage indépendant de l'heure et de l'endroit. »[Guide, 05]
3
Définition 2
La définition de l'apprentissage en ligne (e-Learning) donnée par l'Union Européenne
est : « l’e-Learning est l’utilisation des nouvelles technologies multimédias de l’Internet pour
améliorer la qualité de l’apprentissage en facilitant d’une part l’accès à des ressources et à
des services, d’autre part les échanges et la collaboration à distance ».
En anglais, le terme e-Learning, employé par le monde économique, résulte d’une volonté
d’unifier des termes tels que : « Open and Distance Learning » (ODL) pour qualifier sa
dimension ouverte et qui vient du monde de la formation à distance, « Computer-Mediated
Communication » (CMC) pour traduire les technologies de communication (Mails, Forum,
Groupware) appliquées à la formation, « Web-Based Training » (WBT) pour traduire la
technologie dominante sur Internet pour la formation, « Distributed Learning » qui traduit
plus une approche pédagogique de type constructiviste et fondée sur la Cognition Distribuée
[Grabinger , 01].
3. Les technologies du e-Learning

Le e-Learning désigne des dispositifs fonctionnant via les nouvelles technologies de
l’information et de la communication et Internet en particulier.
On distingue des outils synchrones et asynchrones :
3. 1. Outils synchrones
3.1.1 Classes virtuelles et visioconférences :

Un outil de communication bidirectionnelle de groupe, qui privilégie l’articulation et
l’audiovisuel et des télécommunications où l’ordinateur est sollicité d’une manière auxiliaire,
par deux biais essentiellement : d’une part celui du traitement du signal et de l’automatisation
des prises de vue et de parole [Moeglin, 99]
3.1.2 Télévision interactive (webcasting) : Télévision interactive est une technique

de livraison de diffusion audio ou vidéo sur le Web en direct ou en différé.
3.1.3 Chat : Echange de message en temps réel via un logiciel spécifique.
4
3.2. Outils asynchrones : l’interactivité n’est pas en temps réel mais en différé :
3.2.1. Forum : 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.
3.2.2 Foire aux questions : Les questions de chaque apprenant, leurs réponses données
par un formateur, voire un autre apprenant sont consultables par tous.
3.2.3 Transfert de fichier : une fonctionnalité très utile, permet d’envoyer des
documents, des photos, des vidéos,…etc.
4. Les plateformes e-Learning

Une plateforme pédagogique est un logiciel qui permet de gérer des parcours, des
programmes, des étapes d’une façon très fine (gestion des individus, de groupes et sous
groupes, gestion des contenus par module, session ou formation). Elle doit également donner
la possibilité de relier certaines fonctionnalités (par exemple, offrir un tableau de bord des
rendus de devoirs de chaque individu, masquer ou rendre visible rapidement un document ou
un ensemble de documents, etc.).
Dans le domaine du e-Learning on peut distinguer deux types de plateformes : les LMS
(Learning Management System) et les LCMS (Learning Content Management System).
4.1. Les Learning Management Systems (LMS)
Un LMS (Learning Management System) ou MLE (Managed Learning Environment)

ou VLE (Virtual Learning Environment) ou CMS (Course Management System) ou LSS
(Learning Support System) est un système logiciel développé pour accompagner les
enseignants dans leur gestion des cours d'éducation en ligne pour leurs étudiants. Les services
offerts incluent généralement un contrôle d'accès, des outils de communication (synchrones
et/ou asynchrones) et l'administration des groupes d'utilisateurs.
La plupart de ces systèmes présentent également des générateurs internes de tests d'évaluation
que l'on retrouve sous forme de QCM, QCU, vrai/faux, texte à trous, appariements. Ces
activités sont soit soumises à validation par l'enseignant soit proposées comme activités de
régulation en auto-évaluation. D'une manière générale, elles sont intégrables en tant que
5
ressources pédagogiques dans un parcours d'apprentissage au sein de la plateforme. Si celle-ci

est compatible avec le standard SCORM1, les résultats à ces activités d'évaluation sont alors
pris en compte dans la gestion du parcours d'apprentissage de l'étudiant [URL, 1]
4.2. Les Learning Content Management Systems (LCMS):

Ces systèmes permettent à des experts d’un domaine, à des développeurs, de coopérer
(via le Web) pour créer des contenus éducatifs (ou Learning Contents) aussi réutilisables que
possible [Rengarajan, 01]
Figure 1. Le rôle du LMS et du LCMS dans la diffusion de contenus éducatifs

pour le Web [Benayache, 05]
1
SCORM (Sharable Content Object Reference Model).
Le standard en matière de conception de cours et de plates-formes e-Learning (LMS).
Un cours respectant SCORM sera Réutilisable, accessible, interopérable, durable.
6
4.3 Comparaison entre LMS et LCMS
Les fonctionnalités des LMS et des LCMS sont complémentaires bien qu’elles se
recoupent sur certains points (figure 2) :
• les LMS permettent de créer du contenu, mais de façon souvent limitée.
• les LCMS permettent en théorie de diffuser des contenus de façon plus complète que les
LMS (personnalisation dynamique), mais cette fonctionnalité n’est pas toujours applicable ;
de plus, si certains LCMS intègrent des fonctions de reporting, cela reste assez rare.
Figure 2. Couvertures fonctionnelles des LMS et des LCMS [LMS, 03]
7
5. Les acteurs d’une plateforme

On distingue trois profils d’utilisateurs d’une plateforme : l’apprenant, le formateur, et
l’administrateur.
5.1. Le formateur
- crée des parcours pédagogiques types et individualisés de son enseignement.
- incorpore des ressources pédagogiques multimédias.
- suit les activités des apprenants.
5.2. L’apprenant
- consulte en ligne ou télécharge les contenus pédagogiques qui lui sont recommandés
- organise et a une vue de l’évolution de son travail
- effectue des exercices, s’auto évalue et transmet des travaux à corriger
Formateurs et apprenants communiquent individuellement ou en groupe, créent des thèmes de

discussion et peuvent dans certains cas collaborer à des documents communs [Luana, 08].
5.3. L’administrateur
L’administrateur, de son côté, assure l’installation et la maintenance du système, gère

les droits d’accès, crée des liens vers d’autres systèmes et ressources externes.
Ainsi, une plateforme peut comporter des fonctionnalités relatives à la gestion des
compétences, à la gestion des ressources pédagogiques, à la gestion de la qualité de la
formation, etc. [Benayache, 05]
8
6. Profil utilisateur
Un processus d’accès personnalisé à l’information a pour objectif de délivrer à
l’utilisateur une information pertinente et appropriée à ses préférences, ses centres d’intérêts
ou plus globalement son profil.
6.1. Définition
« Un profil utilisateur peut être défini comme un ensemble de préférences

caractérisant le centre d'intérêt de l'utilisateur, les modes de production, d'affichage ou
d'ordonnancement des résultats de ses requêtes, son niveau de sécurité ou de confidentialité,
la qualité de l'information désirée et le poids relatif des unes par rapport aux autres de ses
préférences »[URL, 2]
6.2 Le contenu du profil utilisateur
On peut représenter le profil utilisateur sur deux dimensions, la première présente le

centre d’intérêt de l’utilisateur à long terme (La dimension du profil persistant), La deuxième
(La dimension du profil évolutif), présente le centre d’intérêt utilisateur à court terme.
La dimension du profil persistant contient :
- Les données personnelles : définissent l’identité de l’utilisateur (Code, Nom, Prénom, âge).
- Le domaine : un ensemble de termes qui définissent le domaine de l’utilisateur.
- Les pages Web visitées par l’utilisateur.
- Les rapports rédigés par l’utilisateur.
- Les documents jugés pertinents pour chaque serveur.
- Liste des serveurs sélectionnés.
La dimension du profil évolutif contient :
- Le centre d’intérêt à court terme : contient les documents jugés pertinents au moment de la
consultation des résultats de recherche.
9
Le profil persistant est exploité dans le processus de sélection de serveurs. Le profil évolutif
consiste à affiner la requête utilisateur, pour construire une requête plus représentative aux
besoins de l’utilisateur à court terme, avec moins d’effort de ce dernier. La requête affinée
(reformulée) sera utilisée dans le processus de recherche et dans le processus de fusion des
résultats.
Ces données sur l'utilisateur peuvent être décrites à l’aide de modèles standards.
On cite les standards: Personnel and Private Information Standard (PAPI) et Instructional
Management Systems (IMS), qui traitent de plusieurs catégories relatives à l'information sur
un apprenant.
6.2.1. Le modèle PAPI

PAPI (Public And Private Information for Learners) est un standard développé au sein
du groupe Learner Model Working Group. Il s’est donné comme objectif de spécifier la
sémantique et la syntaxe des informations sur l’apprenant. Ces informations peuvent être de
diverses natures : acquisition de connaissances, préférences de l’apprenant, ses performances
et ses compétences, ses relations avec d’autres apprenants, etc. [PAPI 01]
Figure 3. Représentation de la proposition de standard PAPI Learner
10
Le profil d’apprenant PAPI comprend donc les éléments suivants :
informations personnelles sur l’apprenant (PAPI Learner Personal).
informations relationnelles, relatives aux relations entretenues par l’apprenant avec

les autres utilisateurs - professeurs, autres étudiants, etc. (PAPI Learner Relations).
informations sur la sécurité : Mot de passe, clés, etc. (PAPI Learner Security)
informations sur la performance de l’apprenant (PAPI Learner Performance)
informations « portfolio » qui constituent une collection représentative de travaux

de l’apprenant utilisées en tant qu’illustrations de ses capacités
informations liées aux préférences de l’apprenant destinées à améliorer

l’interaction homme-machine et à permettre l’adaptation automatique des systèmes
aux besoins spécifiques de l’apprenant. Les préférences incluent des
caractéristiques techniques, liées à l’interface, ou à la présentation des contenus.
Ces préférences peuvent être explicitement identifiées par l’utilisateur ou être
inférées à partir de son comportement.
6.2.2. Instructional Management Systems (IMS)
IMS est un consortium récent (1997), qui représente un regroupement de 250

établissements éducatifs dont le MIT (Massachusetts Institute of Technology) et UCM
(Université Carnegie Mellon), d’entreprises telles que Apple et IBM, d’agences
gouvernementales telles qu’Industrie Canada et des sociétés de développement telles que
Canvas Learning et Blackboard.
La standardisation recherchée par le consortium IMS concerne les domaines suivants :
- L’enregistrement des informations sur les apprenants.
- L’échange des données pour les systèmes d’administration.
- La description des matériaux pédagogiques, afin de faciliter la publication et la recherche sur

le Web.
- L’interopérabilité des matériaux entre eux.
11
- L’interopérabilité des plateformes avec les matériaux et le système d’information des

organisations.
IMS a permis d’établir un ensemble de spécifications pour structurer un contenu pédagogique,

modéliser un étudiant, ou modéliser à un niveau général comment décrire, référencer et
changer des connaissances, des compétences, des tâches ou des qualifications. Les différents
groupes de travail appartenant au consortium approfondissent de multiples aspects liés à la
formation en ligne :
- Compétences professionnelles,
- Gestion des contenus,
- Définition des profils d’apprenants,
- Ingénierie pédagogique,
- Accessibilité (pour les handicapés, etc.),
- Bibliothèques virtuelles. [Benayache, 05]
6.2.2. 1. Le modèle IMS LIP
Le modèle IMS LIP, qui désigne IMS Learner Information Package, définit une
structure XML pour l'échange des données apprenant entre systèmes coopérants tels que : les
systèmes de gestion d'apprentissage, les systèmes des ressources humaines, les systèmes de
gestion des données des apprenants, les systèmes de gestion des connaissances, et d'autres
systèmes utilisant les processus d'apprentissage.
Il représente un modèle de données qui permet de décrire les caractéristiques nécessaires d'un
utilisateur pour des usages généraux tels que :
- Enregistrement et gestion de l'historique de l'apprentissage de l'apprenant.
- Engagement de l'apprenant dans une expérience d'apprentissage.
- Découverte des opportunités d'apprentissage de l'apprenant.
12
Ci-dessous sont présentées en bref les onze catégories du modèle IMS LIP.
Dans ces définitions, le terme «Personne» représente un apprenant, un organisme ou autre

utilisateur de système d’e-formation.
1. Identification : Cette catégorie contient des éléments qui aident à identifier la personne tels
que son nom, son adresse, son email, etc.
2. Accessibility : Cette catégorie permet de décrire les préférences de la personne, ses

langues, et ses éventuels handicaps.
3. QCL : Cette catégorie permet de décrire les qualifications, les certifications et les diplômes
attribués à une personne.
4. Activity : Cette catégorie regroupe les données sur les activités liées au travail et à la
formation d’une personne.
5. Goal : Cette catégorie contient les données sur les objectifs des personnes.
6. Competency : Cette catégorie décrit les compétences associées avec la formation formelle
ou informelle d’une personne et son expérience de travail.
7. Interest : Cette catégorie regroupe les données sur les hobbies et les activités créatrices
d’une personne.
8. Transcript : Cette catégorie permet de décrire les données sur les bulletins de notes de la
personne.
9. Affiliation : Cette catégorie inclut les informations sur la description de l’organisation

associée à la personne.
10. Securitykey : Cette catégorie regroupe les données de sécurité d’une personne, tels que
les mots de passe et les codes de sécurité qui doivent être utilisés durant ses communications.
Pour chaque clé de sécurité une structure différente sera utilisée.
11. Relationship : Cette catégorie permet de décrire les relations entre les structures de
données utilisées pour stocker les données de la personne employée dans ce modèle
[Oubahssi, 05]
13
6.2.2.2. IMS ePortfolio
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. Quand une activité
pédagogique est réalisée par un apprenant, cette information peut être ajoutée de façon
automatique à son ePortfolio. Il en est de même quand il réalise un travail, ce dernier sera
stocké dans son ePortfolio. Que ce soit avec la spécification LIP ou ePortfolio [Paquette,
02]
6.2.3. Synthèse :
PAPI et IMS LIP forment une des premières bases de structuration des données
participant (ou utilisateur) qui peuvent être échangées entre les différents systèmes de e-
formation.
En effet, les six catégories du modèle PAPI forment l’une des premières spécifications
d’échange des données participant, mais ses éléments ne sont pas suffisamment complets pour
couvrir toutes les données apprenant qui peuvent être échangées entre les systèmes d’e-
formation. Les éléments de ce modèle restent une description générale de l’apprenant. Ces
spécifications ont été développées ensuite par IMS pour donner une version améliorée sous le
nom d’IMS LIP, Dans ce modèle beaucoup d’améliorations ont été apportées au modèle
PAPI, on retrouve les activités pédagogiques liées à l’apprenant.
Par la suite, IMS étend son LIP pour donner l’IMS ePortfolio, qui peut spécifier plus
d’informations sur les apprenants et donne plus de flexibilité d’échange d’informations.
14
7. Conclusion
Le principe derrière le e-Learning est de remplacer les anciennes façons
temps/place/contenu de l’apprentissage prédéterminé avec des processus d’apprentissage
rapides/ouverts/personnalisés.
Les enjeux du e-Learning s’inscrivent dans une perspective d’amélioration du

processus d’apprentissage et d’accès à la connaissance, de rationalisation des coûts de
fonctionnement de l’organisation et d’augmentation de la flexibilité d’accès à l’apprentissage
grâce à des parcours adaptés aux besoins de chacun avec des concepts comme l’autonomie et
la personnalisation.
Une plateforme E-Learning peut être considérée comme un ensemble de Web services,
qui constituent une infrastructure technologique distribuée faite pour assembler des systèmes
hétérogènes en un seul et même modèle logique à travers un réseau et qui coopèrent entre eux
pour fournir certaines fonctionnalités aux acteurs de la plateforme.
Nous présentons les Web services plus en détail dans le chapitre qui suit.
15
Chapitre II
Les Web Services

Chapitre II Les web services
Introduction
Avec l'essor du Web qui a eu dans les dernières années, il a surgi le besoin de permettre
qu'une application client invoque un service d'une application serveur en utilisant Internet. Ce
besoin a été l'origine de ce qui se connaît comme services Web. En tenant en compte que les
services Web permettent de connecter des applications différentes.
Leur objectif principal est de faciliter l'accès aux applications entre entreprises et ainsi de
simplifier les échanges de données. Ils poursuivent un vieux rêve de l'informatique distribuée où
les applications pourraient interopérer à travers le réseau, indépendamment de leur plateforme et
de leur langage d'implémentation. Pour ces raisons les activités de recherche et de
développement autour de ce sujet ont un dynamisme très haut.
Dans ce chapitre on décrira en première partie les technologies plus liés aux services Web,
ensuite on expliquera la notion du Web sémantique dans la deuxième partie et enfin dans la
troisième partie on parlera des services Web sémantiques.
16
I. Web Service
Les Web services servent à transformer le Web en un dispositif distribué où les
programmes (services) peuvent interagir de manière intelligente en étant capables de se découvrir
automatiquement, de négocier entre eux et de se composer en des services plus complexes. En
d’autres termes, l’idée poursuivie avec les Web services, est de mieux exploiter les technologies
de l’Internet en substituant, autant que possible, les humains qui réalisent actuellement un certain
nombre de services (ou tâches), par des machines en vue de permettre une découverte et/ou une
composition automatique de services sur l’Internet.
1. Définition d’un Service Web

Le groupe de W3C (World Wide Web Consortium), qui travaille sur les services Web a
utilisé dans un document appelé «Web Services Architecture» la définition de service Web
suivante
« Un service Web est un système logiciel destiné à supporter l’interaction ordinateur–ordinateur

sur le réseau. Il a une interface décrite en un format traitable par l’ordinateur (e.g. WSDL).
Autres systèmes réagissent réciproquement avec le service Web d’une façon prescrite par sa
description en utilisant des messages SOAP, typiquement transmis avec le protocole http et une
sérialisation XML, en conjonction avec d'autres standards relatifs au Web » [w3c, 04]
2. Architecture des Web Services

Les efforts de recherche et de développement récents autour des Web services ont conduit
à un certain nombre de spécifications qui définissent aujourd’hui l’architecture de référence des
Web services. Cette architecture vise trois objectifs importants [URL, 3]: (i) identification des
composants fonctionnels, (ii) définition des relations entre ces composants et (iii) établissement
d’un ensemble de contraintes sur chaque composant de manière à garantir les propriétés globales
de l’architecture.
L’architecture de référence des Web services (voir figure 4) s’articule autour des trois rôles
suivants :
17
• Le fournisseur de service : correspond au propriétaire du service. D’un point de vue technique,

il est constitué par la plateforme d’accueil du service.
• Le client : correspond au demandeur de service. D’un point de vue technique, il est constitué
par l’application qui va rechercher et invoquer un service. L’application cliente peut être elle-
même un Web service.
• L’annuaire des services : correspond à un registre de descriptions de services offrant des

facilités de publication de services à l’intention des fournisseurs ainsi que des facilités de
recherche de services à l’intention des clients.
Figure 4. Architecture des Web services.
Le fournisseur de services définit la description de son service et la publie dans un annuaire de

service.
Le client utilise les facilités de recherche disponibles au niveau de l’annuaire pour retrouver et
sélectionner un service donné. Il examine ensuite la description du service sélectionné pour
récupérer les informations nécessaires lui permettant de se connecter au fournisseur du service et
d’interagir avec l’implémentation du service considéré.
18
Pour garantir l’interopérabilité des trois opérations précédentes (publication, recherche et lien),
des propositions de standards ont été élaborées pour chaque type d’interactions. Nous citons,
notamment les standards émergents suivants :
• SOAP définit un protocole de transmission de messages basé sur XML.
• WSDL introduit une grammaire commune pour la description des services.
• UDDI fournit l’infrastructure de base pour la publication et la découverte des services.
Toutes ces technologies sont disposées en couches et constituent l'architecture services Web
comme l’illustre ce schéma :
Figure 5. Couches technologiques des services Web.
Les couches XML et SOAP sont les couches de plus bas niveau, elles permettent le transport de
l'information. XSD et WSDL permettent de décrire le service aux utilisateurs externes. Enfin la
couche la plus haute UDDI décrit ce qu'est capable de faire le service, c'est la couche la plus
sémantique [Hermes, 05]
19
3. Le XML et les trois standards SOAP, WSDL et UDDI

3.1. XML
Le XML (eXtensible Markup Language) est le fondement des standards des Web services.
Ce format permet de dissocier l’information de la présentation. Il permet d’échanger des
messages simples ce qui va s’avérer très pratique pour les Web services.
Promulgué en 1998 par le W3C, on retrouve dans XML une généralisation des idées contenues
dans HTML (HyperText Markup Language).
XML a été conçu pour des documents complexes, en s’appuyant sur 5 grands principes :
• Lisibilité par les machines et les utilisateurs

• Définition sans ambiguïté du contenu d’un document
• Définition sans ambiguïté de la structure d’un document
• Séparation entre documents et relations entre documents
• Séparation entre structure du document et présentation du document
Le format XML a été conçu pour permettre le déchiffrement direct par l’utilisateur comme par
les programmes.
Le contenu d’un document est décrit par une succession d’éléments (blocs de texte encadrés par
de paires de balises ouvrantes et fermantes) qui sont les unités de contenu. Ces éléments sont liés
entre eux par une hiérarchie, certains éléments apparaissent imbriqués dans d’autres.
Voici un simple exemple pour illustrer la structure XML
<?xml version=' 1.0' encoding="ISO-8859- 1"?>

<catalogue>
<stage id="XMLpres">
<intitule>XML et les bases de données</intitule>
<prerequis> connaître les langages SQL et HTML</prerequis>
</stage>
</catalogue>
20
3.2. SOAP (Simple Object Access Protocol)

SOAP est un protocole pour l’échange d’information dans un environnement reparti, basé
sur le standard XML. Ce protocole consiste en trois parties : une enveloppe qui définit un canevas
pour décrire le contenu du message et comment le traiter, un jeu de règles de codage à exprimer
les cas de types de données défini par l’application et une convention pour représenter des appels
de procédure éloignés et ses réponses [SOAP, 04]
SOAP n’est pas lié à aucun système d’exploitation ni langage de programmation. Il est
indépendant du langage d’implémentation des applications client et serveur. En plus, il peut
potentiellement être utilisé avec une variété de protocoles (eg. HTTP, HTTP Extension
Framework).
3.2.1 La structure de message SOAP

La figure suivante illustre les éléments principaux d’un message SOAP :
Figure 6. Schéma d’un message SOAP [Rampacek, 06]
21
3.2.1.1 L’en-tête du protocole de transport: Cette partie dépend du protocole de

transport utilisé. Par exemple, si le protocole HTTP est utilisé, cet en-tête contient :
– la version de HTTP utilisée,
– la date de génération de la page,
– le type d’encodage du contenu, etc.
3.2.1.2 Les messages SOAP (l’enveloppe) : l’enveloppe est subdivisée en deux sous-
parties : la partie en-tête et la partie corps du message. Elle permet également de spécifier des
environnements de noms XML utilisés dans la suite du message.
3.2.1.2.1 L’en-tête du message SOAP: L’en-tête SOAP (SOAP Header) est optionnel et
extensible.
Les balises XML permettant de symboliser cette partie sont <env:Header> et </env:Header>.
Ces balises peuvent être complétées par des attributs permettant de définir le domaine de noms du
service Web.
3.2.1.2.2 Le corps du message SOAP: Les données spécifiques à l’application se trouvent
dans le corps du message SOAP (SOAP Body). Tout ce qui est présent dans cette section est
défini lors de la conception de l’application. Enfin, les balises symbolisant cette partie sont
<env:Body> et </env:Body>.
3.3. Description WSDL (Web Services Description Language)

La spécification WSDL joue un rôle important dans l’interopérabilité des composants
services Web. Moyennant un schéma uniforme obéissant à une sémantique bien définie (figure
7), elle permet aux composants de définir ce qui est nécessaire à leur invocation. La spécification
WSDL est définie selon une sémantique totalement indépendante du modèle de programmation
de l’application.
Elle sépare clairement la définition abstraite du service (échange de messages) de ses mécanismes
de liaison (définition des protocoles applicatifs). Cette dernière caractéristique permet aux
composants d’interagir même si l’application a été modifiée, ce qui est un point important pour
assurer l’interopérabilité des services.
22
Un document WSDL utilise les éléments suivants dans la définition des services Web :
Figure 7. Architecture WSDL [Guitton, 06]
• Types un conteneur pour les définitions de types de données à l'aide d'un système de
types (tel que XSD).
• Message une définition de type, abstraite, des données transmises.
• Operation une description abstraite d'une action supportée par le service.
• Port Type série abstraite d'opérations supportées par un ou plusieurs points finaux.
• Binding une spécification concrète relative au protocole et au format de données pour un

type de port particulier.
• Port un point final unique défini comme une combinaison d'une liaison et d’une adresse
réseau.
• Service une série de points réseau.
WSDL définit un mécanisme commun de liaison. Il est utilisé pour attacher un protocole, ou un
format de données, ou une structure spécifique à un message, une opération, ou un point abstrait.
Il permet de réutiliser les définitions abstraites.
23
Voici un exemple de fichier wsdl de la fonction int foo(int arg)du langage C :
<?xml version="1.0" encoding="UTF-8" ?>

<definitions name="FooSample"
targetNamespace="http://tempuri.org/wsdl/"
xmlns:wsdlns="http://tempuri.org/wsdl/"
xmlns:typens="http://tempuri.org/xsd"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:stk="http://schemas.microsoft.com/soap-toolkit/wsdl-extension"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types><schema targetNamespace="http://tempuri.org/xsd"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
elementFormDefault="qualified" ></schema></types>
<message name="Simple.foo">
<part name="arg" type="xsd:int"/> </message>
<message name="Simple.fooResponse">
<part name="result" type="xsd:int"/></message>
<portType name="SimplePortType">
<operation name="foo" parameterOrder="arg" >
<input message="wsdlns:Simple.foo"/>
<output message="wsdlns:Simple.fooResponse"/></operation>
</portType>
<binding name="SimpleBinding" type="wsdlns:SimplePortType">
<stk:binding preferredEncoding="UTF-8" />
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="foo">
<soap:operation
soapAction="http://tempuri.org/action/Simple.foo"/>
<input>
<soap:body use="encoded" namespace="http://tempuri.org/message/"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" /></input>
<output>
<soap:body use="encoded" namespace="http://tempuri.org/message/"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />
</output>
</operation>
</binding>
<service name="FOOSAMPLEService">
<port name="SimplePort" binding="wsdlns:SimpleBinding">
<soap:addresslocation="http://carlos:8080/FooSample/FooSample.asp"/>
</port>
</service>
</definitions>
24
3.4. Référentiel UDDI (Universal Description, Discovery and

Integration)
Dans un environnement ouvert comme Internet, la description d’un service Web n’est
d’aucune utilité s’il n’existe pas de moyen de localiser aussi bien les services Web que leurs
descriptions WSDL : c’est le rôle des référentiels UDDI.
La spécification UDDI constitue une norme pour les annuaires de services Web. Les
fournisseurs disposent d’un schéma de description permettant de publier des données concernant
leurs activités, la liste des services qu’ils offrent et les détails techniques de chaque service. La
spécification offre également une API (Application Programming Interface) aux applications
clientes, pour consulter et extraire des données concernant un service et/ou son fournisseur.
3.4.1. Définition UDDI
UDDI est une spécification en langage XML d'un catalogue des services offerts par les
entreprises sur leurs sites Web. Le catalogue comprend les adresses et les contacts des
entreprises, une classification sectorielle et une description des services proposés. UDDI fournit
différentes manières de recherche à travers les pages jaunes, vertes et blanches, il est facile à
interroger sur Internet mais n’impose pas de contraintes sur la description de services que doivent
introduire les fournisseurs de ces derniers pour publier leurs services. [Chauvet, 02]
Les données capturées dans l’UDDI sont divisées en trois catégories :
Figure 8. Structure UDDI
25
pages blanches (White Pages) : elles regroupent les informations sur les noms des
entreprises publiant leurs services Web, les moyens de les contacter, etc.
pages jaunes (Yellow Pages) : elles regroupent les informations à propos des standards de
classification des entreprises.
pages vertes (Green Pages) : elles contiennent des informations techniques comme les
services offerts par une entreprise, leur spécification, etc.
3.4.2. Les différents rôles d’UDDI
UDDI fournit trois services de bases :
Publish : ce service gère comment le fournisseur de service Web s’enregistre lui-même
ainsi que ses services (en utilisant UDDI).
Find : ce service gère comment un client peut localiser le service Web désiré (cela peut
passer par des invocations de services Web pour une utilisation automatique par un
programme ou par une consultation d’annuaire en utilisant des mots clés).
Bind : ce service gère également comment un client peut se connecter et utiliser le service
Web une fois celui-ci localisé.
Les entreprises qui fournissent ce service et hébergent un annuaire global UDDI sont appelées
des opérateurs UDDI. Ils sont responsables de la synchronisation de l’information des annuaires :
cette synchronisation d’annuaires s’appelle la réplication.
Il existe de nombreux annuaires UDDI dont les principaux sont :
• celui de Microsoft : http://uddi.microsoft.com
• celui d’IBM : http://uddi.ibm.com
Un des enjeux de UDDI est d’éviter le monopole d’une entreprise qui, par un annuaire
quelconque, donnerait comme réponse systématiquement ses services Web plutôt que celle des
autres : ce genre de pratique étant fortement limité car les annuaires UDDI se doivent d’avoir un
contenu identique aux autres annuaires. Ainsi, il permet de donner des solutions industriellement
viables pour la localisation de services Web.
3.4.3. Le modèle de données UDDI
UDDI est un modèle d’information composé de structures de données persistantes
appelées entités. Ces entités doivent être décrites en XML et sont stockées dans les différents
nœuds UDDI.
26
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 for
Descriptive information about
services.
a particular web services
<bindingTemplate>
Technical information about

service entry point and
construction specification
Figure 9. Modèle de données de l’annuaire UDDI. [Rahee, 05]

businessEntity : cette entité décrit l’entreprise (également appelée fournisseur) qui permet
d’accéder aux services Web qu’elle publie : cette entité permet de regrouper toutes les
informations concernant le nom, les contacts de l’entreprise. Chaque enregistrement est associé à
une clé unique appelée UUID (Universal Unique Identifier). Ce sont les éléments accessibles par
l’annuaire pages blanches.
businessService : cette entité représente une classification des services. Elle est contenue dans
l’entité businessEntity décrite précédemment, et elle contient une clé unique identifiant un service
particulier. Ce sont les éléments accessibles par l’annuaire pages jaunes.
27
bindingTemplate : cette entité est utilisée pour les détails techniques des services Web. Elle
contient des informations sur le point d’accès du service (l’adresse du service). Ce sont les
éléments accessibles par l’annuaire pages vertes.
tModel : cette entité permet de stocker les informations spécifiques aux services, comme le
comportement, les conventions de typages et les types eux-mêmes utilisés par les services. Elle
regroupe donc les informations contenues dans les fichiers WSDL.
publisherAssertion : assertions contractuelles entre partenaires dans le cadre des échanges
d’exécution d’un service.
Voici une capture d'écran de la page Business_Search.aspx. Une recherche a été faite sur le
répertoire UDDI de Microsoft pour toutes les entreprises commençant par la lettre "M".
L'identificateur unique pour une entreprise est appelé un "Business Key".
Figure 10. Capture d'écran de la page Business_Search.aspx
28
4. Applications des services Web

Les services Web sont un formidable outil pour créer des applications distribuées; comme
ils sont composés de XML et de SOAP, ils s'appliquent par nature à de multiples plateformes,
citons par exemple : la finance, domaine médicale, la télécommunication, le e-commerce, l’e-
Learning,…etc. Dans notre cas on s’intéresse au domaine du e-Learning.
4.1. Application e-Learning

La fonction principale des plateformes e-Learning (e-formation) est de fournir à
l'apprenant les bonnes activités avec les bons outils au bon moment en fonction de ses besoins.
Cela nécessite l'application de mécanismes d'animation et de coordination des modules et des
activités pédagogiques. Si un système e-Learning est une collection d'activités ou de processus,
nous pouvons découper ses fonctionnalités 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 e-services,
en utilisant la technologie des services Web.
Exemple du projet XESOP (Environnement XML sémantique pour la création et la diffusion
via le Web des objets pédagogiques)
L’approche de ce projet est fondée sur la conviction qu'un système e-Learning est une
collection d'activités ou de processus qui ont un effet d’une part sur les étudiants et d’autre part
sur le contenu pédagogique convenablement choisi sous forme d’objets pédagogiques (Learning
Objects). Ainsi les fonctionnalités de base d'un système e-Learning peuvent être découpées en un
certain nombre de fonctions, qui peuvent alors être implantées séparément sous la forme des
services Web. La mise à disposition de ces services permet la réutilisation du contenu et des
fonctionnalités dans une plateforme e-Learning.
Le projet XESOP propose une étude et des solutions sur les moyens technologiques des
environnements e-Learning. Ses éléments essentiels comprennent, d’une part, des supports
sémantiques pour la création, la présentation et le stockage des objets pédagogiques basés sur des
technologies XML et d’autre part, des moyens pour la gestion du parcours de l’étudiant et
l’exécution d’exercices à distance.
Dans ce projet, l’évolution des travaux est guidée par une perception d’un système e-
Learning, à savoir, une collection d'activités ou de processus. Ces processus peuvent être
décomposés d’abord en éléments autonomes et par la suite réalisés et proposés comme des
29
Services Web à savoir :la conception d’un contenu pédagogique, la publication d’un cours à
partir d’un contenu choisi, la gestion des objets pédagogiques, la mise à jour d’un contenu
pédagogique, l’adaptation d’un contenu à la demande, la recherche et présentation d’un contenu
pédagogique, l’inscription d’un étudiant et gestion de son compte et profil, l’évaluation des
connaissances acquises, mise en place et gestion d’une classe virtuelle, gestion d’un système de
communication synchronisé de type chat…
La publication et la recherche des objets pédagogiques peuvent se faire dans un cadre UDDI
faisant partie de l’architecture des services Web. Ses caractéristiques assurent le stockage de
données concernant la description des objets pédagogiques.
Figure 11. Les activités e-Learning comme services Web [Madjarov, 05]
En utilisant un tel schéma fonctionnel, le contenu pédagogique serait publié et organisé pour être
échangé, et serait accessible dans un environnement fondé sur des services Web
30
5. Conclusion
En quelques mois, les Web Services sont devenus le nouveau point de convergence
technologique de l'ensemble des acteurs du marché de l'informatique, grâce à la disponibilité
immédiate d’outils et de standards permettant l’invocation automatisée des fonctions métiers via
un échange de messages informatisés (SOAP, UDDI, WSDL). Cependant ces mêmes standards,
largement utilisés actuellement, ne permettent de décrire les fonctionnalités des Web Services
que de manière syntaxique. En effet le Web actuel est essentiellement syntaxique, dans le sens
que la structure de documents (ou ressources au sens large) est bien définie, mais que son contenu
reste quasi inaccessible aux traitements machines. Seuls les humains peuvent interpréter leurs
contenus. La nouvelle génération de Web dite Web sémantique a pour ambition de lever cette
difficulté. Les ressources du Web seront plus aisément accessibles aussi bien par l’homme que
par la machine, grâce à la représentation sémantique de leurs contenus.
31
II. Web sémantique

Depuis le début des années 2000, de nombreux axes de recherches concernant
Internet se sont tournés vers le Web sémantique. Internet est un immense réservoir de documents
en tout genre (articles, sites personnels, audio, vidéos) mais plus ces ressources s’accumulent,
plus la recherche d’une information précise s’avère difficile.
Tim Berners-Lee, pionnier dans le domaine d’Internet, propose alors d’ajouter à toutes ces
ressources une sémantique qui permettrait aux systèmes informatiques d’en « comprendre » le
sens en accédant à des collections structurées d’informations et à des règles d’inférence qui
peuvent être utilisées pour conduire des raisonnements automatisés : c’est la naissance du Web
sémantique.
1. Définition
L'expression Web sémantique, attribuée à Tim Berners-Lee au sein du W3C, fait d’abord
référence à la vision du Web de demain comme un vaste espace d’échange de ressources entre
êtres humains et machines permettant une exploitation, qualitativement supérieure, de grands
volumes d’informations et de services variés.
Le Web sémantique, concrètement, est d’abord une infrastructure pour permettre
l’utilisation de connaissances formalisées en plus du contenu informel actuel du Web, même si
aucun consensus n’existe sur jusqu’où cette formalisation doit aller. Cette infrastructure doit
permettre d’abord de localiser, d’identifier et de transformer des ressources de manière robuste et
saine tout en renforçant l’esprit d’ouverture du Web avec sa diversité d’utilisateurs. Elle doit
s’appuyer sur un certain niveau de consensus portant, par exemple, sur les langages de
représentation ou sur les ontologies (sera expliquée plus loin dans ce chapitre) utilisées. Elle doit
contribuer à assurer, le plus automatiquement possible, l’interopérabilité et les transformations
entre les différents formalismes et les différentes ontologies. Elle doit faciliter la mise en œuvre
de calculs et de raisonnements complexes tout en offrant des garanties supérieures sur leur
validité. Elle doit offrir des mécanismes de protection (droits d’accès, d’utilisation et de
reproduction), ainsi que des mécanismes permettant de qualifier les connaissances afin
d’augmenter le niveau de confiance des utilisateurs.
32
2. Les langages pour le Web sémantique

Il a été bien reconnu dans la communauté du Web Sémantique que les ontologies jouent
un rôle clé dans la livraison du Web Sémantique en facilitant le partage d’information entre les
communautés des humains et des agents logiciels. Cependant, le manque de sémantique dans les
schémas XML ne permet pas aux personnes de créer de nouveaux vocabulaires (Le même terme
peut être utilisé avec différents sens dans différents contextes et des termes différents peuvent
être utilisés pour des articles ayant le même sens).
RDF et RDF Schema ont essayé de résoudre ce problème en permettant d’associer des
sémantiques simples. Avec RDF Schema, une personne peut définir des classes qui ayant
plusieurs sous-classes et super classes, et peut aussi définir des propriétés pouvant avoir des sous
propriétés, de domaines ou d’intervalles. Dans ce sens RDF Schema est un langage d’ontologie
pour le Web primitif. Pour atteindre l’interopérabilité entre les divers schémas développés de
façon autonome, des sémantiques plus riches sont nécessaires.
La proposition du W3C s’appuie au départ sur une pyramide de langages dont seulement les
couches basses sont aujourd’hui relativement stabilisées. La figure 12 montre une des versions
de l’organisation en couches proposée par le W3C
Figure 12. Les couches du Web Sémantique [Boutemedjet, 04]
33
XML : fournit une surface syntaxique pour les documents structurés mais ne fournit aucune
contrainte sémantique sur le sens de ces documents.
XML Schema : est un langage pour restreindre la structure des documents XML et étendre aussi
XML avec des types de données.
RDF : est un modèle de données pour les objets (« ressources ») et les relations entre eux,
fournissant des sémantiques simples pour ce modèle de données qui peuvent être représentées en
XML.
RDF Schema : est un vocabulaire pour décrire les propriétés et les classes des ressources RDF.
OWL : ajoute plus de vocabulaire pour décrire les propriétés et les classes entre autres, les
relations entre les classes, cardinalité, égalité, typage de propriétés plus riche, caractéristiques des
propriétés et les hiérarchies des propriétés et des classes.
Nous allons présenter plus en détail les langages RDF et OWL.
2.1. RDF (Resource Description Framework)

RDF est un langage d’assertions destiné à exprimer les propositions en utilisant des
vocabulaires formels et précis, plus spécialement ceux exprimés en RDFS, pour accéder et
utiliser le World Wide Web et il est destiné pour fournir les fondations de base pour les autres
langages d’assertion avancés ayant les mêmes objectifs.
Une assertion telle que définie sur le site du W3C est une expression prétendue être vraie et peut
dépendre de plusieurs facteurs incluant les conventions sociales, les commentaires dans un
langage naturel et des liens vers des documents fournissant du contenu (content-bearing
documents). La plupart de ce contenu est inaccessible aux traitements des machines et est
mentionné ici seulement pour envisager que les sémantiques formelles décrites dans le document
de spécification n’ont pas l’intention de fournir une analyse complète du « sens ».
Un document RDF est un ensemble de triplets de la forme <sujet, prédicat, objet>. Les éléments
de ces triplets peuvent être des URIs (Universal Resource Identifiers) [Berners, 00], des littéraux
ou des variables. Cet ensemble de triplet peut être représenté de façon naturelle par un graphe
plus précisément un multi-graphe orienté étiqueté où les éléments apparaissant comme sujet ou
objet sont des sommets, et chaque triplet est représenté par un arc dont l’origine est son sujet et la
34
destination est son objet. Ce document sera codé en machine par un document RDF/XML ou N3,
mais est souvent représenté sous une forme graphique (voir la figure 13).
Figure 13. Exemple de graphe RDF

Vu les nombreuses limitations qui bornent la capacité d'expression des connaissances établies à
l'aide de RDF/RDFS. On peut citer, par exemple, l'impossibilité de raisonner et de mener des
raisonnements automatisés (automated
automated reasoning)
reasoning) sur les modèles de connaissances établis à
l'aide de RDF/RDFS. C'est ce manque que se propose de combler OWL.
2.2. OWL (Web Ontology Language)

Le langage OWL a été conçu pour être utilisé par les applications qui traitent le contenu
de l’information au lieu de la présenter seulement aux êtres humains. OWL facilite grandement
l’interopérabilité au niveau machine du contenu du Web plus que ce qui est déjà supporté par les
XML, RDF et RDF Schema (RDF-S)
S) en fournissant du vocabulaire supplémentaire
supplé avec des
sémantiques formelles. OWL possède des sous-langages
sous langages de plus en plus expressifs OWL Lite,
OWL DL et OWL Full [W3C, 04].
OWL peut être utilisé pour représenter le sens des termes dans des vocabulaires ainsi que les
relations qui existent entre ces termes. Cette représentation des termes et de leurs interrelations
est appelée ontologie [W3C, 04]. OWL est une révision du langa
langage d’ontologie Web
DAML2+OIL3incorporant les leçons apprises de la conception et de l’application de
2
Language, Extension de RDF pour construire des ontologies.
DAML : Darpa Agent Markup Language
3
OIL : Ontology Interchange Language
Language,Équivalent
Équivalent européen de DAML ne reposant pas sur RDF
DAML+OIL :fusion de DAML et OIL,langage de définition des ontologies.
35
DAML+OIL. OWL décrit la structure d’un domaine en terme de classes et de propriétés comme
les approches orientées objets.
Bien qu’OWL soit dérivé de DAML+OIL qui est équivalent à un langage très expressif de la
logique des descriptions. Certaines caractéristiques font qu’il n’existe aucun algorithme
d’inférence décidable avec toute cette puissance d’expression. Par exemple, les propriétés dans
OWL peuvent être déclarées comme symétriques, une classe peut être traitée simultanément
comme une collection d’individus ou comme un seul individu pour son propre compte. OWL
Permet à une ontologie d’augmenter le sens du vocabulaire prédéfini (RDF et OWL). De ce fait
OWL fournit des sous langages de plus en plus expressifs conçus pour faire un compromis entre
son pouvoir expressif et son pouvoir de raisonnement.
1. OWL Lite : Supporte les utilisateurs qui ont besoin des hiérarchies de classifications et
des caractéristiques de contraintes simples. Par exemple, lorsqu’il supporte les contraintes de
cardinalité, il permet seulement les valeurs 0 et 1.
2. OWL DL : Supporte les utilisateurs qui demandent un maximum d’expressivité tout en

maintenant la complétude (garantie de calculer toutes les conclusions) et la décidabilité (tous les
calculs doivent finir en un temps fini). OWL DL contient tout les constructeurs du langage OWL
mais sont utilisables avec des restrictions (par exemple, lorsqu’une classe peut être une sous
classe de plusieurs autre classes, une classe ne peut être une instance d’une autre classe).
3. OWL Full : destiné aux utilisateurs qui demandent un maximum d’expressivité avec la
liberté syntaxique de RDF sans aucune garantie de calculs. Par exemple, une classe peut être
traitée comme une collection d’individus et en même temps peut être vue comme un seul
individu. OWL Full permet aussi à une ontologie d’augmenter le sens du vocabulaire prédéfini
(RDF et OWL).
OWL doit son nom au terme « ontologie », un mot emprunté à la philosophie qui, s'il est
d'origine grecque, ne fut manifestement créé qu'au XVIIe siècle.
36
3. Les ontologies
Les ontologies ont été développées dans le domaine de l'intelligence artificielle pour
faciliter le partage et la réutilisation de connaissances. Elles sont utilisées dans différents
domaines de recherche comme l'ingénierie de connaissances, la représentation de connaissances,
la recherche d'informations, le commerce électronique, le Web sémantique, les services Web, etc.
3.1. Définition
Plusieurs définitions de l'ontologie ont été proposées. Neches et ses collègues [Neches,
91] définissent l'ontologie comme suit : « Une ontologie définit les termes de base (concepts,
entités, attributs, processus, etc.) et les vocabulaires d'un domaine et des relations qui permettent
de définir des extensions des vocabulaires ». Cette définition indique qu'une ontologie inclut non
seulement les termes et les vocabulaires qui sont définis explicitement mais encore les termes qui
peuvent être inférés en utilisant des relations ou des règles.
Thomas Gruber [Gruber, 93] donne la définition suivante : « Une ontologie est une spécification
formelle explicite d'une conceptualisation partagée ». Le terme « conceptualisation » réfère à un
modèle abstrait d'un phénomène dans le monde, en ayant identifié les concepts appropriés à ce
phénomène. La notion « partagée » réfère au fait qu'une ontologie capture la connaissance
consensuelle, c -à-d, non réservée à quelques individus, mais partagée par un groupe.
3.2. Les composants de l'ontologie Une ontologie est constituée de plusieurs

composants comme :
Les concepts : aussi appelés termes ou classes de l'ontologie. Ils correspondent à la
définition des caractéristiques d'un domaine particulier décrit par l'ontologie. Chaque
concept regroupe un ensemble de propriétés et peut contenir d'autres concepts.
Les relations : traduisent les associations existant entre les concepts de l'ontologie. Ces
relations incluent des associations comme : sous-classe-de (héritage), partie-de
(composition), etc. Ces relations permettent de déterminer la structuration et
l'interrelation des concepts, les uns par rapport aux autres.
Les instances des concepts : ce sont les objets qui peuvent être définis dans une
ontologie.
37
Les ontologies peuvent se représenter par des réseaux sémantiques, la figure 14 nous montre un
exemple d'ontologie représentée par un réseau sémantique.
Figure 14. Un exemple d’ontologie.
38
4. Conclusion
Le Web Sémantique est une vision du futur Web dans lequel l’information est donnée un
sens explicite facilitant ainsi aux machines le traitement et l’intégration des informations sur le
Web. Le Web Sémantique sera construit sur la capacité de XML de définir des schémas de
balisage personnalisés et sur la flexibilité de l’approche RDF pour représenter les données. Si
les machines sont supposées faire des tâches de raisonnement utiles sur ces documents, le langage
doit aller au-delà des sémantiques de base du RDF Schema. OWL a été conçu pour répondre à ce
besoin pour un langage d’ontologie pour le Web.
Appliqués aux Services Web, les principes du Web sémantique doivent permettre de
décrire la sémantique de leurs fonctionnalités, et les raisonnements induits constituent par
conséquent une proposition d’automatisation des différentes tâches de leur cycle de vie.
39
Chapitre II les web services
III. Services Web Sémantique

L’idée consiste à faire converger le Web sémantique et les services Web afin de
proposer des services et des procédés qui prennent en compte la connaissance que l’on peut
avoir d’un service ou d’un procédé afin de pouvoir profiter des travaux sur le raisonnement à
partir de connaissances qui ont été mis en avant par le Web sémantique.
1. présentation des services Web sémantique

Le terme Services Web Sémantique est réservé pour l’automatisation des tâches
d’utilisation des services tels que la découverte, la sélection, la composition et l’établissement
des services appropriés. Les Web services sémantiques se situent à la convergence de deux
domaines de recherche importants qui concernent les technologies de l’Internet : le Web
sémantique et les Web services. Cette tâche est accomplie en rendant les services Web auto-
exploitables par machine. De la même façon que le Web sémantique a promis de permettre
aux machines de tirer partie du contenu statique du Web en utilisant des annotations. L’idée
d’appliquer des techniques semblables aux services Web est très intéressante.
Figure 15. Evolution vers les services Web sémantique [Phan, 05]
40
2. Objectifs des services Web sémantique

L’objectif visé par la notion de Web services sémantiques est de créer un Web
sémantique de services dont les propriétés, les capacités, les interfaces et les effets sont décrits
de manière non ambiguë et exploitable par des machines et ce en utilisant les couches
techniques sans pour autant en être conceptuellement dépendants. La sémantique ainsi
exprimée permettra l’automatisation des fonctionnalités suivantes:
• Processus de description et de publication des services
• Découverte des services
• Sélection des services
• Composition des services
• Fourniture et administration des services
2.1. La découverte automatique des services Web

Actuellement cette tâche doit être réalisée par un humain qui doit utiliser un moteur de
recherche ou un annuaire pour trouver le service, lire la page Web qui décrit l’utilité et
l’utilisation du service, puis l’exécuter manuellement pour vérifier que celui-ci correspond
bien aux attentes de l’utilisateur. Le langage DAML-S 4doit donc fournir une description
déclarative des propriétés et des capacités du service Web.
2.2. Invocation automatique de services Web
L’invocation automatique d’un service signifie l’exécution du service par un
programme informatique ou un agent logiciel. Cet agent doit être capable d’interpréter la
description DAML-S afin de délivrer les données nécessaires à l’exécution du service Web.
2.3. Composition automatique de services Web
L’objectif qu’un utilisateur veut atteindre nécessite souvent l’utilisation de plusieurs
services Web. L’agent logiciel chargé d’atteindre cet objectif doit disposer de suffisamment
de données afin de pouvoir sélectionner, composer et interoperer automatiquement ces
services Web. Les descriptions DAML-S et OWL-S doivent donc pouvoir fournir toutes ces
informations.
4
Daml-s va être détaillé plus loin dans ce chapitre.
41
2.4. Surveillance automatique de l’exécution de services Web

Un des problèmes majeurs avec l’exécution des services, du fait de leur nature
distribuée, est que l’utilisateur ne connait pas le temps d’exécution de ces services. Lors de la
composition de plusieurs services, l’utilisateur doit pouvoir connaitre l’état d’avancement de
ses différentes requêtes.
3. une architecture étendue pour les services Web

Différentes extensions de l’architecture de référence ont été proposées dans la
littérature. Le groupe architecture du W3C travaille activement à l’élaboration d’une
architecture étendue standard.
Une architecture étendue est constituée de plusieurs couches se superposant les unes sur les
autres, d’où le nom de pile des Web services. La figure 16 décrit un exemple d’une telle pile.
La pile est constituée de plusieurs couches, chaque couche s’appuyant sur un standard
particulier. On retrouve, au-dessus de la couche de transport, les trois couches formant
l’infrastructure de base décrite précédemment. Ces couches s’appuient sur les standards
émergents SOAP, WSDL et UDDI. Une couche « Business process » est ajoutée permettant
de rendre les business processes accessibles à l’intérieur d’une entreprise et au-delà même des
frontières d’une entreprise. Les couches dites transversales (ex. sécurité, administration,
transactions et qualité de services (QoS)) permettent de compléter la couche business
process.
La couche « semantics » vient s’intégrer à chacune des quatre couches supérieures et
permettent ainsi d’automatiser ses processus.
42
Figure 16. Pile des Web services sémantiques [Toumani, 04]
43
4. DAML-S
DAML-S [Ankolenkar, 02] est un langage de description de services basé sur XML
utilisant le modèle des logiques de descriptions (et plus précisément DAML+OIL). Son
intérêt est qu’il est un langage de haut niveau pour la description et l’invocation des services
Web dans lequel la sémantique est incluse, contrairement par exemple à UDDI, DAML-S est
composé de trois parties principales:
Figure 17. Classes principales de l'ontologie DAML-S [Guitton, 06]
Service Profile qui permet la description, la promotion et la découverte des services,

en décrivant non seulement les services fournis, mais également des préconditions à la
fourniture de ce service, comme « avoir une carte bleue valide » ou « être membre
d’un des pays de l’Union Européenne ». Les recherches sur les services peuvent se
faire en prenant n’importe quel élément de Service Profile comme critère.
Service Model qui présente le fonctionnement du service en décrivant dans le détail et

de manière relativement abstraite les opérations à effectuer pour y accéder. Certains
éléments du Service Model peuvent être utilisés à la manière du Service Profile afin de
fournir des informations supplémentaires à un utilisateur pour qui les opérations à
effectuer seraient également un critère de choix. C’est le Service Model qui va
permettre une composition des services si besoin est. Il permet également d’effectuer
un contrôle poussé du déroulement du service.
44
Service Grounding va présenter clairement et dans le détail la manière d’accéder à un

service. Tout type abstrait déclaré dans le Service Model s’y verra attribuer une
manière non ambiguë d’échanger l’information. C’est dans cette partie que le
protocole et les formats des messages entre autres sont spécifiés.
Pour l’instant, DAML-S est un langage qui est encore en cours de spécification, mais dont les
grandes lignes sont déjà tracées. Un moyen de l’interfacer avec WSDL a été proposé afin de
pallier son absence de gestion d’échange de messages, ce qui permettra par exemple d’utiliser
SOAP pour échanger des messages XML. DAML-S pourra alors être réservé à une
description abstraite et sémantique des services, permettant également d’exprimer des
contraintes sur les paramètres et d’utiliser des constructeurs (comme « si…alors…sinon… »).
DAML-S est une des seules solutions proposant une réelle sémantique des données, et pas
seulement des champs prédestinés par la structure des standards ou par des « feuilles de styles
» utilisées pour décrire les services ; de plus, son utilisation des logiques de descriptions pour
modéliser les services permet une grande puissance d’expression, que ne possèdent pas les
autres systèmes.
4.1. Interaction avec WSDL

DAML-S fournit une spécification de haut niveau, c'est-à-dire au niveau "application".
Cette spécification est intéressante pour la découverte et la composition, mais elle est
insuffisante pour l'invocation d'un service Web. WSDL, quant à lui, fournit une spécification
de plus bas niveau (niveau "interface") qui permet de réaliser l'invocation d'un service. Ces
deux langages paraissent donc complémentaires. C'est pourquoi, certains articles proposent de
réaliser le "grounding" d'un service à l'aide de WSDL.
Effectuer un "grounding" en WSDL nécessite deux étapes. La première consiste à créer une
sous-classe de la classe "Service Grounding" propre à l'usage de WSDL. La seconde étape
nécessite un mécanisme de correspondance entre certains concepts de DAML-S et certains de
WSDL. Il existe trois grandes règles de correspondance :
1. un processus atomique en DAML-S correspond à la notion d'opération de WSDL. Il
existe quatre situations où cette correspondance peut être obtenue. Ces quatre situations sont
résumées à la table 1.
2. DAML-S autorise d'avoir un ensemble d'entrées ou de sorties. Cette notion n'existe pas en
WSDL, c'est pourquoi un ensemble d'entrées ou de sorties sera traduit, en WSDL, par un
message unique.
45
3. la notion de type des entrées et sorties de DAML-S correspond à la notion de type abstrait
de WSDL. Cette correspondance permet la traduction des entrées et des sorties.
Grâce à ces deux étapes, il est aise de créer un "grounding" pour un service
DAML-S en WSDL.
Table 1. Règles de correspondance entre DAML-S et WSDL [Gautier, 04]
46
5. Conclusion
Les services Web sémantiques sont des services Web dotés de descriptions
sémantiques. Cette sémantique est apportée grâce aux ontologies une des technologies
importantes du Web sémantique.
Les Web services sémantiques se situent à la convergence de deux domaines de
recherche importants qui concernent les technologies de l’Internet : le Web sémantique et les
Web services. Le Web sémantique s’intéresse principalement aux informations statiques
disponibles sur le Web et les moyens de les décrire de manière intelligible pour les machines.
Les Web services, quant à eux, ont pour préoccupation première l’interopérabilité entre
applications via le Web en vue de rendre le Web plus dynamique.
47
Conclusion
Les services Web deviennent des composants technologiques importants dans le
domaine d’intégration d’applications, en effet, ils permettent l’interopérabilité entre divers
logiciels fonctionnant sur diverses plateformes telle qu’une plateforme e-Learning.
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’automatisation
de la découverte, ces concepts consistent, pour la plupart de temps, à ajouter de la sémantique
aux Web services. L’objectif est d'exprimer de manière formelle des informations
sémantiques sur les données, pour qu'elles puissent être exploitées par des ordinateurs. Les
ontologies ont un rôle très important à jouer pour la réalisation du Web sémantique. Elles sont
utilisées pour fournir le vocabulaire et la structure de méta données associées aux sources
annotées, c'est une représentation pivot pour l'intégration de sources de données hétérogènes,
pour décrire des services Web.
Aujourd’hui, les Web services sémantiques constituent une voie prometteuse
permettant de mieux exploiter les Web services en automatisant, autant que possible, les
différentes tâches liées au cycle de vie d’un service.
48
Chapitre III
La découverte des Web services

Chapitre III Découverte de web services
1. Introduction
Ce qui rend la notion de service Web si attirante est qu’il semble que les services Web
soient en mesure de permettre une meilleure automatisation dans la gestion des applications,
par exemple en permettant leur découverte dynamique, en facilitant la communication et la
négociation, voire en permettant leur composition en des services plus complexes.
Dans ce contexte, le problème de la découverte dynamique des services Web est le suivant :
en supposant que l’on a un certain nombre de descriptions de services Web (provenant de
fournisseurs divers et concernant par exemple le domaine du tourisme) ainsi qu’une requête
d’un utilisateur (cherchant par exemple un vol et une chambre d’hôtel), comment découvrir
parmi tous les services, ceux qui correspondent le plus à la requête de l’utilisateur ? Et ceci
dynamiquement puisque l’utilisateur ne sait pas a priori quels services il désire obtenir et
puisque l’offre de services peut changer très rapidement (pour une même requête, à des
instants différents, les services découverts ne seront pas toujours les mêmes, ceux-ci pouvant
à tout moment être modifiés, supprimés ou d’autres pouvant être proposés).
2. Les mécanismes de découverte

La découverte des services Web présente un axe de recherche important. Divers
mécanismes de découverte ont été proposés dans la littérature. Les auteurs ont défini le
mécanisme de découverte comme étant « l’acte de localisation d’une description, traitable
par machine, d’un service Web non connu auparavant décrivant certains critères
fonctionnels ».
Actuellement les descriptions des services sont publiées dans des registres spécialement
conçus à cet effet (ex : UDDI). Le but de ces registres est de faciliter la recherche des services
publiés par les différents organismes commerciaux.
Initialement la découverte de service Web était principalement syntaxique (correspondance
syntaxique des mots-clés de la requête avec les descriptions des services Web). Mais avec le
développement des technologies du Web sémantique les techniques proposées pour la
découverte des services Web sont devenues essentiellement sémantiques. En général, les
approches de découverte peuvent être classées en deux catégories :
1. Approches basées sur des descriptions syntaxiques des services Web.
2. Découverte dynamique des services
49
2.1. Approches basées sur des descriptions syntaxiques des

services Web
Le principe général des approches basées sur la syntaxe des descriptions des services
est la comparaison syntaxique entre la requête, basée mots clés, de l’utilisateur et les
descriptions syntaxiques (WSDL) des services Web.
2.1.1. L’approche UDDI
UDDI est un registre de description de services Web. UDDI est utilisé comme registre
central pour la publication et la découverte, basée mots clés, des services Web. A l’étape de
recherche, l’utilisateur ou le programme de recherche envoie une requête constituée de mots
clés, cette requête est ensuite comparée avec les mots clés du registre UDDI. Un ensemble de
descriptions des services Web est ensuite donné comme résultat de recherche, l’utilisateur
sélectionne le service Web qui répond au mieux à ses exigences. Malgré sa simplicité et sa
facilité d’implémentation, elle présente quand même quelques inconvénients, la méthode
renvoie un nombre important de résultats ou au contraire peu de résultats.
2.2. Découverte dynamique des services

On entend par découverte dynamique la possibilité de localiser automatiquement un
Web service qui répond à des besoins particuliers. Différentes approches ont été proposées
dans la littérature pour réaliser la découverte dynamique des services. Toutes ces approches
implantent en fait une découverte approximative car il n’est pas réaliste d’imaginer qu’il y a
toujours un service qui correspond exactement aux besoins spécifiés. Ces approches diffèrent
par le langage de description des services utilisé (e.g., DAML-S, logique de description…)
et/ou par l’algorithme de découverte utilisé (matchmaking, test de subsumption, réécriture).
Par exemple, [Bernstein, 02] propose d’utiliser des ontologies de processus pour décrire le
comportement des services et définit un langage d’interrogation de processus (Process Query
Language) pour interroger ces ontologies. D’autres approches basées sur une description
DAML-OIL des services proposent d’exploiter les mécanismes de raisonnement fournis par
DAML-OIL pour supporter la découverte dynamique des Web services.
50
2.2.1. Approche DAML-S : DAML-S sert de support à de nombreuses tâches :

1. 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.
2. l'invocation de ce service qui permet de réaliser l'appel effectif du service découvert.
3. l'interopération et la composition de services qui autorisent de composer des services plus
simples afin d'obtenir un service complexe qui répond aux attentes d'un demandeur.
4. la surveillance de l'évolution du processus ("Monitoring") qui sert à surveiller l'état
d'accomplissement et de déroulement du service.
Au cœur de l’ontologie décrite par DAML-S, on trouve la classe service qui présente un
"ServiceProfile", qui est décrite par un "ServiceModel" et supporte un "ServiceGrounding".
Le "ServiceProfile" explique ce que fait le service et ce qu'il exige des autres agents, le
"ServiceModel" définit le fonctionnement du "Web Service", le "ServiceGrounding" fournit
les informations nécessaires à ,l'utilisation du "Web Service" et la classe ressource donne des
informations relatives aux ressources utilisées par le "Web Service".
Le "ServiceProfile" sert de support à la découverte de "Web Services" et à leur sélection.
Cette activité est appelée le "matching". Elle consiste, à partir d'un "ServiceProfile"
hypothétique du service désiré par un demandeur, à fournir le "Web Service" du fournisseur
qui propose un "ServiceProfile" qui correspond le plus à la description du demandeur.
[Paolucci, 02] a établi une distinction entre différents degrés de matching:
1. Exact Match: Dans ce cas les sorties, respectivement les entrées du service demandé
étant exactement identiques à celles du service publié.
2. Plug-in Match: Dans ce cas, les propriétés du service demandé sont incluses dans le
service publié.
3. Subsumes Match: Dans ce cas, les propriétés du service publié sont incluses dans le
service demandé.
4. Intersection Match: Dans ce cas, il existe une intersection entre les propriétés du service
demandé et celles du service publié.
5. Disjoint Match: aucune correspondance n’a été trouvée.
La force de matching est décroissante de l’Exact Match vers le Disjoint Match.
Le "ServiceModel" permet de réaliser plusieurs tâches importantes sur les "Web Services".
En effet, après la découverte d'un service grâce à son "ServiceProfile", le "ServiceModel"
permet d'effectuer une analyse plus détaillée par un agent du service afin de déterminer si le
processus répond véritablement aux attentes de cet agent.
51
Le "ServiceGrounding" établit une correspondance entre une spécification abstraite définie

en DAML-S par les "IOPE's" ("Inputs Outputs Preconditions Effects") pour un
"ServiceModel" et une spécification concrète. Cette mise en correspondance permet d'accéder
au service. Le "ServiceGrounding" sert donc de support à l'invocation du service.
2.2.1.1. Les critiques de DAML-S : parmi les limites de DAML-S on cite :
Le " grounding " en WSDL limite l'expressivité de DAML-S. En effet, la définition
d'un grounding a souvent de l'influence sur la façon de décrire le service. De plus, certains
aspects de DAML-S ne peuvent pas être traduits par un "grounding" en WSDL. Ainsi, les
outputs conditionnels de DAML-S ne peuvent pas être traduits en WSDL car celui-ci n'admet
qu'un seul message de sortie pour un processus.
La sémantique offerte par DAML+OIL n'est pas suffisante pour restreindre les interprétations
des modèles à celles voulues.
Certains mécanismes de DAML-S posent des problèmes de réalisation pratique. Ainsi, le
"matching" nécessite un processus très complexe. Cela entraine une perte de performance.
Pour améliorer la performance, il faut alors diminuer la qualité du "matching". Cet aspect est
un dilemme important étant donné que cette activité doit se faire aussi rapidement que
possible et avec un degré de précision le plus élevé possible.
2.2.2. La découverte des services Web selon la qualité de services

La qualité de service ou QoS est « une combinaison de différentes qualités ou
propriétés d’un service » [Menascé, 02]. C’est un ensemble non fonctionnel d’attributs qui
peuvent influencer la qualité de service fournie par un Web service. Quelques exemples
d’attributs de QoS sont donnés ci-dessous :
• La disponibilité : est la probabilité que le système est en place et peut répondre aux
demandes des utilisateurs. Généralement, il est un peu parallèle à la fiabilité et légèrement
différent de la capacité.
• La capacité : est la limite des demandes courantes qu'un service peut traiter. Quand le
nombre de demandes courantes dépasse la capacité d'un service, sa disponibilité et sa
fiabilité diminuent.
• La fiabilité : est la capacité d'un service de remplir ses fonctions requises dans des
conditions indiquées pendant une période spécifique.
• La performance : est la mesure de la vitesse d'accomplir une demande de service. Elle
est mesurée par la latence (le délai entre l'arrivée et l'accomplissement d'une demande de
52
service), débit (le nombre de demandes accomplies pendant le temps) et temps de réponse
(le délai de la demande pour obtenir une réponse du service).
• Le coût : est la mesure du coût de demander un service. Il peut être chargé par nombre de
demandes de service, ou pourrait être un taux forfaitaire facturé pour une période de
temps.
Recherche sur la découverte de services de Web avec QoS
De nombreux chercheurs travaillent sur la façon de prendre en compte des
informations QoS pour les services Web dans le processus de découverte pour trouver les
services qui répondent le mieux aux exigences de client.
[Gouscos et al, 03] proposent une approche simple à la découverte dynamique de services
Web qui modèle des attributs de gestion de services Web tels que la QoS et le prix. Ils
étudient comment ce modèle simple peut être adapté et exploité dans des normes de
spécifications de base telles que WSDL. Les attributs principaux de qualité et de prix de
services Web sont identifiés et classés par catégorie dans deux groupes, statique et
dynamique. Le prix, le temps de réponse de service promis (SRT) et la probabilité d'échec
promise (POF) sont considérés comme statique dans la nature et pourrait être pris en compte
dans le registre UDDI. Les valeurs réelles de QoS qui sont les SRT réels et PoF sont soumises
à des mises à jour dynamiques et pourraient être stockés dans le registre UDDI ou dans le
document WSDL.
3. Quelques travaux de découverte des services Web

sémantiques
On présentera dans ce qui suit trois travaux pertinents de [Rey, 03], [Oussama, 05] et
[Zhu, 08] concernant la découverte dynamique de Web services sémantiques.
53
I. Un prototype et un algorithme pour la découverte de

services Web dans le contexte du Web sémantique
Le problème de la découverte dynamique des e-services est le suivant : étant donnés
une requête utilisateur et un ensemble de e-services, comment trouver la combinaison de
services Web qui répond au mieux à la requête?
Les algorithmes de découverte sont limités par le fait qu’ils sont basés sur une recherche par
mots-clés, ou par tables de correspondance de couples (clé, valeur). De plus, pour une requête,
ces algorithmes découvrent des e-services séparés, et non des combinaisons de services Web
couvrant l’ensemble de la requête. [Rey, 03] propose sous la forme d’un nouveau
raisonnement pour les LD (logique de description), une découverte qui a l’avantage d’être la
seule à permettre la découverte de combinaisons de services Web pour répondre à une
requête, et à fournir la différence entre la requête et les combinaisons découvertes sous la
forme d’un concept réutilisable pour d’autres traitements (initiation d’un dialogue système-
utilisateur par exemple). Nous présentons le système D2CP (Dynamic Discovery of Concepts
Prototype) qui est le prototype qui implémente l’algorithme computeBCov et qui permet ce
nouveau raisonnement pour la découverte dynamique de services Web, étant donné une
ontologie de services Web et une requête utilisateur au format XML.
I.1. Le prototype D2CP
D2CP ou prototype de découverte dynamique de concepts est un prototype Java dans
lequel est implémenté computeBCov.
Le but de ce système est d’être une plateforme de tests de l’algorithme computeBCov de
découverte dynamique de services Web. Pour ceci, D2CP permet :
(i) de générer aléatoirement des ontologies de e-services et des requêtes associées sous la
forme de fichiers XML.
(ii) de découvrir dynamiquement les meilleures combinaisons de e-services étant données une
requête Q et une ontologie :
- fournies par l’utilisateur,
- ou générées par l’utilisateur à l’aide de D2CP.
(iii) de faire tourner les 6 variantes de l’algorithme computeBCov
(iv) d’obtenir les résultats de la découverte dynamique.
- sous la forme d’une trace d’exécution en arbre
- ou sous la forme de mesures de temps de chaque étape de l’algorithme.
54
Figure 18. Vue d’ensemble des fonctionnalités de D2CP.
55
I.2. L’algorithme computeBCov ComputeBCov repose sur une propriété classique des
hypergraphes donnée dans [Berge, 89] et reprise dans [Mannila 94, Eiter 95], qui en fait un
algorithme itératif qui, à chaque itération, génère un certain nombre de candidats pour ne
conserver que les plus petits (au sens de l’inclusion ensembliste) à la fin de l’itération. Cette
phase de génération de candidats peut être optimisée par deux ajouts :
• La propriété des "persistants" établit une condition nécessaire et suffisante de minimalité
d’un candidat. Grâce à elle, on peut donc ne générer que les candidats minimaux à chaque
itération, et ce au prix d’un coût bien moindre que celui impliqué par l’élagage des non
minimaux après la génération de tous les candidats possibles.
• Une technique d’optimisation combinatoire appelée "Branch and Bound" (BnB) peut être
ajoutée pour améliorer encore l’algorithme de base. Elle permet d’élaguer de nombreuses
branches dans l’arbre des candidats possibles grâce à l’évaluation, à chaque itération, du
coût d’une solution possible, cette évaluation pouvant être calculée de deux manières
possibles (BnB1 ou BnB2).
On a donc au total 6 variantes pour computeBCov : avec ou sans les persistants, avec ou sans
le BnB, et si avec le BnB, alors avec BnB1 ou avec BnB2. Ces 6 variantes sont toutes
implémentées dans D2CP
L’algorithme computeBCov
Entrée(s) : Une ontologie T de services et une requête Q exprimées dans la logique de description
FL0.
Sortie(s) : L’ensemble des meilleures combinaisons de services répondant à Q étant donné
l’ontologieT.
1: Construction de l’hypergraphe HT Q = (∑, Г) ;
2: Tr ← ;
3: CostEval ∑
Г du sommet VSi de plus petit cout dans e ;
4: pour chaque arête e Г faire
5: Tr ← {transversaux minimaux générés selon l’algorithme 2}
6: pour chaque transversal minimal X Tr faire
7: RealCost ← cout(X) ;
8: si RealCost > CostEval alors
9: Tr ← Tr \ X ;
10: sinon si RealCost < CostEval alors
11: Eval ← RealCost+ ∑ Г
du sommet VSi de plus petit cout dans f
;
12: si Eval < CostEval alors
13: CostEval ← Eval ;
14: fin si
15: fin si
16: fin pour
17: fin pour
18: pour chaque X Tr tel que cout(X) = CostEval faire
19: Retourner le concept EX
20: fin pour
56
II. Un modèle de métadonnées pour l'indexation des

services e-Learning
[Oussama, 05] propose un modèle de métadonnées pour l'indexation des services e-
Learning. Il propose de décrire et d'indexer des services e-Learning sur trois dimensions: en
tant que ressources d'apprentissage, comme des services qui contribuent et aident les
chercheurs et comme des services généraux en employant les ontologies et la représentation
de connaissance pour indexer et stocker les caractéristiques des services. Sa proposition est de
faire une ressource d'apprentissage non seulement comme chose téléchargeable qui est
seulement exécutée sur la machine de client sans l'interaction avec des serveurs pendant le
temps d'exécution mais également comme un service accessible par une interface.
II.1. Le modèle de métadonnées proposé

II.1.1. Les ressources d'apprentissage
On se basant sur le Dublin Core et IEEE LOM pour assurer la compatibilité avec les plates
formes existantes et permettre la description d'une ressource d'apprentissage en général.
Les ressources d’apprentissage définissent un ensemble d'éléments comme:
• Titre: le nom donné à la ressource par son créateur.
• Créateur: Les personnes ou les organismes principalement chargés du contenu
intellectuel de la ressource.
• Sujet: le sujet de la ressource, des mots-clés ou des phrases qui décrivent l'objet ou le
contenu de la ressource.
• Description : une description textuelle du contenu de la ressource, y compris les
résumés dans le cas du document et des objets et des descriptions de contenu dans le
cas de ressources visuelles.
• Éditeur : les personnes ou les organismes en plus de ceux spécifiés dans l'élément
créateur qui ont apporté des contributions intellectuelles significatives à la ressource
mais qui est secondaire aux individus ou aux entités spécifiées dans l'élément créateur
(par exemple, rédacteurs).
• Date: la date à laquelle la ressource a été mise à disposition dans sa forme actuelle.
• Langage : langages du contenu intellectuel de la ressource.
• Format : la représentation des données de la ressource, telles que text / html, fichier
Postscript, JPEG image et ainsi de suite.
• Droits: le contenu de cet élément est destiné à être un lien (une URL par exemple) à
un avis de droit d'auteur, les droits de gestion de déclaration et ainsi de suite.
57
II.1.2. Les ressources de recherches Trois champs importants sont identifiés :

II.1.2.1. Un domaine de recherche peut être décrit par:
• Index : mots clés qui décrivent le domaine de recherche.
• Références : un ensemble de papiers, documents et URL qui sont utiles dans le
domaine de recherche.
•Liens: qui sont vers d'autres domaines et les thèmes qui sont liés au domaine de
recherche.
•Description: une courte description textuelle du domaine de recherche.
II.1.2.2. Un chercheur peut être décrit par:
•Les informations personnelles : nom, email, numéros de téléphone, site Web et CV.
•Qualité et titre: docteur, professeur, ingénieur et ainsi de suite.
• Domaines de recherche : la liste des domaines de recherche.
•Domaines d'enseignement: la liste des domaines de l'enseignement.
• Publications : références aux documents édités.
•Département: à qui le chercheur est rattaché.
II.1.2.3. Un département peut être décrit par:

• Nom: du département et l'université ou l'organisme à qui le service est joint.
•Adresse : l'endroit du département.
•Description : une description courte du département.
•Domaines de recherche : la liste des orientations de recherches du département.
•Liste de chercheurs attachés au département.
•Les groupes de recherche qui constituent le département.
Un type de service peut être une ressource d'étude, un logiciel, un programme, un document et
ainsi de suite.
II.1.3. Service général Un service peut être défini par un ensemble de

caractéristiques comme:
•Fournisseur et lieu : définit ses caractéristiques en incluant son nom et son adresse, Le lieu
détermine l'endroit de service comme une adresse de compagnie ou une adresse URL
• Canaux de demande et livraison: le moyen par lequel l’utilisateur demande/ reçoit le
service
58
• Paiement et évaluation: le processus par lequel le fournisseur collecte les prix de ses
services
• Environnement: les caractéristiques de l'environnement utilisées pour exploiter le service.
• Système de livraison : la visioconférence dans le cas des ressources d'apprentissage.
• les outils d'aide: les outils (comme le Chat room, liste de diffusion etc) qui aident les clients
à utiliser le service.
II.2. Représentation des connaissances et des ontologies

Dans cette approche, l’auteur a utilisé des ontologies pour indexer et stocker les
caractéristiques (propriétés) de service e-Learning par concepts. Les clients peuvent découvrir
un service en interrogeant leurs caractéristiques à partir de l'ontologie et à l'aide d'un langage
logique comme Frame-Logic. Il a utilisé un outil nommé Ontobroker, qui permet la gestion
d'ontologies. Il se compose d'une interface de recherche pour la formulation des requêtes et un
moteur d'inférence pour dériver de nouveaux faits.
Il a d'abord créé une ontologie décrivant les propriétés des services e-Learning définies
précédemment. Il a employé les structures fournies par une ontologie comme des relations
d'héritage pour construire le modèle de métadonnées pour son service. Si les métadonnées
sont plus structurées par une ontologie, les requêtes peuvent bénéficier de l'organisation
d'ontologie : elles sont plus flexibles et plus puissantes.
L'exemple suivant est un concept dans l'ontologie écrite en F-Logic, pour décrire
l'emplacement du fournisseur de services:
Provider address [ city name =>> STRING;
street name =>> STRING;
postal code =>> INTEGER;
country code =>> INTEGER].
59
III. Un algorithme de découverte des services e-Learning

basé sur la satisfaction des utilisateurs [Zhu, 08]
[Zhu, 08] Propose un algorithme appelé l'eLSDAUS, pour améliorer l'algorithme de
matching5 (jumelage) basé sur la sémantique. Dans cet algorithme, il a introduit et intégré un
nouveau facteur - la satisfaction de l’utilisateur, qui représente le niveau de satisfaction de
l’utilisateur concernant le résultat de découverte d’un service. Cet algorithme permet aux
utilisateurs de participer dans la découverte des services e-Learning en évaluant le résultat de
cette découverte. L’évaluation de l'utilisateur concernant sa satisfaction est réintroduite dans
le système. En adoptant une fonction modificatrice qui prend la satisfaction des utilisateurs
comme entrée, le système modifie les poids de chaque propriété du service publié, et ensuite
le degré de matching augmente pour arriver au meilleur degré.
III.1. Modèle de description des services e-Learning

[Zhu, 08] propose un modèle de description des services e-Learning qui peut être
défini comme 4-tuplet : eLS :={ INPUTs, OUTPUTs, QoS, US}
III.1.1. INPUTs est l'ensemble des propriétés des entrées des services e-Learning,
III.1.2. OUTPUTs est l'ensemble de propriétés de sortie des services e-Learning

Les concepts dans les ensembles d’INPUTs et OUTPUTs sont tous les concepts de l'ontologie
de domaine des services e-Learning.
III.1.3. QoS est la qualité de service. Elle décrit la capacité des services e-Learning pour
répondre au besoin d'utilisateur.
Un modèle QoS peut être défini comme 3-tuplet, QoS:={ RT, CT, AL}, RT représente le
temps de réponse, il indique le temps de la soumission du service demandé à la réponse du
service publié; CT représente le coût payé pour invoquer le service chaque fois; Al représente
la disponibilité du service publié.
Les valeurs de RT, CT, et AL sont initialisées par le fournisseur de service, puis ils vont
changer dynamiquement sous le contrôle du système.
III.1.4. US est la satisfaction des utilisateurs, elle signifie l'expérience de l'utilisateur de la
comparaison entre le service retourné du système de découverte en fonction de sa demande et
ses espérances. L’architecture de mesure des US peut être divisée en 3 niveaux comme
l'indique la table 2.
5
Le matching est la correspondance entre les propriétés du service demandé et les services publiés.
60
Total Target 1er niveau 2eme niveau

input1
INPUTs ……
Architecture inputl
de output1
mesure OUTPUTs ……
pour US outputm
RT
QoS CT
AL
Table 2. Architecture de mesure pour US.

La satisfaction des utilisateurs à chaque mesure indicatrice peut être représentée par 5
niveaux: Très satisfait, satisfait, Normal (acceptable), non satisfait, mauvais, les valeurs de
chaque US sont 5, 4, 3, 2, 1.
• US to INPUTs pour les services e-Learning peut être défini comme la valeur moyenne

des US à toutes les valeurs d'entrée, US_INPUT= ∑
_ i ; tel que m est le
nombre de propriétés des entrées, US_inputi {1, 2, 3, 4, 5} est une propriété

INPUTs.
• US to OUTPUTs pour les services e-Learning peut être défini comme la valeur
moyenne des US à toutes les valeurs de sorties, US_OUTPUT= i ;
tel que n est le nombre de propriétés des sorties, US_outputi {1, 2, 3, 4, 5} est une
propriété OUTPUTs.
• US to QoS pour les services e-Learning peut être défini comme la valeur moyenne des
US pour le temps de réponse, le coût et la disponibilité.
US_QoS= (US_qos1+US_qos2+US_qos3)/3 ; Tel que US_qos1, US_qos2, US_qos3
{1, 2, 3, 4, 5} sont le temps de réponse, le coût et la disponibilité des services e-
Learning.
61
III.2. L’ALGORITHME eLSDAUS

(1) Établir le dépôt des services publiés ;
(2) Établir le dépôt des services résultats ;
(3) jumelage des propriétés d’INPUTs ;
(4) jumelage des propriétés d’OUTPUTs ;
(5) jumelage des QoS ;
(6) Mettre les services publiés qui satisfont les entrées(INPUTs), les sorties(OUTPUTs)
et la qualité de service(QoS) dans le dépôt des résultats découverts;
(7) Calculer le TotalMatchDegree (degré total de jumelage) de chacun des services

dans le service de dépôt des résultats;
(8) Selon le TotalMatchDegree, trier les services publiés dans le dépôt de résultat. Et
renvoyer le résultat assorti ;
(9) Recueillir l'US aux services retournés ;
(10) Selon le US, calculer le poids de degré de matching de chaque propriété de tout le
service retourné;
(11) Mettre à jour le poids de degré de matching de chaque propriété dans le dépôt des
services publiés.
Requester Service provider

Machmaker
US agent
Advetisement service
Requested service
US feedback
US evaluator Reasoning engine
Service updater
E-Learning service
ONtology repository
Figure 19. L’architecture de découverte des services e-Learning.
62
4. La comparaison des approches étudiées

Après avoir présenté dans le paragraphe précédent quelques approches de découverte
de Web services, nous avons établi un tableau récapitulatif et comparatif des trois approches.
Modèle de Algorithme
Prototype d2cp
métadonnées elSDAUS
Description des services ontologies ontologies ontologies
Domaine de découverte Général e-Learning e-Learning
Techniques de Algorithme Algorithme
Ontobroker
découverte computeBcov elSDAUS
L’utilisateur
Ne tient pas Ne tient pas participe
Profil utilisateur
En compte En compte Au processus de
découverte
Exact Non exact Exact
Exactitude des résultats
Calcul de formule Requête en f-logic Calcul de formule
Calcul de la Réinjection de la
Indexation des
Particularités Couverture Satisfaction de
services e-Learning
minimale L’utilisateur
Table 1: Comparaison des travaux de découverte.
63
5. Conclusion
La découverte de services Web constitue un axe de recherche émergeant. Diverses
approches ont été proposées. Ces approches sont passées d’une recherche basée mots clé
(correspondance syntaxique de la requête avec les descriptions des services Web) aux
méthodes basées sémantique (degré de correspondance sémantique de la requête avec la
sémantique des descriptions des services Web). Cependant vu la diversité des utilisateurs et
des conditions dans lesquelles ils accèdent aux services Web, d’autres paramètres doivent être
considérés lors de la découverte, tel que le type du dispositif utilisé (PDA, ordinateur portable,
etc.), préférences de l’utilisateur, etc. Tous ces paramètres forment un contexte d’utilisation
particulier.
64
Partie II
Conception et mise en œuvre

Chapitre IV
Conception du système
Chapitre IV Conception du système
1. Introduction
Tout au long de la partie précédente nous avons vu des notions tel que : e-Learning,
Web services, Web sémantique, ainsi qu’une phase très importante qui consiste en leur
découverte, les standards et outils utilisés. Les méthodes de découverte comme on l’a déjà vu
sont passées d’une recherche basée mots clé (correspondance syntaxique de la requête avec
les descriptions des services Web) aux méthodes basées sémantique en utilisant les
ontologies.
En effet, notre travail consiste à réaliser une application de recherche et de sélection de

services Web e-Learning et leur adaptation selon le profil utilisateur et cela à l’aide des
ontologies, l’ontologie DAML-S pour la description sémantique des services Web et une
ontologie pour décrire le profil utilisateur.
Dans ce chapitre nous allons décrire les objectifs de notre système, les insuffisances de
DAML-S pour la description des Web services e-Learning et l’ontologie ajoutée à DAML-S,
ensuite nous allons présenter l’architecture du système proposé avec ses différentes
fonctionnalités.
2. Les objectifs du système

Notre travail vise à satisfaire un certain nombre d’objectifs pédagogiques en vue de
satisfaire un maximum d’utilisateurs en se dotant des interfaces de recherche et affichage des
résultats adaptables selon les préférences et les besoins des utilisateurs.
Nous citons parmi ces objectifs :
• Notre système permet la publication de nouveaux services Web. Pour cela, il sera doté
d’un module permettant au fournisseur (enseignant ou administrateur) à travers une
interface interactive, de publier des informations concernant le Web service.
• Il met en œuvre une interface de recherche riche offrant diverses options : recherche
par mot-clé, recherche multicritère, l’interface de recherche permet aussi d’utiliser le
profil utilisateur pour le filtrage et l’adaptation des résultats selon les préférences de
l’utilisateur.
65
3. Insuffisance de DAML-S dans le cadre du e-Learning

DAML-S, qui est une ontologie qui nous permet de faire une description sémantique
des Web services. Les agents de services e-Learning présentent des exigences sur les aspects
technologiques et pédagogiques. Ceci incite les fournisseurs de services Web à les publier en
mentionnant ces caractéristiques. 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).
Le standard DAML-S ne fournit pas une description parfaite sur les aspects
technologiques et pédagogiques des services Web e-Learning. Afin de prendre en
considération ces aspects, en plus des descriptions fonctionnelles, une ontologie a été ajoutée
à DAML-S dans le travail de Mlle Boudali6. Cette ontologie est nommée ‘ontologie de
Qualité de l’Apprentissage’ (QA).et notre projet s’inscrit dans la continuité de ce travail.
3.1. L’ontologie de qualité d’apprentissage (QA)

Une description des plateformes e-Learning selon les caractéristiques pédagogiques,
technologiques et financières s’est avérée nécessaire pour le choix de service Web.
L’ontologie de qualité d’apprentissage (QA) a été élaborée dans cette fin. Cette ontologie a le
schéma suivant :
Qualité
d’apprentissage
Informations
Informations
pédagogiques
financières
Informations
Est techniques
Figure 20. Ontologie de qualité d’apprentissage.
6
Mémoire de magister « Publication et découverte des web services pour le domaine du e-learning », à
l’institut national de formation en informatique. 2008.
66
La classe « Qualité d’apprentissage »

C’est la classe principale de l’ontologie, elle est composée de trois classes qui décrivent les
services Web.
I.La classe « informations pédagogiques »
Comporte les outils pour la collaboration et la communication entre les différents
types d’acteurs de la plateforme, englobe tous les aspects de gestion des ressources
pédagogiques, décrit les informations sur les formations réalisées avec le Web service et
recouvre toutes les fonctionnalités de gestion pédagogique de formation.
II. La classe « informations techniques »
Englobe toutes les informations techniques sur le Web service tel que la possibilité de
changement du système afin qu’il s’adapte aux exigences des utilisateurs, la langue du Web
service, son niveau de sécurité. Elle décrit aussi les informations technologiques du Web
service (Date de mise à jour, Version, Débit, etc.), les outils soft (système d’exploitation,
navigateur et autres logiciels) et matériel exigés et enfin les fonctionnalités de gestion de la
plateforme qui sont offertes pour un administrateur technique.
III. Les informations financières

Cette classe recouvre les coûts affectés au financement des formations, de façon directe
ou indirecte, dans l’institution, le type et coût de la licence de la plateforme, les recettes et
dépenses de formation, et enfin la gestion des contrats et la gestion des paiements.
3.2. Intégration de l’otologie QA avec DAML-S

Le schéma complet de l’ontologie décrivant les Web services e-Learning est illustré
dans la figure ci-dessous:
Service
Supporte
Presents Communique
A pour
ServiceProfile
Interopérabilité
QA
Figure 21. Ontologie des services.
67
L’ontologie comporte l’ontologie de qualité d’apprentissage (QA), une partie de

DAML-S avec un autre élément nécessaire dans la description des services qui est
l’interopérabilité du service avec d’autres services.
Pour DAML-S, seulement la classe « Service » a été exploitée et enrichie 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.
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 LDAP7. Cette classe décrit les services avec lesquels le service en
question peut communiquer. Elle comporte les deux propriétés suivantes :
• 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.
4. L’ontologie du profil utilisateur

Le modèle utilisateur proposé est défini comme une ontologie utilisateur générique,
comprenant diverses caractéristiques d’un utilisateur, à base de concepts, sous concepts et
relations entre les différents concepts. Le profil utilisateur contient des attributs qui aident à
l’identifier, les informations concernant son niveau d’éducation, ses compétences, ses
domaines de qualification et les dispositifs matériels et logiciels dont dispose l’utilisateur.
7
Lightweight Directory Access Protocol.
68
5. Architecture du système
Notre système est constitué d’un module pour la publication des Web services, un
module pour la découverte des services Web, et enfin un module pour le filtrage des résultats
trouvés lors de la recherche en utilisant l’ontologie du profil utilisateur.
L’architecture du système est illustrée dans le schéma ci-après :
Figure 22. Architecture du système.
69
6. Les Diagrammes UML représentatifs du système

UML (Unified Modeling Language) est une méthode de modélisation orientée objet
développée dans le but de définir la notation standard pour la modélisation des applications
construites à l’aide d’objets. L’objectif principal de notre application est de satisfaire au
mieux les demandes des utilisateurs en termes de recherche et de sélection de services Web,
il faut par conséquent bien comprendre leurs désirs et leurs besoins. Pour ce faire nous avons
utilisé les différents diagrammes UML :
- cas d’utilisations pour exprimer les interactions acteurs/système et
- diagrammes de séquence pour mettre en valeur les échanges de messages
(déclenchant des événements) entre acteurs et objets (ou entre objets et objets) de manière
chronologique et de capturer le comportement de tous les objets et acteurs impliqués dans un
cas d’utilisation.
Système de découverte et sélection de services

web
Inscription des
utilisateurs
Gestion des
utilisateurs
« Includes »
Publication de services
web
Enseignant S’authentifie
Administrateur
Recherche de services
web
Gestion du profil
Apprenant
Figure 23. Diagramme des cas d’utilisation.
70
6.1. « inscription des utilisateurs »

1. Description du cas « inscription des utilisateurs »
Objectif : permet l’inscription des nouveaux utilisateurs de la plateforme.
Acteurs : administrateur, enseignant et apprenant.
Pré-conditions :
-L’utilisateur n’existe pas dans le système.
Scénario :
-l’utilisateur remplie un formulaire d’identification (nom, prénom, etc.).
-ensuite il valide les informations introduites.
Post-condition :
- Le nombre d'utilisateurs est incrémenté.
2. Diagramme de séquence d’inscription des utilisateurs

Avant toute utilisation du système, l’utilisateur doit s’inscrire en introduisant ses
informations à travers un formulaire.
Web service de la
Utilisateur Identification Ontologie du profil
gestion des utilisateurs
Afficher message d’accueil
Demande d’inscription
Demande d’inscription
Formulaire à remplir
Formulaire remplie
Mise à jour de l’ontologie
Figure 24. Diagramme de séquence d’inscription des utilisateurs.

6.2. « gestion des utilisateurs »
1. Description du cas « gestion des utilisateurs »
Objectif : permet de gérer les utilisateurs de la plateforme.
71
Acteurs : administrateur.
Pré-conditions :
-L’administrateur doit s’identifier en introduisant son identifiant et son mot de passe.
-Le nombre d’essaies de se connecter au système ne doit pas dépasser trois.
Scénario :
-L’administrateur se connecte au système.
-L’administrateur clique sur l’onglet gestion des utilisateurs.
-il peut :- valider un nouvel utilisateur.
- supprimer un ou plusieurs utilisateurs.
Post-condition :
- Le nombre d'utilisateurs est décrémenté ou incrémenté selon le cas.
2.1. Diagramme de séquence de gestion des utilisateurs «validation des

utilisateurs»
L’administrateur consulte la liste des nouveaux inscrits et valide ensuite leur
inscription comme présenté dans le diagramme ci-dessous :
Web service de la
Choix de l’option « gestion

des utilisateurs »
Demande d’identification
Identification
Demande d’affichage des nouveaux inscrits

Demande de la liste
La liste des
nouveaux inscrits
Affichage de la liste des nouveaux inscrits
Sélection et validation des nouveaux inscrits La liste des nouveaux

utilisateurs validée
Figure 25. Diagramme de séquence «validation des utilisateurs».

72
2.2. Diagramme de séquence de gestion des utilisateurs «suppression des

utilisateurs»
L’administrateur consulte la liste des utilisateurs et supprime ensuite un ou plusieurs,
comme présenté dans le diagramme ci-dessous :
Web service de la
Choix de l’option gestion

des utilisateurs
Identification
Demande d’affichage des utilisateurs Demande la liste des

utilisateurs
La liste des utilisateurs
Affichage de la liste des utilisateurs
Sélection et suppression d’un ou plusieurs utilisateurs

Ontologie mise à jour
Figure 26. Diagramme de séquence de «suppression des utilisateurs».

6.3. « gestion des profils »
1. Description du cas « gestion des profils »
Objectif : permet de gérer les profils utilisateurs.
Pré-conditions :
- l’utilisateur doit être inscrit au système.
-l’utilisateur (administrateur, enseignant et apprenant) s’authentifie à travers la page
d’accueil, en introduisant son login et mot de passe.
Scénario :
-l’utilisateur se connecte au système.
73
-il peut consulter son profil.

-il peut apporter des modifications sur son profil.
-l’administrateur peut consulter et modifier les profils des apprenants et enseignants.
-l’enseignant peut consulter les profils des apprenants.
2.1. Diagramme de séquence de gestion des profils utilisateur

«consultation»
L’utilisateur peut consulter les données enregistrées dans son profil. Bien sur
l’administrateur peut consulter les profils des enseignants et apprenants. L’enseignant a aussi
le droit de voir les profils de ses apprenants pour par exemple des raisons pédagogiques.
Web service de la
Choix de l’option « profil

utilisateur
Identification
Demande d’affichage de profil utilisateur

Demande profil utilisateur
Profil utilisateur
Affichage du profil utilisateur
Figure 27. Diagramme de séquence de «consultation de profil».

2.2. Diagramme de séquence de gestion du profil utilisateur
« modification ».
L’utilisateur peut effectuer des modifications sur les données de son profil,
l’enseignant peut éventuellement modifier les profils des apprenants et l’administrateur a
aussi le droit d’apporter des changements sur les profils apprenants ou enseignants.
74
Web service de la
Choix de l’option « profil

utilisateur
Identification
Demande d’affichage de profil utilisateur

Demande profil utilisateur
Profil utilisateur
Affichage du profil utilisateur
Modification du profil utilisateur
Profil utilisateur
Figure 28. Diagramme de séquence « modification du profil ».

6.4. « recherche des services Web »
1. Description du cas « recherche des services Web »
Objectif : assurer la recherche des services Web qui répondent aux besoins des
utilisateurs.
Pré-conditions :
-l’utilisateur (administrateur, enseignant et apprenant) s’authentifie à travers la page
d’accueil, en introduisant son login et mot de passe.
Scénario :
-l’utilisateur se connecte au système.
-il introduit sa requête.
- L’utilisateur choisit les critères selon lesquels il voudrait effectuer sa recherche.
- il peut choisir d’utiliser son profil pendant la recherche ou non.
75
-s’il décide d’utiliser son profil pendant la recherche les résultats seront filtrés.
- Les services trouvés sont affichés avec une petite description.
2. Diagramme de séquence de découverte des services Web.

Les utilisateurs peuvent trouver des services Web selon leurs besoins en interrogeant
l’ontologie DAML-S et la QA ainsi que l’annuaire UDDI en introduisant une requête et/ou
des critères de recherche. L’utilisateur peut choisir d’utiliser son profil pendant la recherche.
Utilisateur Identification Traitement requête Ontologie profil Filtrage Ontologie QA+DAML-S
Afficher le message d’accueil
Identification
Demande de l’option
« recherche SW » Traitement
Requête utilisateur requête
Requête traitée
Critères de recherche
Résultats trouvés
Ou
Résultats trouvés
Consulter
Préférences
Résultats filtrés
Figure 29. 1Diagramme de séquence de découverte des services Web.

6.5. « publication des services Web »
1. Description du cas « publication des services Web »
Objectif : publier des services.
Acteurs : administrateur, enseignant.
Pré-conditions
-l’utilisateur (administrateur, enseignant) s’authentifie à travers la page d’accueil, en
introduisant son login et mot de passe.
76
Scénario :
- L’utilisateur introduit les informations nécessaires sur le service à publier (le nom,
l’URL, description, informations pédagogiques, coût, etc.).
-l’utilisateur valide les informations introduites.
2. Diagramme de séquence de publication de services Web

Un fournisseur de service qui est soit enseignant ou administrateur a le droit de publier
ses services Web en donnant des informations concernant ces services , ces descriptions
contiennent des descriptions WSDL qui seront déposées au niveau de l’annuaire UDDI et des
descriptions sémantiques au niveau de l’ontologie DAML-s et QA.
Fournisseur Identification Description WS UDDI Ontologie QA+DAML-S

Demande de l’option
« publier SW »
Identification
Informations sur le service

Description WSDL
Description sémantique
Figure 30. Diagramme de séquence de publication de services Web.

Exemple de publication d’un service Web
Citons par exemple la publication d’un cours d’organisation rédigé par l’enseignant
Abdesemmad Reda Ghomari, les étapes se déroulent ainsi :
L’enseignant se connecte au système et demande le volet de publication, le système lui
demande de s’identifier s’il n’est pas déjà inscrit le système lui fournit un formulaire
d’inscription, sinon il introduit son login et mot de passe.
Ensuite il procède à la publication en introduisant les informations suivantes :
Titre : recommandations pour réussir l’écrit et l’exposé oral.
Sujet : organisation
Langue : français
77
Date de création : novembre 2005

Format : pdf
Volume : 352k
Conforme avec le standard : SCORM
Téléchargement : oui
7. Algorithme de découverte des Web services

Il y a de plus en plus de services Web utilisés dans l'apprentissage coopératif, par
conséquent il est devenu de plus en plus important de localiser des services Web appropriés
d'une manière précise et efficace. On propose ci-dessous un algorithme de découverte des
services Web e-Learning.
En premier lieu l’utilisateur introduit sa requête qui est un ensemble de mots-clés, on

calcule ensuite le degré de correspondance entre les concepts de la requête et les instances des
classes de chaque service Web. Dans le cas de recherche multicritère on compare chaque
critère aux instances des classes correspondantes des services. On incrémente le degré de
matching pour chaque service chaque fois qu’il y a correspondance entre le concept et/ou le
critère et le service. Les services trouvés seront affichés en ordre décroissant du degré de
matching.
78
Algorithme découverte des web services

Entrées :
Q : Requête de l’utilisateur ;
Cr: Critères de recherche ; Cc : Ensemble des classes concernées ;
S : Service ; Cpt : degré de matching ; L : Liste des services trouvés ;
Sorties : Liste des services trouvés ;
1 : découper la requête Q en mot-clé Qi ;
2 : charger l’ontologie ;
// La recherche par mot-clé//
3:j 0;
4 : pour chaque service Sj faire
5: cptj 0; i 0;
6: Pour chaque mot clé Qi faire
7: Comparer Qi avec toutes les instances des classes du service Sj ;
8: S’il y a correspondance Cptj Cptj+1 ;
9: Si Cptj=1 alors L L+Sj Fsi;
10 : i i+1 ;
11 : fin pour ;
12 : j j+1 ;
13 : fin pour ;
14 : Retourner L en ordre décroissant du Cptj ;
//La recherche multicritère//
15 : Cc serviceprofile; // Récupérer l’ensemble des classes dont les critères sont choisis
16 : pour chaque critère Cr de recherche faire
17 : Cc Cc+ la classe sélectionnée ;
18 : fin pour ;
19 : j 0;
20 : pour chaque service Sj (de la liste L) faire
21: k 0;
21 : Pour chaque critère Crk d faire
22 : Comparer Crk avec les instances de la classe Cck du service Sj
23 : S’il y a correspondance Cptj Cptj+1 ;
24 : Sinon L L-Sj ; Fsi
25 : K K+1 ;
26 : fin pour
27 : j j+1 ;
28 : fin pour
29: Afficher L en ordre décroissant selon un seuil de tolérance ;
79
En résumé l’algorithme de découverte est structuré ainsi :

Ligne 1 : l’utilisateur introduit sa requête sous forme de mots clés.
Ligne 2 : le système charge l’ontologie.
Lignes 3 à 14: concernent la recherche par mot clé, on associe à chaque service de l’ontologie
un degré de matching qui est initialement nul, ensuite on compare chaque mot clé de la
requête avec tous les concepts de chaque service lorsque il y a correspondance on incrémente
le degré de matching (de correspondance) du service en cours. Si ce service n’existe pas dans
la liste des services trouvés, on l’ajoute alors.
Lignes 15à 18 : si l’utilisateur veut utiliser des critères de recherche, alors la recherche se fait
dans l’ensemble de classes cibles qui contiennent les critères sélectionnés pour une recherche
plus pertinente.
Lignes 19 à 28 : On compare chaque critère sélectionné avec tous les concepts des classes
cibles de chaque service, et lorsque il ya correspondance on met à jour le degré de matching
du service en cours en l’incrémentant. Sinon on élimine le service de la liste des résultats.
Lignes 29 : afficher à l’utilisateur le service ou la liste des services trouvés en ordre
décroissant du degré de matching après sélection.
Exemple de déroulement de l’algorithme de découverte :
Requête (Q)= « formation à distance »
Critères (Cr)= {}, Classes concerné (Cc)= {}, Services (S)= {CLAROLINE, GANESHA 3,
SAKAI}
Services (Sj) Description service Mot clé (Qi) Poids (CPTj)
CLAROLINE Claroline2 est une Formation 1*
plateforme de
formation à distance et distance 2
de travail collaboratif
GANESHA 3 Ganesha est une Formation 1
plateforme de
distance 1
formation ou LMS
SAKAI Le projet Sakai1 a pour Formation 0
objectif de consolider
le développement en distance 0
matière de plateforme
d’apprentissage
* il y a correspondance entre la description du service (formation) et le mot clé de la requête (formation),
incrémenter le poids du service
Liste des services trouvés(L)= {CLAROLINE, GANESHA3}.
80
8. Algorithme de sélection des résultats selon le profil utilisateur

Cet algorithme sert à sélectionner les services Web trouvés dans le module de
découverte et à les adapter selon les préférences de l’utilisateur par exemple les logiciels et
matériel utilisés, le format de la ressource, etc.
Pour ce faire: on définit un ensemble de classes qu’on juge nécessaires pour le filtrage dites
classes cibles puis on compare les instances des classes de chaque service trouvé avec celles
des classes cibles, chaque fois qu’il y a correspondance on incrémente le degré de matching
du service en cours, sinon on élimine le service de la liste des services trouvés, enfin on
affiche les résultats de sélection selon un ordre décroissant de degré de matching.
Notre algorithme a la structure suivante :
Algorithme de sélection des résultats de découverte selon le profil utilisateur
Entrées :
L : La liste des services trouvés ;
Cptj : le degré de matching du service Sj ;
Ontologie du profil utilisateur ;
Cl : l’ensemble des classes cibles de l’ontologie du profil à utiliser pendant le filtrage ;
Sorties : la liste des services sélectionnés ;
1:j 0;
2 : Pour chaque service Sj faire
3: i 0;
4: Pour chaque classe cible Cli faire
5: Comparer Cli avec toutes les classes du service Sj ;

6: S’il y a correspondance alors Cptj Cptj+1 ;
7: i i+1 ;
8: Fin pour
9: Si le service Sj ne satisfait aucune préférence de l’utilisateur alors L L-Sj ;Fsi
10 : j j+1 ;
11 : Fin pour
12: Afficher les services sélectionnés dans l’ordre décroissant des nouveaux degrés de
matching selon un seuil déterminé;
81
En résumé l’algorithme de sélection se compose des étapes suivantes :

Ligne 4 à 8 : on définit un ensemble des classes cibles de l’ontologie du profil qu’on juge
nécessaires pour le filtrage, on compare les classes de chaque service trouvé avec toutes ces
classes cibles et lorsqu’il y a correspondance on incrémente le degré de matching du service
en cours.
Ligne 9: un service est rejeté de la liste des services trouvés s’il ne correspond pas aux
préférences de l’utilisateur.
Ligne 12 : Afficher les services sélectionnés dans l’ordre décroissant des nouveaux degrés de
matching c'est-à-dire ceux qui répondent le mieux aux préférences de l’utilisateur.
Exemple de déroulement de l’algorithme de filtrage des résultats de découverte:
Pour expliquer le fonctionnement de l’algorithme de filtrage des résultats on a pris un
exemple où le filtrage se fait par rapport à la préférence langue de l’utilisateur.
Services trouvés (Sj)= {CLAROLINE, GANESHA 3}
Services (Sj) Langue service Préférence (langue) Poids (CPTj)
CLAROLINE Français Français 3*
GANESHA 3 Anglais Français
* il y a correspondance entre la langue du service (Français) et la préférence de l’utilisateur qui est langue
(Français), donc on incrémente le poids du service. Sinon on élimine le service (GANESHA3)
Liste des services filtrés (L)= {CLAROLINE}.
82
9. Conclusion
Notre système permet à un fournisseur de services (exportateur) d’annoncer une offre
de service et à un consommateur de service (importateur) de s'enquérir afin de découvrir un
service requis. Pour ce faire nous avons employé l’ontologie DAML-S à laquelle une
ontologie a été ajouté qui est nommée qualité d’apprentissage QA citée précédemment.
Nous avons également adapté les services aux besoins des différents utilisateurs. À
cette fin, nous avons défini un profil pour chaque utilisateur. Il contient des valeurs désirées
par l’utilisateur de certaines propriétés d'un service Web. Quand l’utilisateur recherche un
service et s'il y a de nombreuses offres, nous allons employer le profil utilisateur pour filtrer
les services retournés et pour rendre la demande plus sélective. Ceci permet à l’utilisateur
d'obtenir les services qui sont compatibles avec ses préférences.
Dans le chapitre suivant, nous traiterons l’implémentation et la mise en œuvre de notre

système en réalisant les ontologies et les différentes fonctionnalités (publication, découverte
et sélection) de services Web ainsi que des technologies et des outils le permettant.
83
Chapitre V
Mise en œuvre du système

Chapitre V Mise en œuvre du système
1. Introduction :
Après avoir présenté dans le chapitre précédent la conception et l’architecture de notre

système baptisé EAsyLearn en décrivant les modules qui le constituent : le module
publication, le module découverte et le module sélection selon le profil ainsi que leur
fonctionnement. Nous allons dans ce qui suit définir les aspects techniques de notre
application en présentant l’environnement de développement mené de l’argumentation de nos
choix pour chaque outil, nous entamons ensuite l’implémentation des différents modules de
l’application ainsi que son déploiement au sein du serveur d’application.
Et pour expliquer le fonctionnement de notre prototype on a décrit les interfaces offertes par
l’application en utilisant des captures d’écrans.
84
2. Environnement de développement
2.1. Le langage Java

Pour le langage de programmation notre choix s’est porté sur le langage JAVA et cela
parce que JAVA :
• est un langage orienté objet simple ce qui réduit les risques d’incohérence.
• est portable. Il peut être utilisé sous différentes plates formes sans aucune
modification.
• possède une riche bibliothèque de classes.
• 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.
2.2. La technologie jsp et servlets

Nous avons opté pour Les pages Web JSP car c’est une technologie développée par
Sun basée sur Java qui simplifie le processus de développement de sites Web dynamiques.
Le mélange d'HTML et de code Java dans les pages JSP permet de séparer la présentation (en
HTML) des aspects procéduraux contenus dans le code. On a ainsi une grande souplesse dans
le développement de sites Web.
Nous avons eu recours à la technologie des Servlets car écrite en java, une servlet en
retire ses avantages : la portabilité, l'accès à toutes les API de java dont JDBC pour l'accès aux
bases de données.
2.3. Apache Tomcat
Pour le serveur d’application on a choisi Tomcat qui est un serveur Web qui gère les
servlets et les JSP. Comme Tomcat inclut un serveur HTTP interne, il est aussi considéré
comme un serveur HTTP.
Tomcat est un outil open source qui a été écrit en langage Java, il peut donc s'exécuter via la
JVM (machine virtuelle java) sur n'importe quel système d'exploitation la supportant.
85
2.4. Eclipse 3.2

Pour le choix de l’environnement de développement on a opté pour Eclipse car il
possède de nombreux points forts qui sont à l'origine de son énorme succès dont les
principaux sont :
• Une plateforme ouverte pour le développement d'applications et extensible grâce à un
mécanisme de plugins
• Support de plusieurs plates formes d'exécution : Windows, Linux, Mac OS X
• Malgré son écriture en Java, Eclipse est très rapide à l'exécution grâce à l'utilisation de
la bibliothèque SWT
• La construction incrémentale des projets Java grâce à son propre compilateur qui
permet en plus de compiler le code même avec des erreurs, de générer des messages
d'erreurs personnalisés, de sélectionner la cible.
2.5. Protégé 3.2
L’éditeur d’ontologie qu’on a choisi c’est protégé qui est un éditeur open source. Il est
également une librairie Java qui peut être étendue pour créer de véritables applications à bases
de connaissances en utilisant un moteur d'inférence pour raisonner, il possède une interface
modulaire, ce qui permet son enrichissement par des modules additionnels (plugins).
2.6. JUDDI 0.9rc4 et l’API UDDI4J
JUDDI est une implémentation open source réalisée par la fondation Apache. Il propose
le stockage des données sur un grand nombre de bases de données relationnelles ou bien sur
une base xml.
Le but de JUDDI est de permettre au client d’un Web service de ne pas avoir à connaître
l’emplacement de celui-ci, mais juste une information permettant de le retrouver.
Notre objectif est de permettre à une personne souhaitant utiliser un service déployé quelque
part et publié dans l’annuaire JUDDI de pouvoir y accéder en connaissant le minimum de
choses sur le service et sur les mécanismes des services Web.
Le serveur de base de données qu’on a utilisé est MySQL dans sa version 5.0.26-win32.
On a utilisé l’API UDDI4J pour exploiter les données JUDDI.
UDDI4J est une librairie de classes java qui fournit une API pour interagir avec UDDI. La
version IBM de UDDI4J fournit aux développeurs es services Web une implémentation
complète et robuste coté client.
86
3. Les ontologies
3.1. L’ontologie des services
On donne ci – après une figure qui représente l’ontologie des services :
Figure 31 : L’ontologie des Web services.
87
3.2. L’ontologie profil utilisateur

La structure de l’ontologie profil est décrite dans cette figure
Figure 32 : L’ontologie de profil utilisateur.
88
4. Implémentation de l’application EasyLearn

L’accru du besoin de concevoir des applications d'entreprises performantes, robustes
et de moindre coût a permis l’émergence de nouvelles pratiques de programmation qui
consistent à décrire de façon formelle et rigoureuse des modèles de conception pour des
problèmes de la programmation orientée objet. Ces descriptions peuvent être utilisées afin de
construire des solutions fiables, rapides et sûres. Elles sont regroupées au sein de catalogues
de design patterns (schémas de conception).
Parmi ces patterns, on retrouve le modèle MVC (Modèle Vue Contrôleur) qui a été
initialement développé pour le langage Smalltalk dans le but de mieux structurer une
application avec une interface graphique.
L'utilisation du modèle MVC rend un peu plus compliqué le développement de l'application

qui le met en œuvre mais il permet une meilleure structuration de l'application.
4.1. Architecture Modèle/Vue/Contrôleur

L'architecture Modèle/Vue/Contrôleur (MVC) consiste à distinguer trois entités distinctes qui
sont, le modèle, la vue et le contrôleur ayant chacun un rôle précis :
• modèle : données (accès et mise à jour)
• vue : interface utilisateur (entrées et sorties)
• contrôleur : gestion des événements et synchronisation
i. Rôle du modèle : Le modèle contient les données manipulées par le
programme. Il assure la gestion de ces données et garantit leur intégrité en
offrant des méthodes pour les mettre à jour.
ii. Rôle de la vue : La vue fait l'interface avec l'utilisateur. Sa première tâche est
d'afficher les données qu'elle a récupérées auprès du modèle. Sa seconde tâche
est de recevoir toutes les actions de l'utilisateur (clic de souris, sélection d'une
entrées, boutons, …). Ses différents événements sont envoyés au contrôleur.
iii. Rôle du contrôleur : Le contrôleur est chargé de la synchronisation du modèle
et de la vue. Il reçoit tous les événements de l'utilisateur et enclenche les actions
à effectuer.
89
4.2. Implémentation des modules de l'application

Notre application repose sur le schéma de conception MVC, sa structure est la
suivante : une servlet (contrôleur) qui contient de la logique applicative et délègue à une page
JSP (vue) l'envoi de la réponse au client.
4.2.1. Le contrôleur
Le client fait une demande au contrôleur. Celui-ci voit passer toutes les demandes des clients.
C'est la porte d'entrée de l'application.
Le contrôleur traite cette demande. Pour ce faire, il peut avoir besoin de l'aide de la couche
métier. Une fois la demande traitée, le contrôleur peut appeler diverses réponses :
• une page d'erreurs si la demande n'a pu être traitée correctement.
• la réponse (vue) à envoyer au client sinon.
4.2.2. Les modèles
Les modèles constituent la couche [métier] qui implémente les algorithmes de notre
application. Cette couche est indépendante de toute forme d'interface avec l'utilisateur.
Notre application contient un certain nombre de modèles (classes java) qui sont :
• verifier_login : C'est la classe qui se charge de vérifier l’authentification des différents
utilisateurs (apprenants, enseignants et administrateur) au système.
• recuperer : Si le login et le password introduits par l’utilisateur sont corrects, cette classe
accède à l’ontologie et récupère les données personnelles de cet utilisateur.
• inserer_utililisateur : Dans le cas d’un nouvel utilisateur, cette classe permet son
inscription, qui consiste à récupérer les informations remplies dans le formulaire
d’identification (nom, prénom, adresse, login, password.etc) et les insérer dans l’ontologie
de profil utilisateur. Pour ce faire cette classe crée des instances dans les classes
« identité », « démographie » et « contact » et insère dedans les données qui leurs sont
appropriées et crée ensuite une nouvelle instance dans la classe « user » de l’ontologie
profil et remplit ces instances dans le slot « a_don_perso ».
• inserer_profil : Cette classe permet de compléter l’inscription d’un utilisateur en

remplissant les volets : qualifications, compétences, professions, intérêts, préférences,
dispositifs à l’aide des méthodes suivantes :
inserer_qualification (String [] tSlotName_qualif, String [] tValeur_qualif, String

nom_instance) : Elle insère les données de la table tValeur_qualif donnée en entrée
dans la classe «DCL » de l’ontologie profil dont les slots sont comprises dans la
90
table tSlotName_ qualif. on ajoute cette instance dans la classe « user » à l’instance
nom_instance dans le slot a_les_qualifications.
inserer_ Competence, inserer_Profession, inserer_ interet, inserer_ preference, et

inserer_Dispositif
• inserer_service: Cette classe est utilisée pour la publication d’un service e-Learning en
créant une nouvelle instance dans la classe service de l’ontologie service et en insérant les
données introduites par le fournisseur.
• inserer_option_avancée: Cette classe permet de compléter la publication d’un service

Web en insérant: les outils, les ressources, les tests et les formations à l’aide des
méthodes suivantes :
inserer_matériel(String instance_rec,String[] tSlotName_matériel,String[]

tValeur_matériel) : permet d’ajouter un matériel dans la classe « materiel » de
l’ontologie de service et ajoute cette instance dans la classe « service » dans le slot
a_pour_qualite_apprentissage à l’instance instance_rec.,
inserer_ soft_client ,inserer_ soft_serveur, inserer_ synchrone,
inserer_ asynchrone, inserer_ formation, inserer_ ressource, inserer_ test
• decouverte_service: Cette classe permet la découverte des services Web en comparant la
requête utilisateur avec les descriptions des services dans l’ontologie, et donne ensuite une
table résultat qui contient les services adéquats ordonnés selon leurs poids.
• filtrage_profil : Sert à vérifier pour chaque service de la table résultat donnée par
découverte_service, s’il répond aux préférences de l’utilisateur son poids sera mis à jour sinon il
sera éliminé de la liste des services trouvés et retourne enfin la table des résultats filtrés avec leurs
nouveaux poids.
4.2.3. Les vues Les vues sont les interfaces qui permettent de mettre les utilisateurs en
communication avec l’application
• Vue accueil : C’est la vue qui s’affiche au chargement de l’application. C’est un point
d’accès des utilisateurs.
• Vue debut : C’est l’interface qui s’affiche une fois l’authentification faite. Elle affiche
le profil de l’utilisateur, et lui permet d’effectuer une recherche de services Web, gérer
son profil et publier un service s’il a le privilège.
• Vue inscription : permet à un nouvel utilisateur de s’inscrire à EAsyLearn en lui
proposant de remplir un formulaire d’identification.
91
• Vue profil : Cette interface sert à compléter l’inscription d’un utilisateur en

remplissant des volets comme : qualification, compétence .etc.
• Vue recherche : C’est une interface qui permet d’effectuer une recherche par mots clé
et/ou multicritères sur les Web services e-Learning. L’utilisateur peut choisir aussi
d’introduire son profil pour améliorer la recherche.
• Vue publication : C’est une interface qui permet de publier des Web services e-
Learning en introduisant les informations nécessaires.
• Vue publication_avancee : Cette interface sert à compléter la publication d’un Web
service e-Learning en ajoutant par exemple les outils, les ressources.etc.
• Vue resultat_recherche : Pour afficher les résultats d’une recherche
5. Déploiement de l’application EAsyLearn

Nous avons développé notre application Web avec les technologies JSP et Servlet.
Pour qu’elle soit fonctionnelle, elle a été déployée avec le serveur Apache Tomcat qui est à la
fois serveur HTTP (serveur Apache) et conteneur Servlet/JSP, ce qui fait de lui un candidat
idéal pour le déploiement de notre application.
La figure ci-dessous montre le schéma de déploiement de l’application EAsyLearn.
Figure 33. Schéma de déploiement de l'application EAsyLearn.

Le déploiement de l’application EAsyLearn sous Apache Tomcat s’effectue en plaçant le
répertoire contenant les fichiers de l’application dans le répertoire webapps de Tomcat.
92
6. Les interfaces de l’application

Afin d’illustrer les fonctionnalités du système EAsyLearn, nous avons effectué
quelques prises d’écrans que peut rencontrer un utilisateur au cours de sa session. 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, comme le montre la figure ci-dessous :
Figure 34. Interface principale de l’application.

L’utilisateur introduit son login et son mot de passe. S’ils sont corrects, ils lui donneront accès
à la vue « début » qui contient ses informations personnelles. Cette interface permet à
93
l’utilisateur d’effectuer la recherche, la gestion de son profil et la publication s’il a le

privilège.
A l’aide du menu principal l’utilisateur peut effectuer une recherche de services Web : comme
le montre l’interface suivante :
Figure 35. Interface de recherche.
94
Le résultat de cette recherche est montré par la figure ci-dessous :
Figure 36. Interface résultat de la recherche.

Pour obtenir des résultats plus pertinents et adaptés aux préférences de l’utilisateur, il peut
effectuer une recherche multicritère (choix de la langue, le format de la ressource, la
licence.etc) ou choisit d’utiliser son profil pendant la recherche.
Et voici un exemple de cette recherche :
95
Figure 37. Interface de recherche multicritère.

L’interface suivante montre le résultat de la recherche ci-dessus :
96
Figure 38 : Interface de résultat de recherche
Conclusion
Dans ce chapitre nous avons présenté l’implémentation et le déploiement de notre
application. Nous avons tout d’abord cité les différents outils utilisés lors du développement
de notre système, nous avons ensuite détaillé les principaux modules qui sont la découverte et
la publication des services Web et la gestion du profil utilisateur.
On a montré à travers ce système l’intérêt de l’utilisation des ontologies pour la

description des services (ce qui complète l’annuaire UDDI) 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.
Notre application a été mise en œuvre suivant le modèle MVC qui est un modèle de
conception logicielle très répandu et fort utile, recommandé par des experts de la
programmation Web. Les vues de EAsyLearn sont des pages JSP qui assurent la
communication avec les utilisateurs, le contrôleur est une servlet assurant les liaisons entre les
vues et les modèles qui sont des classes java implémentant les algorithmes de l’application.
Pour mieux expliquer les différentes fonctionnalités du système nous avons effectué
quelques prises d’écran illustrant le module de recherche et de publication.
97
Conclusion et perspectives
Conclusion & Perspectives
Les services Web deviennent des composants technologiques importants dans le

domaine d’intégration d’applications, en effet, ils permettent l’interopérabilité entre divers
logiciels fonctionnant sur diverses plateformes telle qu’une plateforme e-Learning.
La réalisation de la découverte des Web services qui se faisait d’une manière manuelle, est
une tâche clairement difficile, en effet 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. L’objectif
est d'exprimer de manière formelle des informations sémantiques sur les données, pour
qu'elles puissent être exploitées par des ordinateurs. Les ontologies ont un rôle très important
à jouer pour la réalisation du Web sémantique, c’est une représentation pivot pour
l'intégration de sources de données hétérogènes, pour décrire des services Web.
Aujourd’hui, les Web services sémantiques constituent une voie prometteuse
permettant de mieux exploiter les Web services en automatisant, autant que possible, les
différentes tâches liées au cycle de vie d’un service.
Notre travail consiste à réaliser une application de recherche et de sélection de services
Web e-Learning et leur adaptation selon le profil utilisateur et cela à l’aide des ontologies,
l’ontologie DAML-S pour la description sémantique des services Web et une ontologie pour
décrire le profil utilisateur. Cependant, le standard DAML-S ne fournit pas une description
parfaite sur les aspects technologiques et pédagogiques des services Web e-Learning. Afin de
prendre en considération ces aspects, en plus des descriptions fonctionnelles, une ontologie a
été ajoutée à DAML-S dans le travail de Mlle Boudali. Cette ontologie est nommée ‘ontologie
de Qualité de l’Apprentissage’ (QA).et notre projet s’inscrit dans la continuité de ce travail.
Notre application vise à satisfaire un certain nombre d’objectifs pédagogiques en vue

de satisfaire un maximum d’utilisateurs en se dotant des interfaces de recherche et affichage
des résultats adaptables selon les préférences et les besoins des utilisateurs. Le prototype
permet la publication de nouveaux services Web Pour cela, il est doté d’un module permettant
au fournisseur (enseignant ou administrateur), à travers une interface interactive, de publier
des informations concernant le Web service. Il met en œuvre une interface de recherche riche
offrant diverses options : recherche par mot-clé, recherche multicritère, l’interface de
recherche permet aussi d’utiliser le profil utilisateur pour le filtrage et l’adaptation des
résultats selon les préférences de l’utilisateur.
98
Conclusion & Perspectives
Le travail qu’on a réalisé peut être amélioré et enrichi afin d’en faire un système plus
performant. Parmi les perspectives à prendre en compte pour améliorer le fonctionnement du
système, nous citons notamment :
Mettre en œuvre l’application dans des situations réelles d’apprentissage de

publication et de découverte, supportant ainsi l’invocation des Web services.
étendre la solution pour supporter la composition des Web services e-Learning.
Introduire le facteur de satisfaction des utilisateurs concernant les résultats de la

recherche.
99
BIBLIOGRAPHIE
Bibliographie
Bibliographie
[Ankolenkar, 02]: ANKOLENKAR Anupriya, BURSTEIN Mark, HOBBS Jerry, LASSILA
Ora, MARTIN David, MCILRAITH Sheila, NARAYANAN Srini, PAOLUCCI Massimo,
PAYNE Terry, SYCARA Katia & ZENG Honglei, « DAML-S: semantic markup for web
services », (2002).
[Benayache, 05]: Ahcene BENAYACHE, « Construction d’une mémoire organisationnelle

de formation et évaluation dans un contexte e-Learning», Le 05/12/2005.
[Berge, 89]: BERGE C, «Hypergraphs», vol. 45 de North Holland Mathematical Library,

Elsevier Science Publishers B.V. (North-Holland), (1989).
[Berners, 00]: Berners-Lee T, «What the semantic web can represent», (2000).
http://www.w3.org/DesignIssues/RDFnot.html
[Bernstein, 02]: A. Bernstein & M. Klein, « Discovering Services: Towards High Precision
Service Retrieval. In CaiSE workshop on Web Services, e-Business, and the Semantic Web:
Foundations, Models, Architecture, Engineering and Applications». Toronto, Canada, (2002).
[Boutemedjet, 04] : Sabri Boutemedjet, « Web Sémantique et e-Learning ».université de

Montréal, (2004).
[Chauvet, 02] : Chauvet J M., « Services Web avec SOAP, WSDL, UDDI, ebXML », Eyrolles,
p. 19-28, (2002).
[Eiter, 95]: EITER T, GOTTLOB G, « Identifying the Minimal Transversals of a hypergraph

and Related Problems », SIAM Journal on Computing, vol. 24, no 6, p. 1278–1304, (1995).
[Gautier, 04] : Gautier Dallons. « DAML-S : interactions, critique et évaluation ». Institut

d'informatique des FUNDP Namur. Belgique, (2004).
[Gouscos et al, 03]: D. Gouscos, M. Kalikakis, and P. Georgiadis, « An approach to modeling

web services QoS and provision price». Proceedings. Of 1st Internatioal web services quality
workshop –WQW 2003 at WISE 2003. Rome, Italy pp 1-10, (2003).
[Grabinger, 01] : Grabinger, «Extraction d’information et visualisation de systèmes

complexes sémantiquement structurés», thèse de doctorat de l’université de pierre et marie
curie, décembre 2001.
[Gruber, 93]: T. R. Gruber. «A Translation Approach to Portable Ontology Specifications»,

Knowledge Acquisition, (1993).
[Guide, 05] : « e-Learning Guide pratique de l'apprentissage Virtuel en entreprise ».
100
Bibliographie
[Guitton, 06] : Julien Guitton, « Planification multi-agent pour la composition dynamique de

services Web » Rapport de stage – Master 2 Recherche Intelligence Interaction Information,
(2006).
[Hermes, 05] : Association HERMES, « LES SERVICES WEB Présentation générale »

Version 0.0.1, Château du Montet tél, Rue du doyen Marcel Roubault 54500 Vandoeuvre-les-
nancy, 15/02/2005.
[LMS, 03]: « LES LEARNING MANAGEMENT SYSTEMS (LMS) Solutions logicielles de

gestion de la formation ». 2002/2003
[Luana, 08]: Luana De Maggio, «Les plateformes pédagogiques », (2008).

http://www.enseignement.be
[Madjarov, 05] : Ivan Madjarov, «Des services web pour le e-Learning», Laboratoire des
Sciences de l’Information et des Systèmes, 28 octobre 2005.
[Mannila, 94]: MANNILA H. «The Design of Relational Databases», Addison- Wesley,

Wokingham, England, (1994).
[Menascé, 02]: Menascé, D. A, «QoS Issues in Web Services», IEEE Internet Computing,
6(6):72-75, (2002).
[Moeglin, 99] : Moeglin Pierre, Tremblay Gaëtan, « Campus virtuel. Les avatars de la
convergence», in Sciences de la Société n° 47, p.96, Presses Universitaires de Toulouse,
(1999).
[Neches, 91]: R. Neches, R. E. Fikes, T. Finin, T. R. Gruber, T.Senator, and W.R Swartout.
Enabling Technology for Knowledge Sharing. « AI Magazine», pages 12(3): 36.56, (1991).
[Oubahssi, 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).
http://www-lium.univ-lemans.fr/~oubahssi/publications/Theseoubahssi_VFinale.pdf
[Oussama, 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).
[Paolucci, 02]: M. Paolucci, T. Kawamura, T. Payne, and K. Sycara, «Semantic matching of

web services capabilities». In Proceeding of the First International Semantic Web Conference
(ISWC2002), Sardinia, Italy, (2002).
[PAPI 01] IEEE P1484.2.26/D8, 2001-11-25. «Draft Standard for Learning Technology -
Public and Private Information (PAPI) for Learners (PAPI Learner) -Learner Portfolio
Information»
101
Bibliographie
[Paquette, 02] : Paquette G, «Modélisation des connaissances et des compétences, pour

concevoir et apprendre ». Presses de l'Université du Québec, (2002).
[Phan, 05]: PHAN Quang Trung Tien Hanoï, «Ontologies et Web Services», juillet 2005.
[Rahee, 05]: Rahee Ghurbhurn «Introduction aux Web Services», Master Web Intelligence,
(2005).
[Rampacek 06] : Sylvain RAMPACEK, «Sémantique, interactions et langages de
description des services web complexes», Thèse de doctorat (2006).
[Rengarajan, 01] Rengarajan R, «ASPEN LCMS: Click2 Learn’s Comprehensive LCMS

Solution», Click2learn Inc, (2001).
[Rey, 03]: Christophe Rey, «D2CP et computeBCov Un prototype et un algorithme pour la

découverte de services web dans le contexte du web sémantique», LIMOS – CNRS UMR
2239 Université Blaise-Pascal Clermont-Ferrand II, (2003).
[SOAP, 04]: W3C World Wide Web Consortium, «SOAP Version 1.2 Part 1: Messaging
Framework», (2004).
http://www.w3.org/TR/soap12-part1/
[Toumani, 04]: Patrick Kellert et Farouk Toumani, « Les Web services sémantiques», (2004).
[W3C, 04]: W3C, «OWL Web Ontology Language Overview», (2004).
[w3c, 04]: W3C, «Web Services Architecture», W3C Working Group Note 11, Février 2004.
http://www.w3.org/TR/ws-arch
[Zhu, 08]: Zhu Zheng-zhou Wu Zhong-fu Zhou Shang-bo « an e-learning services discovery
algorithm based on user satisfaction », college of computer science and technology
Chongqing University, Chongqing, 400044, China, (2008).
Référence web
[URL, 1]: http://www.techno-science.net/?onglet=glossaire&definition=696
[URL, 2]: http://www.prism.uvsq.fr/index.php?id=64
[URL, 3]: http://www.w3.org/2002/ws/
102
Annexe A
L’ONTOLOGIE QUALITE
D’APPRENTISSAGE
L’ontologie de qualité d’apprentissage (QA)
Une description des plateformes e-Learning selon les caractéristiques pédagogiques,
technologiques et financières s’est avérée nécessaire pour le choix de service Web.
L’ontologie de qualité d’apprentissage (QA) a été élaborée dans cette fin. Cette ontologie a le
schéma suivant :
Qualité
d’apprentissage
Informations
Informations
pédagogiques
financières
Informations
techniques
Est
Figure 1: Ontologie de qualité d’apprentissage.
La classe « Qualité d’apprentissage »

C’est la classe principale de l’ontologie, elle est composée de trois classes qui
décrivent les services Web.
I. La classe « informations pédagogiques » comporte les classes suivantes :
103
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 2 : Ontologie de qualité d’apprentissage – «Informations

pédagogiques».
I .1. La classe « Collaboration » comporte les outils pour la collaboration et la
communication entre acteurs classés en deux types :
• Outil synchrone
• Outil asynchrone
I.2. La classe « Ressource » Englobe les aspects suivants :
• 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
104
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éés par modification et par
suppression.
• Partage : c’est le partage de 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 on a les deux classes
suivantes :
I.3. La classe « Contenu » Les ressources pédagogiques sont décrites par :
• 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.
I.4. La classe « Test »
Cette classe décrit tout ce qui concerne le suivi et l’évaluation des apprenants. 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.
I.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.
105
• 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 : 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.
I.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.
I.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.
I.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.
I.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.
I.10. La classe « Administration pédagogique » Recouvre toutes les fonctionnalités de
gestion pédagogique de formation.
106
• 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.
II. La classe « informations techniques » englobe toutes les informations techniques

sur le web service.
Informations
techniques
Administration
Adaptation
technique
Langue
Aide
Sécurité Matériel
Caractéristiques
Logiciel
techniques
Soft Soft
Serveur Client
Est
Figure 3 : Ontologie de qualité d’apprentissage – le volet « Informations

techniques ».
107
II. 1. La classe « Adaptation » 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 : automatique ou manuelle.
• Type d’adaptation : par rapport à l’individu ou par rapport à un groupe d’individu.
II.2. La classe « Langue » indique si le web service est multilingue, chaque instance de cette
classe indique une langue du service.
II.3. La classe « Sécurité » le niveau de sécurité 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.
II.4. La classe « Caractéristiques techniques » 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.
108
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.
II.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,…
II.6. La classe « Soft du client » Les logiciels exigés au niveau des postes clients.
II.7. La classe « Soft du serveur » Les logiciels exigés au niveau du poste serveur.
II.8. La classe « Matériel » 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.
II.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.
• 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.
II.10. La classe « Administration technique » Englobe les fonctionnalités de gestion de la
plateforme qui sont offertes pour un administrateur technique. Cette classe contient :
• Compte : c’est la gestion des comptes utilisateurs et leurs groupes.
• 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.
109
III. Les informations financières Cette classe comporte trois classes principales :
Informations
financières
Coût Administration
financière
Licence
Est
Figure 4 : Ontologie de qualité d’apprentissage – le volet « Informations

financières ».
III.1. La classe « Coût » Recouvre les coûts affectés au financement des formations, de façon
directe ou indirecte, dans l’institution. Elle comporte:
• 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).
III.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.
III.3. La classe « Administration financière » Recouvre les recettes et dépenses de
formation.
• Contrat : la gestion des contrats.
• Paiement : la gestion des paiements.
110
Annexe B
L’ONTOLOGIE DU PROFIL
PROFIL
L’ontologie du profil utilisateur
Le modèle utilisateur proposé est défini comme une ontologie utilisateur générique,
comprenant diverses caractéristiques d’un utilisateur, à base de concepts, sous concepts et
relations entre les différents concepts.
Identité Info_démog Contacts
Sécurité
But
Info_
Souhaite personnelles
A pour
avoir
Est caractérisé
par
Education A l’éducation
Effectue Activité
Compétences A les Utilisateur A Requêtes

compétences l’historique
A les
A les
qualifications
intérêts
Intérêts
Qualifications
A exercé Possède
A les
préférences
Profession
Dispositif
Préférences Mot clé
DCL
Contenant Contenu Logiciel Matériel

Est
Est
Figure 6: l’ontologie de profil d’utilisateur
111
1. La classe « Utilisateur » C’est la classe centrale de l’ontologie.
1.La classe « Info_personnelles » contient des attributs qui aident à identifier une
personne, cette classe est divisée en trois sous classes :
• La classe « Identité » : comprend 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).
2.La classe « Sécurité » 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.
3.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.
4.La classe « Compétences » Le concept Compétence décrit les compétences associées
avec la formation formelle ou informelle de l’utilisateur et son expérience de travail.
• Domaine : le domaine dans lequel l’utilisateur a une expérience ou une certaine
compétence.
• Outils : définit les outils que l’utilisateur maîtrise.
5.La classe « Qualifications » Les domaines où l’utilisateur est qualifié. Elle comporte :
• 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.
6.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.
• 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.
112
• 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.
7.La classe « Profession » comporte les informations sur 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.
• Période : la période durant laquelle la profession a été exercée.
8.La classe « Dispositif » Décrit les dispositifs matériels et logiciels 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.
9.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.
10. La classe « Requêtes » L’historique des requêtes déjà formulées par l’utilisateur.
11. La classe « Activités » Contient les activités liées au travail, formation de l’utilisateur
(consulter un cours, faire un exercice ou autres).
12. La classe « But » Contient l’information sur les buts des utilisateurs/apprenants.
• 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.
13. La classe « Mots clé » Indique les concepts appartenant à un domaine d’intérêt donné.
Un mot clé est défini par sa description et sa priorité.
113
Annexe C
LE MODELE MVC
Le Modèle MVC (Model View Controller)
C’est un modèle de conception logicielle très répandu et fort utile. Créé dans les années
80 par Xerox PARC pour Smalltalk-80, il est aujourd’hui fortement recommandé dans
l’univers J2EE. Néanmoins il faut retenir que c’est un modèle de conception, et il est donc
indépendant du langage de programmation.
1. Principe
• Un modèle à trois couches
Le MVC est un modèle de conception qui repose sur la volonté de séparer les données, les
traitements et la présentation. Ainsi l’application se retrouve segmentée en trois composants
essentiels :
• le modèle
• la vue
• le contrôleur
Chacun de ces trois composants possède un rôle bien défini.

Le modèle représente les données et les règles métiers. C’est dans ce composant que
s’effectuent les traitements liés au cœur du métier. Les données peuvent être liées à une base
de données, des EJBs, des services Web, … Il est important de noter que les données sont
indépendantes de la présentation. En d’autres termes, le modèle ne réalise aucune mise en
forme. Ces données pourront être affichées par plusieurs vues. Du coup le code du modèle est
factorisé : il est écrit une seule et unique fois puis réutilisé par chaque vue.
La vue correspond à l’IHM. Elle présente les données et interagit avec l’utilisateur.
Dans le cadre des applications Web, il s’agit d’une interface HTML, mais n’importe quel
composant graphique peut jouer ce rôle.
Le contrôleur, quant à lui, se charge d’intercepter les requêtes de l’utilisateur,
d’appeler le modèle puis de rediriger vers la vue adéquate. Il ne doit faire aucun traitement. Il
ne fait que de l’interception et de la redirection.
• Cinématique
• L’utilisateur émet une requête
• Le contrôleur intercepte la requête de l’utilisateur
• Le contrôleur détermine quelle partie du modèle est concernée et quelle vue y est
associée
• Le modèle traite les interactions avec les données, applique les règles métier et renvoie
les données au contrôleur
• Le contrôleur sélectionne la vue et lui renseigne les données
• La vue présente les données à l’utilisateur
114
Figure 7 : MVC model 2
Le MVC très pratique, peut se révéler lourd à mettre en place. Ceci à cause de la
multitude de contrôleur à implémenter. Afin de simplifier la réalisation d’un tel modèle, une
nouvelle version a été introduite : le MVC2. C’est exactement le même modèle de conception
à la différence qu’il n’y a plus qu’un seul contrôleur qui se charge de rediriger la requête vers
le bon traitement.
2. Dans la pratique
• Avantages
A l’époque des applications Web, il n’est pas rare que le développeur soit tenté de
mettre du code de traitement dans les composants de présentation (JSP, PHP, …). Certains
composants facilitent même ce genre de développement!! Le MVC impose cette séparation.
Comme précisé plus haut, plusieurs vues peuvent utiliser le même modèle. Ce qui représente
un gain en coût de développement important.
Le modèle est totalement indépendant de la vue. Si l’application a besoin d’un
nouveau mode d’accès, le modèle restera inchangé. Il suffit juste de changer la partie IHM.
Le modèle étant totalement autonome, il peut être modifié beaucoup plus facilement. En effet
si le mode de persistance des données change ou bien si des règles métier évoluent, il suffit de
modifier seulement le modèle. La vue n’a pas besoin d’être modifiée dans ce cas.
Deux équipes peuvent travailler en parallèle. Une équipe d’infographistes peut travailler sur
les vues et en même temps une équipe de développeurs peut travailler sur le modèle et le
115
contrôleur. Cet aspect nécessite tout de même une bonne communication entre les deux
entités.
Les trois couches doivent être réellement indépendantes et ne doivent communiquer
que par des interfaces. Dans ce cas l’application sera très modulaire et n’importe quelle
couche pourra être interchangée sans conséquence pour les autres.
Le contrôleur permet une très grande souplesse dans l’application. C’est lui qui
assemble différentes parties du modèle avec une vue à partir d’une requête. S’il est maitrisé à
la perfection, la factorisation des vues est envisageable. L’architecte peut alors s’amuser à en
surprendre plus d’un développeur!!
• Inconvénients
Le MVC se révèle trop complexe pour de petites applications. Le temps accordé à
l’architecture peut ne pas être rentable pour le projet.
Même si le code est factorisé, le nombre de microcomposant n’en est pas moins augmenté.
C’est le prix à payer pour la séparation des 3 couches. Et toutes les personnes qui font de la
gestion de configuration comprendront que le nombre important de fichiers représente une
charge non négligeable dans un projet.
3. Conclusion
Le MVC favorise le développement et la maintenance du code. Sur de gros projets
et/ou avec de grandes équipes de développements, l’application d’un tel modèle de conception
se révèle très performant. Il existe aujourd’hui des frameworks très avancés qui se basent sur
le MVC ou le MVC2. L’utilisation de ces frameworks facilite sa mise en place et cadre sa
réalisation.
http://blog.lecacheur.com/2004/12/09/mvc-mvc2-modele-vue-controlleur-model-view-controller/
116

Rapport 2 X

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Rapport 2 X

Încărcat de

Drepturi de autor:

Formate disponibile

Découverte et sélection des web services dans le

cadre du e-Learning selon le profil utilisateur

Mémoire de fin d’études

Réalisé par Encadré par

Découverte et sélection des web services dans le cadre du e-

MEMOIRE PRÉSENTÉ EN VUE DE L'OBTENTION

©ATMANI Hocine, SEFSAFI Soumia, 2009.

En signe d’amour de gratitude et de respect je dédie ce modeste travail :

A la mémoire de mes chers grands parents Cherif et Khedoudja,

A mes sœurs Souad, Mouna et Kahina,

A tous mes amis de la cité et ceux du village qui m’ont

Je dédie ce modeste travail :

Ma maman qui m’abreuve d’amour et d’affection intarissable, source de

A mon unique frère Mustapha,

A ma sœur et amie Assia et notre p’tite et adorable sœur Noufida,

A celui qui m’a supportée pendant neuf mois de travail, et qui a su

A toutes mes amies de l’enfance, et celles de l’ESI en

Louange à Allah tout puissant qui nous a guidés pour l’accomplissement

Nous tenons à remercier particulièrement M.BALLA Amar pour sa

Un grand merci à M.AMROUCHE Hakim qui nous a encadrés au cours

Notre reconnaissance va tout naturellement à Mlle BOUDALI Fatiha

Enfin nous adressons nos sincères remerciements à toute personne qui

Notre projet s’inscrit dans la continuité de ce travail et consiste à concevoir et réaliser un

2.Définition du e-learning ........................................................................................................ 3

3. Les technologies du e-Learning ........................................................................................... 4

3.2. Outils asynchrones .................................................................................................... 5

4. Les plateformes e-Learning ..................................................................................................... 5

5. Les acteurs d’une plateforme .................................................................................................. 8

6. Le Profil utilisateur ................................................................................................................. 9

3. Une architecture étendue pour les services Web ............................................................. 42

2. Les mécanismes de découverte .......................................................................................... 49

2.2. Découverte dynamique des services ....................................................................... 50

3. Quelques travaux de découverte des services Web sémantiques ................................... 53

4. La comparaison des approches étudiées .......................................................................... 63

3. Insuffisance de DAML-S dans le cadre du e-Learning ................................................... 66

4. L’ontologie du profil utilisateur ........................................................................................ 68

5. Architecture du système .................................................................................................... 69

6. Les Diagrammes UML représentatifs du système .......................................................... 70

8. Algorithme de sélection des résultats selon le profil utilisateur ..................................... 81

Chapitre V : Mise en œuvre du système

2. Environnement de développement ................................................................................... 85

5. Déploiement de l’application EAsyLearn ........................................................................ 92

6. Les interfaces de l’application ........................................................................................... 93

Conclusion et perspectives ................................................................ 98

Liste des figures

Le premier chapitre porte sur la conception du système et traite sa modélisation, à base

3. Les technologies du e-Learning

3.1.1 Classes virtuelles et visioconférences :

3.1.2 Télévision interactive (webcasting) : Télévision interactive est une technique

3.1.3 Chat : Echange de message en temps réel via un logiciel spécifique.

4. Les plateformes e-Learning

4.1. Les Learning Management Systems (LMS)

Un LMS (Learning Management System) ou MLE (Managed Learning Environment)

ressources pédagogiques dans un parcours d'apprentissage au sein de la plateforme. Si celle-ci

4.2. Les Learning Content Management Systems (LCMS):

Figure 1. Le rôle du LMS et du LCMS dans la diffusion de contenus éducatifs

Le standard en matière de conception de cours et de plates-formes e-Learning (LMS).

Un cours respectant SCORM sera Réutilisable, accessible, interopérable, durable.

4.3 Comparaison entre LMS et LCMS

• les LMS permettent de créer du contenu, mais de façon souvent limitée.

Figure 2. Couvertures fonctionnelles des LMS et des LCMS [LMS, 03]

5. Les acteurs d’une plateforme

- crée des parcours pédagogiques types et individualisés de son enseignement.