ThèseKBelmabrouk31102017 (Memoire)

‫امجلهورية اجلزائرية ادلميقراطية الشعبية‬
‫وزارة التعلمي العايل و البحث العلمي‬

‫جامعة وهران للعلوم و التكنولوجيا محمد بوضياف‬
Présenté par : Karima Belmabrouk
Intitulé
Modèle multi-agents pour la composition des services Web,
fondé sur des techniques de planification
Faculté : Mathématiques et Informatique
Département : Informatique
Spécialité : Informatique
Option : Informatique
Devant le Jury Composé de :
Membres de Jury Grade Qualité Domiciliation

Mohamed Benyettou Pr Président USTO-MB
Fatima Bendella Pr Encadrant USTO-MB
Maroua Bouzid Pr Co-Encadrant UNICAEN
Ghalem Belalem Pr UNIV-Oran1
Moussa Benaissa Pr Examinateurs UNIV-Oran1

Sid Ahmed Rahal Pr USTO-MB
Année Universitaire : 2016-2017

ii
Résumé
Le Web a remporté un succès phénoménal en permettant des interactions simples
entre les êtres humains et les ordinateurs à l’échelle d’Internet. Les services Web sont
des applications accessibles sur Internet, réalisant chacune une tâche spécifique. Ils
reprennent la plupart des idées et des principes du web, et les appliquent à des inter-
actions entre utilisateurs et ordinateurs. Les utilisateurs du Web ont souvent besoin
de composer différents services pour réaliser une tâche plus complexe qui ne peut
pas être satisfaite par un service individuel. Afin de répondre à cette problématique,
nous proposons dans cette thèse un modèle de composition de services Web à base
d’agents. Notre solution, fondée sur des techniques de planification, permet d’assurer
la composition automatique de services web avec prise en considération de quelques
critères permettant d’assurer au client une meilleure qualité de la composition de
ces services.
Mots clés : Modèle, Agent, Service Web, Composition, Planification.
Abstract
The Web has achieved phenomenal success by allowing simple interactions bet-
ween humans and computers on the Internet. Web services are web-provided applica-
tions, each performing a specific task. They take up most of the ideas and principles
of the web, and apply them to interactions between users and computers. Web users
often need to compose different services to perform a more complex task that can
not be satisfied by an individual service. To solve this problem, we propose in this
thesis a model of composition of web services based on agents. Our solution, using
some planning techniques, ensures the automatic composition of web services with
consideration of few criteria to ensure a better quality of the composition of these
services to the user.
Keywords : Model, Agent, Web Service, Composition, Planification.
iii
iv
Dédicaces
Je dédie ce modeste travail à la mémoire de ma très chère sœur
Mme Fatma Mansouri, née Belmabrouk,
qui s’est brulée comme une bougie pour éclairer ma vie
et celle de ma grande famille.
Aucune dédicace ne saurait être assez éloquente
pour exprimer ce que tu mérites pour tous les sacrifices
que tu n’as cessé de me donner
depuis ma naissance,
durant mon enfance
et même à l’âge adulte.
Tu m’as toujours tout donné, sans rien demander ;
Tu m’as appris que nous ne sommes, sur terre, que des passagers ;
Et que la vraie victoire est de nous rencontrer au paradis !
Que Dieu, le miséricordieux, t’accueille dans son éternel paradis.

Karima
v
vi
Remerciements
Je remercie, du fond de mon cœur, ALLAH, de m’avoir donné le courage et la
santé pour que je puisse achever ce modeste travail.
Mes remerciements s’adressent, aussi, à toute personne ayant contribué à la fi-

nalisation de cette thèse et je tiens à préciser :
– Ma mère Yamina : ”Tout ce que j’ai de bon, c’est à ma mère que je le dois”.
Tu es ma force, mon courage, celle qui fait de moi une bonne personne dans
ce monde. Je te remercie pour tout ce que tu as fais pour moi. Que Dieu te
préserve santé et longue vie !
– Mon mari Anouar : ”Ce travail te doit beaucoup”. Qu’il soit pour toi le
témoignage de ma parfaite reconnaissance pour ces années de compréhension,
de privations et d’efforts communs.
– Mes enfants Oussama, Anes et Ayoub : ”Les enfants sont le trésor le plus
précieux dans la vie”. Une bonne maman doit faire tout ce qu’elle peut pour
donner à ses enfants le sens de la famille. Que vous me pardonniez, surtout
pour tout le temps que j’ai consacré à cette thèse au détriment de mes devoirs
envers vous !
– Ma grande famille : Je remercie tous les membres de ma grande famille, sans
citer des noms ou des prénoms par peur d’oublier une personne. Que vous trou-
viez ici l’expression de ma parfaite reconnaissance pour votre aide précieuse et
vos encouragements.
– Tous mes enseignants : ”Sans vous tous, soyez certains que je ne vaux rien”. Si
je suis entrain de taper ces mots en ce moment, c’est grâce à vous ! Que vous
soyez assurés de mon entière reconnaissance.
– Mon encadreur Pr. Fatima Bendella : ”Votre sérieux est une qualité rare,
en ce moment”. Je n’oublierai jamais votre persévérance pour aller jusqu’au
bout ainsi que vos encouragements pour mener à bien cette thèse. Vous étiez
compréhensives aux moments difficiles. Je vous remercie infiniment et j’avoue
que c’est un grand honneur pour moi de continuer mes futurs travaux de
recherche avec vous.
– Mon co-encadreur Pr. Maroua Bouzid : Je tiens à signaler, que c’est grâce à
vous que j’ai pu définir ma problématique. Que vous trouviez, ici, quelques
mots de reconnaissance pour tout ce que vous avez fait pour moi. Vous m’avez
accueilli dans votre laboratoire à bras ouverts et vous m’avez consacré énormément
de votre temps précieux pour m’orienter et me mettre en contact avec les cher-
cheurs de votre laboratoire, spécialement Dr. Mohamad El Falou que je tiens
à remercier, également, pour son aide précieuse.
– Mes chers professeurs Mohamed Benyettou, Ghalem Belalem, Moussa Benaissa
et Sid Ahmed Rahal : Je suis très reconnaissante de l’honneur que vous me
faites en acceptant de juger ce travail. Veuillez croire à l’expression de ma
grande admiration et mon profond respect.
– Finalement, j’adresse toute ma gratitude à toutes mes amies, spécialement
Mme Nawal Bouali et sa famille, à tous mes collègues de travail et à toutes les
personnes qui m’ont aidé dans la réalisation de ce modeste travail.
vii
viii
Contributions
1. Multi-Agent Based Model for Web Service Composition ; Karima Belma-
brouk, Fatima Bendella, Maroua Bouzid ; International Journal of Advanced
Computer Science and Applications (IJACSA), Volume 7 Issue 3, 2016, DOI :
10.14569/IJACSA.2016.070320.
2. L’Intelligence Interactive au service de l’enseignement ; Fatima Bendella,
Karima Belmabrouk, Hasna Bouazza, Abdelhafidh Chadli et Nassima Ouasti ;
Conférence sur la formation à distance en supports technologiques et pratiques
pédagogiques, Oran, décembre 2014.
3. Computer-assisted problem-based learning for word-based mathematical pro-
blem solving ; Chadli Abdelhafid, Bendella Fatima, Belmabrouk Karima ; The
4th International workshop on Interactive Environments and Emerging Tech-
nologies for eLearning, IEETeL 2013, 4 June 2013, Utrecht, the Nederlands,
http ://ceur-ws.org/Vol-991/paper4.pdf.
4. Modèle de conception d’un Système Multi-Agents à base d’un Réseau de
Pétri ; Karima Belmabrouk, Nassima Ouasti ; 6ème journées scientifiques,
InfoDays’2012, 25 et 26 avril 2012, Université Hassiba Benbouali de Chlef,
Algérie.
5. Agent conversationnel animé pour l’apprentissage du calcul, Nassima Ouasti,
Fatima Bendella, Karima Belmabrouk, 1er Séminaire National sur les Tech-
nologies Educative, SNTE’2012, 06 - 07 Mars 2012, Université 8 Mai 1945,
Guelma, Algérie.
6. Complex System Model based on Multi-Agent Systems and Petri Nets ; Bel-
mabrouk Karima, Bendella Fatima and Benkhedda Samira, The International
Arab Conference on Information Technology, ACIT’2011, Naif Arab University
for Security Science (NAUSS), December 11-14, 2011, Riyadh, Saudi Arabia.
7. Simulation of Human Behavior in Situation of Emergency, Samira Ben-
khedda, Fatima Bendella, Karima Belmabrouk ; 23rd European Modeling and
Simulation Symposium, EMSS 2011, Rome, Italy 12 – 14 September 2011,
Volume : ISBN : 978-1-62993-465-5.
8. Multimedia Mining : P-arbres ou R-arbres pour la représentation des données
multimédia ; Karima Belmabrouk, Yahia Slimani ; Conférence Internationale
sur l’Informatique et ses Applications, CIIA’06, Mai 2006, Saida, Algérie.
9. Structures de données pour le Multimedia Mining ; Karima Draou, Yahia
Slimani ; Colloque International sur : Méthodes et Outils d’Aide à la Décision,
MOAD’04, Novembre 2004, Saida, Algérie.
ix
x
Table des matières
Table des matières . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Table des figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Liste des tableaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Introduction générale 1
1 Contexte et problématique . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3 Approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4 Plan du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
I État de l’art 5
1 Les agents et les systèmes multi-agents (SMA) 7
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 L’intelligence artificielle distribuée (I.A.D) . . . . . . . . . . . . . . . 8
3 Thèmes de recherche de L’I.A.D . . . . . . . . . . . . . . . . . . . . 8
4 Problématique de L’I.A.D . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Les problèmes classiques . . . . . . . . . . . . . . . . . . . . . 9
4.2 Les nouveaux problèmes proprement liés au thème de l’I.A.D. 9
5 Évolution vers les systèmes multi-agents . . . . . . . . . . . . . . . . 9
6 Qu’est-ce qu’un agent ? . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1 Quelques définitions . . . . . . . . . . . . . . . . . . . . . . . 10
6.2 Les caractéristiques multidimensionnelles d’un agent . . . . . . 11
6.3 Différentes catégories d’agents . . . . . . . . . . . . . . . . . 13
7 Les systèmes multi-agents (S.M.A) . . . . . . . . . . . . . . . . . . . 15
7.1 Définition d’un S.M.A . . . . . . . . . . . . . . . . . . . . . . 15
7.2 Les problématiques des S.M.A . . . . . . . . . . . . . . . . . 16
7.3 Avantages et objectifs des S.M.A . . . . . . . . . . . . . . . . 17
8 Coopération . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2 Modèles de Coopération . . . . . . . . . . . . . . . . . . . . . 17
9 Résolution de conflits . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1 Coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2 Négociation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10 La communication dans les S.M.A . . . . . . . . . . . . . . . . . . . 19
10.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.2 Les modes de communication . . . . . . . . . . . . . . . . . . 19
11 Méthodes de conception des S.M.A . . . . . . . . . . . . . . . . . . . 20
xi
TABLE DES MATIÈRES
12 Domaines d’utilisation des agents et des systèmes multi-agents . . . . 21

12.1 Utilisations sans réseau . . . . . . . . . . . . . . . . . . . . . . 21
12.2 Utilisations avec réseau . . . . . . . . . . . . . . . . . . . . . . 22
13 Quelques plateformes de développement des SMA . . . . . . . . . . . 23
13.1 CORMAS (COmmon Ressources Multi-agents System) . . . . 23
13.2 MadKit (Multi-Agents Developpement Kit) . . . . . . . . . . 24
13.3 MAGIQUE (Multi-AGents hiérarchIQUE) . . . . . . . . . . . 24
13.4 SimuLE (Simulations Large Echelle) . . . . . . . . . . . . . . 24
13.5 DIMA (Développement et Implémentation de Systèmes Multi-
Agents) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.6 MAGéo (Modélisation Agent Géographique) . . . . . . . . . . 25
13.7 MATSim (Multi-Agent Transport Simulation) . . . . . . . . . 25
13.8 NetLogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.9 JADE (Java Agent DEvelopement) . . . . . . . . . . . . . . . 26
13.10 VDL (View Design Language) . . . . . . . . . . . . . . . . . . 26
14 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2 Les services Web 27

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2 L’architecture orientée service (SOA) . . . . . . . . . . . . . . . . . . 27
2.1 Le Concept de SOA . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2 Les technologies dédiées au SOA . . . . . . . . . . . . . . . . . 28
2.3 Avantages mesurables de l’architecture SOA . . . . . . . . . . 29
3 Qu’est ce qu’un service Web ? . . . . . . . . . . . . . . . . . . . . . . 29
3.1 Quelques définitions de service Web . . . . . . . . . . . . . . . 29
3.2 Qu’est ce qu’un service Web sémantique ? . . . . . . . . . . . 30
3.3 Les différents types des services Web . . . . . . . . . . . . . . 31
3.4 Les caractéristiques d’un service Web . . . . . . . . . . . . . . 31
3.5 L’intérêt d’un service Web . . . . . . . . . . . . . . . . . . . . 34
4 Architecture Orientée Service Web . . . . . . . . . . . . . . . . . . . 34
5 Technologies de base des services Web . . . . . . . . . . . . . . . . . 35
5.1 eXtensible Markup Langage (XML) . . . . . . . . . . . . . . . 35
5.2 Simple Object Access Protocol (SOAP) . . . . . . . . . . . . . 38
5.3 Web Service Description Language (WSDL) . . . . . . . . . . 39
5.4 Universal Description Discovery and Integration (UDDI) . . . 40
6 Publication, recherche et sélection de services Web . . . . . . . . . . . 43
7 Principes généraux sur la recherche de service Web . . . . . . . . . . 44
7.1 Les différentes approches de recherche et de découverte de
service web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.2 Comparaison des différentes approches de recherche des ser-
vices Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8 Qualité d’un service Web . . . . . . . . . . . . . . . . . . . . . . . . . 56
8.1 Définition de la qualité d’un service Web . . . . . . . . . . . . 56
8.2 Classification des attributs de la QdS . . . . . . . . . . . . . . 56
9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
xii TABLE DES MATIÈRES
3 La planification 61
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2 La planification en intelligence artificielle . . . . . . . . . . . . . . . . 61
3 Planification classique . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.1 Planification dans un espace d’états . . . . . . . . . . . . . . . 62
3.2 Planification dans l’espace de plans . . . . . . . . . . . . . . . 65
4 Planification graphique . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.1 Principe de construction de graphe . . . . . . . . . . . . . . . 68
4.2 Planificateur GRAPHPLAN . . . . . . . . . . . . . . . . . . . 69
5 Planification hiérarchique . . . . . . . . . . . . . . . . . . . . . . . . 69
5.1 Algorithme de résolution HTN . . . . . . . . . . . . . . . . . . 70
5.2 Planificateur HTN . . . . . . . . . . . . . . . . . . . . . . . . 70
6 Planification distribuée . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.1 Planification centralisée pour les plans distribués . . . . . . . . 71
6.2 Planification distribuée pour les plans centralisés . . . . . . . . 71
6.3 Planification distribuée pour les plans distribués . . . . . . . . 71
7 Avantages de la planification . . . . . . . . . . . . . . . . . . . . . . . 71
8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4 La composition des services Web 73

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2 Définition de la composition des services Web . . . . . . . . . . . . . 73
3 Techniques de composition des services Web . . . . . . . . . . . . . . 74
3.1 Classification par rapport au niveau du degré d’automatisation 74
3.2 Classification par rapport à la disponibilité des services . . . . 75
4 Modèles de composition des services Web . . . . . . . . . . . . . . . . 78
4.1 Composition à l’aide de BPEL4WS . . . . . . . . . . . . . . . 79
4.2 Composition à l’aide de OWL-S . . . . . . . . . . . . . . . . . 79
4.3 Composition à l’aide de graphes . . . . . . . . . . . . . . . . . 80
5 Cycle de vie de la composition des services Web . . . . . . . . . . . . 80
6 Quelques travaux sur la composition des services Web . . . . . . . . . 81
7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
II Partie : Notre Contribution 87

5 Le modèle proposé 89
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
2 Travaux de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3 Notre contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.1 Définitions formelles . . . . . . . . . . . . . . . . . . . . . . . 91
3.2 L’architecture générale proposée . . . . . . . . . . . . . . . . . 94
4 L’architecture détaillée du modèle . . . . . . . . . . . . . . . . . . . . 94
4.1 L’architecture de l’AgentQueryAnalyzer . . . . . . . . . . . . 96
4.2 L’architecture de l’AgentPlan . . . . . . . . . . . . . . . . . . 96
4.3 L’architecture de l’AgentDiscovry . . . . . . . . . . . . . . . . 98
4.4 L’architecture de l’AgentService . . . . . . . . . . . . . . . . . 101
5 Définition formelle du processus de planification . . . . . . . . . . . . 102
TABLE DES MATIÈRES xiii
5.1 Principe général et définition formelle du processus . . . . . . 102

5.2 La planification dans notre modèle . . . . . . . . . . . . . . . 102
5.3 Stratégie de recherche d’un plan solution . . . . . . . . . . . . 103
6 Illustration à l’aide d’un exemple : L’organisation d’une conférence . 103
6.1 Transport des conférenciers . . . . . . . . . . . . . . . . . . . 104
6.2 Restauration . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.3 Hôtellerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6 Conception et implémentation d’une ontologie du domaine de voyage107

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
2 Conception de l’ontologie de voyage . . . . . . . . . . . . . . . . . . . 107
2.1 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . 108
2.2 Conceptualisation . . . . . . . . . . . . . . . . . . . . . . . . . 108
2.3 Formalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
3 Implémentation de l’ontologie de voyage sous Protégé . . . . . . . . . 115
3.1 Présentation de l’éditeur Protégé . . . . . . . . . . . . . . . . 115
3.2 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7 Implémentation du modèle et validation 119

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
2 Environnement de développement . . . . . . . . . . . . . . . . . . . . 119
2.1 La plateforme Jade . . . . . . . . . . . . . . . . . . . . . . . . 119
2.2 La plateforme J2EE . . . . . . . . . . . . . . . . . . . . . . . 124
2.3 Le serveur web ”Apache Tomcat” . . . . . . . . . . . . . . . . 124
2.4 AXIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
3 Conception et mise œuvre des projets de validation du modèle . . . . 125
3.1 Premier projet : ”L’analyse de la requête Client pour la re-
cherche et la sélection des services Web” . . . . . . . . . . . . 127
3.2 Deuxième projet : ”La planification de la composition des ser-
vices Web” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Conclusion et perspectives 133
Bibliographie 137
Bibliographie 137
xiv TABLE DES MATIÈRES

Table des figures
1.1 Modèle d’un agent réactif [Ber09]. . . . . . . . . . . . . . . . . . . . . 13

1.2 Cycle Perception Délibération Action d’un agent cognitif. . . . . . . . 14
1.3 Représentation d’un agent en interaction avec son environnement et
les autres agents [Fer95]. . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4 Communication par envoi de message. . . . . . . . . . . . . . . . . . 19
1.5 Communication par partage d’information. . . . . . . . . . . . . . . . 20
1.6 Classification des différents types d’application des SMA [Fer95]. . . . 21
2.1 Architecture SOA [Gan07] . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2 Principe de fonctionnement des services Web [Ref17]. . . . . . . . . . 33
2.3 Architecture WSOA [Bel09] . . . . . . . . . . . . . . . . . . . . . . . 35
2.4 Exemple d’un document XML . . . . . . . . . . . . . . . . . . . . . . 36
2.5 Transmission des données avec XML . . . . . . . . . . . . . . . . . . 37
2.6 Fonctionnement de SOAP [Ref17] . . . . . . . . . . . . . . . . . . . . 38
2.7 Structure d’un message SOAP [Bel09] . . . . . . . . . . . . . . . . . . 38
2.8 Structure d’un document WSDL [Bac14] . . . . . . . . . . . . . . . . 41
2.9 Mapping WSDL −→UDDI . . . . . . . . . . . . . . . . . . . . . . . . 41
2.10 Entités composant un annuaire . . . . . . . . . . . . . . . . . . . . . 42
2.11 Les différentes pages d’un registre UDDI. . . . . . . . . . . . . . . . . 43
2.12 Les principales phases de SPOC [Cla06]. . . . . . . . . . . . . . . . . 47
2.13 L’architecture SPOC [Cla06]. . . . . . . . . . . . . . . . . . . . . . . 48
2.14 L’architecture GODO [GRGS06]. . . . . . . . . . . . . . . . . . . . . 48
2.15 Processus de définition et de mise en œuvre de démarche dans SATIS
[MC09]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.16 Les étapes de l’approche DRISS [DMJ+ 10]. . . . . . . . . . . . . . . . 50
2.17 L’architecture SECSE [ZMZJ07]. . . . . . . . . . . . . . . . . . . . . 51
2.18 AASDU Framework [PC04]. . . . . . . . . . . . . . . . . . . . . . . . 52
2.19 L’architecture WSPAB [AHT+ 08] . . . . . . . . . . . . . . . . . . . . 53
2.20 Classification des attributs de QdS [GRI05]. . . . . . . . . . . . . . . 57
3.1 Problème de planification . . . . . . . . . . . . . . . . . . . . . . . . 62
4.1 Une chorégraphie de services Web [Bel11] . . . . . . . . . . . . . . . . 75

4.2 Une orchestration de services Web [Bel11] . . . . . . . . . . . . . . . 76
4.3 Composition basée sur les Workflows . . . . . . . . . . . . . . . . . . 77
4.4 Le flot de processus avec BPEL4WS [Pel03] . . . . . . . . . . . . . . 79
4.5 Tableau comparatif des travaux de découverte et composition de ser-
vices Web [Bek12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
xv
TABLE DES FIGURES
5.1 Architecture à base d’agents pour la composition automatique de ser-

vices Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.2 L’architecture fonctionnelle de l’AgentQueryAnalyzer . . . . . . . . . 97
5.3 L’architecture fonctionnelle de l’AgentPlan . . . . . . . . . . . . . . . 98
5.4 L’architecture fonctionnelle de l’AgentDiscovry . . . . . . . . . . . . 99
5.5 L’architecture fonctionnelle de l’AgentService . . . . . . . . . . . . . 101
5.6 Principe de planification . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.1 Hiérarchie des classes de l’ontologie du voyage . . . . . . . . . . . . . 110

6.2 Diagramme des relations binaires de l’ontologie du voyage . . . . . . 111
6.3 Aperçu de la hiérarchie des classes de l’ontologie de voyage . . . . . . 117
7.1 Structure d’un message FIPA ACL. . . . . . . . . . . . . . . . . . . . 121

7.2 L’architecture de la plateforme J2EE [You14]. . . . . . . . . . . . . . 125
7.3 Diagramme de séquence de l’approche proposée. . . . . . . . . . . . . 126
7.4 L’AgentQueryAnalyzer et l’AgentDiscovry dans l’interface graphique
de Jade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
7.5 Interface de traitement d’une requête client . . . . . . . . . . . . . . . 128
7.6 Traitement d’une requête guidée . . . . . . . . . . . . . . . . . . . . . 128
7.7 Traitement d’une requête brute . . . . . . . . . . . . . . . . . . . . . 129
7.8 Résultat d’exécution de la requête client . . . . . . . . . . . . . . . . 130
7.9 Processus de planification des services Web . . . . . . . . . . . . . . . 131
xvi TABLE DES FIGURES

Liste des tableaux
1.1 Différence entre agent réactif et agent cognitif . . . . . . . . . . . . . 14
2.1 Tableau comparatif des différentes approches de recherche des services

Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.1 Quelques variantes du langage PDDL . . . . . . . . . . . . . . . . . . 66
6.1 Tableau du glossaire des termes . . . . . . . . . . . . . . . . . . . . . 109

6.2 Dictionnaire des concepts de l’ontologie . . . . . . . . . . . . . . . . . 111
6.3 Table des relations binaires de l’ontologie . . . . . . . . . . . . . . . . 112
6.4 Table des attributs des concepts de l’ontologie . . . . . . . . . . . . . 114
6.5 Table de définition des concepts de l’ontologie (TBOX) . . . . . . . . 116
6.6 Table de définition des rôles de l’ontologie (TBOX) . . . . . . . . . . 116
7.1 Structure d’un message ACL . . . . . . . . . . . . . . . . . . . . . . . 123

7.2 Les résultats correspondant aux différents types d’entrées possibles . 130
xvii
LISTE DES TABLEAUX
xviii LISTE DES TABLEAUX

Introduction générale
1 Contexte et problématique
L’internet est devenu la baguette magique servant ses utilisateurs des différents
endroits du monde de recueillir d’énormes quantités d’information dont ils ont be-
soin. Mais ces utilisateurs du Net n’ont pas besoin, uniquement, de l’information,
ce dont ils ont vraiment besoin, actuellement, dépasse la recherche d’information
à la recherche de service et avance encore plus loin pour exiger l’invocation de ces
services avec prise en considération de plusieurs facteurs, pouvant jouer un rôle très
important dans le cadre de l’optimisation de la qualité de ces services.
Les services Web sont des applications accessibles sur Internet réalisant chacune
une tâche spécifique comme par exemple, réserver un billet d’avion, afficher un re-
levé bancaire, acheter un livre ou autre. Cependant, les services Web ont, pour la
plupart, une utilité limitée puisqu’ils n’effectuent qu’une seule tâche spécifique. Par
exemple, pour partir en vacances, une personne devra trouver un service Web pour
chaque réservation qu’elle désire réaliser (avion, train, hôtel,...).
Pour remédier à ce problème, des services Web peuvent être regroupés pour ne
former, du point de vue de l’utilisateur, qu’un seul service ; on parle alors de la
composition des services Web.
Notre problématique consiste à proposer un modèle pour la composition des

services Web, facilitant aux utilisateurs de l’internet de rechercher leurs services de
façon simple et efficace.
2 Objectif
Après avoir situé nos travaux de recherche, dans la section précédente, parmi la
multitude des axes de recherche présents, actuellement, dans le domaine informa-
tique, de façon générale ; et dans le domaine de l’intelligence artificielle, des agents
et des systèmes multi-agents, des services Web et de la planification, de façon plus
précise. Nous tenons à préciser que notre objectif principal est de proposer un modèle
de composition des services Web à l’aide des agents et que l’approche de composition
adoptée soit fondée sur des techniques de planification.
1
INTRODUCTION GÉNÉRALE
3 Approche
La nécessité de composer des services Web, nous mène à la découverte de différentes
approches pouvant nous aider à la réalisation de cet objectif. Dans ce contexte, nous
avons pu réaliser une synthèse qui nous a permis de faire la distinction entre :
– Une composition manuelle et une composition automatique,

– Une composition statique et une composition dynamique,
– une composition à base d’orchestration et une composition à base de chorégraphie.
Notre synthèse nous a, également, permis de découvrir les principaux modèles de

composition existants, tels que ceux qui utilisent BPEL4WS, OWL-S, les graphes ou
autres. Et ce après avoir découvert plusieurs standards qui ont été créés spécialement
pour décrire, localiser et composer les services Web, tels que UDDI (Universal Des-
cription, Discovery and Integration), WSDL (Web Services Description Language),
WSCI (Web Service Choreography Interface), WSFL (Web Service Flow Language)
et plus récemment WS-BPEL (Web Services Business Process Execution Language).
L’approche que nous avons adopté pour la conception de notre modèle est une
approche :
– Automatique : ce sont les agents du modèle qui vont assurer cette composition,
sans aucune intervention humaine.
– Dynamique : nos agents vont assurer cette composition, quelque soit le service
demandé, avec une auto-organisation permettant leur adaptation pour pouvoir
satisfaire l’utilisateur du service demandé.
En plus des qualifications précédentes de notre approche, nous avons donné un

poids important à la qualité du service composite retourné au client. Et ce afin de
pouvoir prendre en considération les différents critères des utilisateurs introduits
dans le cadre de la recherche et la sélection des services Web demandés par les utili-
sateurs lors de l’exécution de leurs requêtes, assurant ainsi une meilleure qualité de
service.
Cette qualité de service a pris sa part dans la conception de notre modèle au

même degré que l’utilisation de quelques techniques de planification comme celles
qui ont été adoptées par différentes équipes de recherche. Parmi lesquelles, nous
ne pouvons ignorer le rôle qu’a joué l’équipe MAD (Modèle, Agent, Décision) qui
s’intéresse à des problématiques d’intelligence artificielle dans le contexte d’agents
autonomes, pour la définition de notre problématique.
4 Plan du document
Cette thèse est composée de deux parties où :
– La première est un état de l’art sur les principaux domaines de recherche
liés à notre problématique tels que les systèmes multi-agents (SMA), les ser-
vices Web, la planification ainsi que la présentation de quelques travaux de
recherche réalisés pour remédier aux différents problèmes liés à la composition
2 3. APPROCHE
des services Web et,

– La la seconde partie est consacrée à la présentation de notre contribution, et
ce en essayant de détailler le modèle que nous avons proposé pour remédier au
problème de la composition des services Web.
Et nous terminons cette thèse par une conclusion générale et quelques perspectives
pour de futurs travaux de recherche.
4. PLAN DU DOCUMENT 3
4 4. PLAN DU DOCUMENT
Première partie
État de l’art
5
Chapitre 1
Les agents et les systèmes

multi-agents (SMA)
1 Introduction
L’éclatement de l’internet et l’augmentation des capacités des ordinateurs offrent
aujourd’hui des possibilités importantes quant au passage de relais des humains aux
ordinateurs d’une partie de leur effort cognitif. Ainsi, l’arrivée de l’approche orientée
objet avait suscité beaucoup d’espérance et d’intérêt du moment où les concepts
d’encapsulation et d’héritage représentent au mieux le monde réel. Malheureuse-
ment, cette approche s’est avérée insuffisante : malgré les avantages offerts par les
objets, ils restent des structures de données passives et ils dépendent du système
dans lequel ils sont implémentés c’est à dire ils n’ont pas une marge importante
de contrôle sur leur propre comportement. En effet, le besoin qui se faisait le plus
ressentir était d’avoir des entités autonomes et flexibles, qui ont des buts et qui
essaient de leur propre intention de trouver la manière avec laquelle ils doivent agir
et décider afin de les atteindre. Cette entité s’appelle un agent.
D’un autre côté, la puissance de l’intelligence artificielle avec les systèmes à bases
de connaissances (SBC) traditionnels avaient entretenu l’espoir quant à la possibi-
lité qu’un ordinateur puisse remplacer l’être humain. Néanmoins, les SBC qui ont,
surement, prouvé leurs puissance notamment dans le domaine de la médecine et
de la reconnaissance du langage naturel, ont déçu notamment dans les applications
distribuées et/ou temps réel. En effet, le principal handicap des SBC traditionnels
est que le contrôle y est centralisé, ce qui limite les capacités et l’efficacité du système.
Le besoin d’avoir des systèmes où le contrôle est distribué doivent être flexibles,
simples à maintenir et aptes à l’émergence d’organisations. Ces systèmes sont appelés
Systèmes multi-agents (SMA), ce sont des systèmes dont les composantes principales
sont des agents.
Dans ce chapitre, nous présentons un état de l’art sur les agents et les systèmes
multi-agents (SMA) après avoir introduit l’intelligence artificielle distribué (I.A.D)
et avoir mis l’accent sur l’évolution de cette discipline vers les SMA.
7
CHAPITRE 1. LES AGENTS ET LES SYSTÈMES MULTI-AGENTS (SMA)
2 L’intelligence artificielle distribuée (I.A.D)

L’évolution des domaines d’application de l’I.A. pour recouvrir des domaines
complexes et hétérogènes tels que l’aide à la décision, la reconnaissance et la compréhension
des formes, la conduite des processus industriels, etc., a montré les limites de l’ap-
proche classique de l’I.A. qui s’appuie sur une centralisation de l’expertise au sein
d’un système unique.
Les travaux menés au début des années 70 sur la concurrence et la distribution
ont contribué à la naissance d’une nouvelle discipline : l’Intelligence Artificielle Dis-
tribuée (I.A.D)[FG88]. L’I.A.D a pour but de remédier aux insuffisances de l’ap-
proche classique de l’I.A. en proposant la distribution de l’expertise sur un groupe
d’agents devant être capables de travailler et d’agir dans un environnement commun
et résoudre les conflits éventuels d’où la naissance de notions nouvelles en I.A, telles
que la coopération, la coordination d’actions, la négociation et l’émergence.
L’I.A.D peut alors être définie comme étant la branche de l’I.A qui s’intéresse à
la modélisation de comportement ”intelligent” (jusque là c’est la définition de l’I.A
classique) par la coopération entre un ensemble d’agents [Huh87].
3 Thèmes de recherche de L’I.A.D

Après avoir défini l’I.A.D et la différence entre celle-ci et l’I.A classique, nous
présentons trois axes fondamentaux dans la recherche en I.A.D :
– Les systèmes multi-agents (S.M.A) : il s’agit de faire coopérer un en-
semble d’agents dotés d’un comportement intelligent et de coordonner leurs
buts et leurs plans d’actions pour la résolution d’un problème. C’est le thème
auquel nous nous intéressons le plus[GDK87].
– La résolution distribuée des problèmes (R.D.P) : elle s’intéresse à la

manière de diviser un problème particulier sur un ensembles d’entités dis-
tribuées et coopérantes. Elle s’intéresse aussi à la manière de partager la
connaissance du problème et d’en obtenir la solution[LC87].
– L’intelligence artificielle parallèle (I.A.P) : elle concerne le développement

de langages et d’algorithmes parallèles pour l’I.A.D. L’I.A.P vise l’amélioration
des performances des systèmes d’intelligence artificielle sans, toutefois, s’intéresser
à la nature du raisonnement ou au comportement intelligent d’un groupe
d’agents. Cependant, il est vrai que le développement de langages concurrents
et d’architectures parallèles peut avoir un impact important sur les systèmes
d’I.A.D [Dav80].
4 Problématique de L’I.A.D
Les problèmes que l’I.A.D s’attachent à résoudre peuvent être divisés en deux
classes : la première concerne les problèmes classiques de l’I.A qui ont pris une
nouvelle dimension dans le contexte multi-agents. La seconde regroupe les nouveaux
problèmes proprement liés au thème de l’I.A.D.
8 2. L’INTELLIGENCE ARTIFICIELLE DISTRIBUÉE (I.A.D)
4.1 Les problèmes classiques

Dans cette première classe on peut citer :
– La modélisation de la connaissance et le problème de sa répartition

sur les différents agents : comment formuler, décomposer, allouer des
problèmes et synthétiser les résultats d’un groupe d’agents ?
– Les problèmes de génération de plans d’actions : où il faut prendre en

considération la présence d’autres agents.
– La gestion des conflits entre les agents : de points de vue différents des
agents et le maintien de la cohérence des décisions et des plans d’actions.
– Le problème de la communication : comment permettre la communica-

tion et l’interaction entre les agents ? Quel langage et quel protocole faut-il
employer ? Une communication dans les univers multi-agents n’est plus une
simple tâche d’entrée-sortie, mais doit être modélisée comme un acte pouvant
influer sur l’état des autres agents.
4.2 Les nouveaux problèmes proprement liés au thème de

l’I.A.D.
Les problèmes de cette seconde classe peuvent être divisés en deux sous classes :
– Les problèmes spécifiques au groupe d’agents : qui portent sur l’organi-

sation, l’architecture de l’ensemble des agents et les paradigmes de coopération
et d’action ;
– Les problèmes liés au comportement d’un agent au sein d’un groupe :

On s’intéresse aux capacités sociales d’un agent telles que le partage des
tâches, le partage des ressources, le raisonnement sur les autres agents (pou-
voir modéliser leurs connaissances et être en mesure de connaı̂tre leurs plans
d’actions et de raisonner en fonction de ces plans).
D’autres thèmes de recherche sont présents dans le contexte des systèmes multi-
agents, à savoir, le raisonnement temporel, le raisonnement hypothétique, la représentation
de la connaissance imprécise, etc[Ber09].
5 Évolution vers les systèmes multi-agents

Contrairement à l’approche centralisée de l’I.A, l’intelligence artificielle distribuée
vise la distribution de l’expertise sur un ensemble de composants qui communiquent
pour atteindre un objectif global (élaboration d’un diagnostic, résolution d’un problème,
etc.). Cette approche nécessite la division du problème en sous-problèmes. Mais cette
hypothèse n’est pas toujours réaliste car beaucoup de problèmes ne peuvent être par-
titionnés de cette manière [Gin85].
5. ÉVOLUTION VERS LES SYSTÈMES MULTI-AGENTS 9

Une extension des systèmes de l’I.A.D est proposée : les composants doivent
être capables de raisonner sur les connaissances et les capacités des autres dans le
but d’une coopération effective. Pour ce faire, ils doivent être dotés de capacités
de perception et d’action sur leur environnement et doivent posséder une certaine
autonomie de comportement, on parle alors d’agents et par conséquent de systèmes
multi-agents[GDK87].
6 Qu’est-ce qu’un agent ?

Le concept d’agent a été l’objet d’étude pendant plusieurs décennies dans différentes
disciplines. Il a été utilisé dans les systèmes à base de connaissances, la robotique,
le langage naturel et d’autres domaines de l’intelligence artificielle, et aussi dans des
disciplines comme la philosophie et la psychologie. Aujourd’hui, avec l’avènement
de nouvelles technologies et l’expansion de l’Internet, ce concept est encore associé
à plusieurs nouvelles applications comme agent ressource, agent courtier, assistant
personnel, agent interface, agent ontologique, etc. Dans la littérature, on trouve
une multitude de définitions d’agents. Elles se ressemblent toutes, mais elles sont
différentes selon le type d’application pour laquelle est conçu l’agent.
6.1 Quelques définitions

Nous trouvons dans [FN71] une discussion sur les différentes définitions attribués
aux agents ainsi que la différence entre un agent et un programme classique. A titre
d’exemple, voici l’une des premières définitions de l’agent donnée par Jacques Ferber
dans [FG88, Fer95] :
Définition 1 [FG88]
On appelle agent une entité physique ou abstraite qui est capable d’agir sur
elle-même et sur son environnement, qui dispose une représentation partielle de cet
environnement, qui, dans un univers multi-agents, peut communiquer avec d’autre
agents, et dont le comportement est la conséquence de ses observations, de sa
connaissance et de ses interaction avec d’autre agents.
Définition 2 [Fer95]
Un agent est une entité autonome, réelle ou abstraite, qui est capable d’agir sur
elle-même et sur son environnement, qui, dans un univers multi-agents, peut com-
muniquer avec d’autres agents, et dont le comportement est la conséquence de ses
observations, de ses connaissances et des interactions avec les autres agents.
Il ressort de cette définition des propriétés clés comme l’autonomie, l’action, la per-
ception et la communication. D’autres propriétés peuvent être attribuées aux agents.
Nous citons en particulier la réactivité, la rationalité, l’engagement et l’intention.
Définition 3 [WJ95]
Wooldridge et Jennings ont proposé la définition suivante : ”Un agent est un
système informatique, situé dans un environnement, et qui agit d’une façon auto-
10 6. QU’EST-CE QU’UN AGENT ?
nome pour atteindre les objectifs (buts) pour lesquels il a été conçu”.
Définition 4 [Sho93]
Un agent selon Shoham est une entité qui fonctionne continuellement et de
manière autonome dans un environnement où d’autres processus se déroulent et
d’autres agents existent.
Définition 5 [Wei04]
Weiss a défini l’agent comme suit : ”Un agent est une ”entité computationnelle”,
comme un programme informatique ou un robot, qui peut être vue comme percevant
et agissant de façon autonome sur son environnement. On peut parler d’autonomie
parce que son comportement dépend au moins partiellement de son expérience”.
Définition 6 [RN95, RN10]

Récemment, Stuart Russell et Peter Norvig ont, également, proposé la définition
suivante : ”Un agent est une entité qui perçoit son environnement et agisse sur
celui-ci”.
6.2 Les caractéristiques multidimensionnelles d’un agent

Plusieurs propriétés sont reliées aux agents mais un agent ne possède pas forcément
toutes ces propriétés. Celles qui sont le plus énoncées dans la littérature sont [Ben09b] :
– La nature : agents physiques ou virtuels.
– L’autonomie : l’agent est plus ou moins indépendant de l’utilisateur, des

autres agents, et des ressources (U.C, mémoire, etc.). Il est capable d’agir sans
l’intervention d’un tiers (humain ou agent) et contrôle ses propres actions ainsi
que son état interne.
– L’environnement : c’est l’espace dans lequel l’agent va agir ; celui-ci peut

se réduire au réseau constitué par l’ensemble des agents. l’agent est capable
d’agir sur son environnement à partir des entrées sensorielles qu’il reçoit de ce
même environnement. Exemples : systèmes de contrôle de processus, systèmes
embarqués, etc.
– La capacité représentationnelle : l’agent peut avoir une vision très locale

de son environnement, mais il peut aussi avoir une représentation plus large
de cet environnement et notamment des agents qui l’entourent.
– La flexibilité : l’agent dans ce cas est :
– capable de répondre à temps : l’agent doit être capable de percevoir

son environnement et d’élaborer une réponse dans les temps requis,
6. QU’EST-CE QU’UN AGENT ? 11

– pro-actif : l’agent doit exhiber un comportement pro-actif et opportuniste,

tout en étant capable de prendre l’initiative au bon moment,
– social : l’agent doit être capable d’interagir avec les autres agents (logiciels
et humains) quand la situation l’exige afin d’accomplir ses tâches ou aider
ces agents à accomplir les leurs.
– La communication : l’agent aura plus ou moins de capacités à communi-

quer avec les autres agents.
– Le raisonnement : l’agent peut être lié à un système expert ou à d’autres

mécanismes de raisonnements plus ou moins complexes.
– La quantité de ses congénères : le système peut contenir de quelques-uns

un à plusieurs milliers d’agents.
– Le contrôle : il peut être totalement distribué entre les agents mais peut
être voué à une certaine classe d’agents comme les agents facilitateurs.
– L’anticipation : l’agent peut plus ou moins avoir les capacités d’anticiper

les événements futurs.
– La granularité ou complexité : l’agent peut être très simple comme un

neurone mais aussi plus complexe.
– La contribution : l’agent participe plus ou moins à la résolution du problème

ou à l’activité globale du système.
– L’efficacité : l’agent et sa rapidité d’exécution, d’intervention.
– La bienveillance : l’agent a plus ou moins le devoir d’aider ses congénères

plutôt que de s’opposer à eux.
– L’intentionnalité : Un agent intentionnel est un agent guidé par ses buts.

Une intention[Sea69] est la déclaration explicite des buts et des moyens d’y
parvenir. Elle exprime donc la volonté d’un agent d’atteindre un but ou d’ef-
fectuer une action.
– La rationalité : Un agent rationnel est un agent qui suit le principe suivant

(dit principe de rationalité)[New04] : Si un agent sait qu’une de ses actions
lui permet d’atteindre un de ses buts, il la sélectionne . Les agents rationnels
disposent de critères d’évaluation de leurs actions, et sélectionnent selon ces
critères les meilleures actions qui leur permettent d’atteindre le but. De tels
agents sont capables de justifier leurs décisions.
– L’adaptabilité : un agent adaptatif est un agent capable de contrôler ses

aptitudes (de communication, de comportement, etc.) selon l’agent avec qui il

interagit. Un agent adaptatif est un agent d’un haut niveau de flexibilité.
– L’engagement : La notion d’engagement [Bon90] est l’une des qualités es-

sentielles des agents coopératifs. Un agent coopératif planifie ses actions par
coordination et négociation avec les autres agents. En construisant un plan
pour atteindre un but, l’agent se donne les moyens d’y parvenir et donc s’en-
gage à accomplir les actions qui satisfont ce but ; l’agent croit qu’il a élaboré,
ce qui le conduit à agir en conséquence.
– L’intelligence : On appelle agent intelligent un agent cognitif, rationnel,

intentionnel et adaptatif.
6.3 Différentes catégories d’agents

On peut classer les agents selon plusieurs critères mais par la suite on tiendra
compte d’un seul mode de classification qui est la granularité et qui détermine le
processus de décision de l’agent. La taxonomie des agents se fait selon :
– La granularité : agent réactif ou agent cognitif.
– La mobilité : agent mobile (ou nomade) et agent stationnaire.
– La fonctionnalité : agent logiciel, agent d’information, agent de commerce,
agent assistant (secrétaire virtuelle).
Dans la littérature, on distingue deux grandes catégories d’agents et ceci en se ba-
sant sur leur modèle de décision : les agents réactifs et les agents cognitifs. On peut
aussi parler d’agent hybride qui se situe entre ces deux extrêmes et qui regroupe
les propriétés des agents réactifs et des agents cognitifs. Chaque type d’agent est
différent des autres types sur le plan comportemental, structural et interactif :
a. Les Agents réactifs : Les agents réactifs n’ont pas une représentation ex-
plicite de leur environnement et ne tiennent pas compte de leurs actions
passées. Ils ont un comportement de type stimulus / réponse (perception/action).
Les agents réagissent ainsi à des changements survenant dans leur environne-
ment à travers des actions prédéfinies auparavant. La figure 1.1 montre bien
le mécanisme évoqué. Un système multi-agents constitué uniquement d’agents
Figure 1.1 – Modèle d’un agent réactif [Ber09].
réactifs requiert un nombre élevé d’agents pour pouvoir parler d’un système in-
6. QU’EST-CE QU’UN AGENT ? 13
telligent. En effet, l’interaction entre ces différents agents permet l’émergence

d’une intelligence bien que le comportement d’un seul agent tende vers la
simplicité. [Dro93] présente un exemple d’agents réactifs qui simulent le com-
portement d’une société de fourmis au sein du projet MANTA (Modeling an
ANThil Activity). Il montre que bien qu’une fourmi ne peut effectuer qu’une
action simple, prédéfinie et sans aucune intelligence, l’ensemble des fourmis
peut effectuer des actions complexes et évoluées, et ainsi faire émerger un
comportement intelligent.
b. Les Agents cognitifs : Contrairement aux agents réactifs, les agents cog-
nitifs (ou délibératifs ou intentionnels) ont une représentation plus globale de
leur environnement (de soi, du groupe, des autres, de la tâche), ils possèdent
une faculté de raisonnement et de choix de l’action adéquate selon les chan-
gements perçus afin d’atteindre un but précis et d’une manière optimale (voir
figure 1.2). Ils ont aussi une faculté d’apprentissage qui permet de les qualifier
d’agent intelligent. Ainsi un agent cognitif possède des buts, des connaissances
et des désirs et peut s’adapter et réagir à des situations nouvelles sans une
intervention humaine ou extérieure.
Figure 1.2 – Cycle Perception Délibération Action d’un agent cognitif.
De ce fait, on peut dire qu’un agent cognitif possède un état mental qui se
base sur les notions de connaissances, de la croyance, de l’intentionnalité et de
l’engagement. Tous ces concepts vont être réunis à l’intérieur de l’agent selon
l’architecture qui va être adoptée afin de définir une structure agençant les
composants de ce dernier.
Le tableau 1.1 résume les différences entre les deux approches : cognitive et
réactive.
Systèmes d’agents cognitifs Systèmes d’agents réactifs
Représentation explicite de l’environnement Pas de représentation explicite
Peut tenir compte de son passé Pas de mémoire de son historique
Agent complexe Fonctionnement stimulus/action
Petit nombre d’agents Grand nombre d’agents
Table 1.1 – Différence entre agent réactif et agent cognitif

7 Les systèmes multi-agents (S.M.A)

7.1 Définition d’un S.M.A
Un système multi-agents est un système distribué composé d’un ensemble d’agents.
Contrairement aux systèmes de l’IA, qui simulent dans une certaine mesure les capa-
cités du raisonnement humain, les SMA sont conçus et implantés idéalement comme
un ensemble d’agents interagissants, le plus souvent, selon des modes de coopération,
de concurrence ou de coexistence.
Définition [Fer95]
1. Un environnement E, c’est-à-dire un espace disposant généralement d’une
métrique.
2. Un ensemble d’objets O. Ces objets sont situés, c’est-à-dire que, pour tout
objet, il est possible, à un moment donné, d’associer une position dans E. Ces
objets sont passifs, c’est-à-dire qu’ils peuvent être perçus, créés, détruits et
modifiés par les agents.
3. Un ensemble A d’agents, qui sont des objets particuliers (A inclu dans O),
lesquels représentent les entités actives du système.
4. Un ensemble de relations R qui unissent des objets (et donc des agents) entre
eux.
5. Un ensemble d’opérations Op permettant aux agents de A de percevoir, pro-
duire, consommer, transformer et manipuler des objets de O.
6. Des opérateurs chargés de représenter l’application de ces opérations et la
réaction du monde à cette tentative de modification, que l’on appellera les lois
de l’univers.
La figure 1.3 donne une illustration de la notion de système multi-agents.
Figure 1.3 – Représentation d’un agent en interaction avec son environnement et

les autres agents [Fer95].
7. LES SYSTÈMES MULTI-AGENTS (S.M.A) 15

Un SMA est généralement caractérisé par :

– chaque agent a des informations ou des capacités de résolution de problèmes
limitées, ainsi chaque agent a un point de vue partiel,
– il n’y a aucun contrôle global du système multi-agents,
– les donnés sont décentralisées,
– le calcul est asynchrone.
7.2 Les problématiques des S.M.A

Selon Ferber [Fer95], il est possible de relever cinq problématiques principales
lors de la création d’un système multi-agents (SMA) :
La problématique de l’action :
Cela revient à répondre à des questions du genre : comment un ensemble d’agents
peut agir de manière simultanée dans un environnement partagé ?, et comment cet
environnement interagit en retour avec les agents ? Les questions sous-jacentes sont
entre-autres celles de la représentation de l’environnement par les agents, de la col-
laboration entre agents et de la planification multi-agents.
La problématique de l’agent et de sa relation avec le monde :

L’agent doit être capable de mettre en œuvre les actions qui répondent au mieux
à ses objectifs. Cette capacité à la décision est liée à un ”état mental” qui reflète les
perceptions, les représentations, les croyances et un certain nombre de paramètres
”psychiques” (désirs, tendances...) de l’agent. La problématique de l’individu et de
sa relation au monde couvre aussi la notion d’engagement de l’agent vis-à-vis d’un
agent.
La problématique de l’interaction :
La problématique de l’interaction s’intéresse aux moyens de l’interaction (quel
langage ? quel support ?), et à l’analyse et la conception des formes d’interaction
entre agents. Les notions de collaboration et coopération.
La problématique de l’adaptation :
Il s’agit de l’adaptation en terme d’adaptation individuelle ou apprentissage
d’une part et d’adaptation collective ou évolution d’une autre part.
La problématique de l’implémentation :
Enfin, il reste la question de la réalisation effective des SMA, en structurant
notamment les langages de programmation en plusieurs types allant du langage de
type L5, ou langage de formalisation et de spécification, au langage de type L1 qui
est le langage d’implémentation effective. Entre les deux, on retrouve le langage
de communication entre agents, de description des lois de l’environnement et de
représentation des connaissances.
16 7. LES SYSTÈMES MULTI-AGENTS (S.M.A)
7.3 Avantages et objectifs des S.M.A

Les S.M.A sont des systèmes idéaux pour représenter des problèmes qui possèdent
de multiples méthodes de résolution, de multiples perspectives. L’approche S.M.A
est justifiée par les propriétés :
– La modularité.
– La vitesse, avec le parallélisme.
– Fiabilité, due à la redondance.
– Traitement symbolique au niveau de connaissances.
– La réutilisation et la portabilité.
– L’intervention des schémas d’interaction sophistiqués (coopération, coordina-
tion, négociation).
Les deux objectifs majeurs de recherche dans le domaine des S.M.A sont :
1. l’analyse théorique et expérimentale des mécanismes.
2. La résolution de programmes distribués.
Pour résoudre deux genres de problèmes :
– Modéliser, expliquer et simuler des phénomènes naturels.
– La réalisation de systèmes informatiques complexes.
8 Coopération
8.1 Définition
La coopération est nécessaire quand un agent ne peut pas atteindre ses buts
sans l’aide des autres agents. Cette situation est fréquente même chez des espèces
primitives, édification d’une fourmilière par exemple. Souvent les buts nécessitant
la coopération sont des buts sociaux, ils assurent la survie du groupe ou de l’espèce.
Quelquefois, ce sont des buts individuels, un agent qui en aide un autre peut attendre
une aide en retour ou se faire payer son travail. Un agent peut avoir besoin d’un
autre agent parce que cet agent a des compétences qu’il n’a pas, ou parce qu’il faut
être plusieurs pour réaliser la tâche (pousser un objet trop lourd). La coopération
n’est pas forcément consciente, elle peut résulter d’un comportement automatique,
comme la construction des ruches ou des termitières.
Jacques Ferber propose la définition suivante [Fer95] : On dira que plusieurs
agents coopèrent, ou encore qu’ils sont dans une situation de coopération, si l’une
des deux conditions est vérifiée :
1. L’ajout d’un nouvel agent permet d’accroı̂tre différentiellement les perfor-
mances du groupe.
2. L’action des agents sert à éviter ou à résoudre des conflits potentiels ou actuels.
Il suffit alors que l’une de ces deux conditions soit vérifiée pour que l’on puisse
juger la situation étudiée comme coopérative.
8.2 Modèles de Coopération

Quelque soit l’organisation d’une société d’agents, un agent peut coopérer suivant
les modèles suivants [VS87] :
8. COOPÉRATION 17
– Coopération par partage de tâches et de résultats, avec la possibilité de prendre

en compte localement les plans des autres.
– Commande : un agent supérieur A décompose le problème en sous problèmes
qu’il répartit entre les autres agents Xi. Ceux-ci le résolvent et renvoient les
solutions partielles à A.
– Appel d’offre : A décompose le problème en des sous-problèmes dont il diffuse
la liste. Chaque agent Xi qui le souhaite envoie une offre : A choisit parmi
celles-ci et distribue les sous-problèmes. Le système travaille ensuite en mode
commande.
– Compétition : dans le mode compétition, A décompose et diffuse la liste des
sous-problèmes comme dans le mode appel d’offre, chaque agent Xi résout un
ou plusieurs sous-problèmes et envoie les résultats correspondants à A qui à
son tour fait le tri.
9 Résolution de conflits
Les agents coopératifs ont besoin d’éviter autant que possible les situations
conflictuelles pour résoudre un problème. Pour ce faire, ils peuvent être amenés
à coordonner leurs activités et négocier leurs actions pour arriver à une solution.
9.1 Coordination
Les agents travaillent sur des problèmes dont les solutions sont utiles pour les
autres agents. Leur travail doit donc être coordonné dans le temps. La coordination
[GDK87] permet aux agents de considérer toutes les tâches et de ne pas dupliquer
le travail. La coordination des actions est liée à la planification et à la résolution des
conflits, car c’est à ce niveau qu’on tient compte des actions (plans) des autres agents.
Dans les systèmes d’IAD, la coordination des actions des agents peut s’organiser
suivant deux schémas principaux [Fer95] : une coordination au moyen d’un système
capable de déterminer et de planifier globalement les actions des différents agents
ou à l’inverse, on décide de donner une totale autonomie aux agents qui, à leur tour,
identifient les conflits pour les résoudre localement.
On peut distinguer deux types de coordination :
– la coordination due à la gêne (problème de navigation : les agents doivent
coordonner leurs plans de navigation pour s’éviter mutuellement),
– la coordination due à l’aide (manutention : dans un environnement multi-
robots, les agents doivent synchroniser leurs actions pour pouvoir agir effica-
cement et transporter un objet [Peg88]).
9.2 Négociation
Les activités des agents dans un système distribué sont souvent interdépendantes
et entraı̂nent des conflits. Pour les résoudre, il faut considérer les points de vue des
agents, les négocier, et utiliser des mécanismes de décision concernant les buts sur
lesquels le système doit se focaliser [Che92]. La négociation est caractérisée par :
– Un nombre faible d’agents impliqués dans le processus.
18 9. RÉSOLUTION DE CONFLITS
– Un protocole minimal d’actions : proposer, évaluer, modifier et accepter ou

refuser une solution. Le problème de la négociation ne consiste pas forcément
à trouver un compromis mais peut s’étendre à la modification des croyances
d’autres agents pour faire prévaloir un point de vue.
10 La communication dans les S.M.A

10.1 Définition
La communication est l’ensemble des processus physiques et psychologiques par
lesquels s’effectue l’échange d’information entre un ou plusieurs agents (émetteurs )
avec un ou plusieurs agents ( récepteurs ), en vue d’atteindre certains objectifs.
10.2 Les modes de communication

Il existe deux principaux modes de communication : la communication par envoi
de messages et la communication par partage d’informations.
Communication par envoi de messages

Les agents sont en liaison directe et envoient leurs messages directement et ex-
plicitement au destinataire. La seule contrainte est la connaissance de l’agent des-
tinataire : ” Si un agent A connaı̂t l’agent B alors il peut entrer en communication
avec lui”. Les systèmes fondés sur la communication par envoi de messages relèvent
d’une distribution totale à la fois de la connaissance, des résultats et des méthodes
utilisées pour la résolution du problème (voir figure 1.4)
Figure 1.4 – Communication par envoi de message.
Communication par partage d’information

Les composants ne sont pas en liaison directe mais communiquent via une struc-
ture de données partagée, où on trouve les connaissances relatives à la résolution
(état courant du problème) qui évolue durant le processus d’exécution. Cette manière
10. LA COMMUNICATION DANS LES S.M.A 19
de communiquer est l’une des plus utilisées dans la conception des systèmes multi-
experts. L’exemple parfait d’utilisation de ce mode de communication est l’archi-
tecture de blackboard, on parle plutôt de sources de connaissances que d’agents.
Ce mode de communication n’existe pas dans les systèmes multi-agents où l’on dis-
pose que d’une vision partielle du système alors que la communication par partage
d’informations suppose l’existence d’une base partagée sur laquelle les composants
viennent lire et écrire (voir figure 1.5).
Figure 1.5 – Communication par partage d’information.
11 Méthodes de conception des S.M.A

Les S.M.A sont souvent des systèmes complexes qui demandent de longs efforts
de développement, il devient nécessaire de développer de façon systématique des
systèmes opérationnels.
Plusieurs méthodes d’analyse et de conception des S.M.A ont été proposées

récemment. La plupart d’entre elles, s’appuient sur des techniques de modélisation
empruntées à des méthodes connues en développement orienté objets ou en ingénierie
des connaissances pour aider à la construction des modèles d’agents, de l’architec-
ture du S.M.A, pour la spécification des modèles d’organisation, d’interaction, etc.
Pour mettre en œuvre un S.M.A, il faut gérer globalement le cycle de vie des
agents, la communication entre les agents et le contrôle des agents du système. Le
cycle de vie d’un S.M.A est géré par un processus de management qui peut être
centralisé même si le processus propre au S.M.A est distribué. Ce processus de ma-
nagement comporte :
– Une phase d’initialisation : où les agents sont créés et initialisés. D’autres
agents peuvent être crées ensuite si certains agents ont la possibilité d’en créer.
– Une phase de comportement : qui consiste à transmettre les messages et

à donner la possibilité aux agents du système d’exécuter leur comportement
avec répétition jusqu’à ce qu’une condition d’arrêt soit rencontrée.
20 11. MÉTHODES DE CONCEPTION DES S.M.A

– Une phase de terminaison : où tous les agents du S.M.A doivent être
supprimés pour redonner un environnement propre. Tous les agents doivent
donc être référencés, soit par le système, soit par un autre agent.
12 Domaines d’utilisation des agents et des systèmes

multi-agents
Les domaines d’application des systèmes multi-agents sont particulièrement riches.
Nous en citerons seulement les principales directions, toute recherche d’exhaustivité
aboutissant à une sclérose a priori d’un domaine de recherche en pleine évolution.
D’après Ferber [Fer95] On peut considérer qu’il existe cinq grandes catégories d’ap-
plications des systèmes multi-agents (voir figure 1.6 ) :
– la simulation multi-agents,
– la résolution de problèmes au sens large,
– la robotique distribuée,
– la construction de mondes hypothétiques et
– la conception kénétique de programmes.
Figure 1.6 – Classification des différents types d’application des SMA [Fer95].
Une autre classification des domaines d’application des agents permet de distinguer
le fait qu’un agent est utilisé dans un réseau ou sans réseau :
12.1 Utilisations sans réseau

Dans un environnement ne disposant pas de réseau, plusieurs rôles d’agents
peuvent être distingués tels que :
Les assistants
Ce sont des agents qui travaillent pour et avec vous. Le plus célèbre d’entre eux
est sûrement l’assistant de Microsoft Office. En effet, cet assistant surveille tout ce
12. DOMAINES D’UTILISATION DES AGENTS ET DES SYSTÈMES 21
MULTI-AGENTS
que vous faites et vous propose des astuces pour aller plus vite (raccourcis claviers,
manipulation à la souris...).
Les jeux
Des agents permettent de faire fonctionner des avatars, c’est à dire, les joueurs
gérés par l’ordinateur. En effet, lorsque c’est l’ordinateur qui joue, il y a de fortes
chances pour que ce soit un agent qui joue.
La robotique
Dans ce cas, on n’est plus dans le domaine de l’informatique. Le petit robot qui
transporte des charges, la tondeuse ou la balayeuse automatique, ce sont des agents.
Autres utilisations
D’autres applications utilisent des agents, mais leur diffusion est marginale : les
applications de recherche en reconnaissance de forme, reconnaissance de parole...
12.2 Utilisations avec réseau

C’est les plus prometteurs pour l’avenir. En effet le développement rapide d’In-
ternet a entraı̂né le développement des agents mobiles, c’est à dire, des agents qui
peuvent se déplacer sur le réseau. Les différentes utilisations possibles sont :
La recherche d’information
La recherche d’information est une des applications la plus souvent mise en
avant lorsque l’on parle d’agents. En effet, la quantité d’informations disponible sur
Internet étant gigantesque, il est impossible pour un Homme de trouver la bonne
information. Même si des moteurs de recherche (Yahoo, Alta Vista...) existent, il
est très vite fastidieux de rechercher une information. Dans ces conditions, un agent
mobile qui peut se déplacer de site en site à la recherche d’informations peut se
révéler très utile. De plus cet agent peut être ”intelligent” et mémoriser, par exemple,
les préférences de l’utilisateur ou les recherches antérieures pour accélérer la récolte
des informations.
La surveillance
Parfois, le problème n’est pas de savoir où se trouve l’information mais quand
est-ce qu’elle va s’y trouver. Dans ce cas, les agents peuvent aussi se révéler utiles.
Prenons l’exemple des cours boursiers : En France les cours boursiers sont disponibles
sur Internet (Bourse de Paris, Yahoo - Finance...). On sait donc où est l’information,
il faut maintenant savoir quand l’information va devenir intéressante. Ainsi, on peut
envoyer un agent sur le serveur de la bourse en lui disant d’attendre jusqu’à ce qu’une
action atteigne un certain cours puis de revenir nous faire un rapport. Quand l’agent
est sur le serveur de la bourse, il peut revenir à tout moment. Vous avez alors deux
solutions :
22 12. DOMAINES D’UTILISATION DES AGENTS ET DES SYSTÈMES
MULTI-AGENTS
– Vous restez connecté et l’agent revient vous faire un rapport dès que le cours
est atteint.
– Vous ne restez pas connecté et l’agent attend que vous vous connectiez pour
faire son rapport.
Le commerce électronique
Avec le développement du commerce électronique, l’utilisation d’un agent qui fait
vos courses est de plus en plus envisageable. Par exemple si vous voulez aller de Paris
à New-York-York en avion, un agent peut aller dans les agences de voyages et revenir
avec la liste des vols, les horaires et bien sûr les prix. Il peut ensuite vous proposer
le meilleur compromis horaire/prix et effectuer la réservation à votre place. Prenons
un autre exemple : un site accueille des agents qui achètent ou vendent des voitures.
Si vous voulez vendre une voiture, vous envoyez un agent avec les informations
concernant votre voiture (prix, couleur, marque, année, options...). Si vous voulez
acheter une voiture, vous envoyez aussi un agent en précisant la voiture de votre
rêve. Dans les deux cas, les agents vont négocier à votre place l’achat ou la vente de
votre voiture.
Calcul parallèle
Une application beaucoup plus informatique des agents est le calcul parallèle.
Un calcul complexe peut s’exécuter facilement sur plusieurs machines en utilisant
des agents : Il suffit d’envoyer des agents pour effectuer de petites parties du calcul
sur des machines différentes. Ainsi, on utilise plusieurs ordinateurs pour effectuer le
calcul et le résultat est obtenu plus rapidement.
Les jeux
Enfin, l’application la moins utile, mais peut être celle qui va se servir le plus
des agents : les jeux en réseau. Les joueurs programment des agents qui vont sur
un serveur de jeu. Les agents jouent alors ensemble. Si le serveur de jeu est à Las
Vegas, votre agent pourrait jouer votre propre argent au poker.
13 Quelques plateformes de développement des

SMA
Plusieurs plateformes ont été développées, dans le but de fournir aux program-
meurs d’applications à base d’agents un environnement convenable. Une présentation
des plus connues est faites dans les paragraphes suivants :
13.1 CORMAS (COmmon Ressources Multi-agents System)

C’est un framework de développement de systèmes multi-agents, open-source et
basé sur le langage Java et plus précisément le langage-objets SmallTalk . Spatialisé,
il est centré sur des problématiques de recherche en sciences du développement et
13. QUELQUES PLATEFORMES DE DÉVELOPPEMENT DES SMA 23
de négociation entre acteurs [BBPL98, BBLB16].
13.2 MadKit (Multi-Agents Developpement Kit)

C’est une plateforme multi-agents modulaire écrite en Java et conçue selon le
modèle d’organisation Alaadin AGR (Agent/ Group/ Role), développée en 1996
par Olivier GETKNECHT et Michel FERBER au Laboratoire d’Informatique, de
Robotique et de Microélectronique de Montpellier (LIRMM) de l’Université Mont-
pellier II. C’est une plate-forme libre pour l’utilisation dans l’éducation où les agents
sont situés dans des groupes et jouent des rôles. Elle est dotée d’un environnement
de développement graphique facilitant la construction des applications. C’est une
plateforme multi-agents modulaire écrite en Java et construite autour du modèle
organisationnel [Fer09, GFM00].
13.3 MAGIQUE (Multi-AGents hiérarchIQUE)

C’est une plateforme de développement multi-agents développée par l’équipe
SMAC du laboratoire LIFL de l’université de Lille. Elle propose à la fois un modèle
organisationnel, basé sur une organisation hiérarchique par défaut, et un modèle
d’agent, qui est basé sur une construction incrémentale des agents. C’est une plate-
forme pour agents physiquement distribués écrite en Java [MBR01].
13.4 SimuLE (Simulations Large Echelle)

Ce projet a pour objectif d’étudier les techniques logicielles à mettre en oeuvre
pour réaliser des systèmes multi-agents réactifs situés à large échelle où un agent est
positionné dans un espace métrique et il se déplace pour mener à bien ses actions.
Le comportement des agents obéit à des règles simples étroitement dépendantes de
leur environnement physique et social. L’objectif principal de ce type de systèmes
est de pouvoir passer à une échelle de simulation de plusieurs milliers ou dizaines
de milliers d’agents, en conservant des comportements non triviaux affichables en
temps réel. C’est le Large échelle [MP05].
13.5 DIMA (Développement et Implémentation de Systèmes

Multi-Agents)
C’est un environnement de développement de systèmes multi-agents réalisé dans
le cadre de la thèse de Zahia Guessoum en 1996 et dont l’implémentation a com-
mencé en 1993. Il a été utilisé pour développer plusieurs applications réelles (Venti-
lation artificielle, simulation de modèles économiques, etc.)dans différents domaines
tels que la simulation, la résolution de problèmes ou les systèmes de contrôle ayant
des contraintes de temps réel. La première version de DIMA a été implémentée en
Smalltalk-80 et a été ensuite portée en JAVA [GB96].
24 13. QUELQUES PLATEFORMES DE DÉVELOPPEMENT DES SMA

13.6 MAGéo (Modélisation Agent Géographique)

C’est une plateforme de simulation multi-agents dédiée aux problématiques spa-
tialisées et multi-niveaux. Elle intègre en un seul outil toutes les phases du cycle de
vie d’un modèle, de la conception à la réalisation et jusqu’à la simulation dans l’es-
pace et le temps permettant la validation. Chaque modèle est conçu sous forme gra-
phique à travers son modèle conceptuel (ou ontologie). L’ontologie du modèle repose
sur le méta-modèle AOC qui intègre les entités Agent, Organisation, Comportement
et qui permet de décrire des modèles complexes et multi-niveau. MAGéo permet
d’imaginer une gamme très importante de modèles dynamiques et répond aux be-
soins des modèles les plus exigeants. C’est une plateforme de recherche développée
par l’équipe d’intelligence artificielle de l’Université de Technologie de Compiègne,
sous la direction de Jean-Paul Barthès [LBD15].
13.7 MATSim (Multi-Agent Transport Simulation)

C’est un framework, open-source depuis 2013, qui fournit un cadre pour implémenter
des simulations de transport à grande échelle fondées sur des agents. Le cadre de
développement se compose de plusieurs modules qui peuvent être combinés ou uti-
lisés en autonomie. Les modules peuvent être remplacés par des implémentations
propres à tester des aspects uniques de votre propre travail. Actuellement, MATSim
offre un cadre pour la modélisation de la demande, la simulation de la mobilité (simu-
lation de flux de trafic), la planification, un contrôleur des simulations itératives ainsi
que des méthodes d’analyse de la sortie générée par les modules. Le projet MATSim
a été lancé vers 2006 dans le but de générer des modèles de trafic et d’encombrement
en suivant des voyageurs synthétiques individuels grâce à leur programme d’activités
quotidien ou hebdomadaire. Depuis lors, il est passé d’une collection de programmes
C++ autonomes à un framework intégré basé sur Java, hébergé publiquement, dispo-
nible open-source, testé automatiquement par régression. Il est actuellement utilisé
par environ 40 groupes à travers le monde [HNA16].
13.8 NetLogo
C’est un environnement de simulation des phénomènes naturels et sociaux à base
d’agents. Il a été créé par Uri Wilenski en 1999 et son développement est poursuivi
de manière continue par le ”Center for Connected Learning and Computer-Based
Modeling”. NetLogo convient tout particulièrement à la modélisation de systèmes
complexes évoluant au cours du temps. Les modélisateurs peuvent donner des
instructions à des centaines ou des milliers d’agents opérant indépendamment
les uns des autres. Ce qui permet d’explorer les liens entre les comportements des
individus à leur niveau et les schémas généraux (comportements de groupe ou de
masse) qui émergent des interactions entre de nombreux individus [Wil99, Wil17].
13. QUELQUES PLATEFORMES DE DÉVELOPPEMENT DES SMA 25

13.9 JADE (Java Agent DEvelopement)

C’est un framework de développement de systèmes multi-agents, open-source
implémenté en Java [BCRP17]. Il est open-source et distribué par Telecom Ita-
lia sous la license LGPL. Il offre en particulier des outils de validation syntaxique
des messages entre agents basé sur les ontologies. Il permet le développement de
système multi-agents en mettant à disposition des outils graphiques. JADE est
conforme aux spécifications FIPA (Foundation for Intelligent Physical Agents) pour
l’interopérabilité des systèmes multi-agents intelligents. Le plus utilisé des standards
de la FIPA est un standard de langage de communication ACL (Agent Communi-
cation Language). Tout comme KQML, ce dernier est basé sur la théorie des actes
de langage : les messages sont des actions ou des actes communicatifs, car ils sont
prévus pour effectuer une certaine action en vertu de l’envoi.
13.10 VDL (View Design Language)

C’est une plateforme qui propose un modèle d’interaction directe fondé sur la
théorie des actes de langage. Ce langage de communication modélise en plus des
performatifs proposés par le modèle FIPA, des performatifs permettant d’utiliser les
capacités de raisonnement des agents. Le langage VDL est un langage de program-
mation d’agent basé sur la réécriture d’arbres XML. L’objectif du modèle VDL est
de programmer des composants logiciels autonomes et interactifs (agents) capables
d’accéder au moment de l’exécution à la description de leurs propres actions. Un
agent VDL est un composant logiciel qui intègre en une seule représentation la des-
cription des données qu’il manipule, sa sémantique, la description de ses actions et
ses capacités d’interaction [Sab08].
14 Conclusion
Dans ce chapitre, nous avons présenté une étude de l’univers des agents, tout en
essayant de clarifier la terminologie du domaine : I.A.D, agent et systèmes multi-
agents. Les SMA sont largement répandus et développés autour du monde. Ils sont
parmi les domaines les plus porteurs en Intelligence Artificielle.
Vu que le domaine des SMA est en pleine expansion et qu’il est encore mystérieux
par rapport à la majorité de nos étudiants, et vu le rôle important que vont jouer les
agents dans notre modèle, nous avons jugé indispensable de consacrer plusieurs sec-
tions dans ce chapitre pour pouvoir éclaircir les principaux concepts liés aux agents
et aux systèmes multi-agents.
Dans le chapitre suivant, nous allons présenter les services Web avant de passer
à la présentation de la relation entre les SMA et les services Web.
26 14. CONCLUSION
Chapitre 2
Les services Web
1 Introduction
Le Web a remporté un succès phénoménal en permettant des interactions simples
entre les êtres humains et les machines. Les services Web reprennent la plupart des
idées et des principes du Web, et les appliquent à des interactions entre utilisa-
teurs et ordinateurs. Ces dernières doivent être basées sur des architectures fiables
et stables. Ce qui explique l’abandon des architectures centralisées (client/serveur)
au profit des architectures distribuées. Les services Web sont un sujet complexe,
intégrant plusieurs domaines informatiques (documents, sécurité, programmation,
implémentation, etc.). Le nombre de normes est impressionnant, mais est dépassé
par la multitude de solutions d’implémentation. Notre objectif dans ce chapitre est de
présenter un état de l’art sur les services Web. Différentes sections sont consacrées à
leur définition, la présentation de leur utilité, l’énumération de leurs caractéristiques,
la présentation de leur architecture, leur fonctionnement et nous terminons par la
présentation de leurs avantages et leurs inconvénients.
2 L’architecture orientée service (SOA)

L’architecture orientée service ou en anglais ”Service Oriented Architecture (SOA)”
est un modèle d’interaction applicatif qui met en œuvre des services avec une forte
cohérence interne (par l’utilisation d’un format d’échange pivot, le plus souvent
XML) et des couplages externes ”lâches” (par l’utilisation d’une couche d’interface
interopérable, le plus souvent un service Web).
2.1 Le Concept de SOA

Le service est l’unité atomique d’une architecture SOA. Une application est un
ensemble de services qui dialoguent entre eux par des messages. Le couplage entre
services est un couplage lâche et les communications peuvent être synchrones ou
asynchrones. Le service peut :
– Être codé dans n’importe quel langage ;
– S’exécuter sur n’importe quelle plateforme (matérielle et logicielle).
Le service doit :
– Offrir un ensemble d’opérations dont les interfaces sont publiées ;
27
CHAPITRE 2. LES SERVICES WEB
– Être autonome (disposer de toutes les informations nécessaires à son exécution :

pas de notion d’état) ;
– Respecter un ensemble de contrats (règles de fonctionnement) ;
– Correspondre aux processus métier et fonctions mutualisables au niveau de
l’entreprise afin d’aligner l’informatique aux changements des décisions stratégiques
et tactiques. Voir la figure 2.1.
Figure 2.1 – Architecture SOA [Gan07]
Le service englobe et propose les fonctionnalités des composants du système. Ces

systèmes peuvent aussi être définis comme des couches applicatives. L’architecture
orientée service est une réponse très efficace aux problématiques que rencontrent les
entreprises en termes de réutilisabilité, d’interopérabilité et de réduction de couplage
entre les différents systèmes qui implémentent leurs systèmes d’information.
2.2 Les technologies dédiées au SOA

Les Web Services proposent un mécanisme de communication standard pour
faire dialoguer deux applications basées sur des technologies hétérogènes. La com-
munication repose, le plus souvent, sur l’échange de messages XML. Ils fournissent
les normes pour assurer l’interopérabilité entre les différentes applications logicielles
s’exécutant sur des plateformes variées. Ils fournissent également un langage (WSDL)
décrivant les services couplés de façon flottante, indépendamment des contextes
dans lesquels sont utilisés ces services, ainsi qu’un registre (UDDI) pour publier et
découvrir des services. Les Web Services permettent de faire la distinction entre un
service et l’agent qui l’exécute, avec pour objectif de pouvoir substituer de nouveaux
agents tout en continuant à livrer les mêmes services[Kre01].
Les architectures SOA ont été popularisées avec l’apparition de standards liés
aux services Web dans l’e-commerce (commerce électronique) (B2B, inter-entreprise,
ou B2C, d’entreprise à consommateur), basés sur des plateformes comme J2EE ou
.NET.
Au sein de l’architecture orientée services, on distingue les notions d’annuaire,

de bus, de contrat et de service, ce dernier étant le noyau et le point central d’une
28 2. L’ARCHITECTURE ORIENTÉE SERVICE (SOA)
architecture orientée services. La déclinaison ou plus précisément l’implémentation

de la SOA qui se propose entièrement sur internet est la WOA (Web Oriented
Architecture)[Kre01].
2.3 Avantages mesurables de l’architecture SOA

Parmi les avantages de l’architecture SOA on peut citer [Ref17] :
– Améliorer la qualité des applications.
– Donner à des utilisateurs un meilleur accès à l’information et aux possibilités
dont elles ont besoin.
– Augmenter la productivité, l’efficacité et la satisfaction.
– Réduire le temps-à-marché.
– Fournir les nouveaux dispositifs, nouvelles possibilités plus rapidement.
– Augmenter la facilité de faire des affaires.
– Le faciliter pour intégrer avec des clients, des associés, et des fournisseurs.
– Améliorer l’uniformité dans les systèmes.
– Extérioriser la fonctionnalité d’infrastructure.
– Serrer la sécurité, assurer la conformité.
– Réduire les coûts.
3 Qu’est ce qu’un service Web ?

Les services Web relient des sites aux applications pour apporter des fonction-
nalités que des composants simples ne pourraient fournir. Ils permettent aux appli-
cations de communiquer et d’offrir un service à travers le Web sans se préoccuper
du système d’exploitation ou du langage de programmation. Un service Web est
indépendant de la plateforme, c’est une évolution vers un nouveau modèle d’infor-
mation distribué sur internet. Différents exemples de services peuvent être offerts
via le net tels que :
– La conversion d’une monnaie suivant le taux de change.
– L’organisation d’un voyage organisé.
– Le retrait d’un relevé de compte bancaire ou CCP.
3.1 Quelques définitions de service Web

Souvent, un service Web est considéré comme une application accessible à d’autres
applications sur le Web. Plusieurs définitions ont été proposées, nous présentons ici
quelques unes tirées de différentes sources d’information :
Définition 1 [BH03] :
Le consortium W3C 1 a donné la définition suivante : ”Un service Web est un
système logiciel identifié par un URI, dont les interfaces et liaisons publiques sont
définies et décrites à l’aide de XML. Sa définition peut être découverte par d’autres
1. World Wide Web Consortium (http ://www.w3.org) : une communauté internationale qui
élabore des protocoles et des standards pour assurer la croissance du Web à long terme.
3. QU’EST CE QU’UN SERVICE WEB ? 29
systèmes logiciels. Les services Web peuvent interagir entre eux d’une manière pres-
crite par leurs définitions, en utilisant des messages XML portés par les protocoles
Internet”.
Définition 2 [ACKM04] :
Une définition plus précise est fournie par le consortium UDDI, qui caractérise
les services Web comme des applications métiers autonomes et modulaires qui ont
des interfaces ouvertes, orientées vers Internet et basées sur des standards.
Définition 3 [Wik17] :
Selon Wikipédia 2 : ”Un service Web est un protocole d’interface informatique de
la famille des technologies Web permettant la communication et l’échange de données
entre applications et systèmes hétérogènes dans des environnements distribués. Il
s’agit donc d’un ensemble de fonctionnalités exposées sur internet ou sur un intranet,
par et pour des applications ou machines, sans intervention humaine, de manière
synchrone ou asynchrone. Le protocole de communication est défini dans le cadre
de la norme SOAP dans la signature du service exposé (WSDL). Actuellement, le
protocole de transport est essentiellement HTTP(S)”.
Définition 4 [Pon08] :
Julien Ponge a, également, proposé une défintion très acceptable dans [Pon08] :
”Les services Web sont une nouvelle génération d’applications Web. Ce sont des
applications modulaires autonomes, auto-descriptibles, qui peuvent être publiées,
localisées et invoquées sur le Web. Les services Web exécutent des fonctions, allant
de simples demandes à des processus commerciaux compliqués..., une fois qu’un
service Web est déployé, d’autres applications (et d’autres services Web) peuvent
découvrir et invoquer le service déployé”.
Définition 5 [BSS17]
Dans le dictionnaire technique en ligne Webopedia 3 , un service Web est défini
comme une manière standardisée d’intégrer des applications Web à l’aide des
normes ouvertes XML, SOAP, WSDL et UDDI sur un squelette de protocole In-
ternet. XML est utilisé pour marquer les données, SOAP est utilisé pour transférer
les données, WSDL est utilisé pour décrire les services disponibles et UDDI est uti-
lisé pour répertorier les services disponibles”.
3.2 Qu’est ce qu’un service Web sémantique ?

Selon Céline LOPEZ-VELASCO, un service Web est dit sémantique si sa des-
cription intègre, en plus de la description fonctionnelle, une dimension sémantique.
2. projet d’encyclopédie collective en ligne, universelle, multilingue et fonctionnant sur le prin-
cipe du wiki. Wikipédia a pour objectif d’offrir un contenu librement réutilisable, objectif et
vérifiable, que chacun peut modifier et améliorer.
3. Webopedia est un dictionnaire en ligne (http ://www.webopedia.com)
30 3. QU’EST CE QU’UN SERVICE WEB ?
Cette dimension englobe toute description complémentaire (du fournisseur, des ob-
jectifs du service Web, etc.) de la description fonctionnelle qui permet d’ajouter de
l’information à la description classique du service Web. Cette information peut en-
suite être traitée par des mécanismes (tels que l’inférence) afin d’en extraire de la
connaissance [LV08]. Les services Web sémantiques sont à la convergence de la tech-
nologie de services Web et du Web sémantique[KT03], ce sont des services Web à
descriptions dotées de sémantique. Actuellement les services Web sont décrits par le
langage WSDL qui permet de définir les opérations et les paramètres autorisés par le
service Web. Cela est fait en attribuant des noms aux opérations et aux paramètres,
puis associer ces paramètres à des types abstraits de données (string, char,...) .
3.3 Les différents types des services Web

Les services Web sont variés. D’après Alonso et al. dans [ACKM04], deux types
de services Web sont distingués :
Les services Web à base fonctionnelle

Ces services sont invoqués par l’envoi d’un message. Après l’invocation, le service
répond par le résultat sans interagir avec le client au cours de l’exécution. Ce type
de Web service est défini généralement par l’ensemble de ses paramètres d’entrée et
de sortie, et par les pré-conditions et les effets d’exécution du service.
Les services Web à base de processus

Ce sont les services composés de plusieurs activités (sous-services). Leurs inter-
actions avec leur client ne sont pas limitées à une simple invocation, mais nécessitent
parfois plusieurs interactions (itératives ou conditionnelles) pour répondre aux be-
soins du client. Amazon.com 4 est un exemple de service à base de processus. En
effet, pour acheter un livre, le client doit sélectionner le livre en envoyant son nom.
Ensuite, il doit vérifier que le livre est disponible en stock, enfin il l’ajoute dans
son panier et indique le mode et l’adresse de livraison pour pouvoir passer à l’étape
de payement. A cette étape, Amazon.com lui demande les informations de carte
bancaire et prend contact avec sa banque pour vérifier les coordonnées de la carte
bancaire afin d’effectuer la livraison. Ce type de services est défini généralement par
des systèmes de transition à états.
3.4 Les caractéristiques d’un service Web

La technologie des services Web repose principalement sur une représentation
standard des données (interfaces, messageries) au moyen du langage XML. Cette
technologie est devenue la base de l’informatique distribuée sur Internet et offre
beaucoup d’opportunités au développeur Web [Cer02]. Un service Web possède les
caractéristiques suivantes :
– Il est accessible via le réseau.
4. Amazon.com, Inc. est une entreprise de commerce électronique américaine basée à Seattle. Sa
spécialité initiale est la vente de livres, mais elle s’est diversifiée dans d’autres produits, notamment
dans la vente de tous types de produits culturels.
– Il dispose d’une interface publique (ensemble d’opérations) décrite en XML.

– Ses descriptions (fonctionnalités, comment l’invoquer et ou le trouver ?) sont
stockées dans un annuaire.
– Il communique en utilisant des messages XML, ces messages sont transportés
par des protocoles Internet (Dans la plupart du temps HTTP, mais rien n’empêche
d’utiliser d’autres protocoles de transfert tels que : SMTP, FTP, BEEP...).
– L’intégration d’application en implémentant des services Web produit des
systèmes légèrement couplés, le demandeur du service ne connaı̂t pas forcément
le fournisseur. Ce dernier peut disparaı̂tre sans perturber l’application cliente
qui trouvera un autre fournisseur en cherchant dans l’annuaire[Cer02]. Par
légèrement couplée, on sous-entends que le Web Service et le programme (le
client) qui l’invoque peuvent être modifiés indépendamment l’un de l’autre.
Cela veut aussi dire que, contrairement à une composante logicielle qui serait
fortement couplée, il n’est pas nécessaire de connaı̂tre la machine, le langage, le
système d’exploitation ou tout autre détail, pour qu’une communication puisse
avoir lieu. Cela offre une flexibilité qui permet aux entreprises d’éviter les coûts
engendrés par l’intégration via des communications fortement couplées.
Les principaux acteurs d’un service Web
1. Le fournisseur ”Service Provider” : Le fournisseur de service met en

application le service Web et le rend disponible sur Internet. Il s’agit ici de
l’acteur qui propose le service. Ce service peut être de toute nature (un progiciel
de gestion de comptabilité, un module d’achat en ligne, une consultation de
catalogue). Pour proposer ce service le fournisseur doit généralement publier la
description technique du service (comment l’utiliser, l’appeler, ce qu’il renvoie)
et permettre un accès (standard) à ce service.
2. L’annuaire ”Service Registry” : L’annuaire est un registre de services qui
fournit un endroit central où les programmeurs peuvent publier de nouveaux
services ou en trouver d’autres. Cet acteur a pour but de lister l’ensemble des
services disponibles à travers le réseau. Il sert en quelque sorte d’annuaire de
pages jaunes permettant à tout client de chercher et trouver le service voulu. Il
permet ensuite au client de se rediriger vers le fournisseur qui publie le service.
3. Le client ”Service Requester” : Le client est l’acteur qui désire utiliser un
service. Il doit localiser le service, l’invoquer et interagir avec lui. il s’agit de
n’importe quel consommateur du service Web. Le demandeur utilise un service
Web existant en ouvrant une connexion réseau et en envoyant une demande
en XML-REST, XML-RPC, SOAP. L’architecture des Services Web fait que
le développeur du client soit libre d’en choisir l’implémentation puisqu’il n’est
pas techniquement contraint par l’implémentation du service utilisé. Le client
peut Être soit autonome, soit un module intégrer au sein d’un système d’in-
formation auquel cas les informations échangées avec le service émaneront ou
seront réceptionnées par le système d’information[Kre01].
Les interactions entre ces trois acteurs suivent plusieurs étapes :
32 3. QU’EST CE QU’UN SERVICE WEB ?

– publication du service : le fournisseur diffuse les descriptions de ses services

Web dans l’annuaire.
– La recherche du service : le client cherche un service particulier, il s’adresse

à un annuaire qui va lui fournir les descriptions et les URL des services de-
mandés afin de lui permettre de les invoquer.
– L’invocation du service : une fois que le client récupère l’URL et la des-

cription du service, il les utilise pour l’invoquer auprès de son fournisseur.
Principe de fonctionnement d’un service Web

Le principe général de fonctionnement des services Web est le suivant :
1. Le Service Web qui a été créé doit tout d’abord s’enregistrer auprès d’un
distributeur.
2. Un client se connecte sur le serveur (distributeur) pour rechercher un Service
Web correspondant à ses besoins.
3. Le serveur lui retourne une liste des Services Web disponibles.
4. Le client choisit son service Web et l’invoque en contactant le fournisseur.
5. Le service Web répond au client (début des échanges).
6. Les services Web quelque soit leur implémentation ou la plateforme sur laquelle
ils tournent, fonctionnent tous de la même façon. La figure 2.2 présente ce
modèle générique de fonctionnement.
Figure 2.2 – Principe de fonctionnement des services Web [Ref17].

3.5 L’intérêt d’un service Web

L’utilisation des services Web engendre plusieurs avantages tel qu’il a été men-
tionné dans [BL03, Ref17, Cer02, MN12] :
– L’interopérabilité : C’est la capacité des services Web d’interagir avec d’autres

composantes logicielles via des éléments XML et utilisant des protocoles de
l’Internet. Les services Web fournissent un lien entre applications. Ainsi, ces
applications utilisant des technologies différentes peuvent envoyer et recevoir
des données au travers de protocoles compréhensibles par tout le monde.
– La simplicité : Les services Web réduisent la complexité des branchements

entre les participants. Cela se fait en ne créant la fonctionnalité qu’une seule
fois plutôt qu’en obligeant tous les fournisseurs à reproduire la même fonction-
nalité à chacun des clients selon le protocole de communication supporté.
– La normalisation : Les services Web sont normalisés car ils utilisent les
standards XML et HTTP pour transférer des données et ils sont compatibles
avec de nombreux autres environnements de développement. Ils sont donc
indépendants des plates-formes. C’est dans ce contexte qu’un intérêt très par-
ticulier a été attribué à la conception des services Web puisqu’ils permettent
aux entreprises d’offrir des applications accessibles à distance par d’autres en-
treprises. Cela s’explique par le fait que les services Web n’imposent pas de
modèles de programmation spécifiques.
– Une composante logicielle légèrement couplée : L’architecture modu-

laire des services Web, combinée au faible couplage des interfaces associées,
permet l’utilisation et la réutilisation de services qui peuvent facilement être
recombinés à différents autres applications.
– Auto-descriptivité : Les services Web ont la particularité d’être auto-descriptifs,

c’est à dire capables de fournir des informations permettant de comprendre
comment les manipuler. La capacité des services à se décrire par eux-mêmes
permet d’envisager l’automatisation de l’intégration de services.
Les services Web représentent donc la façon la plus efficace de partager des méthodes
et des fonctionnalités. De plus, ils réduisent le temps de réalisation en permettant
de tirer directement parti de services existants.
4 Architecture Orientée Service Web

Les services Web représentent une technologie relativement nouvelle qui a pu
bénéficier des atouts de l’architecture orientée service (SOA).Ils offrent une approche
distribuée pour l’intégration des applications hétérogènes sur le Net. Selon Youssef
Belaid [Bel09], lorsque l’architecture SOA s’appuie sur des web services, on parle
alors de WSOA, pour Web Services Oriented Architecture (voir figure 2.3).
34 4. ARCHITECTURE ORIENTÉE SERVICE WEB
Figure 2.3 – Architecture WSOA [Bel09]
5 Technologies de base des services Web

5.1 eXtensible Markup Langage (XML)
Définition :
XML (eXtensible Markup Language) est un langage de balisage extensible, c-à-d.
qui permet d’inventer ses propres balises et qu’elles peuvent tout décrire. XML est un
standard qui sert de base pour créer des langages balisés spécialisés ; c’est un méta
langage qui permet d’écrire des grammaires qui définissent des documents. Il est
suffisamment général pour que les langages basés sur XML, appelés aussi dialectes
XML, puissent être utilisés pour décrire toutes sortes de données et de textes. Il
s’agit donc partiellement d’un format de données. Son objectif est, dans un échange
entre systèmes informatiques, de transférer, en même temps, des données et leurs
structures. Permettant de coder n’importe quel type de donnée, depuis l’échange
EDI (Electronic Data Interchange ou Echange de Données Informatisées) jusqu’aux
documents les plus complexes, son potentiel est de devenir le standard universel et
multilingue d’échange d’information. Un document XML est composé des éléments
suivants :
– Un entête, il s’agit de la première ligne décrivant la version du document XML
ainsi que l’encodage.
– Des instructions de traitement qui servent à donner, à l’application qui utilise
le document XML, des informations.
– Des commentaires.
– Des nœuds, tag ou balises. Ces balises peuvent avoir des attributs (clé, valeur)
qui les définissent.
Un exemple de document XML est présenté dans la figure 2.4 de la page 36.
XML Namespaces est une extension de la recommandation XML qui permet
de créer des espaces de nommages. Les espaces de noms d’XML permettent de
qualifier de manière unique des éléments et des attributs. On sait alors à quel do-
maine de définition se rapporte un objet et comment il doit être interprété, selon
sa spécification. Différencier des espaces de noms permet de faire coopérer, dans un
5. TECHNOLOGIES DE BASE DES SERVICES WEB 35
Figure 2.4 – Exemple d’un document XML
même document, des objets ayant le même nom, mais une signification différente,
souvent liée à un modèle de contenu différent. Cette spécification est une avancée
importante car, à partir du moment où beaucoup de formats s’expriment selon XML,
les risques de collision de noms deviennent plus importants et cette spécification
prend alors toute son importance [MN12].
Origine :
XML a été développé par le XML Working Group sous la tutelle du W3C (World
Wide Web Consortium) dès 1996. Depuis le 10 février 1998, les spécifications XML
1.0 sont reconnues comme recommandation par le W3C, ultime étape du processus
d’approbation de cet organisme. Une seconde édition de la norme XML 1.0 a été
publiée, elle vise principalement à prendre en compte un certain nombre de correc-
tions , et ne défini en aucun cas une nouvelle recommandation. A sa création, les
objectifs de conception de XML étaient les suivants :
1. XML devrait pouvoir être utilisé sans difficulté sur Internet
2. XML devrait soutenir une grande variété d’applications
3. XML devrait être compatible avec SGML (pour Standard Generalized Markup
Language)
4. Il devrait être facile d’écrire des programmes traitant les documents XML
5. Le nombre d’options dans XML doit être réduit au minimum, idéalement à
aucune
6. Les documents XML devraient être lisibles par l’homme et raisonnablement
clairs
7. La conception de XML devrait être préparée rapidement
8. La conception de XML devrait être formelle et concise
9. Il devrait être facile de créer des documents XML
10. La concision dans le balisage de XML est de peu d’importance
36 5. TECHNOLOGIES DE BASE DES SERVICES WEB

Impacts :
Le code XML ne dépend pas de la plateforme, ce qui signifie que tous les pro-
grammes conçus pour utiliser le langage XML peuvent lire et traiter des données
XML, quel que soit le matériel ou le système d’exploitation. Par exemple, avec les
balises XML appropriées, il est possible d’utiliser un programme bureautique pour
ouvrir et utiliser des données sur un gros ordinateur. Quel que soit l’auteur d’un
corps de données XML, il est possible d’utiliser les mêmes données dans plusieurs
programmes Microsoft Office 2003 et Microsoft Office Professional 2007, dont Mi-
crosoft Office Access 2007, Microsoft Office Word 2007, Microsoft Office InfoPath
2007 et Microsoft Office Excel 2007 (voir figure 2.5). Grâce à sa grande portabilité,
le langage XML s’est imposé comme l’une des technologies les plus courantes pour
l’échange de données entre des bases de données et des utilisateurs.
Figure 2.5 – Transmission des données avec XML
Outre les données bien formées qui utilisent des balises, les systèmes XML uti-
lisent généralement des composants supplémentaires : des schémas et des transfor-
mations. Et parmi les points forts qu’offre XML, nous pouvons citer les suivants :
– XML est bien adapté à la transmission de données, du serveur vers le naviga-
teur (portable, échangeable, universel),
– XML est lisible et présentable par les navigateurs Web,
– XML est aussi un outil idéal de communication :
– d’application à application
– de machine à machine
– de base de données à base de données (compatible avec tous les SGBD)

5.2 Simple Object Access Protocol (SOAP)

Définition :
SOAP (Simple Object Access Protocol) pour procédure simple d’appel distant
d’objet, est un protocole standardisé permettant à une application d’envoyer et de
recevoir des messages via l’Internet. La figure 2.6 explique le fonctionnement du
protocole (SOAP).
Figure 2.6 – Fonctionnement de SOAP [Ref17]
SOAP est un protocole d’échange de messages dans un milieu distribué. SOAP

définit aussi un RPC (Remote Procedure Call ou Appel de Procédures Distantes),
mais n’est pas limité à cette utilisation : il est possible d’utiliser SOAP pour des
appels asynchrones (SOAP ne fonctionne pas nécessairement sur le modèle requête
/ réponse) [Ref17].
Un message SOAP est un document XML constitué d’une enveloppe, contenant

un entête (facultatif) et le corps du message (voir figure 2.7).
Figure 2.7 – Structure d’un message SOAP [Bel09]

Origine :
La définition du protocole SOAP débuta en 1998, à l’initiative de Microsoft,
de DevelopMentor et d’Userland Software [KT03], dans le but de parvenir à la
création d’une procédure d’appel distant utilisant http comme couche de transport
de données. Puis, ce groupe de réflexion fut rejoint par IBM et d’autres grands
éditeurs, afin de contribuer à transformer SOAP en un standard, soumis au World
Wide Web Consortium - W3C. SOAP se base sur les spécifications XML-RPC.
Ce dernier est un RPC au même titre que CORBA ou DCOM, mais il n’impose
aucun modèle de composants, des deux côtés de la connexion. L’activation des objets
exécutant les méthodes est aussi laissée à la charge des applications. La norme XML-
RPC précise l’enveloppe des messages échangés par les deux applications (envoi de
requête et de réponse), et la manière d’utiliser ces messages dans le but de faire des
appels de procédures distantes.
Impacts :
SOAP est une RPC simple et légère qui permet de sortir du réseau local. Les
précédentes tentatives (DCOM, CORBA, RMI) ont échoué car elles n’étaient pas
simples, ni standards. SOAP, a au contraire été conçu pour être simple et devenir
standard international grâce au support du plus grand nombre. SOAP pourrait
bien devenir le middleware pour Internet : couche logicielle permettant de faire du
client-serveur entre applications (interconnexion) à travers l’Internet et c’est une
nouveauté.
5.3 Web Service Description Language (WSDL)

Définition :
WSDL pour Web Services Description Language ou langage de description de
Service Web, est une syntaxe XML pour décrire les méthodes et les paramètres
des Services Web invocables par le biais de messages au format SOAP. Il permet
de définir qu’est-ce qu’un Service Web est capable de faire, ou est-ce qu’il réside
et comment l’invoquer. L’objectif de WSDL selon M. Dumas et M.C. Fauvet dans
[Dum08] est de fournir la description, en XML, des services indépendamment de la
plateforme et du langage utilisés et sous une forme que des personnes ou des pro-
grammes peuvent interpréter. Dans le langage WSDL, un service est vu comme une
collection de messages pour les échanges et d’une collection de points d’entrée. Un
point d’entrée consiste en la description abstraite d’une interface et de son implan-
tation. La description abstraite contient :
1. la définition des messages qui sont consommés et générés par le service (les
entrées et les sorties), et
2. la signature des opérations offertes par le service.
WSDL pour les Services Web est l’équivalent de l’IDL (Interface Definition Lan-
guage) pour la programmation distribuée (CORBA, DCOM). Ce langage permet de
décrire de façon précise les Services Web, en incluant des détails tels que les proto-
coles, les serveurs, les ports utilisés, les opérations pouvant être effectuées, le format
des messages d’entrée et de sortie, et les exceptions pouvant être renvoyées[BL03].
Origine :
Il y a eu d’autres tentatives de langages pour résoudre le problème de la définition
des services Web. Microsoft a d’abord proposé SDL (Service Description Language)
avec une implémentation fournie dans leur toolkit SOAP, puis IBM a proposé NASSL
(Network Accessible Service Specification Language), dont une implémentation est
fournie dans SOAP4J. Microsoft a modifié sa première spécification pour proposer
SCL (SOAP Contract Language), puis les différents acteurs se sont accordés sur
WSDL.
Structure d’un document WSDL :

Un document WSDL décrit un service Web en deux niveaux principaux [Ref17].
La figure 2.8 représente les principaux éléments constituant la partie concrète et la
partie abstraite d’un document WSDL.
1. Niveau concret : Ce niveau permet de définir les protocoles utilisés par le

service et sa localisation. La description concrète est composée des éléments
qui sont orientés vers le client pour le service physique.
2. Niveau abstrait : Une partie de description de service Web qui permet de

définir les types de données, les messages transmis et les ports et ce de façon
indépendante des protocoles utilisés. La description abstraite est composée
des éléments qui sont orientés vers la description des capacités du service
Web. Ses éléments abstraits définissent les messages SOAP de façon totalement
indépendante de la plate-forme et de la langue. Cela facilite la définition d’un
ensemble de services pouvant être implémentés par différents sites Web.
5.4 Universal Description Discovery and Integration (UDDI)

Définition :
L’annuaire UDDI(Universal Description, Discovery and Integration) propose un
cadre technique indépendant des plateformes et ouvert pour permettre aux entre-
prises d’enregistrer et de découvrir leurs services Web. Cet annuaire définit comment
interagir avec un service et permet une immatriculation mondiale. Il peut être im-
planté au niveau mondial sur Internet ou au niveau entreprise sur intranet. Pour
les services définis en WSDL, l’annuaire permet de retrouver le document décrivant
ports et opérations. Ainsi en obtenant la définition WSDL d’un service, le client peut
générer les souches logicielles (procurations d’opérations) nécessaires pour invoquer
le service[Ref17] comme indiqué dans la figure 2.9.
UDDI est subdivisé en deux parties principales : partie publication ou inscription,

et partie découverte. La partie publication regroupe l’ensemble des informations
relatives aux entreprises et à leurs services. Ces informations sont introduites via
une API d’enregistrement. La partie découverte facilite la recherche d’information
contenue dans UDDI grâce à l’API SOAP.
Figure 2.8 – Structure d’un document WSDL [Bac14]
Figure 2.9 – Mapping WSDL −→UDDI
Origine :
UDDI a été conçu en 2000 à l’initiative d’un ensemble d’industriels (Ariba 5 ,
IBM 6 , Microsoft 7 ) en vue de devenir le registre standard de la technologie des
5. http ://www.ariba.com/
6. http ://www.ibm.com
7. http ://research.microsoft.com
services Web et dans le but de faciliter la découverte de services Web en plus de

leurs publications. UDDI est un annuaire orienté Business pour services Web. Les
organisations publient les informations décrivant leurs services Web dans l’annuaire,
et l’application client ayant besoin d’un certain service, consulte cet annuaire pour
la recherche des informations concernant le service Web qui fournit le service désiré
pour une éventuelle interaction. Les services référencés dans UDDI sont accessibles
par l’intermédiaire du protocole de communication SOAP, et la publication des
informations concernant les fournisseurs et les services doit être spécifiée en XML afin
que la recherche et l’utilisation soient faites de manière dynamique et automatique.
Structures de données UDDI :
Un registre UDDI se compose de quatre types de structures de données : le

BusinessEntity, le BusinessService, le bindingTemplates et le tModel comme indiqué
dans la figure 2.10. Cette répartition par type fournit des partitions simples pour
faciliter la localisation rapide et la compréhension des différentes informations qui
constituent un enregistrement [Ref17]
Figure 2.10 – Entités composant un annuaire
– BusinessEntity (entité d’affaires) : Les ”businessEntities” sont en quelque

sorte les pages blanches d’un annuaire UDDI. Elles décrivent les organisations
ayant publié des services dans le répertoire. On y trouve notamment le nom de
l’organisation, ses adresses (physiques et Web), des éléments de classification,
une liste de contacts ainsi que d’autres informations.
– BusinessService (service d’affaires) : Les ”business Services” sont en

quelque sorte les pages jaunes d’un annuaire UDDI. Elles décrivent de manière
non technique les services proposés par les différentes organisations. On y
trouve essentiellement le nom et la description textuelle des services ainsi
qu’une référence à l’organisation proposant le service et un ou plusieurs ”
bindingTemplate ”.
– BindingTemplate (modèle de rattachement) : UDDI permet de décrire

des services Web utilisant HTTP, mais également des services invoqués par
d’autres moyens (SMTP, FTP...). Les ” bindingTemplates ” donnent les coor-
données des services. Ce sont les pages vertes de l’annuaire UDDI. Ils contiennent
notamment une description, la définition du point d’accès (une URL) et les
éventuels ” tModels ” associés.
– TModel (index) : Les ” TModels ” sont les descriptions techniques des ser-
vices. UDDI n’impose aucun format pour ces descriptions qui peuvent Être pu-
bliées sous n’importe quelle forme et notamment sous forme de documents tex-
tuels (XHTML, par exemple). C’est à ce niveau que WSDL intervient comme
le vocabulaire de choix pour publier des descriptions techniques de services.
Consultation de l’annuaire UDDI

L’annuaire UDDI est consultable de différentes manières relativement aux différents
types de page comme présenté dans la figure 2.11 :
– Pages blanches : comprennent la liste des entreprises enregistrées ainsi que

des informations associées à ces dernières (noms, adresses, contacts, identi-
fiants...). Ces informations sont décrites dans des entités de type Business-
Entity. Cette description inclut des informations de catégorisation permettant
de faire des recherches spécifiques dépendant du métier de l’entreprise.
– Pages jaunes : recensent des détails sur le métier de l’entreprise et les ser-
vices qu’elle propose. Ces informations sont décrites dans des entités de type
Business-Service.
– Pages vertes : fournissent des informations techniques précises sur les ser-
vices proposés. Les pages vertes incluent des références vers les spécifications
des services Web, et les détails nécessaires à l’utilisation de ces services.
Figure 2.11 – Les différentes pages d’un registre UDDI.
6 Publication, recherche et sélection de services

Web
Les services Web sont articulés autour des trois standards suivants : WSDL (Web
Service Description Language), UDDI et SOAP. Ces standards facilitent la descrip-
6. PUBLICATION, RECHERCHE ET SÉLECTION DE SERVICES WEB 43
tion, la publication, la découverte et la communication entre services. Cependant,

cette infrastructure de base ne permet pas encore aux services Web d’assurer une in-
teropérabilité automatisée. Cette automatisation est pourtant essentielle pour faire
face aux exigences de passage à l’échelle, et pour réduire les coûts de développement.
Le premier pas de cette interopérabilité commence au niveau de la recherche

automatique des services web. En effet, lorsqu’on peut localiser efficacement les
services web dont on a besoin, on peut réaliser par la suite, les autres formes de
l’interopérabilité (telles que la composition, l’invocation, la surveillance, etc.).
Il faut donc un mécanisme permettant aux clients de publier les services qu’ils
offrent et de trouver les services dont ils ont besoin. Ce mécanisme doit être trans-
parent pour l’utilisateur : les services proposés doivent correspondre à la requête de
l’utilisateur. Différentes approches ont été développées pour résoudre la problématique
de recherche telles que celles présentées dans [HM06, BHRT03, KFKS05].
7 Principes généraux sur la recherche de service

Web
La recherche de service confronte deux acteurs : le fournisseur ou producteur
de service qui cherche à annoncer du mieux possible ses services et l’utilisateur qui
ne sait pas ou chercher le service de ses rêves. Dans cette section on va essayer de
répondre à quelques questions fréquentes telles que :
– Quel est l’objet central de l’approche de recherche ?
– Pourquoi l’approche est- elle utilisée ?
– Comment l’approche est conceptualisée ?
La première question se centre sur l’objet sur lequel on applique la publication et

la recherche de services, c’est-a-dire, l’entité que l’on publie et que l’on recherche,
sa granularité et sa visibilité. Deux perspectives sur les services doivent être com-
prises afin de fournir une terminologie partagée pour les services : Un point de vue
technologique (informatique) et un point de vue métier (business) [BGOA04]. A ces
deux perspectives, nous ajoutons le point de vue oriente but qui traduit le fait qu’un
service exhibe une intentionnalité formulée par le but qu’il permet a ses clients d’at-
teindre.
Un service peut être atomique ou agrégat [RK05] et on distingue deux types de

spécification : les services décrits comme une boite noire, avec une partie interface
unique disponible a d’autres services lui permettant d’être compose ; et les services
décrits comme une boite blanche, lesquels incluent dans leur spécification les infor-
mations sur les règles, les processus et la structure du service, informations qui sont
donc partagées avec d’autres services [ABRL09].
La deuxième question repose sur le contexte d’usage de recherche de services.

Cet objectif désigne l’identification dans un annuaire de services qui répondent di-
rectement ou indirectement aux besoins de l’utilisateur. Ces services auront été
44 7. PRINCIPES GÉNÉRAUX SUR LA RECHERCHE DE SERVICE WEB
préalablement modélisés et publiés dans un annuaire de services. La découverte de

service se focalise ainsi sur la phase d’appariement sémantique entre l’offre et la
demande de service. On souligne ainsi que ce mécanisme désigne les opérations par
lesquelles l’approche retrouve dans l’annuaire les services qui correspondent à la
requête formulée par l’utilisateur. Celle-ci peut prendre plusieurs formes tel qu’un
mécanisme spécifique d’interrogation, une formulation directe dans le langage de
description de service ou dans un langage technique d’interrogation ; ou bien une
expression avec un langage de haut niveau autre que le langage de description de
service. La recherche de service fait généralement appel à des techniques d’appa-
riement (lexicale, sémantiques, ontologiques, etc.. . . ). Cette opération de mise en
correspondance ou de Mapping utilise une similarité relative selon une fonction
de mesure donnée [KR05].
La troisième question concerne les modèles utilisés dans l’approche autant pour
les aspects processus que les aspects produits. Coté produit, nous nous intéressons
aux langages qui permettent aux utilisateurs d’exprimer et éventuellement de modéliser
leurs requêtes lors de la recherche de services. Nous avons pu identifier quelques
formes :
– Mots-clés : C’est la forme utilisée pour saisir une requête dans les annuaires
standards de service (tels que les annuaires UDDI).
– Modèle de tâche : Dans cette forme, l’utilisateur exprime sa requête comme
un modèle de tâche métier. Une tâche est une action réalisée par un ou plusieurs
agents afin d’atteindre un but. C’est le choix fait dans l’approche proposée par
Da Silva Santos dans [DSSGPvS09].
– Modèle de but : l’utilisateur exprime sa requête selon une certaine structure,
où l’on distingue le sujet, le verbe et les paramètres.
– Modèle de carte : La Carte est un système de représentation qui permet
de modéliser les processus dans des termes intentionnels. Le graphe montre
quelles intentions peuvent être réalisées au moyen de quelles stratégies. C’est
le choix fait dans l’approche proposée par Mirbel et Crescenzo dans [MC09].
Et nous nous intéressons aussi au modèle de requête, c’est à dire la forme à partir
de laquelle le moteur de recherche associé à l’annuaire effectue la recherche. Cette
forme peut correspondre directement à ce que l’utilisateur a formulé dans sa requête,
ou bien elle est obtenue par transformation de la requête vers une autre forme que
le moteur de recherche peut traiter. Nous avons pu identifier quelques formes :
– Mots-clés
– XQuery : langage optimisé pour l’interrogation de tous les types de données
XML..
– SPARQL : Ce langage combine un langage d’interrogation et un protocole
pour créer un service web au sens propre.
Côté processus, nous nous intéressons, en premier lieu, au processus de formulation
de requête. Cette action concerne la démarche avec laquelle l’utilisateur final formule
et construit une requête. Nous avons identifié trois valeurs possibles :
– Brut : Le processus de formulation est brut lorsque l’utilisateur doit manuel-
lement saisir la requête. Ce processus est entièrement à sa charge, et aucun
support n’est fourni par le système.
7. PRINCIPES GÉNÉRAUX SUR LA RECHERCHE DE SERVICE WEB 45
– Guidé : on parle de processus de formulation guidé lorsque le système dispose

d’une certaine connaissance sur la manière avec laquelle ce processus doit être
conduit. Cela suppose qu’une modélisation préalable de ce processus a été faite,
et que cette modélisation est exploitable par le système. Ce guidage facilite la
formulation d’une requête et permet d’exploiter toutes les possibilités offertes
par le modèle (ou le langage) d’interrogation.
– Intelligent : Le processus de formulation de requête est intelligent lorsque le
système est capable de raisonner sur la connaissance qui est exprimée dans la
requête en cours de traitement. Cela suppose que le système repose sur l’uti-
lisation d’ontologies, et que ces ontologies sont utilisées pour raisonner sur les
concepts apparaissant dans la requête et ceux référencés dans les descripteurs
des services.
En deuxième lieu nous nous intéressons à l’appariement ou bien le Matching qui

concerne la mise en correspondance entre les éléments de deux ensembles, en l’oc-
currence ceux de la requête et ceux des résultats potentiels de cette requête. Ce
processus repose sur un ensemble de fonctions permettant de mesurer le degré de
similarité entre ces éléments. Ceci est réalisé par une ou plusieurs méthodes de com-
paraison dites matcher ; ce sont des fonctions utilisées pour calculer la distance
(lexicale, sémantique, conceptuelle, grammaticale, etc.) entre ces deux entités. Les
Matchers peuvent ainsi combiner plusieurs techniques dans le processus de d’ap-
pariement. Nous avons identifié deux valeurs possibles pour caractériser le processus
d’appariement :
– Lexical : dans l’appariement lexical, c’est la forme textuelle et syntaxique des
éléments comparés qui est privilégiée. La mesure se fait dans ce cas par des
métriques connues telles que la mesure Levenshtein , la mesure du vecteur
cosinus, la méthode TF/IDF , la méthode de divergence des informations
Jensen-Shannon .
– Sémantique : dans l’appariement sémantique, c’est la signification des éléments

comparés qui est à la base du processus d’appariement. Ce type de processus
suppose donc l’existence d’ontologies qui permettent d’associer des hiérarchies
de concepts aux éléments de la requête et à ceux des descripteurs de services.
La mesure porte donc sur une distance sémantique dans une ontologie.
L’algorithme de Matching doit permettre une recherche :
– précise : Les résultats renvoyés par l’algorithme doivent correspondre aux
définitions des degrés de correspondance, expliqués ci-après pour chacun des
mécanismes.
– efficace : Le temps de réponse doit être plus fluide.
– efficiente : L’ensemble des résultats ne doit pas être trop grand. Mieux vaut
un petit ensemble avec un degré de correspondance élevé.
L’algorithme doit réduire le nombre de faux positifs et de faux négatifs. De plus,

il serait intéressant d’encourager les acteurs à faire une description honnête de leur
service. Autrement dit, si la description n’est pas honnête, le service n’est pas ou
mal repris dans les résultats lui correspondant.
7.1 Les différentes approches de recherche et de découverte

de service web
Plusieurs Approches ont été développées ces dernières années dans ce domaine,
parmi toutes celles étudiées, nous choisissons de décrire quelques-unes dans le but
d’essayer de former un ensemble représentatif de l’état de l’art.
SPOC
Le modèle SPOC (Semantic based Planning Optimized Compositions)a été pro-
posée par Daniella Barreiro Claro dans sa thèse de doctorat [Cla06]. Plus précisément,
son travail se focalise sur la composition automatique de services Web en se basant
sur les 4 phases présentées dans la figure 2.12.
Figure 2.12 – Les principales phases de SPOC [Cla06].
A propos de la phase recherche de service web, l’auteur utilise une description

sémantique et propose une ontologie du domaine qui organise les services web selon
une similarité sémantique. Une fois une tâche définie, le processus de découverte
cherche dans cette ontologie les services Web qui le réalisent comme indiqué dans la
figure 2.13.
GODO
Goal Oriented Discovery for Semantic Web Services est une approche de
découverte et d’invocation de services web dont l’objectif principal est d’aider les
utilisateurs à formuler leurs besoins pour rechercher des services web sémantique
[GRGS06]. La requête est exprimée en langage naturel. L’approche est dotée d’un
éditeur intelligent qui aide les utilisateurs à formuler leurs besoins. Pour cela, l’ap-
proche GODO fait usage des ontologies sur les actions les plus invoquées qui sont
stockées dans un référentiel. Une fois les entrées de l’utilisateur analysées par GODO,
il extrait les actions similaires à la demande de l’utilisateur et sélectionne les plus
proches en les exprimant sous forme de buts.
Le couplage de GODO avec un annuaire sémantique tels que WSMX, DAML-

S virtuelle machine et METEOR-S permet de réaliser la recherche. Malgré que
le but n’étant pas intégré dans le descripteur sémantique de ces annuaires, celui-
ci est transformé en mots-clés par le Goal Sender . GODO prend en compte
Figure 2.13 – L’architecture SPOC [Cla06].
uniquement la découverte et la recherche de services lors de la conception du système.

Le processus de publication et l’algorithme de l’appariement (lexical) sont laissés à la
charge de l’annuaire de services. Par contre, les ontologies sont utilisées à l’extérieur
de l’annuaire par le processus de formulation.
Figure 2.14 – L’architecture GODO [GRGS06].
SWASDL-MX
Cette approche de découverte était proposée en 2009 par M. Klüsch [KKZ09].
Son objectif est d’aider les utilisateurs à rechercher et classer les services web
sémantiques. Pour cela, il fait usage d’ontologies de domaine pour faire un apparie-
ment hybride qui utilise une combinaison de mécanismes d’appariement lexical et
sémantique afin de donner de meilleures performances.
Parmi les appariements hybrides, on peut citer les prototypes LARKS et OWLS-
MX, ils combinent les capacités formelles (basées sur les logiques de descriptions) et
informelles des services web, dans le Matching. OWLSMX propose 5 types de pro-
cessus de ”Matching”, dont un est purement logique, et les autres sont des méthodes
inspirées des techniques de recherche d’information.
Les auteurs affirment qu’une approche basée sur l’appariement lexical ou sur
l’appariement sémantique seulement, échouerait en raison de ses limitations.
La requête attendue de l’utilisateur doit être conforme au langage ”XQuery”. Les

ontologies sont utilisées à l’intérieur de l’annuaire pour améliorer les performances
de recherche.
SATIS
Cette approche s’inscrit dans la famille des approches de recherche de service web
par but. Elle est développée au sein du laboratoire I3S par Isabelle Mirabel [MC09].
C’est une approche sémantique guidée par les intentions, elle repose sur un modèle
pour capitaliser, réutiliser et partager des requêtes de recherche d’information et
pour les organiser en un ensemble de démarches de recherche formalisées également
réutilisables et partageables. Cette approche repose sur les techniques et modèles du
Web sémantique pour proposer des moyens de raisonnement et d’explications des
services web trouvés, ainsi que sur la représentation intentionnelle d’un processus.
Les auteurs proposent ainsi un modèle pour formaliser et raisonner sur les buts
et les sous-buts. Enfin, cette proposition permet la réutilisation et le partage d’étapes
(de sous-buts) entre les procédures de recherche. Précisément, les auteurs s’intéressent
à la construction et l’exploitation d’une base de requêtes rendant opérationnelles
les étapes d’un scénario de recherche d’information qu’ils appellent démarche de
recherche d’information. Cette base de connaissances peut être vue comme une
mémoire épisodique dans laquelle les démarches de recherche sont construites dyna-
miquement en fonction du contexte.
Dans SATIS, trois acteurs principaux sont déterminés : le concepteur de services

Web, l’expert en modélisation de processus et l’expert du domaine métier. Et elle
s’appuie sur trois ontologies à la fois : l’ontologie des processus intentionnels qui
sont annotés à l’aide de concepts et des relations de cette ontologie permettant ainsi
le partage et le raisonnement sur ces représentations intentionnelles, l’ontologie de
domaine de neuro-scientifique décrivant les images médicales et leurs traitements
d’images associés, et la description sémantique de services web selon OWL-S. Ces
requêtes sont représentées en ”SPARQL” [MC09].
DRISS
Dans cette approche de modélisation, de recherche et de sélection de services
web, les auteurs proposent une approche centrée exigence. Les besoins de l’utilisa-
Figure 2.15 – Processus de définition et de mise en œuvre de démarche dans SATIS

[MC09].
teur sont formalisés en termes de besoins fonctionnels et non fonctionnels, à l’aide

du formalisme de la Carte en spécifiant les services requis en utilisant le modèle
intentionnel de service. La recherche des services se fait en interrogeant le moteur de
recherche des services Web Service-Finder en utilisant des mots-clés extraits des
spécifications fournies par MiS, et la sélection automatique des services pertinents et
de haute qualité se fait en appliquant l’analyse formelle des concepts (AFC) comme
présenté dans la figure 2.16 [DMJ+ 10].
Figure 2.16 – Les étapes de l’approche DRISS [DMJ+ 10].
SECSE
Cette approche de découverte de services à partir des exigences exprimées en
langage naturel a était développée par Zachos en 2007 [ZMZJ07]. Sa principale fonc-
tion est la recherche et le classement de services web à partir des requêtes composées
et structurées en langage naturel.
Cette approche utilise un annuaire étendu. Comme le montre la figure 11, l’ap-
proche SECSE est composée de 4 étapes. Dans la première étape, la requête de
Figure 2.17 – L’architecture SECSE [ZMZJ07].
service permet de découper en phrases, puis en jetons, tagués et modifiés pour in-
clure les racines morphologiques de chaque terme (par exemple le voyage à voyager,
et du voyageur à voyager).
Dans la seconde étape, l’algorithme applique des procédures pour lever l’am-
biguı̈té en définissant à chaque terme son sens correct et l’insère pour chaque terme
(par exemple la définition d’un pilote est le conducteur d’un avion plutôt qu’un pi-
lote d’un périphérique informatique).
Dans la troisième étape, l’algorithme augmente chaque terme avec d’autres termes
qui ont un sens similaire, afin d’augmenter ainsi la probabilité d’un appariement avec
une description de service (par exemple, conducteur est un terme synonyme du terme
automobiliste qui est également inclus dans la requête).
Dans la quatrième étape, l’algorithme fait un Matching avec tous les termes
élargis et tagués de la requête. Ce qui aboutit à un ensemble semblable de termes qui
décrivent chaque service candidat, exprimé en utilisant la facette de la description
du service, dans le registre des services.
SeCSE répond à la requête en 2 étapes :

1. XQuery recherche syntaxiquement à découvrir une première série de descrip-
tions des services qui satisfont les contraintes de recherche ;
2. le modèle de recherche d’information de la forme traditionnelle d’espace vecto-
riel, renforcé par WordNet, affine et évalue les qualités de l’ensemble de services
candidats.
Cette approche permet en deux étapes de surmonter la limitation de recherche de

XQuery basée sur le texte. A propos de WordNet : Le lexique en ligne WordNet joue
un rôle important pour les trois composants de l’algorithme. WordNet est une base
de données lexicale. Premièrement, il divise le lexique en quatre catégories : noms,
verbes, adjectifs et adverbes. Les sens des mots, appelés sens, pour chaque catégorie
sont organisés en des ensembles de synonymes qui représentent des concepts, et
chaque synonyme est suivi par sa définition qui contient une phrase définissant, un
commentaire optionnel et un ou plusieurs exemples. Deuxièmement, WordNet est
structuré selon des relations sémantiques entre les significations de mots qui relient
les concepts [ZMZJ07].
AASDU
C’est une approche multi agents pour la découverte de services Web proposée
dans [PC04]. Le système appelé AASDU (Agent Approach for Service Discovery and
Utilization) contient quatre composants :
1. Une interface utilisateur graphique (GUI)
2. Un agent analyseur de requête
3. Un système référentiel des domaines d’expertises des agents de service
4. Le module de services
Figure 2.18 – AASDU Framework [PC04].
Dans ce système, l’utilisateur entre sa requête de recherche sous forme de chaı̂ne

de caractères via l’interface GUI. La requête est ensuite envoyée à l’agent QAA
pour Query Analyzer Agent. Le rôle de cet agent est de faire ressortir de cette
requête les mots clés pertinents qui seront utilisés pour sélectionner des agents du
système référentiel des domaines d’expertise des agents service. Pour ce faire, l’agent
QAA utilise une simple variante de la technique TFIDF (Term Frenquency Inverse
Document Frequency) pour ressortir les mots clés pertinents, sur la base de ces mots
clés l’agent QAA sélectionne un ensemble d’agents experts. Les agents sélectionnés
transmettent par la suite les paramètres des services avec lesquels ils sont liés à
l’agent composition. Ce dernier invoque un des services selon le choix de l’utilisateur
[PC04, Ber09].
WSPAB
L’approche WSPAB (Web Service Personal Address Book) se base sur le développement
d’une application qui facilite la découverte des services Web les plus pertinents à une
requête donnée. Elle fonctionne avec les autres approches de découverte de services
Web, et ce afin de donner une solution pertinente et précise. Vu que le nombre de
services d’une solution offerte par les moteurs de recherche actuels est important
alors, le travail de sélection manuelle d’un service Web sera généralement trop diffi-
cile [AHT+ 08].
La figure 2.19 présente l’architecture de l’approche WSPAB et définit ses étapes

d’exécution comme suit :
– Analyse des services Web ;
– Filtration des services Web ;
– Identification des services pertinents ;
– Tri des signatures. La classification de services Web se réalise à l’aide d’un
outil d’analyse formelle de concepts appelé Galicia (Galois Lattice Interactive
Constructor), qui analyse les relations binaires entre les services et retourne le
résultat sous forme graphique.
Figure 2.19 – L’architecture WSPAB [AHT+ 08]

7.2 Comparaison des différentes approches de recherche des

services Web
Le tableau 2.1 de la page 55 représente une récapitulation des différentes ap-
proches de recherche des services Web vues précédemment, incluant le principe
de fonctionnement de chacune ainsi que quelques remarques. Cette section nous
a permis de décrire le principe de certaines approches intéressantes dont l’objectif
commun était de découvrir des descriptions non connues auparavant, de services
Web décrivant certains critères fonctionnels. Suite à notre synthèse, nous pouvons
en déduire que les approches de découverte sémantique donnent de bons résultats
comparées aux approches syntaxiques. De plus, nous avons pu constater que peu de
travaux prennent en compte les qualités de service lors de la sélection des services
Web.

Approche Fonctionnement Remarque

SPOC Utilisation d’ontologie de services jusqu’à ce jour, cette ontologie n’existe
UDDI, utilisation du web sémantique pas - pour ses tests, l’auteur utilise OPS
comme langage de description des 3 (Ontology to Publish Services)
services Web
GODO Requête exprimé en langage naturel, Son originalité est de proposer un pro-
éditeur intelligent, couplage avec un an- cessus de formulation de requêtes intel-
nuaire sémantique pour permettre la re- ligent et indépendant de l’annuaire des
cherche services sémantiques
SAWSDL-MX Usage ontologie de domaine et apparie- Garantie plus de performance coté
ment hybride découverte de service web mais elle ne
s’intéresse pas au problème de formula-
tion de requêtes
SATIS Les services sont atomiques et de type Le processus de recherche est guidé et
boite Noire (modèle de Carte) indépendant de l’annuaire de services
sémantiques
DRISS l’approche utilise le modèle MiS, car Son originalité réside dans l’exploita-
le service est décrit selon une pers- tion du modèle de Carte et du modèle
pective opérationnelle et non intention- MiS lors de la formulation de requêtes
nelle (WSDL standard) Elle délègue la (processus guidé).et le modèle AFC lors
recherche au composant ServiceFin- de la sélection de service pertinent
der en lui passant les éléments MiS
comme une séquence de mots-clés sans
sémantique
SeCSE Approche centrée sur un service ato- L’originalité de cette approche est
mique de type boite noire selon une d’améliorer le processus de la formula-
perspective technologique, SeCSE se fo- tion par l’expansion de la requête en
calise uniquement sur la découverte de utilisant WordNet. Le processus de for-
services et ne s’intéresse pas au proces- mulation est intelligent puisqu’il trans-
sus de publication. l’appariement pro- forme la requête exprimée en langage
posé n’est que lexical naturel selon quatre étapes successives
AASDU Approches basées sur la syntaxe des Adopte la technologie multi-agents et
descriptions des services est la com- une architecture distribué et pour
paraison syntaxique entre la requête, la recherche elle utilise la technique
basée mots clés, de l’utilisateur et les TFIDF
descriptions syntaxiques (WSDL) des

services Web
WSPAB Les utilisateurs de WSPAB peuvent uti- L’originalité ce cette approche réside
liser leur moteur de recherche préféré dans le fait qu’elle utilise des infor-
où ils peuvent effectuer des recherches mations syntaxiques sur les services
de services par des mots-clés simples. Web où la plupart des approches exis-
L’optimisation est faite sur le jeu de tantes utilisent des critères de qualité
résultats renvoyé. La classification à définis manuellement. Cela permet à
l’aide de réseaux de concepts est ef- cette solution d’être entièrement auto-
fectuée ensuite sur une petite liste de matique même si certaines des informa-
services Web tions fournies sur chaque service indexé
sont incorrectes ou incomplètes
Table 2.1 – Tableau comparatif des différentes approches de recherche des services
Web

8 Qualité d’un service Web

La consultation d’un service Web peut être faite selon sa description fonction-
nelle, avec la qualité exigée des différents attributs par le client comme des contraintes
de consultation. Le fournisseur d’un service Web doit fournir les informations, les
aspects fonctionnels du service fournis conformément à votre demande par le registre
courant UDDI, aussi que fournir la qualité d’informations de service liées au service
Web proposé. La qualité de service doit être certifiée et enregistrée.
8.1 Définition de la qualité d’un service Web

Le terme QoS (acronyme de Quality of Service , en français QdS pour Qua-
lité de Service ) désigne la capacité à fournir un service conforme à des exigences
en matière de temps de réponse et de coût.
8.2 Classification des attributs de la QdS

Relativement à un domaine donné, il est possible de classifier les attributs de la
qualité de service en des attributs génériques ou spécifiques. Tels que les attributs
génériques correspondent à tous les services Web indépendamment des domaines
auxquels ils appartiennent et selon les travaux de recherche de Shuping Ran ces
attributs sont classifiés de différentes manières [Shu03a].
L’équipe de travail Architecture des Services Web du W3C a identifié et décrit

un ensemble de paramètres de QdS pour les services Web [WVKT06], à savoir : la
performance (qui englobe le débit, le temps de réponse et le temps d’exécution), la
fiabilité, la scalabilité ou l’adaptation au facteur d’échelle, la capacité, la robustesse,
le traitement d’exception, l’exactitude, l’intégrité, l’accessibilité, la disponibilité, l’in-
teropérabilité, la sécurité, et les exigences en QdS liées au réseau .
Il n’y a pas un consensus bien précis au sujet de l’ensemble des paramètres de

QdS les plus importants pour les services Web, mais la plupart des travaux de re-
cherche qui ont essayé d’identifier et de classifier les paramètres de QdS ont pris en
considération les paramètres définis par le W3C auxquels sont associés dans certains
travaux d’autres paramètres.
Parmi les classifications les plus importantes, nous pouvons citer celle de Glen
Dobson et al. dans [GRI05] (voir figure 2.20) qui propose de diviser les attributs en
deux classes :
1. Attributs de QdS spécifiques : Les QdS spécifiques sont des qualités qui
concernent une application particulière et qui sont en relation avec sa logique
métier. Par exemple, pour le processus de revue coopérative, nous pouvons
identifier une liste de dysfonctionnements qui pourraient dégrader la QdS. En
effet, il s’agit des événements à mesurer afin de diagnostiquer des éventuels
problèmes du système. Ces QdS spécifiques peuvent être des QdS liées aux
arguments.
2. Attributs de QdS génériques : Dans cette classe d’attributs, nous distin-
guons les attributs mesurables des attributs non mesurables.
56 8. QUALITÉ D’UN SERVICE WEB
(a) Attributs mesurables : Les attributs mesurables les plus communs sont
décrits pas les paramètres liés à la performance :
– Le débit : Le nombre de requêtes servies pendant un intervalle de
temps.
– Le temps de réponse : Le temps requis pour compléter une requête
du service Web.
– La fiabilité : La capacité d’un service d’exécuter correctement ses
fonctions.
– La scalabilité : La capacité du service de traiter le plus grand nombre
d’opérations ou de transactions pendant une période donnée tout en
gardant les mêmes performances.
– La robustesse : La probabilité qu’un service peut réagir proprement
à des messages d’entrée invalides, incomplètes ou conflictuelles.
– La disponibilité : La probabilité d’accessibilité d’un service.
(b) Attributs non mesurables : Il y a des attributs de QdS qui ne sont
pas mesurables, mais qui sont importants pour les services Web tels que :
– Le coût ou le prix d’exécution : C’est le prix qu’un client du
service doit payer pour bénéficier du service.
– La réputation : C’est une mesure de la crédibilité du service. Elle
dépend des expériences d’utilisateurs finals.
– La sécurité : C’est un regroupement d’un ensemble de qualités à sa-
voir : la confidentialité, le cryptage des messages et le contrôle d’accès.
Figure 2.20 – Classification des attributs de QdS [GRI05].
Le modèle de QdS pour les services Web, proposé dans [AS04], suggère une clas-
sification principale des attributs de QdS basée sur les attributs indépendants de
l’environnement du service (partie fonctionnelle) et les attributs dépendent de l’envi-
ronnement du service (partie non fonctionnelle). Bien que les métriques soient moins
définies que le modèle détaillé dans l’approche de Glen Dobson et al. [GRI05], ce
8. QUALITÉ D’UN SERVICE WEB 57
modèle donne une orientation générale que certains des attributs de QdS doivent être
mesurés en examinant l’implémentation du service (c.-à-d. les attributs internes).
Riadh Benhalima a proposé dans [Ben09a] une autre classification des attributs
de QdS avec prise en considération de différents paramètres tels que :
– La performance des services Web : la performance des services Web n’est

pas un concept formellement défini. Elle est quantifiée à l’aide de différentes
métriques. Une définition fournie par le groupe travaillant sur les architec-
tures des services Web du W3C a été adoptée. Cette définition est composée
du débit, du temps de réponse, du temps de communication et du temps
d’exécution. Le temps d’exécution et le temps de communication sont deux
sous-concepts de la définition du temps de réponse du W3C.
– Monitoring de QdS de point de vue client : L’information de QdS coté

client est utilisée pour différencier les fournisseurs de service offrant des ser-
vices similaires, ce qui est principalement à la charge du client plutôt que le
fournisseur.
– Collection des mesures du côté client et fournisseur : La performance

pourrait être mesurée du côté serveur, et dans quelque cas, les mesures ef-
fectuées peuvent être différentes de celles effectuées du côté client. Une cou-
verture de ces paramètres des deux côtés : côté client et côté fournisseur de
service peut être plus bénéfique.
Le travail mené par Shuping Ran dans [Shu03b] a identifié et organisé les attributs
de QdS des services Web en catégories :
– Attributs liés à l’exécution : Scalabilité, capacité, performance (temps
de réponse, temps de latence, et débit), fiabilité, disponibilité, robustesse/
flexibilité, réputation, traitement d’exception, et exactitude.
– Attributs liés au support de transaction : Intégrité de transaction.
– Attributs liés au prix et à la gestion de configuration : Standard
supporté, stabilité, prix et complétude.
– Attributs liés à la sécurité : Authentification, autorisation, confidentialité,
traçabilité et cryptage de données.
9 Conclusion
Dans ce chapitre nous avons présenté le concept des services Web comme étant
la dernière technologie pour l’intégration et l’interopérabilité des systèmes réparties.
Basés sur le standard XML, ils sont caractérisés par leurs indépendances aux pla-
teformes et aux systèmes d’exploitation, ce qui a impliqué leur adoption par les
différentes organisations commerciales et industrielles offrant leurs services à tra-
vers le Web, et par conséquent l’augmentation du nombre de services offerts. La
découverte de services devient de ce fait un des aspects les plus importants relatifs
aux services Web.
58 9. CONCLUSION
La technologie fondamentale pour la découverte de services Web est le registre

UDDI. Destiné à être utilisé par les utilisateurs humains, UDDI permet la recherche
et la sélection manuelle de descriptions des services Web. UDDI fournit une API de
recherche basée mots clés. De plus, il permet aussi de faire la recherche des services
en se basant sur leurs descriptions WSDL.
L’objectif de ce chapitre était de faire le point sur la technologie des services

Web. Pour cela, nous avons essayé de les définir, de présenter leurs utilités, ca-
ractéristiques, architectures ainsi que leur fonctionnement.
L’un des facteurs ayant contribué au succès des services Web est sans doute l’uti-
lisation des standards Internet tels que XML et HTTP. Par conséquent, tout système
capable d’analyser du texte et de communiquer via un protocole de transport Inter-
net standard peut communiquer avec un service Web. XML a engendré l’apparition
de nouveaux standards tels que SOAP pour l’échange de messages, WSDL pour la
description de services et UDDI pour la publication et la découverte de services. Ces
derniers ont été présentés dans ce chapitre via la section des technologies de base des
services Web, avant de procéder à la définition du concept de la qualité de service
Web et de la citation de quelques classification de ses différents attributs.
Les technologies présentées reposent sur une architecture orientée services (SOA),
et correspondent à des composants logiciels qui peuvent être combinés, grâce à un
certain processus de composition, pour former de nouveaux services plus élaborés.
Ce processus fera l’objet d’un chapitre en entier, vu son importance et ce après avoir
présenté le concept de planification, de façon détaillée, dans le chapitre suivant.
9. CONCLUSION 59
60 9. CONCLUSION
Chapitre 3
La planification
1 Introduction
Nous présentons dans ce chapitre une formalisation des principaux codages des
problèmes de planification classique qui peuvent être classés en deux grandes classes,
à savoir la planification dans l’espace d’états et la planification dans l’espace de plans,
inspirées des paradigmes classiques de résolution de problèmes de planification et
suite à une étude bibliographique détaillée des principaux travaux concernant la
planification automatique.
Deux techniques de planification sont, ensuite, présentées. La première permet

de décrire le domaine de planification en utilisant un ensemble de tâches qui doivent
être accomplies ; il s’agit de la technique de planification graphique qui a été in-
troduite par Blum et Furst dans un espace de recherche très puissant [BF97]et la
deuxième est la technique dite hiérarchique (HTN pour Hierarchical Task Network)
utilisée par Nau et al. dans [NIK+ 03].
La quatrième partie consiste à présenter une nouvelle classe de planification, qui

est la planification distribuée avec présentation de ses trois sous classes, à savoir
la planification centralisée avec plans distribués et la planification distribuée avec
plans centralisés ou distribués.
Nous terminons ce chapitre par la présentation des principaux avantages de la

planification.
2 La planification en intelligence artificielle

Le problème de planification en intelligence artificielle consiste à déterminer
quelles sont les actions à exécuter, et ce, dans quel ordre, pour atteindre un but
donné.
La planification est une discipline de l’intelligence artificielle qui vise à concevoir

des systèmes capables de générer automatiquement, grâce à une procédure forma-
lisée, un résultat appelé plan solution. Ce dernier est une collection organisée de
descriptions d’opérations ; il est destiné à guider l’action d’un ou de plusieurs agents
61
CHAPITRE 3. LA PLANIFICATION
exécuteurs (systèmes robotiques ou humains) qui doivent agir dans un monde par-
ticulier pour atteindre un but préalablement défini. L’exécution est la réalisation
d’actions effectuée suivant les directives du plan. Elle vise à réaliser la prédiction
que constitue ce plan ; lorsqu’elle est conforme à ce qu’il indique, elle doit permettre
(en l’absence d’évènements imprévus et si la modélisation du monde est pertinente)
de faire évoluer l’univers de l’état initial vers un état satisfaisant le but [MRV08].
Un plan est élaboré par un planificateur. Par exemple, pour se rendre d’une pièce
à une autre, le plan est de se lever de sa chaise, de s’orienter vers la porte, puis de
marcher en réalisant un certain nombre de pas jusqu’à ce que l’on soit dans la pièce
à atteindre [Gab06].
La planification en IA peut aussi être conceptualisée comme un choix et une or-

ganisation d’actions pour changer l’état d’un système. Par extension, elle produit un
plan qui est présenté sous la forme d’une collection de descriptions d’opérateurs. Le
planificateur ou générateur de plans est le système qui produit un plan. L’exécution
est la réalisation des actions présentes dans le plan. L’exécution d’un plan modifie les
propriétés du monde en le faisant évoluer de l’état initial jusqu’au but tracé [GNT04].
La Figure 3.1 représente un problème de planification [AL07].
Figure 3.1 – Problème de planification
3 Planification classique
Les algorithmes de planification peuvent être regroupés en deux grandes familles :
les algorithmes de planification dans un espace d’états (state space planning) et les
algorithmes de planification dans un espace de plans (plan space planning) [FN71].
Dans la suite du chapitre, nous introduisons les principaux concepts du domaine

de planification en utilisant le formalisme de la représentation classique STRIPS qui
utilise des notations dérivées de la logique du premier ordre.
3.1 Planification dans un espace d’états

Principe
P
le problème de la planification correspond à un quadruplet = (S, A, E, γ)
[GNT04] où :
62 3. PLANIFICATION CLASSIQUE
S = s1 , s2 , ... est un ensemble d’états fini.
A = a1 , a2 , ... est un ensemble d’actions fini.
E = e1 , e2 , ... est un ensemble d’événements fini.
et γ : SAE → 2s est la fonction de transition d’état.
Les algorithmes classiques les plus simples sont les algorithmes de recherche dans
un espace d’états. Ce sont des algorithmes de recherche dans lesquels l’espace de re-
cherche est un sous ensemble de l’espace d’états. Chaque nœud correspond à un état
du monde, chaque arc correspond à une transition d’état, et le plan correspond à
un chemin dans l’espace d’états.
L’algorithme de la planification dans l’espace d’états tente de construire un che-

min (plan solution) qui permette de passer de l’état initial du problème à un état
but. Il se termine quand l’état courant contient les buts à atteindre [MRV08].
Les principaux algorithmes de planification dans un espace d’état sont : la re-

cherche par chaı̂nage avant, la recherche par chaı̂nage arrière, la recherche mixte et
l’algorithme STRIPS [FN71]. Dans les sections suivantes, nous détaillons ces algo-
rithmes de recherche.
Les différentes approches se basant sur la planification dans un espace

d’états
1. Recherche par chaı̂nage avant (RCAV) : Cette approche consiste, en
partant de l’état initial, à trouver par essais successifs une suite d’actions qui
permette d’arriver à un état but. C’est pour cela qu’elle est appelée planifi-
cation progressive puisqu’elle se déplace vers l’avant. Le plan-solution est la
suite des opérateurs étiquetant les arcs du chemin-solution, chemin qui mène
de l’état initial à l’état-but.
L’algorithme par chaı̂nage avant prend en entrée un problème de planification

P = (O, init, but) Et retourne un plan solution (s’il existe) ou échec (dans le
cas contraire) [HN01].
Algorithme de Recherche par chaı̂nage avant (RCAV)[EF10]

(a) Chainage-avant(O, init, but)
(b) q ⇐= init
(c) Π ←− ∅ le plan vide
(d) tant que vrai faire
(e) si q satisfait but alors retourne Π
(f) E ←− {a| a est une instance d’un opérateur dans O et precond(a) est
vraie dans q }
3. PLANIFICATION CLASSIQUE 63
(g) si E = ∅ alors retourne échec

(h) Choisir une action a ∈ E d’une manière non déterministe
(i) q ←− θ(q, a)
(j) Π ←− Π.a
2. Recherche par chaı̂nage arrière (RCAR) : L’idée de l’algorithme de re-

cherche par chaı̂nage arrière est de partir du but et d’appliquer l’inverse des
opérateurs de planification jusqu’à atteindre l’état initial [Hel06]. L’inverse
d’un opérateur est défini par γ −1 (but, a) = (but − ef f ects+ (a)) ef f ects− (a)
S
où : but est un état but ou un état sous-but et a est une action. On l’appelle
opérateur de régression.
Les mêmes stratégies de recherche utilisées avec l’algorithme en chaı̂nage avant

peuvent être utilisées avec le chaı̂nage arrière : non-déterministe, profondeur,
largeur, heuristique. Contrairement au chaı̂nage avant, le chaı̂nage arrière per-
met d’éviter les cycles dans l’arbre de recherche ce qui permet de réduire le
temps de recherche d’une solution [HG00].
3. Recherche mixte (bidirectionnelle) : L’idée de base de la stratégie mixte

est de développer en parallèle deux arbres de recherche. Le premier arbre est
développé en utilisant le chaı̂nage avant, le deuxième est développé en utilisant
le chaı̂nage arrière. Ce développement se poursuit jusqu’à l’obtention d’un état
commun aux deux arbres et par conséquent, un plan solution est trouvé. L’ob-
jectif de cette stratégie mixte est de diminuer le temps de recherche parce que
les deux arbres sont développés en parallèle [LaV06].
Le plan-solution est alors la suite des opérateurs qui permettent de passer

de l’état initial à l’état commun plus l’inverse de la suite des opérateurs qui
mènent du but à l’état commun. Cette méthode nécessite la connaissance ex-
plicite du but.
4. Recherche dans STRIPS : L’un des plus grands problèmes des algorithmes
présentés précédemment est de savoir comment améliorer l’efficacité en réduisant
la taille de l’espace de recherche. L’algorithme STRIPS est une tentative de le
faire [FN71]. L’algorithme STRIPS fonctionne de la même manière que l’algo-
rithme de recherche par chaı̂nage arrière, son avantage réside dans sa capacité
à réduire l’espace de recherche. Cette optimisation est caractérisée par les deux
points suivants :
– à chaque appel récursif de l’algorithme STRIPS, les sous-buts qui doivent
être satisfaits sont les pré-conditions du dernier opérateur ajouté dans le
plan, ce qui a comme conséquence de réduire substantiellement le facteur de
branchement de l’algorithme ;
– si l’état courant satisfait toutes les pré-conditions d’un opérateur, alors
STRIPS marque l’opérateur. Ainsi, en cas d’échec, le retour en arrière se
fera à partir de cet opérateur.
Enfin, STRIPS réduit une grande partie de l’espace de recherche, mais il n’est
pas complet ni optimal [FN71].
(a) Principe général : L’algorithme de STRIPS fonctionne selon l’analyse
des fins et des moyens (ou Mean Ends Analysis) énoncée par Aristote :
on part des buts que l’on veut atteindre et on tente de trouver les moyens
qui peuvent y conduire. Cela produit de nouveaux buts que l’on tente de
résoudre et ainsi de suite jusqu’à ce que l’on tombe sur les hypothèses de
départ. Le plan est alors obtenu en cheminant sens inverse. En pratique
l’algorithme calcule la différence entre les états du monde qu’il considère.
Il considère des actions capables de réduire ces différences et les combine
pour construire le plan.
(b) Le langage PDDL (Planning Domain Definition Language) : Le
langage PDDL est une tentative pour standardiser les langages de des-
cription des domaines et des problèmes de planification. C’est un langage
créé en 1998 par Drew McDermott pour la compétition IPC-98 dans le
but de développer un seul langage de description des domaines de plani-
fication utilisé par tous les planificateurs de cette compétition.
Pour comparer les performances des différentes techniques et algorithmes

de planification, des compétitions de planificateurs ont été associées aux
conférences AIPS puis ICAPS. La nécessité de définir un langage de des-
cription commun et plus élaboré que le langage STRIPS a progressive-
ment mené au langage PDDL et à ses différentes versions (PDDL1.2,
PDDL2.1, PDDL2.2, PDDL3.0 et PDDL3.1) [Mar09, Wik17].Il est en-
suite devenu comme un standard utilisé par tous les planificateurs. La
dernière version est PDDL3.1.
En PDDL, les composants nécessaires à la description de la planification

sont :
– Les objets : les choses du monde qui nous intéresse.
– Les prédicats : propriétés des objets intéressants pour nous, peuvent
être vraies ou fausses.
– L’état initial : l’état du monde de départ.
– La spécification de l’objectif : les choses que nous voulons soient
vraies dans le monde.
– Les actions/opérateurs : chemins pour changer l’état du monde.
D’autres variantes du langage PDDL sont apparus pour apporter des mises à
jour afin de traiter des catégories de problèmes de planification plus spécifiques
telles que celles présentées dans le tableau 3.1 de la page 66.
3.2 Planification dans l’espace de plans

Dans l’approche de la planification dans un espace de plans, l’espace de recherche
n’est plus un ensemble d’états du monde mais un espace de plans partiels dont les
nœuds représentent des plans partiellement spécifiés et les arcs sont des opérations de
raffinement de plans, i.e., qui permettent de réaliser un but ouvert ou d’enlever une
Variante Description
PDDL + C’est une extension de PDDL2.1 (2002-2006) qui fournit un modèle plus
souple de changement continu grâce à l’utilisation de processus autonomes et
d’événements
NDDL (New Domain Definition Language) C’est la réponse de la NASA au PDDL à
partir de 2002. Sa représentation diffère de PDDL à plusieurs égards :
– elle utilise une représentation variable / valeur (chronologie / activités )
Plutôt que d’une logique propositionnelle / de premier ordre , et
– il n’y a pas de concept d’états ou d’actions, seulement d’intervalles (activités)
et de contraintes entre ces activités.
MAPL (Multi-Agent Planning Language) C’est une extension de PDDL2.1, vers l’an
2003, qui a introduit des variables d’état non propositionnelles (telles que n-
ary : vrai, faux, inconnu ou autre chose) et qui a introduit, également, des
opérateurs modaux (avant, après, etc.). Ainsi que des actions dont la durée
peut être déterminée dans l’exécution et une synchronisation de plan explicite
qui est réalisée par des actes locutoires de communication entre les agents.
OPT (Ontology with Polymorphic Types) C’est une extension de PDDL2.1 par Drew
McDermott entre 2003 et 2005 (avec quelques similitudes avec PDDL +). Il
s’agit d’une tentative de créer une notation générale pour créer des ontologies
, définies comme des cadres conceptuels formalisés pour la planification de
domaines sur lesquels les applications de planification doivent raisonner.
PPDDL (Probabilistic PDDL) C’est une extension de PDDL2.1 avec des effets pro-
babilistes (discrets, les distributions de probabilité générale sur les effets pos-
sibles d’une action), récompense les fluents (pour incrémenter ou décrémenter
la récompense totale d’un plan dans les effets des actions), les récompenses de
but (Récompensant une trajectoire d’état, qui intègre au moins un état-but), et
des fluents obtenus par rapport à l’objectif (ce qui est vrai, si la trajectoire des
états contient au moins un état-but). Finalement, ces modifications ont généré
PPDDL1.
APPL ( Abstract Plan Preparation Language) est une nouvelle variante de NDDL
apparue en 2006 dont l’objectif était de simplifier l’analyse formelle et la
spécification des problèmes de planification destinés à des applications critiques
pour la sécurité telles que la gestion de l’alimentation ou le rendez-vous automa-
tisé dans le futur engin équipé. APPL a utilisé les mêmes concepts que NDDL
avec l’extension des actions, et aussi d’autres concepts.
RDDL (Relational Dynamic influence Diagram Language) est le langage officiel du
domaine d’incertitude en 2011. Conceptuellement il est basé sur PPDDL1.0 et
PDDL3.0, mais en pratique , il est complètement différent syntaxiquement et
sémantiquement. L’introduction de l’observation partielle est l’un des change-
ments les plus importants dans RDDL par rapport à PPDDL1.0. Il permet une
description efficace des processus de décision de Markov (MDP) et des proces-
sus de décision Markov partiellement observables (POMDP) en représentant
tout (état-fluents, observations, actions, ...) avec des variables.
MA-PDDL (Multi Agent PDDL) C’est une extension modulaire de PDDL3.1 introduite en
2012 (soit une nouvelle exigence multi-agent) qui permet la planification par et
pour plusieurs agents. l’extension est compatible avec toutes les fonctionnalités
de PDDL3.1 et traite la plupart des problèmes de MAPL. Elle ajoute la possi-
bilité de distinguer les actions éventuellement différentes des différents agents
(c.-à-d. Des capacités différentes). De même, différents agents peuvent avoir des
objectifs et/ou des paramètres différents. Les conditions préalables des actions
peuvent maintenant se référer directement à des actions simultanées (p. Ex.
Les actions d’autres agents) et donc les actions avec des effets d’interaction
peuvent être représentées de manière générale et souple.
Table 3.1 – Quelques variantes du langage PDDL

inconsistance potentielle (par exemple lorsque deux actions sont en conflit). Cette
approche obéit au paradigme de la décomposition de but, i.e., le problème initial (but
à atteindre) est décomposé en sous-problèmes plus simples (grâce à l’utilisation de
règles de décomposition) ; ceux-ci sont à nouveau décomposés, et ainsi de suite jus-
qu’à l’obtention de problèmes terminaux (tous solubles par des actions élémentaires).
Un espace de recherche plus élaboré où les nœuds sont des plans partiels [BW94],
les arcs sont des opérations de raffinement d’un plan partiel. La règle des raffinements
consiste à ajouter des actions au plan partiel pour accomplir une proposition ou à
ajouter des contraintes d’ordre entre les actions.
La planification partielle
La planification partielle peut être vue comme une recherche dans un espace
de plans d’ordres partiels. Au Initialement, l’algorithme de recherche est doté d’un
plan d’initialisation. Les états de l’algorithme de recherche sont des plans. Ensuite,
les moyens de raffinement sont appliqués sur le plan jusqu’à l’obtention d’un plan
complet permettant de résoudre le problème. Les actions dans cette recherche ne
sont pas des actions du domaine de planification appliquées dans les états, mais des
actions appliquées sur les plans comme : l’ajout d’une action au plan, l’ajout d’un
ordre entre deux actions, etc. Chaque plan a les quatre éléments cités ci-après. Les
deux premiers définissent les étapes du plan et les deux derniers servent à déterminer
comment les plans peuvent être étendus :
1. un ensemble d’actions qui constituent les étapes du plan. A l’initialisation, un
plan initial Contient deux actions a0 et a1 . L’action a0 n’a pas de pré-conditions
et a comme effet tous les littéraux de l’état initial. a1 n’a pas d’effets et a
comme pré-conditions tous les littéraux du but
2. un ensemble de contraintes d’ordre d’exécution binaire entre les actions de la
forme a < b. Initialement, a0 < a1 ;
3. un ensemble de liens causaux. Un lien causal défini entre deux actions a et
p
b dans le plan, est désigné par a →
− b. il est lu comme a accomplit p pour
p
b. Une action c ajoutée au plan est en conflit avec a →
− b si l’action c a (p)
comme effet et si c vient après a et avant b ;
4. un ensemble de pré-conditions ouvertes. Une pré-condition est ouverte si elle
n’est pas obtenue par une action du plan.
L’algorithme POP (Partial Order Planning)

Dans le domaine de planification partielle, le problème de planification est défini,
comme d’habitude, par un état initial, un état but, et un ensemble d’actions.
L’état initial contient l’action a0 et l’action a∞ . La contrainte d’ordre a0 < a∞ ,

un ensemble vide des liens causaux, et l’ensemble des pré-conditions ouvertes qui
contient toutes les pré-conditions de l’action a∞ [Kum92].
A chaque itération de l’algorithme, la fonction successeur choisit, d’une manière

arbitraire, une pré-condition ouverte p d’une action b et génère un plan successeur
pour chaque situation consistante possible afin d’accomplir p par une action a. La
consistance est forcée par [Kum92] :
p
1. Le lien causal a →
− b et la contrainte d’ordre a < b sont ajoutés au plan. Si a
n’appartient pas au plan, alors il faut aussi ajouter a0 < a et a < a∞ ;
2. La résolution des conflits entre les nouveaux liens causaux et les actions du
plan d’une part ; et entre l’action a (si elle est nouvelle) et tous les liens causaux
p
d’autre part. Un conflit entre a → − b et c est résolu en forçant c de s’exécuter
à un moment en dehors de l’intervalle de protection, soit en ajoutant b < c ou
c < a. L’état successeur est ajouté si le résultat est un plan consistant ;
3. Le plan solution est trouvé si le plan ne contient pas de pré-conditions ouvertes.
4 Planification graphique
Blum et Furst [BF97] ont introduit les techniques de planification graphiques
dans un espace de recherche très puissant s’appuyant sur les deux types d’espace de
recherche présentées précédemment : planification dans l’espace d’états et planifi-
cation dans l’espace de plans. L’espace d’état fournit un plan comme une séquence
d’actions.
Les planificateurs dans l’espace de plans synthétisent un plan comme un en-

semble d’actions partiellement ordonné. Les techniques de planification graphique
sont basées sur une idée plus puissante : l’analyse de l’accessibilité.
L’analyse de l’accessibilité porte sur la question de savoir si un état qi est acces-

sible à partir d’un état qj grâce à un ensemble d’actions, et quelles sont ces actions
qui le permettent ?
L’idée de Blum et Furst dans [BF97] était de construire un graphe qui est beau-
coup plus petit que le graphe de transition d’états. Le graphe de planification est
polynomial en espace et peut être construit d’une manière efficace pour certains
problèmes difficiles. L’inconvénient est que le graphe de planification contient des
états qui peuvent ne pas être atteints. Cet inconvénient est dû aux relations mu-
tex qui sont définies afin d’exprimer l’impossibilité de certaines combinaisons de
propositions ou d’actions [EF10].
4.1 Principe de construction de graphe

Dans les approches de planification graphique, un graphe est construit en niveaux
[EF10] :
1. L’idée de base est de considérer à chaque niveau i du graphe non pas un état
individuel, mais pour une première approximation, l’union des prédicats de
tous les états accessibles en appliquant i actions.
2. Ainsi, chaque niveau Ni contient deux sous niveaux :
(a) le sous-niveau d’actions Ai et
(b) le sous-niveau de prédicats Pi .
68 4. PLANIFICATION GRAPHIQUE
3. Ensuite le graphe est construit niveau après niveau, en commençant a partir

de P0 . A la première étape, P0 représente l’état initial.
4. A l’étape i, l’ensemble Ai représente toutes les actions exécutables dans Pi−1
et tous les no − op (non-opérateur) actions (no–opp ) pour chaque prédicat
p ∈ Pi−1 , l’action no–opp d’un prédicat p est définie par :
(a) prec(no–op) = ef f et+1 (no–opp ) = p et
(b) prec(no–op) = ef f et−1 (no–op) = ∅.
5. L’ensemble Pi+1 = Pi ef f et(Ai ) où ef f et(Ai ) est l’union des ef f et+1 de
S
tous les opérateurs dans Ai .
6. Les itérations continuent jusqu’à ce que le graphe de planification se stabilise,
ce qui signifie que :
(a) Ai+1 = Ai et
(b) Pi+1 = Pi
ou alors qu’un plan solution soit trouvé.
4.2 Planificateur GRAPHPLAN

Depuis la création initiale de Graphplan [BF97], un certain nombre de chercheurs
ont poussé ces idées dans une variété de directions passionnantes, y compris : élargir
la classe de problèmes pour lesquels ce style de planification peut être appliqué,
réduisant ainsi le temps de fonctionnement (via des améliorations à la fois basiques
Stratégie et au code lui-même), et en utilisant Graphplan comme préprocesseur pour
d’autres stratégies de recherche.
En particulier, des planificateurs tels que BLACKBOX (AT andT / Washington),

IPP (U. Freiburg), STAN (U. Durham) et Sensory Graphplan (U. Washington) ont
été créés comme variantes du planificateur GRAPHPLAN.
5 Planification hiérarchique
La technique de planification hiérarchique (Hierarchical Task Network - HTN)
est une méthodologie d’intelligence artificielle pour la création des plans par la
décomposition des tâches. C’est un processus où le système de planification décompose
les tâches en sous-tâches, jusqu’à ce que des tâches primitives soient trouvées [NIK+ 03].
La planification hiérarchique HTN permet de décrire le domaine de planification

en utilisant des tâches. Un planificateur HTN diffère du planificateur dans un espace
d’états par le fait que l’objectif n’est plus d’atteindre un état satisfaisant le but, mais
d’accomplir un ensemble de tâches. Par exemple, l’objectif peut être de voyager de
Annaba à Oran (travel (Annaba, Oran)). Le planificateur HTN décompose les tâches
non primitives récursivement en tâches de plus en plus élémentaires, jusqu’à ce que
des tâches primitives puissent être exécutées. Par exemple, la tâche taxi-travel se
décompose en get-taxi , ride , pay-driver .
5. PLANIFICATION HIÉRARCHIQUE 69
Les tâches primitives sont exécutées en utilisant un opérateur de la planification

dans un espace d’états. Les définitions de terme, littéral, opérateur, action, fonction
de transition et plan sont les mêmes qu’en planification dans un espace d’états.
Cependant le langage HTN comporte les notions de tâche, de méthode et de réseau
de tâches utilisées dans la définition d’une solution [Gab06].
5.1 Algorithme de résolution HTN

L’idée principale des algorithmes de résolution d’un problème de planification
hiérarchique (HTN) est donnée dans l’algorithme de planification HTN ci-dessous
qui fonctionne de façon itérative par la décomposition des tâches non élémentaires
en sous-tâches de plus en plus petites ; et par la résolution des conflits jusqu’à la
construction d’un plan solution constitué sans conflits par des tâches élémentaires
qui peuvent être résolues en utilisant les opérateurs de planification.
Algorithme de planification HTN

1. Input : problème de planification P
2. Si P contient seulement des tâches primitives, alors résoudre les conflits dans
P et retourner le résultat. Si les conflits ne peuvent être résolus, retourner
échec
3. Choisir une tâche t non primitive dans P
4. Choisir une expansion de t
5. Remplacer t dans l’expansion
6. Utiliser les critiques pour trouver les interactions entre les tâches dans P, et
suggérer des façons de les gérer
7. Appliquer une des façons proposées dans l’étape 6
8. Aller à la ligne 2
5.2 Planificateur HTN

Il existe plusieurs planificateurs dans la littérature adoptant les techniques de pla-
nification hiérarchique tels que : SHOP2 [NIK+ 03], TLPlan [BKS99] et TALPlanner
[DK01], etc. Ces trois planificateurs ont été classés parmi les meilleurs planificateurs
et ils ont reçu des prix de performance distinguée à la quatorzième Compétition in-
ternationale des systèmes de planification (AIPS’02, Sixth International Conference
on AI Planning and Scheduling) en 2002.
6 Planification distribuée
La planification distribuée peut être considérée simplement comme une spécialisation
de la résolution distribuée de problèmes, où le problème est résolu par un plan dis-
tribué. Cependant, une ambiguı̈té existe puisqu’on ne sait pas exactement ce qui est
distribué. En effet, il est possible que le plan soit distribué entre plusieurs systèmes
d’exécution. Ou alors, le processus de planification est distribué, qu’il soit ou non le
70 6. PLANIFICATION DISTRIBUÉE
plan résultat peut l’être [EF10].
Lorsque les agents ont un but commun à atteindre, trois types de planification
distribuée sont distingués [Wei04] :
6.1 Planification centralisée pour les plans distribués

Dans ce type de planification, les plans sont formulés de manière centralisée mais
il doivent être exécutés dans un mode distribué. Pour cela, un planificateur d’ordre
partiel peut générer des plans où il n’y a pas un ordre strict entre certaines actions
qui peuvent s’exécuter en parallèle. Un agent coordonnateur centralisé est envisagé
pour décomposer un tel plan en plusieurs plans locaux transmis à des agents qui
peuvent les exécuter.
6.2 Planification distribuée pour les plans centralisés

Dans ce type de planification, la collaboration de plusieurs agents est nécessaire
pour le processus de planification car la formulation d’un plan complexe peut exiger
la collaboration de plusieurs spécialistes de la planification, comme la génération de
la solution à tout problème complexe. Ainsi, pour la planification complexe dans des
domaines tels que la fabrication et la logistique, le processus de planification pourrait
être réparti entre les agents, où chacun contribue par une partie (plan partiel) à ce
plan de façon centralisée, jusqu’à ce qu’un plan global soit créé.
6.3 Planification distribuée pour les plans distribués

Il s’agit d’une planification où le processus de planification et ses résultats sont
distribués. Dans ce cas, il ne serait peut-être pas nécessaire d’avoir un plan multi-
agents représenté entièrement dans le système, mais pourtant, la répartition des
morceaux de ce plan peut être plus compatible. Cela signifie que les agents ne de-
vraient pas être en conflit les uns avec les autres lors de l’exécution des plans partiels,
et devraient s’entraider les uns avec les autres pour réaliser leurs plans.
Les recherches sur ce type de distribution de planification est relativement riche

et variée [Wei04, EF10].
7 Avantages de la planification
Parmi les principaux avantages de la planification, nous pouvons citer :
– La représentation des actions et des buts afin de permettre une
sélection plus fine :
– États et buts : utilisation des prédicats et de la logique du premier ordre.
– Actions : description logique de pré-conditions et d’effets.
– Connexion directe entre état et actions : permet de guider et contraindre la
recherche au lieu de faire des expansions aveugles d’alternatives.
7. AVANTAGES DE LA PLANIFICATION 71
– Relâcher les contraintes pour la construction séquentielle de solu-

tions :
– Le processus de planification peut ajouter des actions quand elles sont re-
quises.
– Pas d’obligation de le faire à partir de l’état initial de manière incrémentale.
– Réduit le facteur de branchement et le nombre de retour en arrière en pre-
nant des décisions simples et évidentes en premier lieu.
Exemple : on peut décider d’acheter du lait sans savoir où en acheter, com-
ment s’y rendre et quoi faire après. Il n’y a pas nécessairement de lien entre
l’ordre de planification et l’ordre d’exécution.
– Une approche diviser-pour-régner en définissant des sous-buts :

– Les buts peuvent être des conjonctions : aller chercher du lait ET aller
chercher des bananes ET aller chercher une perceuse.
– On peut faire des sous-plans pour chaque sous-but.
– Ceci fonctionne tant que le coût pour combiner les sous-buts n’est pas trop
grand.
8 Conclusion
Nous avons présenté dans ce chapitre les principaux concepts liés à la planifi-
cation ; avec description des principales classes, à savoir la planification classique
ou distribuée et présentation des différentes techniques pouvant être adoptées pour
chacune des deux classes.
La présentation de quelques algorithmes de planification nous paraissait indis-

pensable, non pas dans le but de faire une étude comparative ou de choisir quel
est le meilleur algorithme, mais afin de montrer que chacun d’entre eux peut être
adapté à une situation particulière, dans le but de rechercher un plan optimal. Cette
situation dépend, en effet, de l’exemple auquel nous envisageons d’exécuter notre
planification. Pour cela, nous allons essayer d’adopter l’un des algorithmes que nous
avons vu, dans ce chapitre, et ce pour proposer une structure à base d’agents pour
la planification de la composition des services Web.
Quel est le principe de cette composition de services Web ? Quel sera son ob-
jectif ? Et comment la réaliser ? Ce sont les principales questions auxquelles peut
répondre le chapitre suivant.
72 8. CONCLUSION
Chapitre 4
La composition des services Web
1 Introduction
La composition de services Web est le fait de grouper plusieurs services pour
répondre à un besoin donné. La nécessité de faire une composition est due au fait
que les nombreux services atomiques disponibles sur Internet ne peuvent pas tou-
jours satisfaire individuellement des requêtes spécifiques. Ces services ont besoin
d’être intégrés pour créer des services composites à valeur ajoutée.
Ce chapitre est consacré à la présentation d’un état de l’art sur les travaux liés
à la composition des services Web. Il est organisé de manière à présenter d’abord le
concept de composition : sa définition avec la présentation des différentes techniques
de composition, et nous passons ensuite, au recensement des principaux problèmes,
pouvant être présentés lors de l’adoption de l’une de ces techniques.
Le thème de la composition des services web a été abordé par plusieurs commu-
nautés scientifiques [Bou07, Gsc09, LV08, Che11, Cha07, MM08], nous allons essayer
d’analyser les différentes approches présentées, dans ce contexte, et nous concluons
ce chapitre par les limites que les travaux existants en composition de services n’ont
pas pu dépasser.
2 Définition de la composition des services Web

Un service web est dit composé ou composite lorsque son exécution implique des
interactions avec d’autres services afin de faire appel à leurs fonctionnalités.
La composition des services web spécifie quels services ont besoin d’être invoqués,
dans quel ordre et comment gérer les exceptions des conditions. Par exemple, un re-
vendeur d’ordinateurs personnels peut offrir un service Web qui permet aux clients
de demander des devis et de commander des ordinateurs. Cependant, la mise en
œuvre de l’opération ”Commande” peut exiger l’invocation de plusieurs services
Web, y compris, par exemple, ceux fournis par les fabricants et les expéditeurs de
PC, pour les derniers prix et délais de livraison. Un service Web implanté en in-
voquant d’autres services Web s’appelle un service composite, tandis qu’un service
73
CHAPITRE 4. LA COMPOSITION DES SERVICES WEB
Web implanté en accédant au système local s’appelle le service de base.
Il est à remarquer que le fait qu’un service Web soit basique ou composite n’est
pas pertinent du point de vue des clients car il ne s’agit que d’un problème de mise
en œuvre. En fait, ils sont tous des services Web et peuvent être décrits, découverts
et invoqués de la même manière.
3 Techniques de composition des services Web

La composition de services Web se réfère au processus de création d’un service
composite offrant une nouvelle fonctionnalité, à partir de services Web existants plus
simples, par le processus de découverte dynamique, d’intégration et d’exécution de
ces services dans un ordre bien défini afin de satisfaire un besoin bien déterminé
[MBE03].
La composition des services Web a pour objectif de déterminer une combinaison

de services en fonction d’une requête d’un client. Du côté du client, cette composi-
tion semblera un unique service. La composition sera transparente au client, même
si cette composition sera la combinaison de plusieurs services Web.
A partir des travaux publiés dans le cadre de la composition des services Web
tels que ceux présentés dans [EF10, Bou07, PF09, LV08, DA07, Pel03, Cha07], nous
pouvons distinguer différentes classifications pour les techniques de composition des
services Web :
3.1 Classification par rapport au niveau du degré d’auto-

matisation
Par rapport au niveau du degré d’automatisation, il est possible de distinguer
trois types de techniques, à savoir :
La technique de composition manuelle

Une composition est dite manuelle quand tous les services Web qui font partie
de la composition sont connus ainsi que leurs ordres d’exécution. Cette façon de
composition appelée aussi fixe ou concrète.
La technique de composition semi-automatique

Une technique de composition semi-automatique est un pas en avant en com-
paraison avec la composition manuelle, dans le sens où elle permet de faire des
suggestions sémantiques pour aider à la sélection des services Web dans le processus
de composition.
La technique de composition automatique

La technique de composition totalement automatisée prend en charge tout le
processus de composition et le réalise automatiquement, sans qu’aucune intervention
74 3. TECHNIQUES DE COMPOSITION DES SERVICES WEB
de l’utilisateur ne soit requise.
3.2 Classification par rapport à la disponibilité des services

Deux techniques peuvent être définies ici, à savoir la technique de composition
statique et la technique de composition dynamique :
La technique de composition statique

La composition statique permet de créer de nouveaux services composites à partir
des services déjà existants dans un environnement stable et dans lequel les services
web participants à la composition sont disponibles et leurs comportements sont iden-
tiques.
Dans cette méthode, la composition s’effectue durant la période de conception

et les composants qui constituent le service web composite ne changent pas ou ne
changent que rarement.
Dans la composition statique, on distingue deux approches :

1. La chorégraphie : La chorégraphie définit des taches complexes par l’in-
termédiaire de la définition de conversations qui devraient être effectuées par
chaque service participant. Une conversation décrit l’échange de messages or-
donné entre deux services selon un protocole.
La chorégraphie de services décrit les interactions dans lesquelles les services

engagés participent afin d’atteindre leur objectif, ainsi que les dépendances
entre les interactions telles que le flot de contrôle (ex. une interaction doit
précéder une autre), le flot de données, les corrélations des messages, les
contraintes de temps, les dépendances transactionnelles, etc. [YACT09].
La figure 4.1 montre un schéma de chorégraphie de quatre services Web où

chaque service communique avec deux autres. Par exemple, le service SW1
envoie deux messages en parallèle aux services SW2 et SW4 (1). Lorsque les
services SW2 et SW4 ont communiqué avec les autres services, ils répondent
au service SW1 en séquence suivant l’ordre SW4 (6) suivi de SW2 (7).
2. L’orchestration : L’orchestration décrit, du point de vue d’un service, les
interactions de celui-ci ainsi que les étapes internes (ex. transformations de
données, invocations à des modules internes) entre ses interactions [YACT09].
Elle combine des services existants en ajoutant un coordinateur central (un

orchestrateur) qui est responsable d’appeler et de faire interagir des services.
L’exécution d’une orchestration de services est réalisable et contrôlée par le
coordinateur selon son plan d’exécution.
Dans une orchestration, le chef d’orchestre est donc le service dont les interac-
tions sont décrites. Celles-ci comprennent l’envoi et la réception de messages
à/de la part des partenaires sélectionnés. L’orchestration permet ainsi à un
3. TECHNIQUES DE COMPOSITION DES SERVICES WEB 75
Figure 4.1 – Une chorégraphie de services Web [Bel11]
service d’être enchaı̂né à d’autres d’une manière prédéfinie. Elle est ensuite
exécutée par des scripts d’orchestration qui décrivent les interactions entre les
applications en identifiant les messages, la logique et les séquences d’invoca-
tions. Le composant exécutant les scripts d’orchestration est appelé moteur
d’orchestration. Celui-ci agit comme une entité centralisée pour coordonner
les interactions entre les services.
La figure 4.2 montre un schéma d’orchestration de services Web correspondant

au protocole de communication du service SW1 avec les services SW2 et SW4
de la figure 4.1. L’exemple de l’orchestration montre que le service SW1 envoie
des messages en parallèle aux services SW2 et SW4. Le service SW1 se met
en attente des réponses des services SW4 et SW2 en séquence.
Figure 4.2 – Une orchestration de services Web [Bel11]
Une différence importante entre l’orchestration et la chorégraphie est que la

chorégraphie offre une vision globale et plus collaborative de la coordination en
décrivant le rôle que joue chaque participant impliqué dans l’application. Par
contre, l’orchestration offre une vision locale et centralisée, c’est-à-dire que le
procédé est toujours sous le contrôle d’un des partenaires métier représentant
l’orchestrateur [Bel11].
76 3. TECHNIQUES DE COMPOSITION DES SERVICES WEB
La technique de composition dynamique

On appelle composition dynamique l’agrégation de services Web permettant de
résoudre un objectif précis soumis par un utilisateur en prenant en compte ses
préférences. Cette composition peut se faire avant ou pendant l’exécution des ser-
vices Web. Le service résultant de cette composition est appelé service composite.
Dans ce type de techniques, la composition de services Web tient compte des ser-
vices disponibles, de leurs fonctionnalités et du but à atteindre avant ou pendant
leur exécution.
Les techniques de compositions dynamiques peuvent elles-mêmes être regroupées

en deux sous familles :
1. Les techniques basées sur les ”Workflows” (processus métier) : Ces
techniques permettent aux utilisateurs d’exploiter la puissance d’un grand
nombre de ressources hétérogènes et distribuées par la réduction de l’espace
de recherche et la sélection des services appropriés à appliquer dans la compo-
sition comme indiqué dans la figure 4.3.
L’outil de spécification WSFL pour ”Web Services Flow Language” [Bou07]

est une solution proposée par IBM pour la description des flux des processus
pour deux types de composition de services Web :
– Workflow interne, ou flux d’agrégation de services Web, mettant un en-
semble de services internes services en relation.
– Workflow externe, ou flux entre des services Web échangeant des messages
entre différents partenaires.
Figure 4.3 – Composition basée sur les Workflows
2. Les techniques basées sur des techniques de l’intelligence artificielle :

Plusieurs techniques d’intelligence artificielles peuvent être utilisées pour la
3. TECHNIQUES DE COMPOSITION DES SERVICES WEB 77
composition dynamique des services Web, telles que :
– Le calcul situationnel : dans cette approche, Le problème de la com-

position est abordé de la façon suivante : la requête de l’utilisateur et les
contraintes des services sont représentées en termes de prédicats du premier
ordre dans le langage de calcul situationnel. Les services sont transformés
en actions (primitives ou complexes) dans le même langage. Puis, à l’aide
de règles de déduction et de contraintes, des modèles sont ainsi générés et
sont instanciés à l’exécution à partir des préférences utilisateur.
– Preuve de théorèmes : dans cette approche, les services disponibles et les

requêtes utilisateur sont traduites dans un langage du premier ordre. Puis
des preuves sont produites à partir d’un démonstrateur de théorèmes.
– Composition avec SMA : la composition de services peut être implémentée

aussi en utilisant des SMA. Dans cette approche, chaque agent présente un
service et sert à satisfaire une partie de la requête de l’utilisateur en utilisant
ses propres capacités.
– Composition par planification : ordonner des services web ayant des

pré-conditions et des effets est donc très similaire à un problème de planifi-
cation automatique. De nombreuses études ont été faites pour implémenter
la composition de services web comme une résolution d’un problème de pla-
nification.
4 Modèles de composition des services Web
Les recherches sur les services Web se focalise principalement sur la problématique
de composition, l’interopérabilité entre les services, et la découverte automatisée des
services composites.
Des efforts ont déjà été faits par des industriels et des recherches afin d’atteindre
ces objectifs. Deux outils importants peuvent être utilisés afin de composer les ser-
vices Web. Il s’agit de BPEL4WS et OWL-S. Ces deux outils ont été créés en se
basant sur les modèles basés sur l’activité. De cette façon, BPEL4WS fournit la base
pour spécifier manuellement des services Web composites. D’autre part, OWL-S est
plus ambitieux et fournit une description lisible par machine des services Web qui
permettront la découverte et la composition automatiques (Hull and Su 2004).
En effet, il existe d’autres modèles pour composer des services tels que : work-
flows, graphiques, réseaux de Petri et également des langages de programmation tels
que Java et C. La composition des services Web peut être plus difficile et plus longue
suite au modèle de composition adopté.
78 4. MODÈLES DE COMPOSITION DES SERVICES WEB
4.1 Composition à l’aide de BPEL4WS

La composition des services Web utilisant BPEL4WS permet la manipulation
des services en tant que processus et activités. En fait, le langage BPEL4WS est
une fusion entre XLang de Microsoft et la FSM de IBM, mais tous sont considérés
comme un langage de flux de service Web. En tant que langage de mise en œuvre du
processus exécutable, le rôle de BPEL4WS est de définir un nouveau service Web
en composant un ensemble de systèmes existants. L’interface du service composite
est décrite comme une collection de WSDL PortTypes [CAH06].
BPEL4WS est basé sur XML et sur les Workflows. Selon Andrews et al., ce
langage distingue les processus abstraits des processus exécutables [ACD+ 03] comme
suit :
1. Le processus abstrait : ce processus spécifie les messages échangés entre les

différentes parties (services Web composants) sans indiquer le comportement
de chacune d’elles. Ce processus abstrait peut être relié à une composition de
type chorégraphie. Les services Web communiquent par échange de messages
(partie gauche de la figure 4.4).
2. Le processus exécutable : ce processus permet de spécifier l’ordre d’exécution

des activités, le partenaire concerné, les messages échangés entre ces parte-
naires, et les mécanismes des erreurs et des exceptions. Il s’agit du moteur
de l’orchestration donnant une représentation indépendante des interactions
entre les partenaires.
Figure 4.4 – Le flot de processus avec BPEL4WS [Pel03]
4. MODÈLES DE COMPOSITION DES SERVICES WEB 79

4.2 Composition à l’aide de OWL-S

Le processus de composition de services Web utilisant un langage Web sémantique
comme OWL-S augmente la découverte et la composition automatiques. En fait,
OWL-S repose sur une ontologie et un OWL. Cela signifie que OWL-S est également
basé et construit en utilisant des ressources et des concepts hiérarchiques. Avec une
telle spécification, les agents logiciels peuvent trouver des services en fonction de
leur description machine interprétée.
La principale tâche motivante pour OWL-S est la possibilité de découvrir auto-

matiquement les services Web. D’autres tâches motivantes sont l’invocation auto-
matique d’un service, avec lequel un agent logiciel peut interpréter le balisage pour
comprendre l’apport nécessaire pour l’appel de service, les informations renvoyées
et la manière d’exécuter le service.
En outre, le service Web composé est en fait un service abstrait. En fait, le fichier
de composition n’a que les appels de service. Dans OWL-S, chaque service faisant
partie de la composition a la même structure que celle composée.
4.3 Composition à l’aide de graphes

En 2005, Un autre modèle de composition des services Web a été utilisé par Gri-
gori et Bouzeghoub à l’aide de graphes [BGG12]. Dans leur travail, même s’ils s’in-
quiétaient de la correspondance des services, les exigences des utilisateurs et le ser-
vice publié sont basés sur des représentations graphiques. L’approche de récupération
du service repose sur les processus. Ainsi, un processus est représenté sous la forme
d’un graphe dirigé, dont les nœuds sont des activités. Les bordures ont des condi-
tions de transition associées exprimant les dépendances de flux de contrôle entre les
activités.
5 Cycle de vie de la composition des services Web

Selon Philippe Ramadour et Myriam Fakhri [RF11], la recherche de services
et la description de composition peut se faire à un niveau fonctionnalité et
entrées/sorties , comme elle peut se faire à un niveau intentionnel et métier. Ils
utilisent la notion de but ( business goal ) pour formuler les besoins en services.
Les buts métier sont intéressants dans le cadre de la composition pour de nombreuses
raisons :
– Les besoins peuvent être élémentaires dont la satisfaction ne nécessite qu’un
seul service, comme ils peuvent être complexes nécessitant de nombreux ser-
vices avec un ordonnancement complexe.
– Les buts complexes peuvent être décomposés sur plusieurs niveaux pour être
réduits en un ensemble de buts plus simples. Cette réduction, appliquée aux
buts, permet d’exprimer des alternatives de décomposition de buts, où chaque
alternative peut être mieux adaptée à un certain contexte.
80 5. CYCLE DE VIE DE LA COMPOSITION DES SERVICES WEB

– Au niveau de la composition de services, le processus de réduction d’un but

complexe en sous-buts plus élémentaires permet d’identifier petit à petit les
services à composer, réalisant chacun un but atomiques.
Partant de ce principe, le cycle de vie d’une composition de services doit être

initialisé avec un nouveau besoin. Il comporte les quatre phases suivantes [RF11] :
1. La phase d’analyse de la composition : l’analyse du besoin dans cette
phase est exprimé sous la forme d’un but. Dans le cas où les buts sont com-
plexes ; ils doivent alors être décomposés pour être réalisés. À ce niveau, la
composition de services est exprimée par un ensemble de sous-buts à réaliser ;
elle est appelée composition abstraite et elle ne fait référence à aucun service
ni à aucune logique métier. Elle est décrite par un graphe de composition qui
contient pour un but (le besoin) un ensemble de sous-buts permettant de le
réaliser.
2. La phase de conception de la composition : Dans cette phase, la com-
position est exprimée sous la forme d’un Workflow et elle est appelée une
composition orchestrée. Elle ne fait référence à aucun service mais elle décrit
un processus avec ses activités, certaines devant être réalisées avec des services.
3. La phase d’implantation de la composition : Dans cette phase, nous
devons décrire un processus exécutable BPEL4WS ([ACD+ 03]) ou WSBPEL
qui référence sous forme d’entrées/sorties des spécifications de services publiées
dans un annuaire de type UDDI. Dans ce cas, la composition est dite exécutable
et elle est sous forme d’un processus BPEL.
4. La phase d’exécution de la composition : Dans cette phase, nous allons
exécuter une composition en invoquant et en exécutant des services parti-
culiers, produisant ainsi un résultat en réponse au besoin. À ce niveau, la
composition est appelée une trace de composition et elle décrit les services
exécutés réellement ainsi que leurs données réelles d’entrées/sorties.
6 Quelques travaux sur la composition des ser-

vices Web
Plusieurs travaux ont été réalisé pour composer des services Web .Un processus
de planification peut être utilisé pour chercher l’ordre adéquat des services Web dans
la composition. Comme le nombre de services peut être relativement important, il
est nécessaire d’ajouter une phase d’optimisation dont le but est de proposer à l’uti-
lisateur les meilleures compositions de services selon certains critères.
L’approche proposée par A. Yachir et al. [YACT09] vise à construire un plan

pour une composition de services après avoir vérifié sa faisabilité.
M. El Falou s’est basé dans [EF10] sur l’utilisation de différentes techniques de

planification pour remédier à quelques problèmes liés à la composition de services.
Il a proposé un modèle de résolution distribuée à base d’agents et il a développé une
architecture d’agent de composition de services, dit auto-guérissant, permettant de
6. QUELQUES TRAVAUX SUR LA COMPOSITION DES SERVICES WEB 81
répondre aux requêtes utilisateurs par des plans de composition de services, de diag-
nostiquer en ligne l’état d’exécution du plan, et de le réparer automatiquement dans
le cas de détection de faute d’exécution.
D. Pellier et H. Fiorino ont proposé dans [PF09] une architecture originale de

composition automatique de services Web par des techniques de planification qui
repose sur la conception d’un modèle de planification entièrement distribué dans le-
quel les agents raisonnent conjointement sur leurs services respectifs pour atteindre
un but commun prédéfini par l’utilisateur, créant ainsi un plan global représentant
une composition possible de leurs services.
L’objectif de Daniela Barreiro Claro [Cla06] était de composer automatiquement

et de manière optimale les services web dédiés à la réalisation de devis en utilisant
la planification pour détecter quels services appartiendront à la composition. Elle a
donc proposé un canevas (framework) constitué de plusieurs phases qui permettent
de négocier les services afin de proposer automatiquement des compositions opti-
males aux utilisateurs avec des critères d’optimisation génériques.
Or, les utilisateurs peuvent avoir des critères d’évaluation qui leur sont propres,
voire même contredire les critères génériques, ce qui a fait l’objet des travaux de
P. Albers et O. Licchelli dans [AL07] qui se sont basé sur le prototype SPOC
[Cla06, CAH06] en ajoutant l’emploi des profils d’utilisateur afin d’améliorer les
résultats de ce système, et de présenter les solutions les plus adéquates à un utilisa-
teur donné. Cette approche a été validée sur un exemple de construction de bâtiment
basé sur une ontologie du marché public français.
Le modèle HSN proposé dans [BB09] est un modèle de composition qui permet
de corriger et de valider un service composé avant son exécution. L’éditeur permet la
composition progressive suivie par une vérification des contraintes de temps. Il per-
met à l’utilisateur de localiser et de corriger facilement d’éventuels conflits temporels
dans sa spécification. L’utilisateur peut exporter le fichier RSH pour une utilisation
future.
Le travail présenté par N. Temglit et al. [TAAN08] propose un modèle pour la

composition des services Web sémantiques. Ce modèle est basé sur une représentation
sémantique de l’ensemble des concepts manipulés par les services Web d’un domaine
d’application, à savoir, les opérations et les concepts statiques utilisés pour décrire
les propriétés des services Web.
Imed Chouchani a proposé un outil fondé sur les algorithmes génétiques pour la
découverte et la composition de services web, le consommateur exprime le service
web désiré par un fichier de description WSDL, le système interroge un espace de
recherche contenant une collection de services Web et fournit le résultat sous forme
d’une liste de services possibles (population). Le critère de sélection d’un service est
sa valeur de similarité syntaxique avec le service cible. Les éléments de la population
résultat sont des services qui existent dans l’espace de recherche (découverte d’un
service approprié) ou qui ont été crées par la composition de services existants.
82 6. QUELQUES TRAVAUX SUR LA COMPOSITION DES SERVICES WEB
Pour trouver un service web particulier, il faut trouver les différentes opérations
le constituant, l’espace de recherche est formé donc par un ensemble d’opérations
et l’algorithme génétique tente à trouver une opération similaire à l’opération cible
[Cho10].
Philippe Ramadour et Myriam Fakhri ont présenté dans [RF11] une méthode
pour l’ingénierie de la composition de services, basée sur quatre niveaux d’abstrac-
tion qui permet d’organiser le processus d’ingénierie de la composition et de struc-
turer une application à base de services. Le niveau abstrait décrit une composition
sous forme de buts à réaliser, le niveau orchestré décrit une composition en termes
d’activités ordonnancées, le niveau exécutable décrit une composition sous la forme
de processus BPEL et le niveau trace décrit une composition en termes de services
invoqués réellement. En associant un but et un contexte à chaque composition, quel
que soit son niveau d’abstraction, les patrons permettent la découverte de compo-
sitions, leur réutilisation et leur adaptation. Des opérateurs ont été proposés pour
mettre en œuvre ces activités durant le processus de satisfaction d’un besoin.
AgFlow est un prototype de composition de services Web avec prise en charge

de la qualité des services. Il a été proposé par L. Zeng et al. dans [ZBDS03] et il est
caractérisé par :
– Un modèle de qualité de service pour évaluer la qualité globale des services
Web.
– Deux approches alternatives de sélection du service pour l’exécution des ser-
vices composites.
L. Li, M. Rong and G. Zhang ont présenté dans [LRZ13] une approche de
sélection basée sur la QoS multidimensionnelle qui a introduit la QoS multidimen-
sionnelle pour décrire les propriétés QoS de la composition des services Web et
calcule la QoS de chaque dimension de la composition des services Web. Le résultat
le plus important selon cette recherche est la capacité d’extraire la composition
des services Web qui peut mieux répondre aux contraintes non fonctionnelles des
compositions de service Web qui peuvent satisfaire les exigences fonctionnelles des
utilisateurs.
C. Jatoth et G.R. Gangadharan ont proposé dans [JG15] deux métriques de

fitness comme suit :
– Tout d’abord, ils choisissent les services les mieux adaptés pour la composition
par leur valeur de conditionnement physique locale fondée sur la combinaison
de divers facteurs de QoS et la hiérarchisation.
– Ensuite, ils utilisent une valeur de conditionnement physique globale pour
minimiser la complexité de calcul, autour de la composition du service. Les
résultats de l’expérience indiquent l’importance de l’approche proposée pour
la composition de service évolutive et robuste de QoS. Ils ont également l’in-
tention de concentrer leurs travaux futurs sur une autre approche basée sur la
logique floue afin d’évaluer la valeur de la condition physique locale.
Z. Zheng et al. Ont mené des évaluations sur la QoS observée par les utilisateurs
des services Web à partir d’emplacements distribués. Les utilisateurs de services ont
invoqué un grand nombre de services Web dans des environnements hétérogènes sur
des services Web réels. Ils ont présenté des résultats expérimentaux complets, et
publié des ensembles de données réutilisables [ZZL14].
W. Khowfa et al. ont utilisé les attributs de décision multi-critères (MCDM) et

de qualité de service (QoS) dans [KSK15] pour obtenir le service non fonctionnel
approprié à partir des services similaires disponible dans le ”Cloud”.
De son coté, Amina Bekkouche a fait une étude comparative des différentes
approches de découverte et de composition des services Web qui l’a résumé dans le
tableau (4.5) avant de proposer à son tour un outil de composition de services Web
basé sur les algorithmes génétiques [Bek12].
84 6. QUELQUES TRAVAUX SUR LA COMPOSITION DES SERVICES WEB

Figure 4.5 – Tableau comparatif des travaux de découverte et composition de services Web [Bek12]

7 Conclusion
Nous avons essayé, via ce chapitre, de faire un petit tour d’horizon sur la compo-
sition des services Web. Pour cela, nous avons commencé par la définition de cette
composition et la présentation de ses principales techniques, et ce en faisant une
classification de ces techniques par rapport au niveau du degré d’automatisation, en
premier lieu et une autre classification par rapport à la disponibilité des services, en
second lieu.
La première classification, nous permet de distinguer trois type de composition

sur le plan manuel, semi-automatique ou automatique. Tandis que la deuxième nous
permet de faire la différence entre une composition statique et une autre dynamique.
Après avoir présenté quelques modèles de composition des services Web se basant
sur les ”Workflows”, la description sémantique des services ou même ceux se basant
sur les graphes, nous avons jugé très important de présenter quelques travaux de
recherches axés sur la recherche, la découverte et la composition des services Web
et ce, dans le but de cerner le domaine de la composition des services Web d’un
côté et de pouvoir positionner notre objectif relatif à la composition par rapport
aux travaux existants.
Ce chapitre est le dernier dans la première partie de notre manuscrit, dédiée à

la présentation d’un état de l’art sur :
1. les agents et les systèmes multi-agents,
2. les services Web,
3. la planification et
4. la composition des services Web
Les chapitres suivants ferons l’objet de la deuxième partie de notre thèse, présentant
le modèle que nous allons proposer.
86 7. CONCLUSION
Deuxième partie
Partie : Notre Contribution
87
Chapitre 5
Le modèle proposé
1 Introduction
Après avoir présenté un état de l’art sur les principaux concepts autours desquels
s’articulent notre thèse, dans la première partie de notre pièce écrite, tels que :
– celui des agents et des systèmes multi-agents,
– le concept de service Web ainsi que les principales technologies liées aux ar-
chitectures orientées service,
– la problématique de planification en intelligence artificielle et sa relation avec
les agents et les services Web,
– Le problème de la composition des services Web avec exhibition de quelques
travaux de recherche axés sur le concept de composition.
Nous allons essayé, via cette deuxième partie, de proposer une solution adéquate au
problème de composition. Il est à noter que les résultats obtenus par les chercheurs
adoptant une technique de composition de services Web dynamique tels que ceux de
Pellier et al dans [PF09], Yasmine Charif dans [Cha07], et Mohamed El Falou dans
[EF10, EFBMV10] étaient meilleurs par rapport à ceux obtenus par les équipes qui
ont adopté des techniques de composition statiques. Ce qui nous a encouragé à adop-
ter une technique de composition dynamique avec prise en considération de nouvelles
contraintes permettant d’améliorer les résultats qui ont été obtenus précédemment
d’un côté, et de remédier aux problèmes rencontrés lors de l’implémentation de ces
solutions, d’un autre côté.
Notre solution pour remédier au problème de la satisfaction des contraintes des

utilisateurs des services Web composites, exigeant une certaine qualité de réponse à
leurs requêtes, a fait l’objet d’une publication [BBB16]. Le modèle que nous avons
proposé est un modèle de planification entièrement distribué, dans lequel les agents
raisonnent conjointement sur leurs services respectifs pour atteindre un but commun
prédéfini par l’utilisateur via une requête, créant ainsi un plan global représentant
une composition possible de leurs services.
89
CHAPITRE 5. LE MODÈLE PROPOSÉ
2 Travaux de base
L’ensemble des services web disponibles peut être représenté par un graphe, dont
les nœuds représentent les attributs en entrée et en sortie ainsi que les services Web
et les arcs entre ces nœuds correspondent soient à des liens entre des attributs entrées
et un service Web ou des liens entre un service Web et ses attributs en sortie c.-à-d.
les résultats que le service produit après son exécution. Une composition de services
correspond à un sous-graphe de ce graphe des services Web disponibles.
Deux algorithmes ont été proposés par Mohamed El Falou [EF10], dans ce
contexte. L’idée de base consiste à extraire le meilleur plan local avec l’utilisation
d’une heuristique globale. Cette heuristique globale est basée sur une évaluation
locale du meilleur plan local permettant d’atteindre le but, et aussi sur une estima-
tion d’heuristique globale distribuée qui guide l’agent pour choisir son meilleur plan
local, en garantissant la complétude et l’optimalité de l’algorithme.
Pour pouvoir calculer cette heuristique globale, chaque service qui rejoint le
groupe d’agents des services Web doit calculer tous les liens entre ses services lo-
caux ainsi que tous les liens avec tous les autres services des autres agents.
Un agent calcule l’heuristique globale associée à un service s une seule fois pour
chaque requête, en chaı̂nage arrière de l’état but à l’état initial.
Ensuite, pour chaque service voisin sn d’un service colorié sc , sn est également
colorié à condition que tous ses arcs entrants sortent des services coloriés. En faisant
cela, nous allons obtenir le sous graphe exécutable de services, chaque service dans
ce sous-graphe est un service accessible et exécutable.
Afin de pouvoir répondre aux exigences des utilisateurs des services Web compo-
sites, le système doit prendre en considération toutes les caractéristiques spécifiées,
et ce afin de pouvoir extraire les principaux critères auxquels il doit répondre. Un
tel système doit prendre en compte le fait que la qualité de Service puisse avoir des
dimensions multiples, et le fait que la QoS des services composites est déterminée
en fonction de la qualité de service de ses services composant sous-jacents.
Par exemple, l’utilisateur peut exiger de minimiser la durée d’exécution tout en

satisfaisant certaines contraintes en termes de prix et de fiabilité, tandis qu’un autre
utilisateur peut donner plus d’importance au prix qu’à la durée d’exécution. Une
approche QoS à la composition de service est donc indispensable, ce qui maximise
la QoS des exécutions de services composites avec prise en compte des contraintes
et des préférences définies par les utilisateurs.
3 Notre contribution
Notre contribution est basée sur les différentes descriptions de qualification présentes
dans le registre UDDI pour la sélection des meilleurs services Web pouvant apparte-
90 2. TRAVAUX DE BASE
nir à un service composite. Cette tâche sera attribuée à chaque agent lors du choix
de son meilleur plan local, tout en prenant en considération les différents qualificatifs
spécifiés par le client, lors de l’exécution de sa requête.
3.1 Définitions formelles

Afin de pouvoir concrétiser notre modèle, nous allons présenter, dans cette sec-
tion, une définition formelle de chaque concept utilisé.
Définition des services Web

Soit un environnement E constitué des éléments suivants :
SW : un ensemble de services Web SWi ,
SW = {SW1 , SW2 , .., SWn } = {SWi /i = 1..n}
SW i : est un service Web décrit par un ensemble de paramètres d’entrée P Ei et

de paramètres de sortie P Si ,
SWi = (P Ei , P Si ),
P Ei : est un ensemble de paramètres d’entrée du service Web SWi ,
P Ei = {pei1 , pei2 , .., peim } tel que m est le nombre de ces paramètres d’entrée :
(m = Card(P Ei )) ,
P Ei = {pei1 , pei2 , .., peim } = {peij /j = 1..m}
P Si : est un ensemble de paramètres de sortie du service Web SW ,
P Si = {psi1 , psi2 , .., psik } tel que k est le nombre de ces paramètres de sortie :
(k = Card(P Si )),
P Si = {psi1 , psi2 , .., psik } = {psij /j = 1..k}
Définition des liens sémantiques

Les liens sémantiques ont été défini, formellement, dans [BBB16] comme suit :
LS : est un ensemble de liens sémantiques entre les services Web.
L’ensemble LS peut être représenté par une matrice carrée SW xSW .

 
1 ... 0
LS =  ... . . . ... 
 
0 ... 1
3. NOTRE CONTRIBUTION 91
LSij : est un ensemble de liens sémantiques entre deux services Web SWi et SWj
défini comme suit :
1 ssi∃psit ∈ P Si et psit ∈ P Ej
ls(SWi , SWj ) =
0 ssi∀pejt inP Ej et ∀psit 0 ∈ P Si ⇒ pejt 6= psit 0
f lsij : est une fonction qui permet de mesurer l’intensité du lien sémantique entre
deux services Web SWi et SWj définie comme suit :
Card(P Si 0)
f lsij =
Card(P Ej )
avec P Si 0 = {psit ∈ P Si et ∀t, psit ∈ P Ej } d’où :
– f lsij = 1 ssi CardP Si 0 = CardP Si = Card(P Ej ). Ce qui est évident dans

le cas où tous les paramètres de sortie psik d’un service Web SW i coı̈ncident
exactement avec tous les paramètres d’entrée pejt d’un service Web SW j ;
– f lsij = 0 ssi CardP Si 0 = 0. C’est-à-dire aucun paramètre de sortie psi du

service Web SW i ne figure dans P Ej , l’ensemble des paramètres d’entrée d’un
service Web SWj .
Définition des critères (C) de la qualité de service (QdS)

Dans le même environnement défini précédemment, nous pouvons intégrer les
éléments suivants :
C : est un ensemble de vecteurs des paramètres de qualité Ci correspondants

aux différents services Web SWi .
Ci : est un vecteur des paramètres de qualité, Ci = (ci1 , ci2 , .., cik ) tel que k est
la dimension du vecteur Ci .
Relativement à un domaine donné D, il est possible de classifier les attributs de

la qualité de service en des attributs génériques ou spécifiques. Tels que les attributs
génériques correspondent à tous les services Web indépendamment des domaines
auxquels ils appartiennent et les attributs spécifiques correspondent aux services
Web liés aux domaines auxquels ils dépendent.
Le modèle que nous proposons est composé des deux classes des attributs de
qualité :
– CGen : est la classe des attributs génériques
– CSpe : est la classe des attributs spécifiques
Dans la classe des attributs génériques CGen , nous distinguons les attributs mesu-
rables des attributs non mesurables. Pour pouvoir distinguer ces deux types d’attri-
but, nous allons étendre la notation d’un attribut ci comme suit :
– cmi : est un attribut générique mesurable relatif à un service Web SWi
– cnm
i : est un attribut générique non mesurable relatif à un service Web SWi
92 3. NOTRE CONTRIBUTION
Soit par conséquence, cm

ij le j
ieme
attribut générique qui est de type mesurable pour
le service Web SWi et cik le k ieme attribut générique qui est de type non mesurable
nm
pour le même service Web SWi .
Il est à noter que la plupart des attributs mesurables peuvent être décrits par
des paramètres liés à la performance, tels que :
– Le débit : qui représente le nombre de requêtes servies pendant un intervalle

de temps.
– Le temps de réponse : qui indique le temps requis pour compléter une

requête d’un service Web.
– La fiabilité : qui reflète la capacité d’un service d’exécuter correctement ses

fonctions.
– La scalabilité : qui représente la capacité du service de traiter le plus grand

nombre d’opérations ou de transactions pendant une période donnée tout en
gardant les mêmes performances.
– La robustesse : qui représente la probabilité qu’un service peut réagir pro-

prement à des messages d’entrée invalides, incomplets ou avec conflit.
– La disponibilité : c’est la probabilité d’accessibilité d’un service.
Il y a des attributs de QdS qui ne sont pas mesurables, mais qui sont importants
pour les services web tels que :
– Le coût ou le prix d’exécution : c’est le prix que doit payer un client du

service Web pour bénéficier du service.
– La réputation : est la mesure de la crédibilité du service. Elle dépend des

expériences des utilisateurs.
– La sécurité : est un regroupement d’un ensemble de qualités à savoir : la

confidentialité, le cryptage des messages et le contrôle d’accès.
3. NOTRE CONTRIBUTION 93
3.2 L’architecture générale proposée

Nous proposons une architecture de composition de services Web à base d’agents
afin de pouvoir arriver à une planification distribuée menant à la création d’un ser-
vice Web composite vu comme un plan définissant des relations d’antécédence et de
causalité entre services élémentaires et assurant un certain nombre de contraintes.
Notre modèle consiste à formuler une requête client portant sur un ensemble
de paramètres et exigeant un certain nombre de contraintes. Ces contraintes seront
prises en considération par un agent intelligent de type BDI (Belief-Desire-Intenion)
AgentQueryAnalyzer, qui sera chargé de la gestion des préférences, de l’utilisateur,
qui forment ses croyances. Il sera chargé, également, de la synthèse de ses contraintes,
afin de pouvoir les classifier par type.
Le deuxième type d’agent dans notre architecture est l’AgentPlan qui sera chargé
de la composition des services Web impliqués dans notre processus, en essayant de
proposer une planification optimale, de point de vue temps
La découverte des différents services Web sera assurée par l’AgentDiscovry. C’est
un agent autonome capable de découvrir les différentes offres liées au service de-
mandé.
Un autre type d’agent sera utilisé dans notre modèle relativement à chaque ser-
vice impliqué pour choisir la meilleure offre et invoquer ce service, si nécessaire. Il
s’agit de l’AgentService.
Un ensemble d’agents de type AgentService sera donc automatiquement généré,

dans le but de rechercher les services pouvant répondre à la requête de l’utilisateur,
de filtrer ces services et de les ordonner en fonction de leurs pertinences.
Chaque agent de type AgentService va collaborer avec l’AgentDiscovry et l’Agent-

Plan pour la proposition d’un plan global répondant à la requête utilisateur, tel qu’il
est indiqué dans la figure 5.1 à la page 95.
Une collaboration entre plusieurs agents de type AgentService peut avoir lieu
pour essayer de fournir des plans partiels répondant à une partie de la requête,
représentant une réponse à un service composite partiel. Nous envisageons, dans
ce cas, la possibilité de détruire tous les AgentService impliqués dans la création
du plan partiel fourni par fusion de leurs plans locaux et la naissance d’un nouvel
AgentService avec attribution des rôles de tous les agents détruits. Cet agent pourra
ainsi collaborer avec l’AgentDiscovry et l’AgentPlan, pour rechercher le plan opti-
mal global.
4 L’architecture détaillée du modèle

Soit un environnement E constitué des éléments suivants :
94 4. L’ARCHITECTURE DÉTAILLÉE DU MODÈLE
Figure 5.1 – Architecture à base d’agents pour la composition automatique de

services Web
– SW : un ensemble de services Web, SW = sw1 , sw2 , ... où chaque wsi est
décrit par un ensemble de paramètres d’entrée et de sortie wsi = (P E, P S)
comme suit :
– P E : est l’ensemble des paramètres d’entrée du service, P E = pe1 , pe2 , ... tel
que pei est un paramètre d’entrée. Exemple : pe1 = lieu, pe2 = date, pe3 =
heure, etc.
– P S : est l’ensemble des paramètres de sortie du service, P S = ps1, ps2, . . .
tel que psi est un paramètre de sortie. Exemple : ps1 = heure, ps2 =
date, ps3 = lieu, etc.
– M wsi : une matrice de description des liens sémantiques entre les différents
services wsi .
– F QoS : un ensemble de facteurs de qualité correspondants au service compo-
site. Exemple : durée de transport, prix du service transport, type transport
(taxi, voiture, bus, tram,...), tarif menu, type de menu, classe hôtel (*, **, ...),
type chambre (simple, double, ...), ...
– SW Ci : l’ensemble des services Web composites, décris par l’ensemble des ser-
vices composants. Cet ensemble de services composites peut être réduit à un
seul service composite dans le cas où nos contraintes sont définies par service.
Et il peut contenir jusqu’à N services composites dans le cas où nous choisis-
sons de définir des contraintes par personne.
Notre problème de planification doit définir les états initiaux des croyances des
agents, les opérateurs et méthodes qu’ils peuvent appliquer ainsi que le but qu’ils
doivent réaliser. Le but est représenté par un ensemble de propositions décrivant les
propriétés du monde qui doivent être vérifiées. Nous allons, dans ce cadre, essayer de
décrire l’architecture appropriée pour chaque type d’agent impliqué dans le modèle
proposé, le rôle assuré par chaque agent et les moyens de communication entre les
différents agents du système.
4. L’ARCHITECTURE DÉTAILLÉE DU MODÈLE 95
4.1 L’architecture de l’AgentQueryAnalyzer

L’AgentQueryAnalyzer sert d’interface entre le système et le client. Il est chargé
du traitement de la requête de l’utilisateur, avant de la transmettre à l’AgentPlan
qui va essayer de trouver une solution pour répondre à cette dernière. Son rôle prin-
cipal est d’analyser la requête pour en tirer l’ensemble des paramètres liés au but
ainsi que la liste des contraintes imposées par l’utilisateur. Il offre à l’utilisateur
le choix entre deux formes de requête ; une requête guidée sous forme d’une suite
de mots clés et une autre brute, exprimée en langage naturel. Le système récupère
cette dernière, l’analyse dans le but d’extraire les mots clés par application d’un
algorithme d’extraction qui se base sur la classe Regex et d’une ontologie du do-
maine. L’AgentQueryAnalyzer est composé de deux modules essentiels (voir figure
5.2 à la page 97).
Il a, également, la possibilité d’interroger une ontologie du domaine de la re-

cherche de l’utilisateur afin de pouvoir lier les principaux concepts extraits de la
requête dans le but d’étendre l’intervalle des services Web liés sémantiquement à
cette dernière.
C’est l’agent qui va aussi initier le processus de découverte des services Web liés
à la requête du client, et ce, en émettant, à l’AgentPlan, le résultat de cette analyse
adapté aux préférences des utilisateurs après la phase du traitement.
Cet agent est doté d’un module de raisonnement, lui permettant de traiter la
requête du client et d’un module de communication assurant son interaction avec
les autres agents.
Le module de traitement (ou d’extraction de critères) :

c’est la partie responsable de l’analyse de la requête du client afin de déterminer la
liste des paramètres et celle des contraintes d’entrée. En se basant sur l’ensemble de
connaissances acquises par cet agent et sur ses compétences, il doit pouvoir raisonner,
pour pouvoir en tirer les intentions et les désirs de l’utilisateur avec prise en compte
d’une ontologie du domaine.
Le module de communication :
il permet de gérer la communication et l’interaction de l’AgentQueryAnalyzer
avec les autres agents et ce par échange de messages standards.
4.2 L’architecture de l’AgentPlan

L’AgentPlan doit être capable de raisonner sur la tâche qu’il doit accomplir
et doit être capable de communiquer avec les autres agents (AgentQueryAnalyzer,
AgentDiscovry). Il est initialisé avec la description sémantique du but utilisateur à
réaliser (But, Mots clés, références liées à l’ontologie du domaine).

Figure 5.2 – L’architecture fonctionnelle de l’AgentQueryAnalyzer
Lorsque l’AgentPlan n’arrive pas à trouver une solution à la requête posée par
l’AgentQueryAnalyzer, il procédera donc à la décomposition de la tâche qu’il n’a pas
pu accomplir en sous tâches et chargera l’agentDiscovry de rechercher les services
Web correspondants.
L’AgentPlan est composé de quatre modules (voir figure 5.3 à la page 98).
Le module de raisonnement :
c’est la partie responsable de la définition du comportement de l’agent relati-
vement à ses interactions avec les autres agents ainsi qu’avec son environnement
constitué principalement de trois éléments essentiels qui sont :
1. L’ensemble des données transmises par l’AgentQueryAnalyzer à travers un
envoi de message ou par les autres agents (AgentDiscovry ou AgentService).
2. ses propres intentions et compétences.
3. ses connaissances.
Le module de données :
il sert de support des informations transmises par les autres agents.
Le module de décomposition d’une tâche :

utile pour la décomposition d’une la tache principale en sous taches élémentaires,
dans le cas où l’AgentPlan n’arrive pas à trouver une solution au problème posé par
le client via l’AgentQueryAnalyzer.
Figure 5.3 – L’architecture fonctionnelle de l’AgentPlan
il gère la communication et l’interaction avec les autres agents et qui sera assurée
par un échange de messages avec eux.
4.3 L’architecture de l’AgentDiscovry

C’est un agent cognitif qui assure la découverte des descriptions des services Web
satisfaisant la requête envoyée par l’AgentQueryAnalyzer sur le plan sémantique.
Son architecture interne se compose de deux modules et d’une base de services qui
sert à stocker les descriptions sémantiques des services Web satisfaisant la requête de
l’utilisateur rendue par l’annuaire des services Web (UDDI). Le premier module est le
module de communication inter agents. Il reçoit la requête de l’AgentQueryAnalyzer
sous forme de message, déclenche le module de traitement et retransmet le résultat
de la recherche à l’AgentQueryAnalyzer, et le second, dit module de traitement,
permet de comparer la demande du client avec les offres.
Le module de traitement (ou de recherche des services Web) :
c’est la partie responsable de la recherche du ou des services Web correspondants

à la requête du client afin de déterminer la liste des services Web répondant aux
critères du client. En se basant sur l’ensemble de des compétences, il doit pouvoir
exécuter un algorithme de ”Matching” avec prise en compte d’une ontologie du
domaine pour que sa recherche soit fructueuse.
il permet de gérer la communication et l’interaction de l’AgentDiscovry avec les
autres agents par échange de messages standards contenant le résultat de l’ana-
lyse correspondant aux contraintes client, l’ensemble des services répondants à ces
contraintes et toute autre information échangée entre les agents de notre modèle.
Figure 5.4 – L’architecture fonctionnelle de l’AgentDiscovry
L’algorithme utilisé pour la recherche des services Web est celui du Matchma-
king proposé dans [BCG07] et qui permet de calculer le degré de correspondance
entre les paramètres fonctionnels des services Web avec ceux réclamés par l’utilisa-
teur avec quatre principaux modes de comparaison : le mode Exact, le mode Plugin,
le mode Subsume et le mode Fail.
1. Le mode Exact : sélectionne une offre si elle correspond exactement à une
demande (demande = offre) c’est-à-dire les entrées et les sorties de la demande
sont équivalents aux entrées et sorties de l’offre (Matching exact).
2. Le mode Plug-In : retourne une offre si elle englobe une demande (de-
mande¡offre) c’est-à-dire les entrées de la demande englobe les entrées de l’offre
et les sorties de la demande sont englobées par les sorties de l’offre dans l’on-
tologie de domaine ( Matching inclusif).
3. Le mode Subsume : retourne une offre si elle est incluse dans une demande
(demande > of f re) (l’inverse du mode Plug-In) ( Matching partiel)
4. Le mode Fail : retourne faux, si aucune correspondance entre l’offre et la
demande (demande 6= of f re) (echec de Matching ). L’agent applique un
test sur ces entrées. Ensuite, nous allons attribuer un score pour chaque mode
de Matching :
– Exact (score=3),
– PlugIn (score=2),
– Subsume (score=1) et
– Fail (score=0).
Illustration du principe à l’aide d’un exemple :
Supposons qu’il existe quatre services Web de voyage S1, S2, S3 et S4 publiés
sur le Web. Leurs paramètres fonctionnels (entrées, sorties) sont :
– S1 ayant les valeurs (Alger, Rabat, 20000, 19/07/2015).
– S2 ayant les valeurs (Oran, paris, 22000, 12/07/2015).
– S3 ayant les valeurs (Maroc, Tunisie, 23000, 14/07/2015).
– S4 ayant les valeurs (Algérie, France, 22000, 12/07/2015).
S1 :
– Oran à Alger, mode = Subsume, score = 1
– Paris à Rabat, mode = Fail, score = 0
– 20000 à 20000, mode = Exact, score = 3
– 12/07/2016 à 19/07/2016, mode = Fail, score = 0
Total = 4
S2 :
– Oran à Oran, mode = Exact, score = 3
– Paris à Paris, mode = Exact, score = 3
– 20000 à 22000, mode = Fail, score = 0
– 12/07/2016 à 12/07/2016, mode = Exact, score = 3
Total = 9
S3 :
– Oran à Morocco, mode = Fail, score = 0
– Paris à Tunisia, mode = Fail, score = 0
– 20000 à 24000, mode = Fail, score = 0
– 12/07/2016 à 12/07/2016, mode = Fail, score = 0
Total = 0
S4 :
– Oran à Algeria, mode = Plug-in, score = 2
– Paris à France, mode = Plug-In, score = 2
– 20000 à 22000, mode = Fail, score = 0
– 12/07/2016 à 12/07/2016, mode = exact, score = 3
Total = 7
Pour le Matching global nous obtiendrons :
– S1 : score = 6, pas mal
– S2 : score = 9 Meilleur
– S3 : score = 0, Pas bon
– S4 : score = 7 Bien
Donc, le service Web S2 est considéré comme le meilleur qui correspond à la

requête lors de l’affichage. L’agent classe les services par ordre croissant selon leurs
scores, en éliminant ceux avec un score égal à zéro.
4.4 L’architecture de l’AgentService

Un AgentService sera utilisé pour invoquer chaque service nécessaire dans le
cadre de la composition des services liés à la requête du client. Lorsque l’Agent-
Plan n’arrive pas à trouver une solution à la requête posée par l’AgentQueryA-
nalyzer. L’AgentPlan procédera donc à la décomposition de la tache qu’il n’a pas
pu accomplir en sous taches et chargera l’agentDiscovry de rechercher et invoquer
un ensemble d’agents de type AgentService de trouver des solutions partielles aux
différentes taches élémentaires. Le rôle principal d’un AgentService est de trouver
un plan partiel répondant à la requête du client avec prise en considération de ses
contraintes. Son architecture peut être décrite à l’aide de deux modules essentiels
(voir figure 5.5).
Le module de raisonnement :
c’est la partie responsable de la recherche de la solution partielle d’un but proposé

par l’AgentPlan afin de contribuer à la résolution d’une partie du problème posé.
Le raisonnement se fera sur la base des connaissances de l’AgentService et de ses
compétences.
il permet de gérer la communication et l’interaction de l’AgentService avec

l’AgentDiscovry pour lui envoyer une réponse ou avec l’AgentPlan pour lui trans-
mettre son plan partiel. Il est, également possible, qu’il s’échange des messages avec
un autre AgentService pour collaborer avec lui dans le but de se rapprocher du plan
global, en fusionnant leurs plans partiels.
Figure 5.5 – L’architecture fonctionnelle de l’AgentService

5 Définition formelle du processus de planifica-

tion
5.1 Principe général et définition formelle du processus
La planification peut être décrite par l’interaction entre trois éléments comme
présenté dans la figure 5.6 :
– le système de transition d’états qui évolue par sa fonction de transition entre
états en fonction des évènements et des actions qu’il reçoit ;
– un contrôleur qui prend en entrée l’état s du système et qui fournit une action
a en fonction du plan à exécuter ;
– un planificateur qui prend en entrée une description du système, une situation
initiale et des objectifs à atteindre (un ou plusieurs états buts). Il synthétise
un plan en fonction de son état but puis le transmet au contrôleur.
Figure 5.6 – Principe de planification
Définition d’une action

L’action est une instance d’un opérateur. Si a est une action et si un état tel
que :
precond+ (a) ∈ si et precond− (a) ∩ si = ∅
alors a est applicable à si , et le résultat de cette application est l’état :
si+1 = γ(si , a) = (si − ef f ets− (a)) ∩ ef f ets+ (a).
5.2 La planification dans notre modèle

La planification est la partie la plus importante dans notre modèle. Après avoir
présenté une description formelle, nous avons jugé utile de rappeler le scénario qui
va déclencher ce processus, relativement au modèle proposé. Dans ce scénario, l’es-
sentiel est de savoir que la requête client est envoyée par l’AgentQueryAnalyzer à
l’AgentPlan. A ce niveau, nous exigeons que cette requête soit fournie à l’AgentPlan
sous la forme suivante :
Req(P, C) : requête fournie à l’AgentPlan pour traitement, constitué des éléments
P et C où :
– P : est un vecteur des attributs de la requête.
Rappelons que ces attributs peuvent être des paramètres d’entrée peik tel que
peik ∈ P Ei d’un service Web SWi .
102 5. DÉFINITION FORMELLE DU PROCESSUS DE PLANIFICATION
– C : est un vecteur des contraintes de la requête. Rappelons que ces contraintes

correspondent aux critères cik du vecteur de la qualité du service tel que :
cik ∈ Ci d’un service Web SWi .
Cette requête représente le but initial et sert comme un paramètre d’entrée de

l’AgentPlan pour arriver à la solution désirée, représentant le but final. Et elle sera
traitée par l’AgentPlan de la manière suivante :
1. Il demande à l’AgentDiscovry de rechercher le service qui répond au mieux à la
requête Req. Dans le cas favorable, il demande à l’AgentService correspondant
de lui fournir cette solution et il la fourni au client. Sinon,
2. Il procède à la décomposition du but initial en sous buts partiels, qui serviront
d’entrée à un ensemble d’AgentService correspondant aux services Web SWi ,
pouvant faire l’objet d’un service Web composite SW C.
3. Chaque AgentService sera chargé de la recherche d’une solution partielle rela-
tivement au sousbutpartiel qu’il doit atteindre.
4. les plans partiels fournis par les différents AgentService seront transmis par
ces derniers à l’AgentPlan, qui se chargera de la combinaison de ces différents
plans pour la construction du plan global.
5.3 Stratégie de recherche d’un plan solution

Notre stratégie de recherche d’un plan solution est basée sur l’utilisation d’une
fonction de récompense des agents permettant de mesurer leur degré de satisfaction.
Ag : ensemble fini d’agents Agi .
Ai : ensemble fini de m actions aj de l’agent Agi , Ai = a1 , a2 , ..., aj , ..., am .
RAgi : fonction de récompense de l’agent Agi .
RAgi : Ag × Ai → R
Cette fonction reflète le degré de satisfaction d’un agent Agi lors de l’exécution d’une
action aj .
Pour chaque plan partiel Pi fournit par un agent Agi , nous devons ajouter une
contrainte temporelle Cti , permettant de situer temporellement un plan par rapport
aux autres, dans le but de pouvoir les synchroniser entre eux, lors de la construction
du plan global.
6 Illustration à l’aide d’un exemple : L’organisa-

tion d’une conférence
Soit le service Web composite relatif à l’organisation d’une conférence interna-
tionale. Et pour lequel, nous allons suivre les étapes suivantes :
6. ILLUSTRATION À L’AIDE D’UN EXEMPLE : L’ORGANISATION D’UNE 103
CONFÉRENCE
– Au début de notre travail, nous allons supposer que les services Web existent
et que nous pouvons les invoquer à partir de leurs URL. Et nous essayerons
d’aborder la phase de recherche et d’invocation, une fois le problème de com-
position traité.
– Il est donc possible de les importer et de connaı̂tre leurs descriptions à partir
de leurs fichiers WSDL associés.
– Passage d’une description à base de fichier WSDL vers un modèle de descrip-
tion servant d’entrée pour notre modèle de composition.
– Définition des liens sémantiques entre les services composants.
– Modélisation de la composition des services avec prise en considération du
facteur QoS.
Essayons de simplifier le processus d’organisation d’une conférence et de le res-
treindre aux taches élémentaires suivantes :
6.1 Transport des conférenciers

de leurs :
– lieux d’arrivée (gare, aéroport,...) vers leurs hôtels
– hôtels vers leurs salles de conférences
– salles de conférences vers leurs hôtels
– hôtels vers leurs lieux de départ (gare, aéroport,...)
– salles de conférences vers les restaurants
– restaurants vers les salles des conférences
– restaurants vers les hôtels
6.2 Restauration
– Sous-traiter avec des services de restauration existants :
– Nécessitant de faire déplacer les conférenciers, donc étendre le service trans-
port pour assurer le transport des conférenciers entre les salles de conférences
et les restaurants.
– Assurer un service sur place, donc prévoir des salles proches des salles de
conférence pour assurer la restauration
– Assurer le service par l’organisme assurant la réservation des salles de conférence.
6.3 Hôtellerie
– Réservation de chambre d’hôtel
– Réservation des salles de conférence
– Étudier la possibilité d’assurer la restauration par les hôtels
Dans cet exemple, nous pouvons envisager deux types de contraintes à prendre
en considération :
1. Contraintes par service : dans ce type de contraintes, nous allons admettre
que tous les conférenciers seront traités de la même manière et que les seules
contraintes à prendre en considération sont celles qui peuvent être présentées
lors de la sélection des services offerts. A titre d’exemple, nous pouvons dire
que tous les conférenciers seront pris en charge dès leurs arrivées pour être
104 6. ILLUSTRATION À L’AIDE D’UN EXEMPLE : L’ORGANISATION D’UNE
CONFÉRENCE
déplacés vers leurs hôtels, un service de transport leur sera assuré pour aller
de/vers leurs hôtels vers/de leurs salles de conférences et de même pour le
service de restauration.
Il est à noter, dans ce type de contraintes, que les facteurs de qualité sont
définis, d’une façon générale et de la même manière, par les organisateurs de
la conférence et qu’aucun cas particulier ne sera traité à part.
2. Contraintes par personne : ce type de contraintes impose la prise en
considération des préférences des conférenciers lors du choix des services à
offrir. C’est-à-dire que le conférencier sera impliqué, lors de la sélection des
services et là, il pourra définir ses contraintes pour le choix des différents ser-
vices offerts. Pour illustrer ce type de contraintes, nous pouvons nous baser sur
le cas où le conférencier préfère faire une réservation dans un hôtel spécifique
(5, 4, ... étoiles) ou qu’il préfère prendre un taxi ou louer une voiture pour se
déplacer. Et dans ce cas les facteurs de qualité seront définis de façon indivi-
duelle par les clients (conférenciers).
Un scénario relatif à l’exemple choisi avec des contraintes par personne :

– Soit la requête suivante posée par le client X : Je serai à Paris le 02 juillet
2017 à 15h00, je veux prendre le moyen de transport le moins cher pour aller
à Caen où j’aurai besoin de faire une réservation d’hôtel le plus proche du
Campus 2 où ma conférence aura lieu .
– L’AgentQueryAnalyzer analyse la requête du client et transmet un message à
l’AgentPlan lui demandant une solution pour son problème ;
– L’AgentPlan demande à l’AgentDiscovry de rechercher les services Web relatifs
à la requête de l’utilisateur ;
– L’AgentDiscovry répond : Je dois contacter l’AgentService Transport et
l’AgentService Hôtellerie pour répondre à ta question
– L’AgentPlan à l’AgentDiscovry : Vas y fais tes contacts ;
– L’AgentDiscovry à l’AgentService Transport : Je cherche le moyen de trans-
port le moins cher de Paris à Partir de 15h00 vers Caen.
– L’AgentDiscovry à l’AgentService Hôtellerie : Je cherche l’hôtel à Caen le
plus proche du Campus2 à partir du 02 juillet 2017
– L’AgentService Transport : répond à l’AgentDiscory L’idéal est de prendre
un train, le premier est à 16h00
– L’AgentDiscovry à l’AgentService Transport : Ok pour le train de 16h00
– L’AgentService Hotellerie à l’AgentDiscovry : Je te propose l’hôtel Novotel
Caen Côte de Nacre ou bien Liberté au centre ville .
– L’AgentDiscovry à l’AgentService Hôtellerie : Ok pour l’hôtel Novotel Caen
Côte de Nacre
7 Conclusion
Nous avons proposé, dans ce chapitre, un modèle de composition des services
Web en se basant sur destechniques de planification et en utilisant une architecture
distribuée à base d’agents. La spécificité de notre modèle par rapport au modèle pro-
7. CONCLUSION 105
posé dans [BBB16] consiste en l’utilisation de modules supplémentaires permettant

l’analyse de la requête de l’utilisateur. Et ce afin de pouvoir prendre en considération
les différents critères des utilisateurs introduits dans le cadre de la recherche et la
sélection des services Web demandés par les utilisateurs lors de l’exécution de leurs
requêtes, assurant ainsi une meilleure qualité de service.
Vu que la phase d’analyse d’une requête client, assurée par l’AgentQueryAna-

lyzer, nécessite l’utilisation d’une ontologie du domaine dans le but d’extraire l’en-
semble des mots clés liés aux différents concepts introduits par le client dans sa
requête, nous avons jugé indispensable d’implémenter une ontologie d’un domaine
spécifique, afin de pouvoir l’exploiter dans le cadre de la recherche des services Web
nécessaires. Pour cela, et dans le but de valider notre modèle, nous avons choisi le
domaine de l’organisation de voyage, pour l’implémentation de notre ontologie qui
fera l’objet du chapitre suivant. Et ce, avant de passer au troisième chapitre de cette
deuxième partie qui sera axé sur l’implémentation du modèle proposé.
106 7. CONCLUSION
Chapitre 6
Conception et implémentation
d’une ontologie du domaine de
voyage
1 Introduction
Une ontologie est une représentation partagée et consensuelle entre les collabo-
rateurs qui a pour but de se mettre d’accord sur un sujet particulier avec un objectif
commun. Le but est de définir un ensemble de connaissances dans un domaine donné.
Il existe plusieurs types d’ontologie et leurs applications sont diverses dans le monde
du développement. La création d’une ontologie a pour but de spécifier un vocabulaire
commun et faire usage de représentations et concepts partagés, afin de permettre
l’interopérabilité des documents et faciliter l’élaboration des connaissances.
Les ontologies sont des architectures de concepts, et non pas des listes orga-
nisées de termes. Les concepts, à la différence des termes, se caractérisent par des
définitions formelles. C’est ce caractère formel qui permet à l’information d’être ma-
nipulée par les machines.
Dans le but de pouvoir analyser l’aspect sémantique de notre requête client et

ne pas se limiter au caractère syntaxique de cette dernière, nous avons jugé utile
et indispensable d’implémenter une ontologie liée au domaine des voyages afin de
pouvoir synthétiser au mieux les critères de recherche spécifiés par l’utilisateur et
assurer ainsi une meilleure qualité du service rendu.
2 Conception de l’ontologie de voyage

Plusieurs méthodes ont été proposées dans le cadre de la construction d’une onto-
logie et celle que nous avons choisi pour notre domaine d’application est la méthode
METHONTOLOGY .
Cette méthode vise la construction d’ontologie au niveau de connaissance. Ce

projet a été motivé par le constat de l’absence de méthodes ou de guides structurés
qui est un obstacle pour la construction d’ontologies partagées et consensuelles. Il
107
CHAPITRE 6. CONCEPTION ET IMPLÉMENTATION D’UNE ONTOLOGIE DU
DOMAINE DE VOYAGE
est également un obstacle à l’extension d’une ontologie existante ou à sa réutilisation

dans d’autres ontologies.
L’approche METHONTOLOGY distingue plusieurs étapes dans son processus
de construction qui seront détaillées dans les sections suivantes relativement à notre
domaine de voyage :
1. Spécification des besoins
2. Conceptualisation
3. Formalisation.
4. Implémentation.
5. Évolution de l’ontologie et Test.
2.1 Spécification des besoins

Avant de commencer l’implémentation de notre ontologie, nous devons commen-
cer par la phase de spécification qui consiste à établir un document de spécification
des besoins.
– Domaine : catalogue des destinations liées aux ”Voyages”
– Développée par : BELMABROUK Karima
– Objectif Opérationnel : La modélisation sémantique de l’organisation d’un
voyage avec modélisation des pays et leurs villes, principalement les villes ayant
un aéroport.
– Utilisateur : L’utilisateur principal est l’AgentQueryAnalyzer de notre modèle
mais elle peut être utilisée, également, par des clients voulant réserver un
voyage, des responsables de compagnie de voyage voulant avoir un accès facile
dans le but d’organiser un voyage.
– Degré de formalisme : formel.
– Portée : Cet aspect détermine à priori la liste des termes de l’ontologie (les
plus importants) parmi lesquels, nous pouvons citer : Hébergement, Moyens
transport, Info Voyage, Distance destination, Destination, Continent, Trajet,
Client, Équipements chambre, pays, ville.
– Granularité (niveau de détails) : large
– Source de connaissance : autres ontologies, sites Web de voyages, sites des
agences de voyages.
2.2 Conceptualisation
Une fois que la majorité des connaissances soient acquises, nous devons les orga-
niser et les structurer en utilisant des représentations intermédiaires semi-formelles,
faciles à comprendre et indépendantes de tout langage d’implémentation.
Les principales étapes de la phase de conceptualisation sont :

– Construction du glossaire des termes ;
– Hiérarchie des classes de l’ontologie ;
– Diagramme des relations binaires ;
– Dictionnaire des concepts de l’ontologie ;
– Table des relations binaires ;
– Table des attributs des concepts de l’ontologie
108 2. CONCEPTION DE L’ONTOLOGIE DE VOYAGE
DOMAINE DE VOYAGE
Concept Description
Voyage décrit tout ce qui a rapport avec le concept de voyage
Hébergement décrit l’hébergement du client qui va réserver
Chambre d’hôtes décrit les chambres qui offrent un petit déjeuner
Hôtel décrit l’hôtel que le client veut réserver
Moyens transport décrit les moyens de transport choisis ou loués
Moto décrit le moyen de transport moto
Train décrit le moyen de transport Train
Bateau décrit le moyen de transport Bateau
Traversier décrit le moyen de transport Traversier
Avion décrit le moyen de transport Avion
Automobile décrit le moyen de transport Automobile
Info Voyage décrit toutes les informations concernant le voyage
Voyage train décrit les informations concernant le voyage par train
Voyage Avion décrit les informations concernant le voyage par Avion
Distance destination décrit la distance de la destination
Destination décrit toutes les informations de la destination
Continent décrit le continent
Trajet décrit tout ce qui concerne le trajet
Client décrit les informations du client
Équipement chambre décrit les informations sur les équipements de la chambre
Table 6.1 – Tableau du glossaire des termes
Construction du glossaire des termes

Ce glossaire contient la définition de tous les termes relatifs au domaine qui seront
représentés dans l’ontologie finale. Le tableau 6.1 fournit une liste de quelques termes
utilisés dans notre ontologie.
Hiérarchie des classes de l’ontologie

Dans cette étape, nous construisons les diagrammes de classification de concepts.
Initialement, nous répertorions les concepts en ensemble d’organisations, ensuite
nous relions les concepts entre eux, si nécessaire, par des relations Est-un .
La relation Est-un entre les classes signifie que, la classe C1 est une sous classe
de la classe C2, si et seulement si toute instance de la classe C1 est une instance de
la classe C2. La figure 6.1 représente les différentes classes de concepts construits.
Un concept universel Thing , qui généralise tous les concepts, racine de notre
hiérarchie de concepts, peut être utilisé pour former une seule hiérarchie globale,
afin d’éviter d’avoir des concepts isolés.
Diagramme des relations binaires

Dans cette étape, nous construisons le diagramme des relations binaires. Dans
ce diagramme, les classes sont représentées par des rectangles et les relations par
des arcs orientés (du domaine vers le co-domaine) et étiquetés par le nom de la
2. CONCEPTION DE L’ONTOLOGIE DE VOYAGE 109
DOMAINE DE VOYAGE
Figure 6.1 – Hiérarchie des classes de l’ontologie du voyage
relation. La relation inverse d’une relation est aussi schématisée dans ce diagramme.
Le diagramme des relations binaires de notre ontologie de voyage est présenté dans
la figure 6.2.
Dictionnaire des concepts de l’ontologie

Dans cette étape, nous allons fournir une description formelle des concepts qui
ont été présentés dans la hiérarchie des classes. Ce processus correspond à la création
du dictionnaire de concepts relatif à la méthodologie ”METHONTOLOGY”. Dans
ce dictionnaire, nous définissons pour chaque concept : les attributs, les relations
dont la source est ce concept ainsi que le père comme présenté dans le tableau 6.2.
Table des relations binaires

Les relations binaires sont représentées sous forme de propriétés qui lient un
concept à un autre. Pour chaque relation dont la source est dans l’arbre de classifi-
cation des concepts, nous définissons : son nom, sa description, le nom du concept
source, le nom du concept cible, la cardinalité et le nom de la relation inverse comme
indiqué dans le tableau 6.3 de la page 112.
110 2. CONCEPTION DE L’ONTOLOGIE DE VOYAGE

DOMAINE DE VOYAGE
Figure 6.2 – Diagramme des relations binaires de l’ontologie du voyage
Concept Parent Attributs

Client Voyage Nom client, Date naissance
Trajet Voyage Ville départ, Ville Arrivé
Info Voyage Voyage Temps Arrivée, Temps Départ, Arrivée, Aéroport
Voyage Avion Info Voyage Prix Classe économique, Prix classe business
Voyage Train Info Voyage
Hébergement Voyage URL, disponibilité des chambres, chien, description
Chambre d’hôtes Hébergement
Hôtel Hébergement Classement d’hôtel(nombre d’étoile)
Moyens transport Voyage Modèle, Réservation
Moto Moyens transport
Train Moyens transport
Bateau Moyens transport
Traversier Moyens transport
Avion Moyens transport
Automobile Moyens transport
Destination Voyage Pays, transport local, intérêt, ville
Distance Destination Voyage Distance km
Continent Voyage Nom continent
Équipement chambre Voyage Tarif, Inetrnet, Nombre lit, télé
Table 6.2 – Dictionnaire des concepts de l’ontologie

112
DOMAINE DE VOYAGE
Relation Description Concepts sources Concepts cibles Cardinalités

Trajet de Relie le Trajet avec le client trajet client 0..* -
Info de Relie info de trajet à trajet Info trajet Trajet 0..1 0..*
Arrivée de Relie destination à info trajet et trajet destination Info trajet, Trajet 0..1 0..1
Départ de Relie destination à info trajet et trajet destination Info trajet, Trajet 0..1 0..1
Hébergement de Relie Hébergement à Info trajet et à destination Hébergement Info Trajet, destination 0..1 1..N
De Relie Destination et la distance destination destination Distance destination 0..1 0..1
à Relie Destination et la distance destination destination Distance destination 0..1 0..1
Moyens transport de Relie les moyens de transport aux informations du trajet Moyens transport Info trajet 0..1 0..1
Équipement de Relie équipement de la chambre à l’hébergement Équipement chambre Hébergement 0..1 0..1
Continent de Relie continent à la destination Continent Destination 0..1 0..1
Type d’avion de Relie Type de l’avion au moyens de transport Avion Moyens transport 0..1 0..1
Table 6.3 – Table des relations binaires de l’ontologie

2. CONCEPTION DE L’ONTOLOGIE DE VOYAGE

DOMAINE DE VOYAGE
Table des attributs des concepts de l’ontologie

Les attributs sont des propriétés qui prennent leurs valeurs dans les types prédéfinis
(String, Integer, Boolean, Date. . . ). Pour chaque attribut nous spécifions : son nom,
description, les concepts qu’il contient, son type et l’intervalle de ses valeurs pos-
sibles, sa cardinalité et sa valeur par défaut.
Les principaux attributs des concepts de notre ontologie sont présentés dans le ta-
bleau 6.4 de la page 114.

Attributs Description Concepts Type Card.
114
NomClient le nom du client Client chaine de caractères 0..1
DateDépart la date du départ du client Trajet chaine de caractères 0..1
DateArrivée la date d’arrivée du client Trajet chaine de caractères 0..1
ArrivéeAéroport nom de l’aéroport d’arrivée InfoVoyage chaine de caractères 0..1
DépartAéroport nom de l’aéroport de départ InfoVoyage chaine de caractères 0..1
TempsArrivée temps d’arrivée InfoVoyage chaine de caractères 0..1
TempsDépart temps de départ InfoVoyage chaine de caractères 0..1
DOMAINE DE VOYAGE
PrixClasseEco Prix de la classe économique Voyage Avion double 0..1

PrixClasseBusiness Prix de la classe Affaire Voyage Avion double 0..1
URL Redirection d’URL et compte d’hébergement Hébergement chaine de caractères 0..1
DisponibilitéChambre disponibilté de chambre pour hébergement Hébergement entier 0..1
Chien si l’accompagnement de chien est permis Hébergement Booléen 0..1
Description Description de l’endroit d’hébergement Hébergement chaine de caractères 0..1
DistancePlage Distance entre l’hôtel et la plage Hébergement Double 0..1
NomHéberegement nom de l’endroit où le client sera hébergé Hébergement chaine de caractères 0..1
NumTéléphone Numéro de téléphone de l’hébergement Hébergement chaine de caractères 0..1
NumChambre Le numéro de la chambre réservée Hébergement entier 0..1
Adresse L’adresse de l’hébergement Hébergement chaine de caractères 0..1
ClassementHotel Nombre d’étoile de l’hôtel Hôtel entier -
Modèle Le modèle de transport MoyenTransport chaine de caractères 0..1
Réservation Réservation du moyen de transport MoyenTransport chaine de caractères 0..1
Pays Nom du pays Destination chaine de caractères 0..1
Ville Nom de la ville Destination chaine de caractères 0..1
TransportLocal Réservation du transport local Destination chaine de caractères 0..*
Intérêts Les points d’intérêt du client Destination chaine de caractères 0..*
Distance La distance de la destination Destination double 1..1
Tarif Le tarif de la chambre Chambre double 0..1
2. CONCEPTION DE L’ONTOLOGIE DE VOYAGE

Internet Disponibilté de Internet Chambre Booléen 0..1
NbreLits Nombre de lits dans la chambre Chambre entier 0..1
DisponibilitéTélé Disponibilité de télévision dans la chambre Chambre Booléen 0..1
Table 6.4 – Table des attributs des concepts de l’ontologie

DOMAINE DE VOYAGE
2.3 Formalisation
Dans cette étape, nous utilisons le formalisme des logiques de description pour
formaliser le modèle conceptuel que nous avons obtenu dans l’étape de conceptuali-
sation. Cela revient à réaliser les étapes suivantes :
– Construction de la table (TBOX) :
– Définition des concepts de l’ontologie ;
– Définition des rôles de l’ontologie ;
– Construction de la table (ABOX)
Table de définition des concepts de l’ontologie (TBOX)

Dans cette étape nous définissions les concepts relatifs à notre domaine, en uti-
lisant les constructeurs fournis par les logiques de descriptions pour donner des des-
criptions structurées aux concepts. Nous spécifions ainsi les relations de subsomption
qui existent entre les différents concepts (voir table 6.5 de la page 116.
Table de définition des rôles de l’ontologie (TBOX)

Dans cette étape nous définissions les rôles, et ce en donnant les couples des
concepts sources et cibles de chacune, et en spécifiant son rôle inverse s’il existe
(voir table 6.6 de la page 116).
3 Implémentation de l’ontologie de voyage sous

Protégé
Plusieurs outils peuvent être utilisés pour l’implémentation de notre ontologie.
Notre objectif n’est pas de faire une comparaison entre ces différents outils, ni de
choisir le meilleur. Mais, tout simplement, d’implémenter cette ontologie du domaine
de voyage afin de pouvoir l’exploiter pour la recherche des services Web adéquats.
Vues la simplicité et la gratuité de Protégé, nous l’avons adopté pour la réalisation
de notre projet.
3.1 Présentation de l’éditeur Protégé

C’est un éditeur d’ontologies et framework de gestion des connaissances, développé
en open-source au sein de l’université de médecine de Stanford. Il dispose d’une in-
terface permettant l’édition, la visualisation, le contrôle (vérification des contraintes)
d’ontologies, issu du modèle des frames et contenant des classes (concepts), des slots
(propriétés) et des facettes (valeurs des propriétés et contraintes), ainsi que des ins-
tances des classes et des propriétés.
Les applications développées avec Protégé sont employées dans la résolution des
problèmes et la prise de décision dans un domaine particulier. Protégé est aussi
une plate-forme extensible, grâce au système de plugins, qui permet de gérer des
contenus multimédias, interroger, évaluer et fusionner des ontologies, etc. L’outil
Protégé possède une interface utilisateur graphique (GUI) lui permettant de ma-
nipuler aisément tous les éléments d’une ontologie : classe, méta-classe, propriété,
3. IMPLÉMENTATION DE L’ONTOLOGIE DE VOYAGE SOUS PROTÉGÉ 115
DOMAINE DE VOYAGE
Concept Relation de subsomption

Voyage Voyage ⊂ thing
Client Client ⊂ Voyage
Trajet Trajet ⊂ Voyage
Info Voyage Info Voyage ⊂ Voyage
Voyage Avion Type ⊂ Info Voyage
Voyage Train Classe ⊂ Info Voyage
Hébergement Hébergement ⊂ Voyage
Chambre d’hôtes Chambre d’hôtes ⊂ Hébergement
Hôtel Hôtel ⊂ Hébergement
Moyens transport Moyens transport ⊂ Voyage
Moto Moto ⊂ Moyens transport
Train Train ⊂ Moyens transport
Bateau Bateau ⊂ Moyens transport
Traversier Traversier ⊂ Moyens transport
Avion Avion ⊂ Moyens transport
Automobile Automobile ⊂ Moyens transport
Destination Destination ⊂ Voyage
Distance destination Distance destination ⊂ Voyage
Continent Continent ⊂ Voyage
Équipement chambre Équipement chambre ⊂ Voyage
Table 6.5 – Table de définition des concepts de l’ontologie (TBOX)
Rôle Couple (domaine,co-domaine) Rôle inverse

Trajet de Trajet, Client -
Info de (info-trajet, trajet) -
Arrivée de (Destination, info-trajet) Départ de
Départ de (Destination, info-trajet) Arrivée de
Hébergement de (Hébergement, Destination) -
De (Hébergement, info-trajet) à
à (Destination, trajet) De
Moyens transport de (Moyens transport, info-trajet -
Équipement de (Équipement , Hébergement)) -
Continent de (continent ,Destination) -
Type d’avion de (Avion, Voyage Avion) -
Table 6.6 – Table de définition des rôles de l’ontologie (TBOX)
116 3. IMPLÉMENTATION DE L’ONTOLOGIE DE VOYAGE SOUS PROTÉGÉ

DOMAINE DE VOYAGE
instance, etc.
Protégé peut être utilisé dans n’importe quel domaine où les concepts peuvent
être modélisés en une hiérarchie des classes. Il permet, également, de créer et d’im-
porter des ontologies écrites dans les différents langages d’ontologies tel que : RDF-
Schéma, OWL, DAML, OIL, et autres. Cela est rendu possible grâce à l’utilisation
de plugins disponibles en téléchargement pour la plupart de ces langages.
3.2 Implémentation
Pour implémenter notre ontologie, nous avons commencer par la définition de
notre hiérarchie des classes dont un aperçu graphique d’une partie de cette hiérarchie
est présenté dans la figure 6.3 de la page 117.
Ensuite, nous sommes passer à la création des propriétés des classes (datatype-
Property) afin de définir, pour chaque classe, l’ensemble de ses caractéristiques avant
de passer à la phase de création des restrictions et celle de définition des attributs.
Figure 6.3 – Aperçu de la hiérarchie des classes de l’ontologie de voyage
4 Conclusion
Notre principal objectif, dans ce chapitre, était de concevoir et d’implémenter
une ontologie du domaine de voyage afin de pouvoir l’exploiter, dans le cadre de la
recherche des services Web. Cette ontologie sera utilisée par l’AgentQueryAnalyzer,
décrit dans le chapitre précédent afin d’analyser la requête du client.
4. CONCLUSION 117
DOMAINE DE VOYAGE
Les détails concernant cette phase d’analyse de requête ainsi que celle de la re-
cherche des services Web seront présentés dans le chapitre suivant dédié à l’implémentation
de quelques projets servant pour la validation du modèle proposé.
118 4. CONCLUSION
Chapitre 7
Implémentation du modèle et
validation
1 Introduction
Ce chapitre est consacré à la présentation des différents outils logiciels utilisés
dans la phase d’implémentation de toutes les applications développées dans le cadre
de notre projet ; et ce avant de passer à la description de chaque application, liée au
modèle que nous avons présenté dans le cinquième chapitre, de façon détaillée.
Ces différentes applications ont été développées dans le but de valider le modèle
proposé via un environnement constitué de plusieurs plateformes, telles que : des
plateformes de simulation et de conception de SMA comme NetLogo et Jade, la pla-
teforme J2EE (Java 2 Entreprise Edition), le serveur web Apache Tomcat et AXIS
pour les services Web et MySQL pour les modules des données.
Cet environnement fera l’objet de la deuxième section de ce chapitre, tandis que

la présentation des différentes applications implémentées dans le cadre de validation
de notre modèle sera détaillée dans la troisième section.
2 Environnement de développement
L’ensemble des plateformes et outils que nous utilisé pour l’implémentation de
nos applications sont définis dans les sous-sections suivantes :
2.1 La plateforme Jade

Définition
JADE pour (Java Agent DEvelopment framework est un framework distribué

par TILab en Open Source avec une licence LGPL. C’est une plateforme qui a été
développée par CSELT (Groupe de recherche de Gruppo Telecom, Italie) implémenté
en langage java. Elle simplifie la mise en œuvre des systèmes multi-agents au moyen
d’un middleware qui respecte les spécifications FIPA et par une série d’outils qui
119
CHAPITRE 7. IMPLÉMENTATION DU MODÈLE ET VALIDATION
prend en charge le débogage et la phase de déploiement.
La plateforme JADE peut être répartie entre tous les types de machines (elle n’a
même pas besoin de partager le même système d’exploitation), la configuration peut
être contrôlée via une interface graphique à distance. Elle peut être modifiée, même
au temps d’exécution par le déplacement des agents d’une machine à une autre, tant
que de besoin. La seule exigence est le système Java Runtime version 1.4 ou plus 1 .
Le but de JADE est de simplifier le développement des systèmes multi-agents en

conformité avec la norme FIPA pour réaliser des systèmes multi-agents interopérables.
Pour atteindre ce but, JADE offre la liste suivante de caractéristiques au program-
meur d’agents :
– La plateforme multi-agents compatible FIPA, qui inclut le Système de Gestion

d’Agents (AMS), le Facilitateur d’Annuaire (DF), et le Canal de Communica-
tion entre Agents (ACC) – (7.1). Ces trois agents sont automatiquement créés
et activés quand la plateforme est activée.
– La plateforme d’agents peut être distribuée sur plusieurs hôtes, à condition

qu’il n’y ait pas de pare-feu entre ces hôtes. Une seule application Java, et donc
une seule Machine Virtuelle Java, est exécutée sur chaque hôte. Les agents sont
implémentés comme des threads d’exécution Java et les événements Java sont
utilisés pour la communication efficace et légère entre agents sur un même
hôte. Un agent peut exécuter des tâches parallèles et JADE planifie ces tâches
d’une manière plus efficace (et même plus simple pour le programmeur) que la
planification faite par la Machine Virtuelle Java pour les threads d’exécution.
– Un certain nombre de DF (Facilitateurs d’Annuaire) compatibles FIPA qui

peuvent être activés quand on lance la plateforme pour exécuter les applica-
tions multi-domaines, où la notion de domaine est la notion logique décrite
par le document FIPA97 2 dans sa Partie 1.
– Une interface de programmation pour simplifier l’enregistrement de services

d’agents avec un ou plusieurs domaines de type DF.
– Le mécanisme de transport et l’interface pour l’envoi et la réception des mes-

sages.
– Le protocole IIOP compatible avec le document FIPA97 pour connecter les

différentes plateformes multi-agents.
– Le transport léger de messages ACL sur la même plateforme d’agents. Dans

le but de simplifier la transmission, les messages internes (à la même plate-
forme) sont transférés codés comme des objets Java et non comme des chaı̂nes
de caractères. Quand l’expéditeur ou le récepteur n’appartient pas à la même
1. http ://jade.tilab.com/
2. Les spécifications FIPA 97 étaient les premières spécifications à publier par FIPA.
120 2. ENVIRONNEMENT DE DÉVELOPPEMENT
plateforme, le message est automatiquement converti au format de chaı̂ne de

caractères spécifiés par la FIPA. De cette façon, la conversion est cachée au
programmeur d’agents, qui a seulement besoin de traiter la classe d’objets
Java.
– Une bibliothèque de protocoles d’interaction compatibles FIPA.
– L’enregistrement automatique d’agents dans le Système de Gestion d’Agents

(AMS).
– Un service d’attribution de noms compatible FIPA, quand on lance la plate-

forme, un agent obtient un identificateur unique (Globally Unique Identifier -
GUID).
– Une interface graphique utilisateur pour gérer plusieurs agents et plates-formes

multi-agents en partant d’un agent unique. L’activité de chaque plateforme
peut être supervisée et enregistrée.
La plateforme d’agent de JADE inclut tous les composants nécessaires pour

contrôler un SMA. Ces composants sont l’ACC, l’AMS et le DF. Toute la commu-
nication entre agents est exécutée par messages FIPA ACL dont la structure est
présentée dans la figure 7.1.
Figure 7.1 – Structure d’un message FIPA ACL.
La communication entre agents dans JADE

Pour communiquer, les agents doivent pouvoir recevoir et envoyer des messages
au travers d’un réseau de communication. Cette communication s’appelle une com-
munication adressée, le destinataire est un ou plusieurs agents certains paramètres
spécifiant le message portent l’identifiant du ou des destinataires, ce modèle de
communication est marqué par les techniques classiques de la communication en in-
formatique. Dans cette situation, l’agent émetteur a un rôle actif, tandis que l’agent
récepteur est passif dans sa réception. Le message est déplacé jusqu’à son destina-
taire, c’est le cas des massages basés sur FIPA-ACL.
2. ENVIRONNEMENT DE DÉVELOPPEMENT 121
Les types des messages
Le type de message est appelé ’acte de langage’. Cet acte décrit selon la théorie
de John Searle dans [Sea69] comme suit : Il existe plusieurs catégories de tels actes :
– Assertifs : servent à donner une information sur le monde en affirmant

quelque chose (information, témoignage...),
– Directifs : sont utilisés pour donner des directives au destinataire (demande,

question, ordre ...)
– Permissifs : engagent les locuteurs à accomplir certains actes (promesse,

vœux, menace, ...)
– Déclaratifs : accomplissent un acte par le fait même de prononcer l’énoncé

(définition, condamnation, ...)
– Interrogatifs : pour demander une information.
– Expressifs : servent à donner au destinataire des indications concernant l’état

mental du locuteur (excuse, félicitation, remerciement)
En pratique un message est identifié par son performatif, qui correspond à l’une
des catégories de Searle [Sea69]. Par exemple si le performatif d’un message est
’Inform’, ce message sera un acte de langage assertif. De même, le performatif ’Offer’
correspondra à un acte promissif, etc. Mais ceci reste inconvenante pour le reste de
l’ensemble des messages qui peuvent être des objets complexes ou des plans ou
des stratégies échangées. Dans JADE le langage de communication est FIPA-ACL
(Agent Communication Langage).
Message ACL de FIPA
Un message FIPA-ACL contient un ensemble d’un ou plusieurs éléments du

message. Précisément quels éléments sont nécessaires pour l’agent de communication
efficace variera selon la situation, le seul élément qui est obligatoire dans toutes les
messages ACL est le performatif, mais on s’attend à ce que les messages les plus ACL
contiendront également l’expéditeur et éléments de contenu, en général les messages
sont composés de :
– L’émetteur du message : un champ rempli automatiquement lors de l’envoi
d’un message.
– L’ensemble des récepteurs du message : un message peut être envoyé à plusieurs
agents simultanément.
– L’acte de communication : qui représente le but de l’envoi du message en cours
(informer l’agent récepteur, appel d’offre, réponse à une requête,...)
– Le contenu du message.
– Un ensemble de champs facultatifs, comme la langue utilisée, l’ontologie, le
timeOut, l’adresse de réponse ...
Élément Catégorie des éléments

Performatif Type de l’acte de communication
Sender Expéditeur de message
Receiver Destinataire de message
Reply-to Participant de la communication
Content Contenu de message
Langage Langue dans laquelle le paramètre de contenu est ex-
primé
Encoding Codage spécifique du contenu du message
Ontology Référence à une ontologie de donner un sens aux sym-
boles dans le contenu du message
Protocol Protocole d’interaction utilisé pour structurer une
conversation
Conversation-id L’identité unique d’un fil de conversation
Reply-with Une expression à être utilisé par un agent de répondre
à identifier le message
In-reply-to Référence à une action antérieure à laquelle le message
est une réponse
Reply-by heure / date en indiquant si une réponse doit être reçue
Table 7.1 – Structure d’un message ACL
La classe ACLMessage représente les messages qui peuvent être échangés par les
agents, la communication de message se fait en mode asynchrone.
Lorsqu’un agent souhaite envoyer un message, il doit créer un nouvel objet ACL-
Message, compléter ses champs avec des valeurs appropriées et enfin appeler la
méthode send().
Lorsqu’un agent souhaite recevoir un message, il doit employer la méthode re-

ceive() ou la méthode blockingReceive().
Un message ACL dispose obligatoirement des champs du tableau 7.1.
Tous les attributs de la classe ACLMessage peuvent être obtenus et modifiés par
les méthodes set/get(). Le contenu de message peut être aussi bien du texte que des
objets car la sérialisation java est supportée.
Comportements des agents dans la plateforme JADE

Dans une plateforme multi-agents, un agent est confronté à des situations différentes
donc il doit être capable de gérer plusieurs taches de manière concurrente en réponse
aux différents événements extérieurs. Afin de rendre efficace cette gestion, chaque
agent de JADE est composé d’un seul thread et chaque comportement qui le compose
est en fait un objet de type Behaviour. L’agent peut exécuter plusieurs Behaviours
simultanément en choisissant un bon mécanisme de passation d’un Behaviour à un
autre (c’est à la charge du programmeur et non pas à la charge de JADE). Des
2. ENVIRONNEMENT DE DÉVELOPPEMENT 123
agents multi-threads peuvent être créés mais il n’existe pour l’heure actuelle aucun
support fournis par la plateforme (excepté la synchronisation de la file des messages
ACL).
2.2 La plateforme J2EE

Définition
J2EE (Java 2 Entreprise Edition) est une norme proposée par la société Sun,
visant développer des applications d’entreprises basées sur des composants. On parle
généralement de ”plate-forme J2EE” pour désigner l’ensemble constitué des services
(API) offerts et de l’infrastructure d’exécution. J2EE comprend notamment :
– Les spécifications du serveur d’application, c’est-à-dire de l’environnement
d’exécution : J2EE définit finement les rôles et les interfaces pour les applica-
tions ainsi que l’environnement dans lequel elles seront exécutées.
– Des services, au travers d’API, c’est-à-dire un ensemble d’API qui peuvent
être utilisées au cours du développement.
L’architecture de la plateforme J2EE

L’architecture J2EE spécifie ce que se doit d’être un serveur d’applications J2EE.
Un serveur d’applications est un ensemble de services et d’API permettant l’hébergement
d’applications d’entreprise. Le schéma de la figure 7.2 reprend les principaux com-
posants de cette architecture où deux catégories de composants peuvent être dis-
tinguées :
1. Couche Web : Il s’agit de la partie présentation (interface de l’utilisateur
et les traitements). Le client reçoit seulement du texte HTML, mais il s’agit
seulement de la partie visible de l’application. Derrière la scène, différentes
technologies permettent à votre code d’être plus performant, plus robuste, et
plus facile à mettre à maintenir :
– JSP : Les JSP (Java Server Page) sont les pages servant à générer l’ensemble
du code HTML de l’interface utilisateur. On y intègre aussi bien du code
HTML que des scriplet Java (code java) ou encore des balises personnalisées
(tag-lib). Cette technologie est donc dédiée à la génération de HTML et non
au traitement de la requête de l’utilisateur. On l’appelle généralement ”Vue”.
– Servlet : Une Servlet est une classe Java qui permet de traiter une requête
venant d’un client. Cette technologie doit s’occuper de traiter les données
envoyées par l’utilisateur et choisir la Vue à retourner à celui-ci.
2. Couche Métier - EJB (Entreprise JavaBean) : Il s’agit de composants
spécifiques chargés des traitements des données propres à un secteur d’activité
(on parle de logique métier ou de logique applicative) et de l’interfaçage avec
les bases de données. On parle de la partie ”Modèle”.
2.3 Le serveur web ”Apache Tomcat”

Apache Tomcat est un serveur web qui permet de générer des pages HTML grâce
a des servlets J2EE (programmes java exécutés par le serveur web) ou les pages JSP
Figure 7.2 – L’architecture de la plateforme J2EE [You14].
(Java Server Pages), pages mélangeant code java et code HTML. Nous avons donc
choisi un serveur Apache Tomcat qui représente, a notre avis, une solution robuste et
ouverte. Ce serveur est classique, et il prend en charge les requêtes des utilisateurs.
Tomcat est lui même un serveur web (écrit en java) qui coopère avec le serveur
http apache capable de charger des objets java (les servlets) qui vont prendre en
charge certaines requêtes http et engendrer dynamiquement un document HTML
Constituant la réponse. Il représente aussi une plateforme pour le développement et
le déploiement d’applications Web et des services Web. Il inclut des outils pour la
configuration et la gestion, mais peut également être configuré en éditant des fichiers
de configuration XML. Tomcat peut donc s’exécuter via la JVM (Java Virtual Ma-
chine) sur n’importe quel système d’exploitation. La version que nous avons utilisé
pour implémenter notre application est Apache Tomcat 7.0.34.0.
2.4 AXIS
AXIS est l’acronyme d’Apache eXtensible Interaction System. C’est une nou-
velle implémentation de la spécification SOAP (Simple Object Access Protocol)
développé par la fondation Apache (The Apache Software Foundation), qui succède
à Apache SOAP. Les caractéristiques qui le mettent au dessus de son prédécesseur
est le fait qu’il est plus performant, plus modulaire et plus extensible. AXIS est à
la fois un environnement d’hébergement de services web, et un toolkit complet de
développement pour la création de services et l’accès à des services tiers.
3 Conception et mise œuvre des projets de vali-

dation du modèle
Étant donné que les agents et les services Web constituent le cœur de notre tra-
vail, disposer de ces derniers a été le premier besoin pour notre codage. Bien que
3. CONCEPTION ET MISE ŒUVRE DES PROJETS DE VALIDATION DU 125
MODÈLE
dans notre contexte nous n’avons besoin que des descriptions WSDL des services
Web, nous avons préféré développer ces services Web dans le but de découvrir da-
vantage l’univers SMA et celui des services Web.
Comme les services Web sont gérés par des agents alors nous avons opté pour
une conception globale en combinant les deux environnements comme présenté dans
le diagramme de séquence de la figure 7.3.
Figure 7.3 – Diagramme de séquence de l’approche proposée.
Il est à noter que nous avons développé plusieurs projets, dans le but de valider
notre modèle. Mais nous nous sommes limitées à la présentation de deux projets
uniquement et ce afin de ne pas trop charger notre manuscrit par des exemples
variés et de domaines différents d’un côté et pour simplifier la compréhension du
principe de fonctionnement de notre modèle et ce en choisissant les deux projets les
plus représentant de notre modèle. En fait, nous avons divisé notre travail en deux
parties. La première consiste à implémenter :
– Une interface permettant la saisie de la requête du client en lui permettant de
de choisir entre deux modes de requête ; à savoir : le mode guidé et le mode
brut
– Un AgentQueryAnalyser permettant d’analyser la requête du client, en se
servant de l’ontologie du domaine implémenté dans la chapitre précédent
– Un AgentDiscovery permettant de rechercher les services Web répondants à la
requête du client
Et la deuxième consiste à implémenter :

– Un AgentPlan permettant de planifier la composition des services Web liés à
la requête du client
– Des Agents de type AgentService permettant d’invoquer les services Web fai-
sant partie du processus de composition.
L’exemple sur lequel nous nous sommes basés pour valider notre travail est celui
de l’organisation d’un voyage. Un utilisateur qui souhaite faire un voyage à un en-
126 3. CONCEPTION ET MISE ŒUVRE DES PROJETS DE VALIDATION DU
MODÈLE
droit précis a surement besoin d’un ensemble de services pour son voyage tels que
le service de transport (avion), l’hôtellerie (réservation d’hôtel) et la restauration, à
des contraintes spécifiques telles que la date, la durée de son séjour, le prix à ne pas
dépasser, etc.
Une présentation détaillée de chacune des deux parties fera l’objet des sections
suivantes, en se basant sur l’exemple su-cité.
3.1 Premier projet : ”L’analyse de la requête Client pour la

recherche et la sélection des services Web”
L’objectif principal de ce projet était de développer un système multi-agents
constitué des deux premiers agents de notre modèle et ce dans le but de valider le
modèle que nous avons proposé en se concentrant sur l’assurance d’une meilleure
qualité de services Web retournés par notre système. Dans ce cadre, nous avons
essayé d’implémenter notre AgentQueryAnalyzer chargé de l’analyse de la requête
du client et notre AgentDiscovry chargé de la recherche des services Web demandés.
La figure 7.4 représente l’interface graphique de la plateforme Jade après la

création de nos agents ; AgentQueryAnalyzer et AgentDiscovry.
Figure 7.4 – L’AgentQueryAnalyzer et l’AgentDiscovry dans l’interface graphique

de Jade
Implémentation de l’AgentQueryAnalyzer
Tout en respectant l’architecture proposée dans le chapitre 5, figure 5.2 de la

page 97, nous avons essayé d’implémenter notre AgentQueryAnalyzer. Cet agent est
créé automatiquement dès le lancement du traitement de notre requête.
MODÈLE
Principe de traitement d’une requête client

L’AgentQueryAnalyzer peut choisir entre deux types de requête pour faire sa
recherche (voir figure 7.5) : une requête guidée, où il n’a qu’à remplir les champs
sur son interface avec les informations recherchées sinon, il choisit d’introduire une
requête brute.
Figure 7.5 – Interface de traitement d’une requête client
1. Cas d’une requête guidée : Le client doit préciser les contraintes les plus
significatives pour son choix. A savoir, par exemple, la ville ou le pays de son
départ et de son arrivée, la date de départ et le prix comme indiqué dans la
figure 7.6.
Figure 7.6 – Traitement d’une requête guidée
Dans ce cas, l’AgentQueryAnalyzer récupère les mots clés pour les envoyer
directement à l’AgentDiscovry chargé d’appliquer l’algorithme de Matching
entre l’offre et la demande.
2. Cas d’une requête brute : Le client introduit sa requête en langage natu-

rel, comme indiqué dans la figure 7.7 pour qu’elle soit traitée par l’AgentQue-
ryAnalyzer afin d’appliquer l’algorithme d’extraction des mots clés, pour les
transmettre à l’AgentDiscovry. Le traitement d’une requête brute consiste à
décomposer cette dernière en un ensemble de mots et de les classer dans un
MODÈLE
tableau avec une prise en considération de la pertinence de ces derniers.

L’extraction des mots clés est fondé sur l’opération de comparaison des mots
extraits avec les différents concepts présents dans notre ontologie du domaine
de voyage implémentée dans le chapitre 6.
Figure 7.7 – Traitement d’une requête brute
Implémentation de l’AgentDiscovry
L’AgentDiscovry est le deuxième agent que nous avons implémenté suivant l’ar-
chitecture présentée dans la figure 5.4 de la page 99 du chapitre 5. Son rôle principal
est de rechercher tous les services Web liés à l’ensemble des mots clés récupérés dans
notre application, de façon directe, de l’AgentQueryAnalyzer après avoir analysé la
requête du client et l’avoir transformé sous forme de mots clés.
Malgré que nous remarquons, dans notre architecture générale présentée dans
la figure 5.1 de la page 95 du chapitre 5, qu’il n’y a pas de contact direct entre
l’AgentQueryAnalyzer et l’agentDiscovry, nous avons exclu le rôle de l’AgentPlan,
de façon provisoire, pour nous focaliser, dans cette première partie, sur l’analyse de
la requête client et la recherche des services Web liés à cette dernière.
Principe de recherche d’un service Web

Après la phase d’analyse de la requête client assurée par l’AgentQueryAnalyzer,
l’AgentDiscovry applique l’algorithme de Matching et affiche les résultats cor-
respondant aux services trouvés, répondant à la requête client (voir figure 7.8).
Les résultats correspondant aux différents types des entrées possibles sont présentés
dans la table 7.2.
3.2 Deuxième projet : ”La planification de la composition

des services Web”
L’objectif de ce projet était de rechercher les meilleures solutions locales offertes
sur le Web et de choisir, ensuite, la solution optimale pouvant être obtenue par
MODÈLE
Figure 7.8 – Résultat d’exécution de la requête client
Départ Arrivée Prix Date Résultat

Pays Pays Numérique dd/mm/yyyy Vols pour villes correspondantes
à chaque pays
Ville Ville Numérique dd/mm/yyyy Vols pour villes données
Pays Ville Numérique dd/mm/yyyy Vols ayant comme départ toutes
les villes de ce pays et l’arrivée
correspond à la ville donnée
Ville Pays Numérique dd/mm/yyyy Vols ayant comme départ la ville
donnée et l’arrivée correspond à
toutes les villes de ce pays
Chaine Pays/Ville Numérique dd/mm/yyyy Erreur
non
reconnue
Pays/Ville Pays/Ville Numérique dd/mm/yyyy < Erreur
date actuelle
Pays/Ville Pays/Ville Chaine de dd/mm/yyyy Erreur
caractère
Table 7.2 – Les résultats correspondant aux différents types d’entrées possibles
composition des plans locaux.

Cette composition des plans locaux qui sera assurée par notre AgentPlan qui cherche,
évidemment, à exécuter une meilleure stratégie lui permettant de satisfaire le client.
Le service fourni au client est constitué d’un ensemble de services Web (Hôtel,
Restauration, Vol) à partir desquels plusieurs informations peuvent être extraites
telles que :
– Les noms des hôtels, leurs classification (le nombre d’étoiles), l’endroit où ils
se trouvent et le prix des chambres.
– Les noms des restaurant et l’endroit où ils se trouvent (ville) ainsi que leurs le
prix.
– Le vol et l’endroit à partir duquel ils vont décoller, la destination, la date de
départ et la date d’arrivée.
Relativement à notre architecture, à chaque service correspond un AgentService

chargé de l’invocation de l’un des services web demandés par l’AgentPlan pour faire
leur planification et découverts par l’AgentDiscovry.
MODÈLE
Dans cette phase et pour des raisons de simplification, nous avons exclu le rôle
de l’Agent Discovry pour réduire notre système à un AgentPlan chargé de la plani-
fication de la composition des services Web et un ensemble d’agents de type Agent-
Service assurant chacun un service particulier.
Implémentation de l’AgentPlan
L’AgentPlan est responsable de la planification de la composition des services
Web(hôtel. restaurant, vol). Il reçoit les critères fournis par l’AgentQueryAnalyzer
et communique avec les agents de type AgentService assurant chacun la recherche
et l’invocation des services correspondants (hôtel, restaurant, vol) tout en essayant
de fournir les meilleures plans locaux offerts à l’AgentPlan.
Dès que les agents de type AgentService retournent leurs résultats à l’AgentPlan, ce
dernier commence à faire la planification.
La planification à pour but d’étudier tous les cas possibles et d’analyser tous les
résultats afin d’atteindre le plan optimal. Le diagramme de la figure 7.9 indique le
processus de planification exécuté par l’AgentPlan.
Figure 7.9 – Processus de planification des services Web
Implémentation de l’AgentSevice
Plusieurs agents de type AgentService sont créés automatiquement, dans notre
application, et ce juste après la récupération des informations concernant ces services
et liées à la requête client.
Le rôle de chaque AgentService est de choisir parmi les services offerts sur le Web,
celui répondant aux exigences du client et offrant, ainsi, le meilleur plan local possible
MODÈLE
pour le remettre à l’AgentPlan. Nous avons implémenté, dans ce cadre, les trois
agents suivants :
1. L’AgentServiceHôtel : chargé de fournir la meilleure offre d’hôtel, relative-
ment à notre requête,
2. L’AgentServiceAvion : assurant l’offre du meilleur vol répondant aux exi-

gences de notre client, et
3. L’AgentServiceRestaurant : permettant de fournir les informations concer-

nant le meilleur service de restauration, dans le cas où notre requête contient
quelques indices relatifs au service de la restauration.
4 Conclusion
Nous avons présenté dans ce chapitre les principaux outils logiciels utilisés pour
l’implémentation de notre modèle et nous avons essayé par la suite, de présenter
deux projets que nous avons essayé d’implémenter, dans le but de valider notre
modèle.
Malgré que nous nous sommes pas arriver à l’implémentation du modèle proposé
intégralement, nous tenons, quand même à estimer les résultats que nous avons
obtenus de très satisfaisants et nous confirmons que le passage à l’échelle est une
question de temps, vue la complexité du projet liée à la diversité des domaines
qu’il touche (agents, services Web, services Web sémantiques, ontologies, compo-
sition, planification et autres) d’un côté et son importance côté fonctionnel suite
au nombre de modules à interagir entre eux de diverses façons (interaction entre
agents, communication par échange de messages, extraction de mots clés, recherche
de services Web, invocation de services, ”Matchmaking”, interrogation d’ontologie,
raisonnement logique, exploration d’une base de connaissances, inférence et autres)
d’un autre côté.
132 4. CONCLUSION
Conclusion et perspectives
Proposer un modèle multi-agents pour la composition de services Web, fondé

sur des techniques de planification, est une problématique qui s’articule autour de
plusieurs axes de recherche :
– les modèles à base d’agents,
– le problème de la composition des services Web,
– les techniques de planification et leurs relations avec les services Web et les
modèles à base d’agents.
Percer dans chacun des axes de recherche su-cités, nécessite surement un temps
important pour pouvoir maitriser chaque domaine. De notre côté, nous avons fait de
notre mieux pour essayer de synthétiser chaque concept lié à notre problématique,
dans le but d’apprendre à mieux l’utiliser pour pouvoir atteindre notre objectif.
Pour cela, nous avons consacré la première partie de notre thèse, constituée de
quatre chapitres, à la présentation d’un état de l’art sur ces différents concepts, d’où
nous avons sacrifié le premier chapitre à la présentation des agents et des systèmes
multi-agents (SMA), leurs problématiques, leurs domaines d’utilisation et l’expo-
sition de quelques plateformes de conception et d’implémentation d’agents et de
systèmes multi-agents.
Les services Web ont trouvé leur part dans notre manuscrit via le deuxième
chapitre, dans lequel nous les avons défini ainsi que leurs différents types, leurs ca-
ractéristiques, leur architecture, leurs technologies de base. Et ce avant d’entamer
les problématiques de : publication, recherche, sélection et invocation, liées toutes à
ces services Web. Une autre problématique liée, également, aux services Web et que
nous ne pouvons négliger, dans cette thèse, est celle de la qualité de service (QdS)
que nous avons synthétisé à la fin de ce chapitre.
Après les agents, les systèmes multi-agents et les services Web, un état de l’art sur
la planification a pris sa place, dans le troisième chapitre pour définir la planification
en intelligence artificielle avant de présenter les différents modèles de planification
tels que :
– la planification classique
– la planification graphique
– la planification hiérarchique, et
– la la planification distribuée
Les avantages de la planification ont fait l’objet de la dernière section de ce chapitre.
133
CONCLUSION ET PERSPECTIVES
Nous n’avons pu proposer notre modèle de composition de services Web qu’après

avoir présenté la problématique de composition des services Web dans le quatrième
et dernier chapitre de la première partie de cette thèse. Une synthèse bibliographique
de quelques travaux de recherche, se basant sur la composition des services Web,
nous a permis de raffiner nos idées pour les exhiber dans la deuxième partie de cette
thèse, consacrée à la présentation de notre contribution qui s’est étalée sur trois
nouveaux chapitres dont le premier était dédié à la la présentation de l’architecture
fonctionnelle détaillée du modèle à base d’agents que nous avons proposé.
Ce modèle est composé principalement de quatre types d’agents, à savoir :

1. l’AgentQueryAnalyzer,
2. l’AgetDiscovry,
3. l’AgentPlan, et
4. l’AgentService
où chaque type est chargé d’assurer un rôle précis dans le cadre de notre composition
de services Web.
Nous ne pensons pas qu’il est vraiment important de refaire la description de

ces différents rôles pour chaque type d’agent car il est toujours possible de revenir
au cinquième chapitre si nous cherchons des détails sur notre architecture proposée,
mais nous tenons à préciser que la spécificité du modèle proposé réside dans le fait
qu’il s’engage à assurer une bonne qualité de service par rapport aux modèles exis-
tants. Cette mesure de qualité de service est fondée sur les contraintes que le client
pourra imposer via sa requête.
L’originalité remarquable du modèle proposé est le fait qu’il permet au client de

définir ses propres contraintes de qualité de façon dynamique, lors de l’introduction
de sa requête. Cette dernière qui pourra être introduite de façon brute, c’est-à-dire.
en langue naturelle ou bien sous forme de mots clés selon le principe de recherche
sur lequel fonctionne les moteurs de recherche tels que Google, Yahoo, ou autres.
Cette stratégie de recherche adoptée par les moteurs de recherche, actuellement,

dans le cadre du Web sémantique s’est imposée dans notre modèle afin de donner à
notre agent analyseur de requête ”l’AgentQueryAnalyzer” une certaine qualification
pour prendre en considération l’aspect sémantique et ne pas se limiter au traitement
syntaxique lors de l’analyse de la requête du client, cherchant sur le Net un service
pouvant être composite. C’est la raison pour laquelle, nous avons jugé indispensable
de nous servir d’une ontologie de domaine.
Se servir d’une ontologie existante dans n’importe quel domaine est possible bien
sûr. Mais, Pourquoi ne pas penser à prendre une nouvelle aventure pour implémenter
notre propre ontologie ? C’est pour cette raison que nous avons essayé, à nouveau,
de nous servir d’une méthodologie assez connue dans le domaine du Web sémantique
qui est la méthodologie ”METHENTOLOGIE” et de l’éditeur ”Protégé” pour conce-
voir et implémenter une ontologie du domaine de voyage, qui a fait l’objet de notre
sixième chapitre.
134 CONCLUSION ET PERSPECTIVES

Il est évident que la valeur de notre travail ne peut être mesurée que si nous arri-
verons à valider notre modèle. Chose qui n’est pas vraiment facile, vue l’importance
du temps nécessaire pour la mise en œuvre du modèle proposé. Mais ce qui est cer-
tain, est que le passage à l’échelle n’est pour nous qu’une question de temps et que
malgré que nous n’avons pu concrétiser qu’une toute petite partie du modèle, qui a
fait l’objet du septième et dernier chapitre, cela, reste un défi qui pourra alimenter
nos futurs travaux de recherche.
Enfin, nous tenons à préciser que les différents agents du modèle proposé ont été
implémentés et qu’ils étaient testés avec des services Web que nous avons implémenté
nous même, faute de ne pas avoir assez de temps pour effectuer nos tests sur des
services Web réels. Malheureusement, les résultats obtenus, ne nous permettent pas
de les situer par rapport aux résultats existants, vu qu’il reste encore des modules
à développer afin d’assurer un passage à l’échelle.
Ce passage à l’échelle sera notre prochain objectif qui nous encouragera à tracer
de nouvelles perspectives telles que :
– l’intégration de nouveaux modules permettant à notre modèle de s’adapter
avec n’importe quel type de service Web,
– la recherche et la sélection de services Web existants dans le cadre de la com-
position,
– l’implémentation de la stratégie de planification décrite dans la section de la
définition formelle du processus de planification du cinquième chapitre,
– Implémentation d’un algorithme de planification assurant la composition au-
tomatique des services impliqués avec prise en considération du facteur QoS.
– passage d’une description à base de fichiers WSDL vers un modèle de descrip-
tion servant d’entrée pour notre modèle de composition.
CONCLUSION ET PERSPECTIVES 135

136 CONCLUSION ET PERSPECTIVES

Bibliographie
[ABRL09] Nicolas Arni-Bloch, Jolita Ralyté, and Michel Léonard. Service dri-
ven information systems evolution : Handling integrity constraints
consistency. In IFIP Working Conference on The Practice of Enter-
prise Modeling, pages 191–206. Springer, 2009.
[ACD+ 03] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, and J. Klein. Bu-
siness Process Execution Language for Web Services, 2003.
[ACKM04] Gustavo Alonso, Fabio Casati, Harumi Kuno, and Vijay Machiraju.
Web Services : Concepts, Architectures and Applications. 2197-9723.
Springer publishing, 2004.
[AHT+ 08] Zeina Azmeh, Marianne Huchard, Chouki Tibermacine, Christelle
Urtado, and Sylvain Vauttier. Wspab : A tool for automatic classi-
fication and selection of web services using formal concept analysis.
In ECOWS 2008 : 6th European Conference on Web Services, pages
31–40, Dublin, Ireland, 2008.
[AL07] P. Albers and O. Licchelli. Composition de services web personnalisés,
juillet 2007.
[AS04] S. Araban and L.S. Sterling. Measuring quality of service for contract
aware web services. In First Australian Workshop on Engineering
Service Oriented Systems, page 54–56, 2004.
[Bac14] Fayçal Bachtarzi. Une approche de composition des services Web
basée transformation de graphes. PhD thesis, Université Abdelhamid
Mehri Constantine 2, décembre 2014. Thèse de doctorat LMD.
[BB09] A. Belkheir and S. Bouyakoub. A hierarchical model for web ser-
vices composition. International Journal of Web Services Practices,
4(1) :44–50, 2009.
[BBB16] Karima Belmabrouk, Fatima Bendella, and Maroua Bouzid. Multi-
agent based model for web service composition. International Jour-
nal of Advanced Computer Science and Applications, IJACSA, 7(3),
march 2016.
[BBLB16] Nicolas Becu, Pierre Bommel, Christophe LePage, and Francois Bous-
quet. Cormas, une plateforme multi-agent pour concevoir collective-
ment des modèles et interagir avec les simulations. In Actes des 24ème
journées Journées Francophones sur les Systèmes Multi-Agents (JF-
SMA), Saint Martin du Vivier (Rouen), 2016. ISBN : 9782364935594.
[BBPL98] François Bousquet, Innocent Bakam, Hubert Proton, and Christophe
LePage. Cormas : Common-pool resources and multi-agent systems.
137
BIBLIOGRAPHIE
In International Conference on Industrial and Engineering Appli-

cations of Artificial Intelligence and Expert Systems (IEA-98-AIE),
pages 826–837, Castellon (Espagne), 1998. Lecture Notes in Artificial
Intelligence.
[BCG07] Fabio Bellifemine, Giovanni Caire, and Dominic Greenwood. Develo-
ping multi-agent systems with JADE. Michael Wooldridge, Liverpool
University, UK. John Wiley and Sons Ltd, 2007.
[BCRP17] Fabio Bellifemine, Giovanni Caire, Giovanni Rimassa, and Agostino
Poggi. Java agent development framework, 2017.
[Bek12] Amina Bekkouche. Composition des services web sémantiques À base
d’algorithmes génétiques. Mémoire de magister, Université Aboubekr
Belkaid Tlemcen, 2012.
[Bel09] Youssef Belaid. Cours : NFE107 Urbanisation et Architecture des
Systèmes d’Information, chapter Service Web - SOAP. Conservatoire
Nationale des Arts et Métiers, 2009.
[Bel11] Nabil Belaid. Modélisation de services et de workflows sémantiques
à base d’ontologies de services et d’indexations. Application à la
modélisation géologique. Thèse, Ecole Nationale Supérieure de
Mécanique et d’Aérotechnique, Laboratoire d’Informatique Scienti-
fique et Industrielle, novembre 2011.
[Ben09a] Riadh Benhalima. Conception, implantation et expérimentation
d’une architecture en bus pour l’auto-réparation des applications dis-
tribuées à base de services Web. Thèse, Université Paul Sabatier -
Toulouse III, 2009.
[Ben09b] Badr Benmammar. Intelligence artificielle et systèmes multi-agents,
2009.
[Ber09] Chafik Berdjouh. Une approche basée agent pour la découverte de ser-
vices web. Master’s thesis, Université Kasdi Merbah Ouargla, 2009.
[BF97] Avrim L. Blum and Merrick L. Furst. Fast planning through planning
graph analysis. Artificial Intelligence, page 281–300, 1997.
[BGG12] Mokrane Bouzeghoub, Daniela Grigori, and Ahmed Gater. A graph-
based approach for semantic process model discovery. In Graph Data
Management : Techniques and Applications, pages 438–462. 2012.
[BGOA04] Z. Baida, J. Gordijn, B. Omelayenko, and H. Akkermans. A shared
service terminology for online service provisioning. In In Proc. of the
Sixth International Conference on Electronic Commerce (ICEC04),
Delft, Netherlands, 2004.
[BH03] Allen Brown and Hugo Haas. Web services glossary, May 2003.
[BHRT03] Boualem Benatallah, Mohand Said Hacid, C. Rey, and Farouk Tou-
mani. Semantic reasoning for web services discovery. In WWW Work-
shop on E-Services and the Semantic Web, Budapest, Hungary, 2003.
[BKS99] F. Bacchus, F. Kabanza, and U. D. Sherbrooke. Using temporal logics
to express search control knowledge for planning. 1999.
138 BIBLIOGRAPHIE
BIBLIOGRAPHIE
[BL03] Gilbert Babin and Michel Leblanc. Les web services et leur impact
sur le commerce b2b. Technical report, CIRANO Burgundy Reports,
2003.
[Bon90] Alan H. Bond. A computational model for organizations of coopera-
ting intelligent agents. SIGOIS Bull., 11(2-3) :21–30, March 1990.
[Bou07] Architecture multi-agents pour la composition automatique de web
services. AFIA2007, 2007.
[BSS17] Vangie Beal, Forrest Stroud, and Paul Shread. Webopedia, 2017.
[Online tech dictionary for IT professionals, educators and students.].
[BW94] A. Barrett and D. S. Weld. Partial-order planning : evaluating pos-
sible efficiency gains. Artificial Intelligence, 67(1), 1994.
[CAH06] Daniella Barreiro Claro, P. Albers, and J. Hao. Semantic Web Ser-
vices : Processes and Applications, chapter Chapter 8, Web Services
composition, pages 195–225. Springer, 2006.
[Cer02] Ethan Cerami. Web Services Essentials. O’Reilly edition, 2002.
[Cha07] Yasmine Charif. Chorégraphie dynamique de services basée sur la co-
ordination d’agents introspectifs. PhD thesis, LIP6, Université Pierre
et Marie Curie, Paris, décembre 2007.
[Che92] V. Chevrier. Coordination et structuration des échanges par
négociation dans les systèmes multi-agents. In Journée Systèmes
Multi-Agents PRC-GDR Intelligence Artificielle. Nancy, 1992.
[Che11] Chantal Cherifi. Classification et Composition de Services Web : Une
Perspective Réseaux Complexes. PhD thesis, Université de Corse -
PASCAL PAOLI, décembre 2011.
[Cho10] Imad Chouchani. Utilisation d’un algorithme génétique pour la com-
position de services web. Master’s thesis, Université du Quebec à
Montréal, Canada, mai 2010. Mémoire de maitrise au département
d’informatique.
[Cla06] Daniela Barreiro Claro. SPOC – Un canevas pour la composition
automatique de services web dédiés à la réalisation de devis. PhD
thesis, Ecole Doctorale d’Angers, Université d’Angers, octobre 2006.
[DA07] Helga Duarte-Amaya. Tcows : Canevas pour la composition des ser-
vices web avec propriétés transactionnelles. Thèse, laboratoire LIG,
Université Joseph Fourier, Université Joseph Fourrier - GrenobleI, no-
vembre 2007. Thèse préparée au sein du Laboratoire d’Informatique
de Grenoble - LIG, équipe MRIM - France.
[Dav80] R. Davis. Report on the workshop on distributed artificial intelli-
gence. In SIGART Newsletter, page 42–52, janvier 1980.
[DK01] Patrick Doherty and Jonas Kvarnström. Talplanner a temporal logic-
based planner. 22(3), 2001.
[DMJ+ 10] M. Driss, N. Moha, Y. Jamoussi, J-M. Jézéquel, and Hajjami
Ben Ghézala. A requirement-centric approach to web service mo-
deling, discovery and selection. In In Proceedings of the 8th Inter-
national Conference on Service Oriented Computing (ICSOC 2010),
San Francisco, USA, December 2010.
BIBLIOGRAPHIE 139
BIBLIOGRAPHIE
[Dro93] Alexis Drogoul. De La Simulation Multi-Agent A La Résolution

Collective de Problèmes : Une Étude De l’Émergence De Structures
D’Organisation Dans Les Systèmes Multi-Agents. PhD thesis, Uni-
versité Paris VI, LAFORIA, I.B.P., Université Paris VI, Boı̂te 169, 4
Place Jussieu, 75232 Paris Cedex 05, Novembre 1993.
[DSSGPvS09] L. O. B. Da Silva Santos, G. Guizzardi, L. F. Pires, and M. van
Sinderen. From user goals to discovery and composition. advances
in conceptual modeling : Challenging perspectives. Lecture Notes in
Computer Science 5833, pages 265–274, 2009. Springer Verlag Berlin.
[Dum08] Intergiciel et Construction d’Applications Réparties : Les Ser-
vices Web, chapter Chapitre 4, pages 85–113. juin 2008.
http ://creativecommons.org/licenses/by-nc-nd/2.0/fr/deed.fr.
[EF10] Mohamad El Falou. Contributions à la composition dynamique de
services fondée sur des techniques de planification et diagnostic multi-
agents. PhD thesis, Université de Caen/Basse-Normandie, U.F.R.
Sciences, Ecole doctorale SIMEM, 2010.
[EFBMV10] Mohamad El Falou, Maroua Bouzid, Abdel-Illah Mouaddib, and
Thierry Vidal. A distributed planning approach for web services
composition. In IEEE Computer Society, editor, 2010 IEEE Inter-
national Conference on Web Services, pages 337–344, 2010.
[Fer95] Jacques Ferber. Les systèmes multi-agents : Vers une intelligence
collective. IIA, 1995.
[Fer09] Jacques Ferber. MadKit pas à pas : Démarrage et prise en main du
logiciel MadKit. LIRMM, Université de Montpellier II, Avril 2009.
[FG88] Jacques Ferber and Malik Ghallab. Problématiques des univers multi-
agents intelligents. In Actes des journees nationales PRC-GRECO
Intelligence Artificielle, 1988.
[FN71] R. E. Fikes and N. J. Nilsson. Strips : A new approach to the appliac-
tion of theorem proving to problem solving. Artificial Intelligence,
page 189–208, 1971.
[Gab06] Yoann Gabillon. Composition d’Interfaces Homme-Machine par pla-
nification automatique. PhD thesis, Université de Grenoble, 2006.
[Gan07] Patrick Gantet. Les concepts de soa, 2007. [Wikipédia, Encyclopédie
libre, consultée le 08/04/2017].
[GB96] Zahia Guessoum and Jean-Pierre Briot. Dima, 1996.
[GDK87] V. R. Gasser, E. H. Durfee, and D. D. Korkill. Coherent coopera-
tion among communicating problem solvers. IEEE Transactions on
Computers, 36, 1987.
[GFM00] Olivier Gutknecht, Jacques Ferber, and Fabien Michel. The madkit
agent platform architecture, mai 2000.
[Gin85] Matthew L Ginsberg. Decision Procedures. Stanford, CA : Depart-
ment of Computer Science, Stanford University, 1985.
[GNT04] M. Ghallab, D. Nau, and P. Traverso. Automated Planning : Theory
and Practice. Elsevier Morgan Kaufmann Publishers, 2004.
140 BIBLIOGRAPHIE
BIBLIOGRAPHIE
[GRGS06] J. Gomez, M. Rico, and F. Garcia-Sanchez. Godo : Goal oriented

discovery for semantic web services. In 5th international Semantic
Web Conference, 2006.
[GRI05] Dobson Glen, Lock Russell, and Sommerville Ian. Qosont : a qos on-
tology for service-centric systems. In IEEE Computer Society, editor,
31st EUROMICRO Conference on Software Engineering and Advan-
ced Applications (EUROMICRO-SEAA 2005), page 80–87, 2005.
[Gsc09] Benoit Gschwind. Composition automatique et adaptative des services
web pour la météorologie. PhD thesis, Mines ParisTech, 2009.
[Hel06] M. Helmert. The fast downward planning system. Journal of Artifi-
cial Intelligence Research (JAIR), 26 :191–246, 2006.
[HG00] P. Haslum and H. Geffner. Admissible heuristics for optimal planning.
In AAAI Press, editor, Proc. 5th International Conference on Artifi-
cial Intelligence Planning and Scheduling (AIPS’00), page 140–149,
2000.
[HM06] F. Hadjila and M. Malki. Les services web sémantiques : Une ap-
proche de découverte basée sur les agents. In Proceeding CIIA 2006
Saida, 2006.
[HN01] J. Hoffmann and B. Nebel. The ff planning system : Fast plan ge-
neration through heuristic search. Journal of Artificial Intelligence
Research(JAIR), 14 :253–302, 2001.
[HNA16] Andreas Horni, Kai Nagel, and Kay W. Axhausen. The Multi-Agent
Transport Simulation MATSim. Ubiquity Press Ltd., 2016.
[Huh87] M. N. Huhns. Distributed Artificial Intelligence : Theory and praxis.
Pitman Publishing-Morgan Kaufman, 1987.
[JG15] C. Jatoth and G.R. Gangadharan. Fitness metrics for qos-awareweb
service composition using metaheuristics. 39, 2015.
[KFKS05] Matthias Klusch, Benedikt Fries, Mahboob Khalid, and Katia Sycara.
Owls-mx : Hybrid owl-s service matchmaking. 2005.
[KKZ09] Matthias Klusch, Patrick Kapahnke, and Ingo Zinnikus. Sawsdl-mx2 :
A machine-learning approach for integrating semanticweb service-
matchmaking variants. IEEE Computer Society ICWS, page 335–342,
2009.
[KR05] Konig Klein and Mussig Ries. What is needed for semantic servvice
descriptions : A proposal for suitable language constructs. Interna-
tional Journal of Web and Grid Services, pages 328–364, 2005.
[Kre01] Heather Kreger. Web service conceptual architecture. In IBM Soft-
ware Group. 2001.
[KSK15] W. Khowfa, O. Silasai, and C. Kaewpruksapimon. Qos based service
selection in cloud environment : A review. 7(3), November 2015.
[KT03] Patrick Kellert and Farouk Toumani. Les services web sémantiques.
Technical report, LIMOS/RR, 2003.
[Kum92] Vipin Kumar. Algorithms for constraintsatisfaction problems : A
survey. In AI Magazine, pages 32–44. 1992.
BIBLIOGRAPHIE 141
BIBLIOGRAPHIE
[LaV06] Steven M. LaValle. PLANNING ALGORITHMS. Cambridge Uni-

versity Press, 2006.
[LBD15] Patrice Langlois, Baptiste Blanpain, and Eric Daudé. Magéo, une pla-
teforme de modélisation et de simulation multi-agent pour les sciences
humaines. octobre 2015.
[LC87] V. R. Lesser and D. D. Corkill. Distributed problem solving networks.
John Wiley and Sons, New York, 1987.
[LRZ13] Lu Li, Mei Rong, and Guangquan Zhang. A web service composition
selection approach based on multi-dimension qos. In The 8th In-
ternational Conference on Computer Science and Education (ICCSE
2013), Colombo, Sri Lanka, pages 1463–1468, April 2013.
[LV08] Céline Lopez-Velasco. Sélection et composition de services Web pour
la génération d’applications adaptées au contexte d’utilisation. PhD
thesis, laboratoire LIG, Université Joseph Fourier, novembre 2008.
[Mar09] Frédéric Maris. Planification SAT et Planification Temporellement
Expressive : Les Systèmes TSP et TLP-GP. PhD thesis, Université
de Toulouse, 2009.
[MBE03] B. Medjahed, A. Bouguettaya, and A. K. Elmagarmid. Composing
web services on the semantic web. The VLDB Journal, 12(4), no-
vember 2003.
[MBR01] Phillipe Mathieu, Nourredine Bensaid, and Jean Christophe Routier.
Magique : Un tutoriel, mai 2001.
[MC09] I. Mirbel and P. Crescenzo. Des besoins des utilisateurs à la recherché
de services web : une approche sémantique guidé par les intentions.
Technical report, Rapport de recherche ISRN I3S/RR-2009-12-FR,
2009.
[MM08] Jean-Claude Morand and Brice Mollard. Tourisme 2.0. M21 Editions,
july 2008.
[MN12] Justin Moskolat Ngossaha. Web services : Etude et conception d’une
plateforme de services pour une environnement numérique de travail
d’université. Master’s thesis, Université de Ngaoundéré, Cameroun,
2012.
[MP05] Philippe Mathieu and Sébastien Picault. Projet simule, 2005.
[MRV08] Frédéric Maris, Pierre Régnier, and Vincent Vidal. Planification par
satisfaction de bases de clauses. In Lakhdar Sais, editor, Problème
SAT : défis et challenges, pages 289–309. Hermès, 2008.
[New04] A. Newell. The Knowledge Level. Artificial Intelligence. PhD thesis,
Verginia Polytechnic, 2004.
[NIK+ 03] D. T. Nau, O. Ilghami, U. Kuter, J. W. Murdock, D. Wu, and F. Ya-
man. Shop2 : An htn planning system. Journal of Artificial Intelli-
gence Research (JAIR), page 379–404, 2003.
[PC04] Paul Palathingal and Sandeep Chandra. Agent approach for service
discovery and utilization. In In HICSS, 2004.
142 BIBLIOGRAPHIE
BIBLIOGRAPHIE
[Peg88] Claude Pegard. Coordination de robots mobiles Autonomes, applica-

tion aux chantiers automatisés. PhD thesis, Université de Picardie,
1988.
[Pel03] C. Peltz. Web services orchestration and choreography. Computer,
26(10) :46–52, 2003.
[PF09] Damien Pellier and Humbert Fiorino. Un modèle de composition au-
tomatique et distribuée de services web par planification. Intelligence
artificielle et web intelligence, pages 13–46, 2009. RSTI - RIA.
[Pon08] Julien Ponge. Model Based Analysis of Time-aware Web Services In-
teractions. PhD thesis, l’Université Blaise Pascal - Clérmont-Ferrand
II, february 2008.
[Ref17] Chabane Refes. Les services web, février 2017. [Mis à jour le mercredi
22 février 2017].
[RF11] Philippe Ramadour and Myriam Fakhri. Modèle et langage de com-
position de services. In Actes du XXIXème Congrès INFORSID,
Lille, France, 24-25 mai 2011, pages 59–76, 2011.
[RK05] C. Rolland and R-S. Kaabi. Designing service based cooperative sys-
tems. In IDEA. Group (pub), editor, Encyclopedia of ETechnologies
and Applications (EETA), 2005.
[RN95] Stuart Russell and Peter Norvig. Artificial Intelligence - A Modern
Approach, 1st edition. Prentice Hall Series. Prentice Hall, 1995.
[RN10] Stuart Russell and Peter Norvig. Artificial Intelligence - A Modern
Approach, 3rd edition. Prentice Hall Series. Prentice Hall, 2010.
[Sab08] Nicolas Sabouret. The view design language, 2008.
[Sea69] John Searle. Speech acts : An essay in the philosophy of language.
Cambridge University Press, 1969.
[Sho93] Y. Shoham. Agent-oriented programming. Artificial Intelligence, 60,
1993.
[Shu03a] Ran Shuping. A framework for discovering web services with desired
quality of services attributes. In IEEE International Conference on
Web Services, Las Vegas, Nevada, USA, june 2003.
[Shu03b] Ran Shuping. A model for web services discovery with qos. ACM
SIGecom Exchanges, 4 :1–10, 2003.
[TAAN08] N. Temglit, H. Aliane, and M. Ahmed Nacer. Un modèle de com-
position des services web sémantiques. In CARI 2008 - Marc Kokou
Assogba, volume 11, 2008.
[VS87] A. Vailly and M. A. Simon. Des systèmes experts coopérants, pour-
quoi, comment ? In AFCET, editor, Actes du congrès Cognitiva, pages
183–188, Paris, Mai 1987.
[Wei04] Gerhard Weiss. Multiagent systems. Morgan kaufman Publishers,The
MIT Press Cambridge, Massachusetts London, England, may 2004.
[Wik17] Wikipédia. Service web - wikipédia, l’encyclopédie libre, 2017. [En
ligne ; Page consultée le 8 avril 2017].
BIBLIOGRAPHIE 143
BIBLIOGRAPHIE
[Wil99] U. Wilensky. Netlogo, 1999.

[Wil17] U. Wilensky. Netlogo user manual, march 2017.
[WJ95] Michael Wooldridge and Nicholas Jennings. Intelligent agents :
Theory and practice. The knowledge Engineering Review, 10(2) :115–
152, 1995.
[WVKT06] X. Wang, T. Vitvar, M. Kerrigan, and I. Toma. A qos-aware selection
model for semantic web services. In Proceedings of the 4th Interna-
tional Conference on Service Oriented Computing ICSOC’06, pages
390–401, Chicago, USA, December 2006.
[YACT09] A. Yachir, Y. Amirat, A. Chibani, and K. Tari. Approche basée sur
la qualité de service pour la composition automatique des services en
robotique ubiquitaire. Technical report, Laboratoire Images, Signaux
et Systèmes Intelligents – LISSI (EA 3956) – Université Paris Est,
2009.
[You14] Mohamed Youssfi. Architecture j2ee, 2014. [Slides consultés le 11
mars 2015].
[ZBDS03] L. Zeng, B. Benatallah, J. Dumas, M.and Kalagnanam, and Q. Z.
Sheng. Quality driven web services composition. In ACMPress, edi-
tor, In Proceedings of the 12th international conference on WWW,
Budapest, Hungary, May 2003.
[ZMZJ07] K. Zachos, N. Maiden, X. Zhu, and S. Jones. Discovering web services
to specify more complete system requirements. In In Proceedings of
the 19th international conference on Advanced information systems
engineering (CAISE’07), 2007.
[ZZL14] Z. Zheng, Y. Zhang, and M. R. Lyu. Investigating qos of real-world
web services. 7(1), 2014. January-March 2014.
144 BIBLIOGRAPHIE

ThèseKBelmabrouk31102017 (Memoire)

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ThèseKBelmabrouk31102017 (Memoire)

Transféré par

Droits d'auteur :

Formats disponibles

‫امجلهورية اجلزائرية ادلميقراطية الشعبية‬

‫وزارة التعلمي العايل و البحث العلمي‬

Présenté par : Karima Belmabrouk

Faculté : Mathématiques et Informatique

Devant le Jury Composé de :

Membres de Jury Grade Qualité Domiciliation

Fatima Bendella Pr Encadrant USTO-MB

Maroua Bouzid Pr Co-Encadrant UNICAEN

Ghalem Belalem Pr UNIV-Oran1

Moussa Benaissa Pr Examinateurs UNIV-Oran1

Année Universitaire : 2016-2017

Mots clés : Modèle, Agent, Service Web, Composition, Planification.

Keywords : Model, Agent, Web Service, Composition, Planification.

Que Dieu, le miséricordieux, t’accueille dans son éternel paradis.

Mes remerciements s’adressent, aussi, à toute personne ayant contribué à la fi-

Table des matières . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

12 Domaines d’utilisation des agents et des systèmes multi-agents . . . . 21

2 Les services Web 27

4 La composition des services Web 73

II Partie : Notre Contribution 87

5.1 Principe général et définition formelle du processus . . . . . . 102

6 Conception et implémentation d’une ontologie du domaine de voyage107

7 Implémentation du modèle et validation 119

Conclusion et perspectives 133

xiv TABLE DES MATIÈRES

1.1 Modèle d’un agent réactif [Ber09]. . . . . . . . . . . . . . . . . . . . . 13

2.1 Architecture SOA [Gan07] . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1 Problème de planification . . . . . . . . . . . . . . . . . . . . . . . . 62

4.1 Une chorégraphie de services Web [Bel11] . . . . . . . . . . . . . . . . 75

5.1 Architecture à base d’agents pour la composition automatique de ser-

6.1 Hiérarchie des classes de l’ontologie du voyage . . . . . . . . . . . . . 110

7.1 Structure d’un message FIPA ACL. . . . . . . . . . . . . . . . . . . . 121

xvi TABLE DES FIGURES

1.1 Différence entre agent réactif et agent cognitif . . . . . . . . . . . . . 14

2.1 Tableau comparatif des différentes approches de recherche des services

3.1 Quelques variantes du langage PDDL . . . . . . . . . . . . . . . . . . 66

6.1 Tableau du glossaire des termes . . . . . . . . . . . . . . . . . . . . . 109

7.1 Structure d’un message ACL . . . . . . . . . . . . . . . . . . . . . . . 123

xviii LISTE DES TABLEAUX

Notre problématique consiste à proposer un modèle pour la composition des

– Une composition manuelle et une composition automatique,

Notre synthèse nous a, également, permis de découvrir les principaux modèles de

En plus des qualifications précédentes de notre approche, nous avons donné un

Cette qualité de service a pris sa part dans la conception de notre modèle au

des services Web et,

Les agents et les systèmes

2 L’intelligence artificielle distribuée (I.A.D)

3 Thèmes de recherche de L’I.A.D

– La résolution distribuée des problèmes (R.D.P) : elle s’intéresse à la

– L’intelligence artificielle parallèle (I.A.P) : elle concerne le développement

4.1 Les problèmes classiques

– La modélisation de la connaissance et le problème de sa répartition

– Les problèmes de génération de plans d’actions : où il faut prendre en

– Le problème de la communication : comment permettre la communica-

4.2 Les nouveaux problèmes proprement liés au thème de

– Les problèmes spécifiques au groupe d’agents : qui portent sur l’organi-

– Les problèmes liés au comportement d’un agent au sein d’un groupe :

5 Évolution vers les systèmes multi-agents

5. ÉVOLUTION VERS LES SYSTÈMES MULTI-AGENTS 9

6 Qu’est-ce qu’un agent ?

6.1 Quelques définitions

Définition 6 [RN95, RN10]

6.2 Les caractéristiques multidimensionnelles d’un agent