numéro d’identification : ACADÉMIE DE M ONTPELLIER
UNIVERSITÉ MONTPELLIER II — S CIENCES ET T ECHNIQUES DU L ANGUEDOC —
THÈSE présentée à l’ Université des Sciences et Techniques du Languedoc pour obtenir le diplôme de DOCTORAT S PÉCIALITÉ : I NFORMATIQUE Formation Doctorale : Informatique École Doctorale : Information, Structures, Systèmes
SaGE, un Système de Gestion d’Exceptions pour la programmation orientée message : Le cas des Systèmes Multi-Agents et des Plates-formes à base de Composants Logiciels
par
F RÉDÉRIC S OUCHON Soutenue le 5 Décembre 2005 devant le jury composé de : M. Olivier B OISSIER, Professeur, École des Mines de Saint-Étienne, M. Philippe L AHIRE, MDC HDR, Université de Nice Sophia Antipolis, M. Alexander ROMANOVSKI, Professor, University of Newcastle upon Tyne, UK, Mlle. Christelle U RTADO, MDC École des Mines d’Alès, M. Jacques F ERBER, Professeur, Université Montpellier II, M. Christophe D ONY, Professeur, Université Montpellier II,
Rapporteur Rapporteur Examinateur Examinateur Examinateur Directeur de Thèse
à mes parents,
2
Remerciements Je remercie respectueusement mon directeur le thèse, le Professeur Christophe Dony, pour ses conseils, ses encouragements, sa confiance, tout ce par quoi il a su orienter ma liberté de recherche. Mes respects et ma gratitude vont également aux membres de mon jury qui m’ont fait l’honneur de juger ce travail en venant pour certains de fort loin et qui tous, par leur disponibilité, leurs observations et leurs rapports m’ont permis de l’enrichir. Mener à terme un doctorat, au delà de la rédaction du document de thèse, porte sur les efforts menés de la découverte de la bibliographie jusqu’à l’organisation de l’événement si particulier que constitue le jour de sa soutenance en passant par les échanges et réflexions qui ont permis de proposer un travail enrichissant pour une communauté scientifique. L’ensemble de ce processus serait irréalisable sans l’aide et le soutien d’autres personnes. Merci à Audrey, Camille, Olivier, Fabien et Eric pour avoir immensément contribué à chacun de ces aspects. Merci à Jérome Chapelle pour toute l’aide qu’il m’a apporté de nombreuses fois durant toutes ces années. Merci à Christelle Urtado et à Sylvain Vauttier de m’avoir fait participer à une activité de recherche si passionnante et inspirante. Merci à mes encadrants pour leur disponibilité lors des pré-soutenances. Merci à Fabien Jalabert pour son immense contribution à l’organisation du jour J. Je remercie également Sylvie Cruvellier et Jocelyne Nanard pour leur précieuse aide lors des démarches administratives. Mener à terme un doctorat suppose aussi bien sur que les choses de la vie vous en aient donnés l’occasion. Je pense à tous mes professeurs sans lesquels ce travail n’existerait pas et plus spécialement à Jacques Ferber qui m’a donné goût à l’étude des systèmes multi-agents. Merci à Fabien Michel et Olivier Simonin pour m’avoir fait partager leur expérience du doctorat. Je remercie l’équipe pédagogique de l’EERIE pour m’avoir permis de faire mes premières armes dans l’enseignement. Je remercie Annie Liothin et François Trousset pour leur aide et les bons moments que nous avons partagés tout au long de cette thèse. Mener à terme un doctorat est aussi une expérience humaine. Je remercie tous ceux qui m’ont aidé dans cette aventure. Merci Géraldine, Nicolas, Canelle, Amélie, Patrice, Clément, Frédéric, Sébastien et Emilie. Je remercie ma mère et je remercie mon père. Merci à Agnès.
3
4
Table des matières 1
2
Introduction
13
1
Contexte et objet de ce mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2
Organisation du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
Contexte d’étude : les programmations par agents et par composants
17
1
Les middlewares : une solution aux limites de la programmation distribuée classique
18
1.1
Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
1.2
Les modes de communication dans les applications . . . . . . . . . . . . . .
21
Concurrence et asynchronisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.1
Possibilité de définir des activités concurrentes . . . . . . . . . . . . . . . .
23
2.2
Coordination des activités concurrentes . . . . . . . . . . . . . . . . . . . .
25
2
3
4
Les Systèmes Multi-Agents, un exemple typique de la programmation orientée message 26 3.1
Introduction et définitions . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.2
Les “sociétés“ d’agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.3
L’exemple des agences de voyage dans un système multi-agents : choix de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
Les plates-formes à base de composants logiciels . . . . . . . . . . . . . . . . . . .
31
4.1
Introduction et définitions . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.2
Typologie des modes d’interaction . . . . . . . . . . . . . . . . . . . . . . .
34
4.2.1
Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.2.2
Interactions par requête/réponse et communications synchrones . .
36
4.2.3
Interactions par requête/réponse et communications asynchrones .
37
4.2.4
Interaction par soumission d’information . . . . . . . . . . . . . .
40
4.3 5 3
L’exemple des agences de voyage dans une plate-forme à base de composants logiciels : choix de modélisation . . . . . . . . . . . . . . . . . . . . . . . .
42
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
Gestion d’exceptions : état de l’art
45
1
Systèmes de Gestion d’Exceptions (SGE) : motivations et définitions . . . . . . . . .
46
1.1
46
Tolérance aux pannes : quelles solutions ? . . . . . . . . . . . . . . . . . . . 5
TABLE DES MATIÈRES 1.1.1
Cahier des charges pour la gestion des exceptions . . . . . . . . .
47
1.1.2
Codes de sortie
. . . . . . . . . . . . . . . . . . . . . . . . . . .
47
1.1.3
Renvoi de valeurs particulières . . . . . . . . . . . . . . . . . . .
48
Gestion d’exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
Gestion d’exceptions en programmation séquentielle . . . . . . . . . . . . . . . . .
50
2.1
Présentation d’un système de gestion d’exceptions typique . . . . . . . . . .
50
2.2
Gestion d’exceptions dans le paradigme objet . . . . . . . . . . . . . . . . .
51
Gestion d’exceptions en milieu concurrent . . . . . . . . . . . . . . . . . . . . . . .
55
1.2 2
3
3.1
La gestion d’exceptions dans le cadre de la concurrence isolée : la cas typique des threads Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2
3.3
56
Gestion d’exceptions dans des langages permettant la concurrence collaborative 56 3.2.1
Gestion d’exceptions dans Multilisp . . . . . . . . . . . . . . . .
56
3.2.2
La concurrence dans ProActive . . . . . . . . . . . . . . . . . . .
58
Des systèmes de gestion d’exceptions pour la concurrence coopérative . . . .
58
3.3.1
Le cas des Threadgroups Java . . . . . . . . . . . . . . . . . . . .
58
3.3.2
Une proposition permettant la concertation d’exceptions dans un langage à multi-procédures . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3 4
Un système distinguant les activités critiques et non-critiques dans le langage Guide . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
Gestion d’exceptions dans les systèmes multi-agents (SMA) . . . . . . . . . . . . .
61
4.1
SMA sans SGE dédié . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.2
SMA avec gestion d’exceptions centralisée . . . . . . . . . . . . . . . . . .
62
4.2.1
SMA à superviseurs . . . . . . . . . . . . . . . . . . . . . . . . .
62
4.2.2
SMA avec gardiens . . . . . . . . . . . . . . . . . . . . . . . . .
63
Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
Gestion d’exceptions dans les plates-formes à base de composants logiciels . . . . .
65
4.3 5
5.1
Gestion d’exceptions pour les composants communiquant de manière synchrone et interagissant par requête/réponse . . . . . . . . . . . . . . . . . .
5.2
5.3 6
59
65
Gestion d’exceptions pour les composants communiquant de manière asynchrone et interagissant par requête/réponse . . . . . . . . . . . . . . . . . .
65
5.2.1
Le cas des MessageDrivenBeans (J2EE) . . . . . . . . . . . . . .
66
5.2.2
Le cas des composants RRA dans .NET . . . . . . . . . . . . . .
68
5.2.3
Le cas des composants RRA dans CORBA . . . . . . . . . . . . .
68
5.2.4
Le modèle à gardien pour composants RRA . . . . . . . . . . . .
69
Gestion d’exceptions pour les composants interagissant par émission d’information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
Cahier des charges résultant de l’étude . . . . . . . . . . . . . . . . . . . . . . . . .
70
6
TABLE DES MATIÈRES 6.1
Réactivité du système lors du signalement d’une exception . . . . . . . . . .
70
6.2
Respect de la contextualisation lors du signalement des exceptions . . . . . .
70
6.3
Asynchronisme des communications et coordination des activités concurrentes lors d’un signalement d’exception . . . . . . . . . . . . . . . . . . . . . . .
71
Concertation d’exceptions signalées par des activités concurrentes . . . . . .
72
7
Travaux connexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
8
Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
6.4
4
SaGE, un SGE dédié aux SMA et aux plates-formes à composants logiciels : Spécification 77 1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
2
Hypothèses sur le contexte d’application . . . . . . . . . . . . . . . . . . . . . . . .
78
3
Statut des exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
4
Définition et association des handlers . . . . . . . . . . . . . . . . . . . . . . . . . .
80
4.1
Les handlers du langage sous-jacent . . . . . . . . . . . . . . . . . . . . . .
80
4.2
Définition et association des handlers SaGE . . . . . . . . . . . . . . . . . .
81
Signalement des exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.1
Levée des exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.2
Mécanisme de signalement . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.2.1
Signalement des exceptions . . . . . . . . . . . . . . . . . . . . .
83
5.2.2
Terminaison des services . . . . . . . . . . . . . . . . . . . . . .
85
Concertation d’exceptions signalées par des activités concurrentes . . . . . .
87
5.3.1
Principe général de la concertation des exceptions dans SaGE . . .
87
5.3.2
Concertation d’exceptions au niveau des services
. . . . . . . . .
88
5.3.3
Concertation d’exceptions au niveau des représentants de rôles . .
89
5.4
Algorithme de signalement . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
5.5
Traitements effectués par les handlers SaGE . . . . . . . . . . . . . . . . . .
92
Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
5
5.3
6 5
Conception et Implémentation
95
1
Représentation des activités individuelles et collectives . . . . . . . . . . . . . . . .
96
1.1
Représentation des activités individuelles par des services . . . . . . . . . .
96
1.2
Représentation des activités collectives par des arborescences de services . .
98
1.3
Services et encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
1.4
Exécution concurrente des services dans les entités . . . . . . . . . . . . . . 102
1.5
Traitement des requêtes groupées . . . . . . . . . . . . . . . . . . . . . . . 104 1.5.1
Les représentants de rôle . . . . . . . . . . . . . . . . . . . . . . 104
1.5.2
Le service de Broadcasting . . . . . . . . . . . . . . . . . . . . . 105
1.6
Exemple complet d’une exécution standard . . . . . . . . . . . . . . . . . . 106
1.7
Le mécanisme de terminaison . . . . . . . . . . . . . . . . . . . . . . . . . 109 7
TABLE DES MATIÈRES 1.8 2
Réactivité du système
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Implémentations de SaGE dans une plate-forme SMA . . . . . . . . . . . . . . . . . 111 2.1
Présentation de MADKit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 2.1.1
La plate-forme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
2.1.2
Les agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
2.2
Gestion des communications pour SaGE . . . . . . . . . . . . . . . . . . . . 114
2.3
Définitions des agents SaGE et de leurs services . . . . . . . . . . . . . . . . 114 2.3.1
Introduction technique : Implémentation des agents dans la plateforme MADKit . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
2.3.2 2.3.3 2.4
Statut des exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
2.5
Gestion des requêtes groupées . . . . . . . . . . . . . . . . . . . . . . . . . 117
2.6
Évaluation des résultats dans MADKit . . . . . . . . . . . . . . . . . . . . . 117
2.7 3
2.6.1
Définition des agents . . . . . . . . . . . . . . . . . . . . . . . . 117
2.6.2
Concertation d’exceptions . . . . . . . . . . . . . . . . . . . . . . 119
2.6.3
Terminaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Implémentation de SaGE dans une plate-forme à base de composants logiciels . . . . 122 3.1
3.2
6
Implémentation des agents SaGE . . . . . . . . . . . . . . . . . . 115 Implémentation des services SaGE . . . . . . . . . . . . . . . . . 116
Présentation de JOnAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 3.1.1
J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
3.1.2
JOnAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3.1.3
Les composants EJB dans JOnAS . . . . . . . . . . . . . . . . . . 124
Définition des SaGEMDBs et de leurs services . . . . . . . . . . . . . . . . 125 3.2.1
Les “SaGEMDB” . . . . . . . . . . . . . . . . . . . . . . . . . . 125
3.2.2
Définition des services SaGE . . . . . . . . . . . . . . . . . . . . 125
3.2.3
Statut des exceptions et des messages . . . . . . . . . . . . . . . . 126
3.3
Gestion des communications par la modification du conteneurs d’EJB . . . . 126
3.4
Gestion des requêtes groupées . . . . . . . . . . . . . . . . . . . . . . . . . 129
3.5
Évaluation des résultats dans JOnAS . . . . . . . . . . . . . . . . . . . . . . 129
3.6
Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Conclusions et perspectives 131 1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 2
Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Bibliographie
139
8
Table des figures 2.1
Place du middleware dans les couches logicielles . . . . . . . . . . . . . . . . . . .
18
2.2
Description d’une invocation de méthode distante avec RMI . . . . . . . . . . . . .
20
2.3
Représentation simplifiée du bus CORBA . . . . . . . . . . . . . . . . . . . . . . .
20
2.4
Communication synchrone entre un client et un serveur . . . . . . . . . . . . . . . .
21
2.5
Communication asynchrone entre un client et un serveur . . . . . . . . . . . . . . .
22
2.6
Un exemple de commande de billet auprès d’une agence de voyage . . . . . . . . . .
24
2.7
Envoi asynchrone d’un message à destination d’une boîte aux lettres . . . . . . . . .
27
2.8
Le modèle Agent-Groupe-Rôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
2.9
Exploitation de la notion de groupe dans l’exemple de l’agence de voyages
. . . . .
31
2.10 Exemple de descripteur de déploiement XML d’un serveur J2EE . . . . . . . . . . .
33
2.11 Structure d’une application construite à base de composants logiciels . . . . . . . . .
34
2.12 Communication synchrone entre composants RRS . . . . . . . . . . . . . . . . . . .
36
2.13 Exemple d’invocation d’une méthode Java d’un Session Bean . . . . . . . . . . . .
36
2.14 Interaction de type requête/réponse et communication asynchrone entre composants RRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
2.15 Traitement d’un message JMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
2.16 Diagramme de classes du patron ServiceActivator . . . . . . . . . . . . . . . . . . .
39
2.17 Communication semi-synchrone entre un client et un serveur . . . . . . . . . . . . .
39
2.18 Exemple de code Java Parallel . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
2.19 Communication synchrone entre composants interagissant par événements . . . . . .
41
2.20 Un événement déclenche l’exécution de comportements . . . . . . . . . . . . . . . .
42
2.21 Classification générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.1
Exemple d’utilisation de code de sortie en C . . . . . . . . . . . . . . . . . . . . . .
47
3.2
Exemple d’une procédure en C pouvant signaler une exception par une valeur de retour particulière . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
3.3
Les trois types de modèles de SGE . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
3.4
Exemples d’exécution de procédures en programmation séquentielle . . . . . . . . .
52
3.5
Structure d’un bloc de code auquel on associe des handlers en C . . . . . . . . . . .
52
3.6
Exemple de programme en C avec gestion d’exceptions . . . . . . . . . . . . . . . .
53
9
TABLE DES FIGURES 3.7
Exemple d’utilisation d’un objet-exception encapsulant de l’information en Java . . .
54
3.8
Différentes politiques de signalement des exceptions . . . . . . . . . . . . . . . . .
55
3.9
Utilisation de future et touch dans Multilisp . . . . . . . . . . . . . . . . . . . . . .
56
3.10 Signalement des exceptions dans MultiLisp . . . . . . . . . . . . . . . . . . . . . .
57
3.11 Association d’un handler à une expression à évaluer en parallèle dans MultiLisp . . .
58
3.12 Invocation synchrone d’une multi-procédure . . . . . . . . . . . . . . . . . . . . . .
60
3.13 Exemple en langage Guide où les deux composantes d’une activité collective sont critiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
3.14 Exemple de gestion d’exceptions interne et globale dans le code Java d’un participant
64
3.15 Gestion d’exceptions dans un Session Bean . . . . . . . . . . . . . . . . . . . . . .
65
3.16 Exemple de gestion d’exceptions dans le code Java d’un Session Bean . . . . . . . .
66
3.17 Gestion d’exception dans un Message Driven Bean . . . . . . . . . . . . . . . . . .
67
3.18 Traitement d’une erreur de délivrance de message dans le code Java d’un MDB . . .
67
3.19 Gestion d’exceptions dans des composants interagissant par événements . . . . . . .
69
3.20 Récapitulatif des SGE dans la programmation classique . . . . . . . . . . . . . . . .
74
3.21 Récapitulatif des SGE dans les SMA et systèmes à composants logiciels . . . . . . .
75
4.1
Définition de la classe SaGEException en Java . . . . . . . . . . . . . . . . . . . .
80
4.2
Cohabitation de SaGE et du SGE de Java . . . . . . . . . . . . . . . . . . . . . . .
80
4.3
Exemple en pseudo-langage d’association d’un handler à une requête . . . . . . . . .
81
4.4
Exemple en pseudo-langage d’association d’un handler à un service . . . . . . . . .
82
4.5
Exemple en pseudo-langage d’association d’un handler à une entité active . . . . . .
82
4.6
Exemple en pseudo-langage de handler associé à un représentant de rôle . . . . . . .
83
4.7
Recherche de handler dans SaGE . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
4.8
Cheminement des exceptions dans SaGE . . . . . . . . . . . . . . . . . . . . . . . .
85
4.9
Exemple de terminaison forcée d’un service pendant . . . . . . . . . . . . . . . . .
86
4.10 Exemples de résultats de concertations d’exceptions . . . . . . . . . . . . . . . . . .
87
4.11 Exemple en pseudo-code de fonction de concertation associée au représentant des Prestataires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
4.12 Définition de la primitive de signalement . . . . . . . . . . . . . . . . . . . . . . . .
90
4.13 Définition du mécanisme de signalement (première partie) . . . . . . . . . . . . . .
91
4.14 Définition du mécanisme de signalement (deuxième partie) . . . . . . . . . . . . . .
91
4.15 Principe de l’algorithme de signalement . . . . . . . . . . . . . . . . . . . . . . . .
93
5.1
Exemple de définition d’un service et d’un service complexe en pseudo-langage . . .
97
5.2
Diagramme UML état-transition d’un service simple SaGE . . . . . . . . . . . . . .
98
5.3
Diagramme UML état-transition d’un service complexe SaGE . . . . . . . . . . . .
99
5.4
Exécution résultant d’une requête à l’agence de voyage . . . . . . . . . . . . . . . .
99
5.5
Interaction transparente entre services . . . . . . . . . . . . . . . . . . . . . . . . . 100 10
TABLE DES FIGURES 5.6
Exemple d’interaction transparente . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.7
Exemple de structure d’une entité en pseudo-code
5.8
Exemple de requêtes traitées concurremment par une agence . . . . . . . . . . . . . 104
5.9
Exemple de traitement concurrent de deux requêtes par une agence . . . . . . . . . . 105
. . . . . . . . . . . . . . . . . . 103
5.10 Comportement d’initialisation du service de Broadcasting écrit en pseudo-langage . . 106 5.11 Arborescence de services (tous services représentés)
. . . . . . . . . . . . . . . . . 107
5.12 Arborescence de services (première étape) . . . . . . . . . . . . . . . . . . . . . . . 108 5.13 Arborescence de services (broadcasting) . . . . . . . . . . . . . . . . . . . . . . . . 108 5.14 Arborescence de services (établissement du contrat) . . . . . . . . . . . . . . . . . . 109 5.15 Exemple d’échanges de messages concernant la terminaison . . . . . . . . . . . . . 111 5.16 Exemple du code Java d’un agent MADKit traitant des chaînes de caractères . . . . . 113 5.17 Diagramme UML de l’implémentation de SaGE dans MADKit . . . . . . . . . . . . 115 5.18 Définition de Prestataires_RoleAgent
. . . . . . . . . . . . . . . . . . . . . . . . . 117
5.19 Une fenêtre MADKit typique avec des instances de SaGEAgents . . . . . . . . . . . 118 5.20 Diagramme de classes de l’exemple dans l’implémentation de SaGE pour MADKit . 118 5.21 Exemples de concertation d’exceptions . . . . . . . . . . . . . . . . . . . . . . . . . 119 5.22 Fonction de concertation associée au code Java de Prestataires_RoleAgent . . . . . . 120 5.23 Handler associé au code Java de Prestataires_RoleAgent . . . . . . . . . . . . . . . 121 5.24 Architecture de JOnAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 5.25 Exemple en code Java de méthode de sélection de service . . . . . . . . . . . . . . . 126 5.26 Diagramme UML de classes de l’implémentation de SaGE pour JOnAS . . . . . . . 127 5.27 Gestion des messages JMS par le conteneur d’EJB JOnAS avec SaGE . . . . . . . . 128
11
TABLE DES FIGURES
12
Chapitre 1
Introduction Sommaire 1
Contexte et objet de ce mémoire . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2
Organisation du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
1 Contexte et objet de ce mémoire Nous observons depuis quelques années une augmentation de l’intérêt porté à de nouveaux paradigmes de programmation tels que les systèmes multi-agents (SMA) [Fer95] ou les plates-formes à base de composants logiciels [Szy98]. Les applications résultantes peuvent être distribuées et éventuellement faire entrer en jeu des communication asynchrones (une entité logicielle qui émet un message de manière asynchrone poursuit son exécution sans attendre la réponse correspondante). La modularité, les facilités offertes en termes de distribution et d’exploitation de la concurrence constituent, entre autres, des qualités de modélisation qui se sont avérées efficaces pour construire des applications évolutives, réutilisables et exploitables sur des systèmes hétérogènes au travers de réseaux informatiques (cf. chapitre 2). Les systèmes multi-agents sont constitués d’un ensemble d’entités logicielles actives et indépendantes (les agents) qui interagissent dans le cadre d’un environnement. Cet ensemble forme un SMA. Les agents sont développés séparément. Par ailleurs ils peuvent être introduits dans un environnement ou en être retirés dynamiquement. Enfin, ils peuvent percevoir, analyser et modifier ce dernier dans la limite de leurs aptitudes et communiquent entre eux de manière asynchrone. Une application à base de composants logiciels est constituée d’un ensemble d’entités logicielles (les composants logiciels) qui sont interconnectées afin de pouvoir interagir. Les composants logiciels doivent être assez génériques pour que l’on puisse les intégrer dans différents environnements et contextes d’utilisation en les assemblant avec d’autres composants logiciels. Les composants logiciels exposent leurs fonctionnalités au travers d’interfaces dédiées et peuvent communiquer avec d’autres composants de manière synchrone et/ou asynchrone en fonction de leur nature. 13
CHAPITRE 1. INTRODUCTION Que ce soit dans le cas des SMA ou des plates-formes à composants logiciels, l’indépendance des entités actives, le caractère modulaire des plates-formes, leur distribution et la possibilité de faire entrer en jeu des communications asynchrones, éventuellement dans le cadre de la programmation orientée message, constituent autant de raisons pour lesquelles il n’est pas possible, dans un tel contexte, de considérer la gestion d’exceptions 1 comme un problème secondaire de la spécification de tels langages (encore moins comme un mécanisme greffé à un langage au travers d’une bibliothèque additionnelle). La gestion d’exceptions est un dispositif-clé des langages de programmation et l’évolution des paradigmes de programmation nous conduit à reconsidérer cette problématique. Dans ce mémoire, nous nous intéressons à la problématique de la gestion des exceptions dans le contexte du développement de systèmes basés sur ces nouveaux paradigmes de programmation. Nous prenons en compte les contraintes induites par l’usage de tels paradigmes comme l’asynchronisme des communications qui n’est que partiellement supportée dans les systèmes de gestion d’exceptions (SGE) existants. Les mécanismes de messagerie asynchrone permettent de développer des applications dont l’activité globale est produite par l’exécution d’un ensemble de processus concurrents qui coopèrent par échanges asynchrones de messages (on parle de programmation orientée-message). Quand une activité est initiée par un message envoyé de manière asynchrone, le processus ayant envoyé ce message poursuit son exécution pendant que le message est traité. Un tel comportement peut être un outil de conception efficace et offrir des performances accrues. En revanche, l’utilisation de mécanismes de communications asynchrones complique la gestion des interactions et, en particulier, la gestion d’exceptions (cf. chapitre 3). Les mécanismes de gestion d’exceptions pour les langages de programmation séquentiels sont matures et répondent bien aux attentes des programmeurs dans le cadre de ces langages. Ils sont basés sur l’exploitation de la pile des appels pour rechercher un gestionnaire d’exception approprié au traitement des exceptions signalées [Goo75]. Malheureusement, dans le cadre de communications asynchrones, la notion de pile des appels perd son sens au niveau global et ne peut alors plus être exploitée pour gérer les exceptions. Par exemple, en cas d’occurrence d’une exception dans le contexte d’une activité invoquée de manière asynchrone, il est possible que l’entité ayant initié l’activité défaillante ne soit plus en cours d’exécution et l’exception ne saurait alors être notifiée à cette dernière. Il se pose donc le problème de la diffusion des exceptions : à quelles entités et dans quel ordre ? Ayant dégagé un ensemble de critères qualitatifs permettant de juger l’efficacité et la validité d’un système de gestion d’exceptions, nous y avons confronté les différents types de SGE existants. Cette étude révèle les limites de ces derniers dans le contexte des nouveaux paradigmes de programmation quand des communications asynchrones entrent en jeu. Dans cette thèse, notre contribution se présente sous la forme d’un système de gestion d’exceptions dédié à ces nouveaux paradigmes de programmation. Ce système, baptisé SaGE (Système avancé de 1
Une exception indique l’occurrence d’une situation dans laquelle l’exécution standard d’un code ne peut se poursuivre. On peut prendre l’exemple classique de la division par zéro.
14
2. ORGANISATION DU MÉMOIRE Gestion d’Exceptions) propose des solutions à un ensemble de problèmes que nous recensons en nous appuyant notamment sur des travaux sur la gestion d’exceptions en milieu concurrent (cf. chapitre 4). De notre point de vue, les possibilités offertes par un langage en termes de gestion d’exceptions sont cruciales pour permettre la réalisation de systèmes fiables dans de tels paradigmes de programmation. Pour être adapté à ces derniers, nous considérons qu’un système de gestion d’exceptions doit présenter trois qualités essentielles : – Respecter le paradigme dans lequel il est exploité, – Gérer la concurrence, – et Gérer les coopérations entre entités logicielles. Par ailleurs, la structure de l’environnement d’exécution a un impact significatif sur le traitement des exceptions. Comme nous l’avons vu plus haut, c’est l’absence d’une représentation globale de l’exécution (on n’a que des piles des appels isolées) qui pose problème dans la gestion d’exceptions lorsque les entités actives s’exécutent de manière concurrente en communiquant de manière asynchrone. C’est pourquoi, dans nos travaux, nous avons été amenés à définir une notion de service permettant la représentation des activités globales pour pouvoir traiter efficacement les exceptions dans ces nouveaux paradigmes de programmation. C’est sur ce point que nous faisons face à une contradiction. D’une part, pour assurer l’indépendance d’entités actives concurrentes, il faut les isoler. D’autre part, pour représenter les coopérations entre entités actives, il faut définir des moyens d’interaction et des liens entre ces dernières (cf. chapitre 5). Nous avons donc dû définir un modèle qui permette à des entités isolées d’échanger des informations leur permettant de coopérer (requêtes, réponses, notification d’exceptions) tout en respectant le paradigme utilisé et l’intégrité du système (isolation des threads).
2 Organisation du mémoire Outre cette introduction, ce mémoire de thèse est organisé en 5 autres chapitres : – Le chapitre 2 présente le contexte de notre étude, c’est-à-dire les paradigmes de programmation des systèmes multi-agents et des plates-formes à composants logiciels. Après avoir vu leurs spécificités communes, nous nous intéressons aux divers modes de communication et d’interaction entre entités logicielles que l’on peut observer et à leur éventuel impact sur la concurrence entre ces dernières. Par la suite, nous voyons plus en détails ce que sont les systèmes multi-agents et les plates-formes à base de composants logiciels. – Le chapitre 3 fait un tour d’horizon de l’existant en matière de gestion des exceptions. Tout d’abord nous y présentons les motivations qui ont mené à la spécification de systèmes de gestion d’exceptions (SGE) pour ensuite voir comment ces principes se sont appliqués dans la programmation “classique”, qu’elle soit séquentielle ou concurrente, puis dans les nouveaux paradigmes de programmation qui nous intéressent. Nous présentons ensuite un ensemble de 15
CHAPITRE 1. INTRODUCTION critères qualitatifs relatifs à la gestion d’exceptions que nous considérons comme indispensables à la définition d’un système de gestion d’exceptions répondant aux attentes et besoins des programmeurs dans le contexte des paradigmes de programmation auxquels nous nous intéressons. Enfin, nous concluons ce chapitre par une synthèse mettant en évidence les lacunes des systèmes de gestion d’exceptions existants au regard des critères qualitatifs pré-cités et établissons en conséquence un cahier des charges pour notre proposition. – Le chapitre 4 présente la spécification de notre proposition : SaGE (Système avancé de Gestion d’Exceptions) [SDUV03, SUVD03, SDUV04, SVUD04], un système de gestion d’exceptions dédié aux systèmes multi-agents et aux plates-formes à base de composants logiciels. Il couvre les problématiques et les besoins identifiés dans le chapitre précédent. Ce chapitre présente une vision générique de notre proposition pour la programmation orientée message. – Le chapitre 5 présente comment nous avons conçu SaGE puis comment nous l’avons implémenté dans deux plates-formes. Notre première expérimentation, dans le cadre des systèmes multi-agents, a été implémentée [SDUV03, SDUV04, SVUD04] pour la plate-forme SMA MADKit (Multi-Agent Development Kit) [vD04]. Puis, nous présentons notre expérimentation, dans le cadre des plates-formes à base de composants logiciels [SUVD03], pour la plate-forme JOnAS [JOn04] (Java Open Application Server) , une plate-forme libre implémentant les EJB (Enterprise JavaBeans) de J2EE (Java2 Enterprise Edition) [Sun04a, Sun03]. – Enfin, le chapitre 6 conclut ce mémoire en établissant un bilan des contributions apportées et en présentant des perspectives pour ces travaux.
16
Chapitre 2
Contexte d’étude : les programmations par agents et par composants Sommaire 1
2
3
4
5
Les middlewares : une solution aux limites de la programmation distribuée classique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
1.1
Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
1.2
Les modes de communication dans les applications . . . . . . . . . . . . .
21
Concurrence et asynchronisme . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.1
Possibilité de définir des activités concurrentes . . . . . . . . . . . . . . .
23
2.2
Coordination des activités concurrentes . . . . . . . . . . . . . . . . . . .
25
Les Systèmes Multi-Agents, un exemple typique de la programmation orientée message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.1
Introduction et définitions . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.2
Les “sociétés“ d’agents . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.3
L’exemple des agences de voyage dans un système multi-agents : choix de modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
Les plates-formes à base de composants logiciels . . . . . . . . . . . . . . . . .
31
4.1
Introduction et définitions . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.2
Typologie des modes d’interaction . . . . . . . . . . . . . . . . . . . . . .
34
4.3
L’exemple des agences de voyage dans une plate-forme à base de composants logiciels : choix de modélisation . . . . . . . . . . . . . . . . . . . .
42
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
Les systèmes multi-agents et les plates-formes à base de composants logiciels prennent une place grandissante dans le monde des systèmes distribués grâce au niveau d’abstraction qu’ils offrent (possibilités de communiquer entre systèmes hétérogènes, abstraction de la distribution et réutilisabilité). 17
CHAPITRE 2. CONTEXTE D’ÉTUDE : LES PROGRAMMATIONS PAR AGENTS ET PAR COMPOSANTS En effet, l’augmentation de la taille du code des logiciels, le besoin de fiabilité et la volonté de diminuer les coûts ont contribué à orienter la pratique industrielle et la recherche en génie logiciel vers la spécification d’entités logicielles de plus en plus réutilisables : les librairies puis les objets et, de nos jours, les agents et composants logiciels [Woo02, WC99, Szy98].
1 Les middlewares : une solution aux limites de la programmation distribuée classique 1.1 Définition Dans les systèmes multi-agents comme dans les plates-formes à composants logiciels, les entités logicielles entrant en jeu (instances de classes, agents, composants, applications. . . ) communiquent par l’intermédiaire d’une couche logicielle commune : l’intergiciel ou middleware. Définition : Le terme middleware désigne le bus de communication qui s’interpose entre les couches du système d’exploitation et celles des logiciels qu’il exécute (cf. figure 2.1). Le middleware assure les communications entre applications (éventuellement distantes) en faisant abstraction de l’hétérogénéité des systèmes impliqués en termes d’architecture physique des processeurs, de système d’exploitation, de langage de programmation utilisé et de représentation des données [WSPK01, Hal00, Pes00].
F IG . 2.1 – Place du middleware dans les couches logicielles Les entreprises exploitent de multiples applications qui ont été construites indépendamment en utilisant divers langages et diverses plates-formes. Ces applications ont toutefois besoin d’échanger des données et des services. Pour ce faire, les transferts de fichiers et les bases de données partagées sont exploités mais ces solutions restent souvent insuffisantes. En effet, les modifications de données peuvent nécessiter que des opérations de maintien de la cohérence des données soient exécutées dans plusieurs applications concernées. Il faut alors un mécanisme permettant à une application d’invoquer une fonctionnalité d’une autre application en lui communiquant l’identifiant ou la description de la fonctionnalité souhaitée et les valeurs et paramètres correspondants. De plus, dans la mesure où les 18
1. LES MIDDLEWARES : UNE SOLUTION AUX LIMITES DE LA PROGRAMMATION DISTRIBUÉE CLASSIQUE applications en interaction peuvent ne pas être exécutées sur la même machine, le mécanisme d’invocation de méthodes doit offrir l’abstraction de la distribution des applications impliquées. C’est ce que permettent, par exemple, les mécanismes de Remote Procedure Call (RPC). Avec de tels mécanismes, les applications peuvent fournir de multiples interfaces pour une même fonctionnalité afin de permettre l’interopérabilité avec des clients hétérogènes et éventuellement distants. Par exemple, la solution Java RMI (Remote Method Invocation) [Gro01] de Sun pour l’invocation distante de méthodes Java est incluse par défaut dans J2SE (Java2 Standard Edition) [Sun04b] depuis sa version 1.1. RMI est un mécanisme de RPC (Remote Procedure Call) dédié aux objets Java, dans le cadre duquel des interfaces spécifiques, appelées interfaces distantes, définissent les fonctionnalités des objets accessibles à des objets distants. Pour masquer les sérialisation/désérialisation 1 (marshalling/unmarshalling) des données transportées et les communications distantes, RMI génère, pour chaque interface distante définie, une classe souche (stub) côté client et une classe squelette (skeleton) côté serveur comme présenté en figure 2.2. Dans cette dernière, on observe le déroulement d’une invocation de méthode distante au travers de RMI. Un client récupère auprès du serveur de nommage RMI correspondant une référence vers un objet représentant (proxy) l’objet distant avec lequel on souhaite interagir (1-2). Cet objet représentant est une instance de la classe souche correspondant au type (interface distante) de l’objet distant. L’invocation d’une méthode de l’objet représentant génère un message de requête contenant le nom de la méthode invoquée et la valeur des paramètres d’appel (sérialisation). Cette requête est transmise, côté serveur, à une instance de la classe squelette correspondante (3) qui est capable d’extraire du message le nom de la méthode invoquée ainsi que la valeur des paramètres d’appel (désérialisation). L’instance de la classe squelette délègue alors l’exécution de la méthode à l’objet distant auquel elle est associée (4). Elle récupère alors la valeur de retour ou l’exception générée par l’exécution de la méthode invoquée et sérialise cette réponse pour la transmettre à l’objet client qui la récupère par l’intermédiaire de la classe souche utilisée (5-6). Avec RMI : – Les paramètres de types simples (int, float, . . .) sont transmis par copie, – Les paramètres de type objet non défini par une interface distante sont sérialisés et transmis par copie, – Les paramètres de type objet distant sont transmis par référence. Un middleware doit reposer sur des standards communs pour garantir l’interopérabilité des applications en interaction. A titre d’exemple, CORBA (Common Object Request Broker Architecture) [Sie00], défini par l’OMG (Object Management Group) [otOMG] est un middleware de communication multi-systèmes d’exploitation et multi-langages qui offre, grâce au langage IDL 2 (on retrouve 1
La sérialisation est un mécanisme qui permet de représenter un objet à envoyer comme paramètre dans le cadre d’une invocation de méthode distante sous une forme transportable (chaîne de bytes) pour le middleware utilisé. La désérialisation est le mécanisme inverse qui permet de reconstruire, à partir des données transmises par le middleware, une copie locale de l’objet attendu. 2 Interface Definition Language, qui est exploitable dans tout langage de programmation offrant une connectivité au bus logiciel CORBA.
19
CHAPITRE 2. CONTEXTE D’ÉTUDE : LES PROGRAMMATIONS PAR AGENTS ET PAR COMPOSANTS
F IG . 2.2 – Description d’une invocation de méthode distante avec RMI les mêmes qualité avec RMI) : – La transparence de localisation et d’accès : possibilité d’utiliser des objets indépendamment de leur localisation grâce à des représentations par proxy des objets distants. Le programmeur peut alors exploiter les méthodes des objets distants comme si ces derniers étaient locaux en exploitant les ORBs (Object Request Broker) disponibles sur le bus CORBA comme présenté en figure 2.3. – La séparation des interfaces et des implémentations : les clients sont définis uniquement en fonction des interfaces IDL mises à disposition du middleware et non pas en fonction des implémentations de la couche applicative. On assure ainsi l’interopérabilité entre, par exemple, des éléments d’applications développés séparément.
F IG . 2.3 – Représentation simplifiée du bus CORBA 20
1. LES MIDDLEWARES : UNE SOLUTION AUX LIMITES DE LA PROGRAMMATION DISTRIBUÉE CLASSIQUE De tels systèmes assurent une totale transparence de la distribution sans pour autant assurer l’interopérabilité de manière systématique. Par exemple, si CORBA [Sie00] autorise les interactions entre entités logicielles développées dans des langages différents, ce n’est pas le cas de RMI qui ne concerne que Java. La transparence de la distribution étant assurée par l’ensemble des middlewares, nous ne prendrons plus en compte la problématique de la distribution des applications dans la suite de ce mémoire.
1.2 Les modes de communication dans les applications Les middlewares, en fonction de leur spécification, permettent des communications entre entités logicielles synchrones, ou asynchrones (ou les deux modes de communication). Définition : on parle de communication synchrone entre entités logicielles quand, suite à l’envoi d’un message par une entité logicielle A, son exécution est bloquée jusqu’à ce que l’entité logicielle destinataire B ait fini de traiter le message avec un éventuel renvoi de réponse (cf. Figure 2.4). Ce mode de communication n’induit pas de concurrence et on le trouve dans les langages les plus courants comme Java et C++. Client
Entité logicielle exécutable
Server Invocation
Communication Exécution de code
Retour
Attente du retour
F IG . 2.4 – Communication synchrone entre un client et un serveur Bien qu’un mécanisme de type RPC abstraie la distribution, les accès distants par ce biais sont plus lents et moins fiables que s’ils étaient réellement locaux. Or, quand de multiples applications d’une entreprise communiquent, il n’est pas souhaitable que la défaillance de l’une d’entre elles paralyse tout le système. Pour assurer fiabilité, performance et évolutivité, il est donc nécessaire d’assurer un fort découplage entre applications distribuées. Les mécanismes de messagerie asynchrone sont alors une solution pragmatique à ce problème. Définition : on parle de communication asynchrone entre deux entités logicielles quand l’envoi d’un message ne bloque pas l’exécution de son émetteur pendant qu’il est traité par son destinataire [JS96, YBS86, YT87, Car93]. Dans les middlewares, la communication asynchrone est qualifiée d’interaction par messagerie ou de programmation orientée message (MOM : Message-Oriented Middleware) comme présenté en figures 21
CHAPITRE 2. CONTEXTE D’ÉTUDE : LES PROGRAMMATIONS PAR AGENTS ET PAR COMPOSANTS Client
Server Entité logicielle exécutable
Message
Communication Exécution de code
F IG . 2.5 – Communication asynchrone entre un client et un serveur 2.5 et 2.7. Ce mécanisme induit de la concurrence dans les systèmes qui l’utilisent car l’émetteur d’un message poursuit son exécution pendant que ce dernier est traité par son destinataire. Cette pratique permet par ailleurs de découpler les entités logicielles. En effet, dans la mesure où les communications asynchrones ne nécessitent pas d’édition de liens à la compilation, la phase de développement des entités logicielles et la phase de leur intégration pour produire une application sont indépendantes [Sun02]. Le principal biais induit par l’utilisation de communications asynchrones est que les tâches de tests et de corrections deviennent plus fastidieuses qu’avec des applications qui s’exécutent séquentiellement et que le programmeur peut faire face à des problèmes de nondéterminisme [CHS04]. Par exemple, pour debugguer une application codée en C++, le développeur a accès à la pile d’exécution qui représente l’état global de l’exécution alors que cet outil n’existe pas si on utilise un MOM. Même dans le cadre de communications asynchrones, il se peut que le programmeur souhaite définir des interactions dans lesquelles une entité logicielle émet une demande pour laquelle elle attend une réponse, à l’image des valeurs de retour des méthodes. On parle alors de communication semisynchrone. Dans ce contexte, une fois que le point d’exécution au niveau duquel l’émetteur d’une demande a besoin de la réponse est atteint, un mécanisme de “futur” [BBP86, LAB +78, Lis88] est utilisé pour interrompre l’exécution de l’émetteur jusqu’à ce que la réponse nécessaire à la poursuite de son exécution soit obtenue. Définition : On parle de futur explicite quand, pour interrompre l’exécution d’une entité logicielle qui a émis une requête de manière asynchrone jusqu’à réception de la réponse correspondante, une fonction d’attente dédiée est utilisée. On peut prendre l’exemple de la fonction d’attente “touch” de Multilisp [HL85] (cf. section 3.2.1 du chapitre 3 et figure 3.9). Définition : On parle de futur implicite quand, pour interrompre l’exécution d’une entité logicielle qui a émis une requête de manière asynchrone jusqu’à réception de la réponse correspondante. Par exemple, un mécanisme de synchronisation transparent peut être mis en œuvre lors de la tentative d’accès à la valeur de la réponse correspondante. 22
2. CONCURRENCE ET ASYNCHRONISME Dans tout les cas, l’utilisation de communications asynchrones permet d’introduire de la concurrence car l’émetteur d’un message peut poursuivre son exécution parallèlement à celle du traitement de ce message par son destinataire. Dans certains MOMs [DF94, FG98, vD04, Sun03], un message peut-être envoyé non seulement à une entité destinataire unique, mais aussi à un groupe d’entités destinataires 3 . Dans ce dernier cas, on parle de diffusion groupée (broadcasting) et le message émis de la sorte est diffusé de manière transparente à l’ensemble des entités membres du groupe destinataire. Il est par ailleurs possible que l’émetteur d’un tel message ne connaisse ni l’identité ni le nombre de ces derniers. Si le message émis est une requête, on parle alors de requête groupée.
2 Concurrence et asynchronisme 2.1 Possibilité de définir des activités concurrentes Les paradigmes de programmation que nous étudions permettent : – des accès concurrents à des entités partagés (le code d’une entité pourra être exécuté concurremment par plusieurs threads d’exécution), – d’utiliser des communications asynchrones (qui permettent à une entité active de poursuivre son exécution pendant que d’autres traitent des requêtes qu’elle leur a soumises), – d’exécuter des traitements concurrents au sein d’une même entité logicielle active (une entité active peut en effet se voir affecter la gestion de plusieurs threads d’exécution). Ces possibilités offrent des opportunités pour le développement d’applications dans lesquelles il s’avère souhaitable d’exécuter des traitements concurremment. La concurrence permet le développement d’applications plus évoluées. Elle peut en effet : – offrir un gain en terme de temps d’exécution en exploitant parallèlement plusieurs ressources de calcul, – permettre la définition de politiques de traitement des réponses plus évoluées, – rendre le système plus réactif (disponibilité) que dans une application purement séquentielle. On peut illustrer ces faits en prenant l’exemple d’une application que nous réutiliserons tout au long de ce mémoire : un logiciel de réservation pour agences de voyages. En voici une présentation générique qui fait abstraction du paradigme utilisé. Dans cette application, trois types d’entités entrent en jeu : une agence de voyages qui travaille en relation avec un ensemble de prestataires pour répondre aux demandes émises par des clients. Voici un scénario d’exécution classique (cf. Figure 2.6) : Un client demande un billet d’avion à l’agence de voyage (1) qui demande alors leurs tarifs aux prestataires de service avec lesquels elle travaille (2-3). Elle sélectionne ensuite le prestataire le plus 3
On peut rapprocher cette vision de la notion de groupes d’objets (Object Groups) [PJA01].
23
CHAPITRE 2. CONTEXTE D’ÉTUDE : LES PROGRAMMATIONS PAR AGENTS ET PAR COMPOSANTS économique pour communiquer son identité et son tarif au client demandeur (4) et avertit le prestataire retenu qu’il doit préparer un contrat (5). Enfin le client demandeur entre en contact avec le prestataire sélectionné pour valider le contrat (6).
F IG . 2.6 – Un exemple de commande de billet auprès d’une agence de voyage Si l’on s’intéresse à une application de la concurrence dans un tel exemple, il est souhaitable que l’agence de voyage puisse envoyer concurremment les demandes de tarifs auprès des prestataires qu’elle connaît. Tout d’abord, sur le plan du temps d’exécution, le gain est évident car : – Si les communications étaient synchrones, il faudrait que l’agence de voyage attende, pour chaque prestataire, qu’il traite la demande et retourne sa réponse. Dans ce cas, le temps de réponse global est la somme des temps de réponse individuels des prestataires (t =
Pn
i=0 ti ).
– Si l’agence de voyage communique avec les prestataires par des communications asynchrones, les ressources des prestataires seront exploitées concurremment. Dans ce cas, le temps de réponse global est théoriquement celui du prestataire qui met le plus de temps à répondre (t = maxni=0 ti ). D’autre part, le programmeur se voit pourvu d’un pouvoir d’expression plus complet qu’en programmation séquentielle car il va pouvoir définir des comportements spécifiques pour le traitement des réponses reçues. Si on reprend l’exemple des demandes de tarifs émises par l’agence de voyages auprès des prestataires de service, on peut imaginer des comportements spécifiques comme : “Attendre les réponses des prestataires dans la limite d’un délai donné“ ou “Se contenter des réponses déjà reçues une fois un niveau de représentativité ou de qualité de service (QoS) donné atteint” [Hal00, HHRS01, WSPK01, XNVW00]. Ce genre de politique peut être défini, par exemple, à des 24
2. CONCURRENCE ET ASYNCHRONISME fins d’optimisation en termes de temps ou de trafic réseau. Enfin, la concurrence peut apporter un gain en termes de réactivité et de disponibilité car elle peut être exploitée pour permettre à une entité logicielle de traiter concurremment plusieurs requêtes. Par exemple, l’agence de voyage doit pouvoir traiter concurremment plusieurs requêtes émises par des clients afin de répondre plus rapidement à ces derniers. En effet, si l’agence de voyage traitait les requêtes des clients séquentiellement, du temps d’exécution serait perdu, entre les traitements de chaque requête émise par un client, durant la phase d’attente des réponses des prestataires.
2.2 Coordination des activités concurrentes La programmation de systèmes concurrents a toujours posé le problème de la coordination (souvent appelée synchronisation) des processus concurrents [BBP86, JS96, Lac90, Lis88] pour assurer, par exemple, la cohérence des données, la possibilité d’exploiter des mécanismes transactionnels ou même pour optimiser l’exploitation de ressources. Dans [RK01], A LEXANDER ROMANOVSKY et J ÖRG K IENZLE proposent une classification qui distingue trois types de gestions de la concurrence qui peuvent être mis en place dans des systèmes orientés-objets. Dans ce contexte, processus et objets sont orthogonaux : Les objets sont vus comme des entités passives dont le code est exécuté par des processus qui leurs sont extérieurs. – Tout d’abord, la concurrence disjointe désigne le type de concurrence que l’on trouve dans les systèmes n’offrant pas d’outils pour coordonner les activités concurrentes. Il est alors difficile de garantir, par exemple, la cohérence des objets partagés. – Ensuite, la concurrence compétitive désigne le type de concurrence que l’on trouve dans les systèmes gérant l’isolation des entités actives (les processus dans le contexte des systèmes à objets ou les agents dans le cadre d’un système multi-agent). Ces systèmes fournissent des mécanismes permettant d’éviter les incohérences dues à l’usage concurrent de ressources partagées. Ce type de gestion de la concurrence est mis en place grâce à des mécanismes de verrous [BCF+ 97] qui permettent de garantir l’isolation (c’est-à-dire l’indépendance) d’opérations travaillant sur les mêmes données. – Enfin, la concurrence coopérative désigne la gestion de la concurrence par les systèmes qui permettent la gestion de la collaboration entre entités actives. Il s’agit alors de coordonner des activités concurrentes qui contribuent à une même activité collective. En particulier, gérer la concurrence coopérative requiert un modèle d’exécution qui autorise la représentation explicite des activités collectives et donc de l’imbrication des activités pour pouvoir gérer les contextes de ces collaborations : Pour chaque activité, il doit être possible de connaître l’activité qui l’a sollicitée et les activités qu’elle a requises. Cette pratique permet la définition d’outils de synchronisation des activités pour, par exemple, interrompre l’ensemble des activités qui ont été directement ou indirectement sollicitées par une activité dont l’exécution est interrompue. 25
CHAPITRE 2. CONTEXTE D’ÉTUDE : LES PROGRAMMATIONS PAR AGENTS ET PAR COMPOSANTS Les auteurs de cette classification soulignent la possibilité de combiner les concurrences compétitive et coopérative. En fonction du niveau de contrôle de la concurrence souhaité, il convient de mettre en place un modèle d’exécution adéquat. L’introduction de la concurrence induit donc la prise en compte de problématiques qui vont affecter, en fonction du niveau de contrôle des activités concurrentes désiré, le modèle d’exécution de la plate-forme utilisée. Afin de pouvoir spécifier des systèmes gérant à la fois les modes de concurrence coopératif et compétitif, le concept de CA Actions (Coordinated Atomic Actions) a été introduit dans [XRR + 95]. Ces dernières définissent une structuration coopérative des exécutions concurrentes intégrant et étendant les concepts complémentaires d’action (pour gérer la concurrence coopérative) et de transaction atomique (pour gérer la concurrence compétitive en maintenant la cohérence des ressources partagées) [WX95, Vac00, GRRV04]. Une CA action est définie comme une multi-procédure dans laquelle chaque participant remplit un rôle. Les rôles d’une même CA action coopèrent les uns avec les autres et les CA Actions peuvent être imbriquées. Les objets partagés peuvent être utilisés concurremment par plusieurs CA actions (concurrence compétitive) de telle manière que toute séquence d’opérations sur ces objets entre le début et la fin d’une CA action vérifie les propriétés ACID [BCF + 97] en respectant les autres séquences d’opérations [RK00]. Ainsi, l’exécution d’une CA action est vue comme une transaction atomique. Par ailleurs, les participants d’une CA Action coopèrent en accédant à des objets locaux à la CA Action correspondante (concurrence coopérative). Après avoir vu ces généralités sur les nouveaux paradigmes de programmation, nous allons voir plus en détail les spécificités concernant les systèmes multi-agents puis les plates-formes à base de composants logiciels.
3 Les Systèmes Multi-Agents, un exemple typique de la programmation orientée message 3.1 Introduction et définitions Définition : Un agent est une entité réelle ou virtuelle, évoluant dans un environnement, capable de le percevoir et d’agir sur celui-ci. Un agent peut communiquer avec d’autres agents et adopte un comportement autonome défini par ses connaissances, ses interactions avec d’autres agents et les buts qu’il poursuit. Une entité est donc un agent à partir du moment où elle est capable d’exercer un contrôle sur ses processus de perception, de communication, d’acquisition de connaissances, de raisonnement, de prise de décision ou d’exécution [Fer95, Woo02]. Nous nous intéressons dans cette thèse au cas particulier des agents logiciels que nous appellerons par la suite simplement agents. Par ailleurs, nous ne considérons dans cette thèse les agents que comme des éléments logiciels en mettant de côté les aspects cognitifs (émergence, intelligence, . . .) et sociaux (normes, . . .).
26
3. LES SYSTÈMES MULTI-AGENTS, UN EXEMPLE TYPIQUE DE LA PROGRAMMATION ORIENTÉE MESSAGE
Définition : Un agent logiciel est une entité logicielle mue par un ensemble d’objectifs propres, qui s’exécute à l’aide de ses ressources propres dans un système informatique ouvert (ensemble d’applications, de réseaux et de systèmes hétérogènes) et qui peut communiquer avec d’autres agents en leur envoyant des messages de manière asynchrone (programmation orientée message). Un agent peut offrir un ensemble de services aux autres agents et adopte un comportement tendant à satisfaire ses objectifs propres en prenant en compte les ressources et compétences dont il dispose, les messages qu’il reçoit et sa perception de l’environnement. Un agent ne dispose en général que d’une représentation partielle et locale de son environnement (autres agents, ressources disponibles dans son environnement. . .). La principale caractéristique qui distingue les agents des autres formes d’entités logicielles est leur autonomie [WC99] : – Un agent a en effet la capacité de décider indépendamment d’entreprendre une activité (dans la limite de ses capacités) afin d’atteindre un objectif individuel, – Les agents disposent de leur(s) propre(s) flot(s) d’exécution (threads), – Les agents communiquent de manière asynchrone, – Les agents sont autonomes mais pas isolés pour autant : Ils interagissent en s’échangeant des messages de manière asynchrone et sont donc capables de collaborer tout en préservant leur autonomie. – Pour un agent, la réception d’un message n’est pas pré-emptive : Lors de la réception d’un message, un agent peut décider d’en reporter le traitement afin d’effectuer préalablement des activités plus urgentes. Un agent est donc capable de s’affecter lui-même des priorités. Dans la mesure où l’arrivée d’un message dans la boîte aux lettres d’un agent ne déclenche pas directement le traitement correspondant (il est stocké dans la boîte aux lettres de l’agent destinataire qui retirera le message à un moment dépendant de la définition de son comportement), on parle de mécanisme Pull ou de consommation asynchrone des messages (cf. figure 2.7).
F IG . 2.7 – Envoi asynchrone d’un message à destination d’une boîte aux lettres
27
CHAPITRE 2. CONTEXTE D’ÉTUDE : LES PROGRAMMATIONS PAR AGENTS ET PAR COMPOSANTS
Définition : On appelle système multi-agents (SMA) un ensemble d’agents qui agissent (et interagissent) dans un environnement commun pour y coopérer, collaborer (assignation de tâches), négocier (résolution de conflits) et se coordonner (synchronisation). Dans un SMA, les activités individuelles des agents font tendre le système vers un comportement global qui n’est défini par aucun agent ou règle globale : On parle d’émergence de comportement. Lors de la conception d’un SMA, il s’agit de définir des comportements individuels faisant émerger des comportements globaux qui feront converger le système vers l’objectif global de l’application. De nombreuses expérimentations sont généralement nécessaires avant de définir les comportements individuels qui font émerger le comportement global souhaité car un comportement émergent est difficilement prévisible. Pour assurer une meilleure interopérabilité, la Fondation pour les Agents Physiques Intelligents (FIPA) [FIP00] fournit des standards permettant l’interaction d’agents exécutés dans des systèmes multi-agents hétérogènes. Ces standards fournissent par exemple des types de messages standardisés qui permettront à des agents développées séparément d’interagir. On peut donc voir ces spécifications comme un outil d’interopérabilité pour les middlewares dédiés aux SMA. Un système multi-agents peut se voir attribuer divers qualificatifs comme [Fer95] : Ouvert : les agents y entrent et en sortent librement (un bar ou une application de commerce électronique peuvent donc être perçus comme des SMA), Fermé : l’ensemble d’agents reste le même (un match de football, un système multi-experts), Homogène : tous les agents sont construits sur le même modèle (des agents jouant le rôle de clients de dialogue en direct), Hétérogène : des agents de modèles différents, de granularités différentes (un éco-système). La conception d’un système multi-agents impose une vision à la fois locale et décentralisée : – Une vision locale car chaque agent est responsable de ses connaissances (encapsulation) et de ses actions (autonomie), mais également de ses interactions avec d’autres agents. Aucun agent n’a de vue globale du SMA tout entier. – Une vision décentralisée car il ne doit pas y avoir de contrôle central dans un SMA. Les tâches à réaliser et les compétences pour le faire sont distribuées sur les agents.
3.2 Les “sociétés“ d’agents Généralement l’application des systèmes multi-agents à la simulation de phénomènes sociaux est associée au courant sociologique dit de l’individualisme qui considère l’individu singulier comme l’unité élémentaire, comme l’atome de la société [DF94]. Cependant, l’assimilation des individus et des agents peut être trompeuse : il est tout à fait possible de considérer comme agents des groupes 28
3. LES SYSTÈMES MULTI-AGENTS, UN EXEMPLE TYPIQUE DE LA PROGRAMMATION ORIENTÉE MESSAGE sociaux ou des institutions données, avec leurs règles de fonctionnement, leurs normes. Les agents sont donc conduits par des contraintes et des règles exprimées au niveau des groupes sociaux auxquels ils appartiennent. Dans cet esprit, afin de permettre la représentation et la gestion de comportements collectifs, les systèmes multi-agents sont souvent organisés en sociétés d’agents. Par exemple, dans la plateforme multi-agents MADKit [vD04], c’est le modèle organisationnel AALAADIN [FG98] aussi appelé modèle Agent/Groupe/Rôle (AGR) qui est utilisé. Le modèle AALAADIN est basé sur trois concepts : l’agent, le groupe et le rôle (cf. Figure 2.8). Dans ce modèle, aucune contrainte ou pré-requis sur l’architecture interne de l’agent n’est posé et aucun formalisme ou modèle particulier pour en décrire le comportement n’est pré-supposé.
F IG . 2.8 – Le modèle Agent-Groupe-Rôle – L’agent est simplement décrit comme une entité autonome communiquante. La très faible sémantique associée à l’agent dans ce modèle permet de laisser la définition d’agent en retrait et ainsi offrir au concepteur toute liberté pour choisir l’architecture interne appropriée à son domaine applicatif. – Un groupe est un regroupement d’agents. – Chaque agent peut être membre d’un ou plusieurs groupes. – Le groupe peut être vu comme un SMA usuel car seuls les agents appartenant à un même groupe peuvent communiquer entre eux. – Dans AALAADIN, les différents groupes peuvent se recouper librement. Ainsi, pour que deux groupes d’agents puissent interagir, il suffit qu’ils aient un ou plusieurs agent(s) en commun pour servir de passerelle entre groupes. – Le rôle est une représentation abstraite d’une fonction, d’une offre de service ou d’une identification d’un agent au sein d’un groupe particulier. – Chaque agent peut avoir plusieurs rôles. – Un même rôle peut être tenu par plusieurs agents. – Les rôles sont locaux aux groupes. 29
CHAPITRE 2. CONTEXTE D’ÉTUDE : LES PROGRAMMATIONS PAR AGENTS ET PAR COMPOSANTS La notion de rôle peut être exploitée pour gérer la diffusion groupée de messages (cf. section 1.2) : la plate-forme MADKit offre la possibilité de diffuser, par un envoi de message unique, un message auprès de tous les agents jouant un rôle donné sans que l’émetteur n’ait besoin de connaître l’identité ou le nombre des agents destinataires. Bien que d’autres modèles organisationnels comme Moise [HSB02], Moca [AMBN02] ou Gaia [WJK00] existent, AALAADIN est le seul que nous aborderons dans ce mémoire car : – Il est, à l’image de la plate-forme MADKit, générique tout en étant représentatif de l’existant, – Il permet d’établir des parallèles avec les organisations que l’on observe généralement dans les plates-formes à base de composants logiciels (cf. section 4.2.3).
3.3 L’exemple des agences de voyage dans un système multi-agents : choix de modélisation Du fait de leur autonomie, la coordination entre agents devra être définie localement à chaque agent. Par exemple, le programmeur devra définir dans l’agent représentant l’agence de voyages : – la gestion de l’émission des requêtes auprès des prestataires, – l’attente et le traitement des réponses correspondantes qui pourront être reçues concurremment, – la gestion de la concurrence des traitements des requêtes de recherche de billet émises par différents clients. Pour exploiter cet exemple dans MADKit en utilisant le modèle Agent/Groupe/Rôle, on a, à l’état initial (cf. Figure 2.9(a)) : – Le(s) agents client(s) dans le groupe des clients, – Les agents prestataires dans le groupe des prestataires, – L’agent agence de voyage dans ces deux groupes. C’est donc cet agent qui joue le rôle de passerelle entre clients et prestataires. Pour répondre à la requête initiée par un client, l’agence de voyage se renseigne sur les conditions des différents prestataires puis, une fois qu’elle a déterminé quel prestataire était le moins coûteux, elle crée un groupe dédié à l’établissement du contrat (le groupe des contractants) et invite l’agent client et l’agent prestataire sélectionné à s’y rejoindre pour communiquer (cf. Figure 2.9(b)). D’autre part la notion de rôle peut être utile dans cet exemple pour effectuer les demandes de tarifs auprès des prestataires. On peut en effet utiliser la notion de rôle en attribuant à tout agent prestataire le rôle de fournisseur dans le groupe des prestataires. Ainsi, l’agence de voyage peut envoyer une unique requête groupée qui sera diffusée auprès de tous les agents du groupe des prestataires remplissant le rôle de fournisseur. Après avoir introduit quelques notions relatives au paradigme agent, nous présentons, dans la section suivante, celui des plates-formes à base de composants logiciels qui constitue le second champ d’application de notre étude. 30
4. LES PLATES-FORMES À BASE DE COMPOSANTS LOGICIELS
(a) Etat initial
(b) Etat final
F IG . 2.9 – Exploitation de la notion de groupe dans l’exemple de l’agence de voyages
4 Les plates-formes à base de composants logiciels 4.1 Introduction et définitions Face à l’accroissement des besoins en terme de réutilisabilité et de distribution des applications [LQ04], la programmation orientée-objets traditionnelle s’est avérée insuffisante dans la mesure où elle n’offre pas un niveau d’abstraction suffisant pour développer des application distribuées et réutilisables de manière transparente. La programmation orientée-objets permet l’encapsulation des variables et du code pour masquer l’implémentation et autorise l’utilisation des objets au travers d’interfaces. Si cette pratique fournit un niveau d’abstraction déjà important, la construction d’une application par la définition de classes impose l’ouverture et la connaissance d’une partie du code, que ce soit pour introduire des références vers d’autres objets, ou pour hériter d’autres classes. La programmation orientée-objets impose également la prise en charge non-automatisée d’un grand nombre de tâches comme certaines synchronisations entre processus et la gestion des références entre un nombre d’instances qui devient trop important avec l’augmentation de la taille des systèmes d’informations. Par exemple, des appels de méthodes explicites entre un grand nombre d’objets peuvent rendre le code d’une application difficilement compréhensible et donc difficile à entretenir et à réutiliser même s’il est bien documenté. On peut alors faire face à des situations dans lesquelles il est difficile de modifier le système pour, par exemple, faire évoluer les services système tout en maintenant la compatibilité avec les objets existants ou gérer l’assemblage et le déploiement de l’application. Il s’est donc avéré nécessaire de définir des architectures permettant d’une part de différencier l’aspect fonctionnel de l’aspect système et d’autre part de définir des entités logicielles fonctionnelles plus génériques. 31
CHAPITRE 2. CONTEXTE D’ÉTUDE : LES PROGRAMMATIONS PAR AGENTS ET PAR COMPOSANTS Les besoins en terme de réutilisabilité, d’interopérabilité et de l’usage de systèmes distribués ont constitué autant de motivations pour faire émerger la programmation “orientée-composants” qui consiste à construire des applications par assemblage d’entités existantes (les composants) et par la définition de connecteurs et d’architecture d’assemblage entre les composants [Hil99]. Ainsi, il est devenu possible pour des entités logicielles qui n’avaient aucune référence entre elles - voire qui ont été développées séparément - d’interagir en s’intégrant dans une même application. Définition : Un composant logiciel est une entité logicielle assez générique pour que l’on puisse l’intégrer dans différents environnements et contextes d’utilisation en le composant avec d’autres composants logiciels [Szy98]. Un composant logiciel : – Est doté d’interfaces standards pour pouvoir interopérer avec d’autres composants logiciels, – Doit pouvoir être déployé indépendamment de l’application pour laquelle il a été initialement conçu, – Doit pouvoir être réutilisé dans un autre contexte applicatif. Un composant logiciel est donc caractérisé par les propriétés et opérations qu’il expose et est partiellement configurable, par exemple, au travers d’un descripteur en Extensible Markup Language (XML) [WWWCW04]. Les connecteurs (ports, interfaces) d’un composant logiciel lui donnent la possibilité de s’auto-décrire (on parle d’introspection) car ils définissent l’ensemble des fonctionnalités que ce composant logiciel peut offrir. Chaque plate-forme a son propre modèle de composants mais l’objectif demeure commun : augmenter le niveau de réutilisabilité et de composabilité. Définition : Un conteneur est une entité qui encapsule des composants logiciels et constitue leur environnement d’exécution. La mise en place des composants logiciels dans les conteneurs d’un serveur d’applications est définie lors du déploiement de l’application. Les conteneurs de composants assurent à la fois la prise en charge et la transparence des services systèmes (sécurité, nommage, . . .) et les connexions entre composants en fournissant à ces derniers, au moment du déploiement (voir l’exemple de descripteur de déploiement présenté en figure 2.10), des adaptateurs qui leur permettront de s’interconnecter (avec d’autres composants). Ces conteneurs sont eux-mêmes accueillis par un serveur d’application qui joue, quant à lui, le rôle de médiateur entre les conteneurs et le middleware (cf. Figure 2.11). Ce découpage permet une séparation claire entre la partie applicative, c’est-à-dire le code encapsulé dans les composants logiciels et la configuration des services techniques non fonctionnels (conteneurs, serveurs, services systèmes. . .) qui ne font qu’assurer les interactions entre composants (messagerie, sécurité, . . .). Parallèlement, on observe une séparation des métiers dans la phase de développement qui va permettre, d’une part, aux développeurs de composants de ne se concentrer que sur la partie fonctionnelle par la définition du code et de l’interface des composants et, d’autre part, 32
4. LES PLATES-FORMES À BASE DE COMPOSANTS LOGICIELS < ?xml version="1.0" encoding="ISO-8859-1" ?> < !DOCTYPE ejb-jar PUBLIC "//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http ://java.sun.com/dtd/ejb-jar_2_0.dtd">
Deployment descriptor for the eb JOnAS example eb example Deployment descriptor for the AccountExpl bean JOnAS example AccountExpl eb.AccountHome eb.Account eb.AccountExplBean Bean java.lang.Integer jdbc/AccountExplDs javax.sql.DataSource Container Deployment descriptor for the AccountImpl bean JOnAS example AccountImpl eb.AccountHome eb.Account eb.AccountImplBean Container java.lang.Integer accno customer balance accno AccountExpl * AccountImpl *
F IG . 2.10 – Exemple de descripteur de déploiement XML d’un serveur J2EE
aux architectes (déployeurs) d’applications de définir comment les composants devront être interconnectés et comment les services correspondants devront être configurés. Les composants deviennent alors génériques et réutilisables dans la mesure où le découplage les rend exploitables non seulement dans diverses applications mais aussi dans diverses plates-formes et selon diverses méthodes de dé33
CHAPITRE 2. CONTEXTE D’ÉTUDE : LES PROGRAMMATIONS PAR AGENTS ET PAR COMPOSANTS
F IG . 2.11 – Structure d’une application construite à base de composants logiciels ploiement (cf. Figure 2.10). Ainsi, la réutilisation, la conception, le développement et la maintenance sont grandement facilités par le niveau d’abstraction offert par les modèles de composants qui sont d’ailleurs en train d’évoluer vers des niveaux encore plus élevés d’abstraction avec, par exemple, les démarches de conception dirigées par les modèles [Hil99, StOSSG00]. Les modèles de composants permettent divers types d’interactions entre ces derniers en fonction de la nature des connecteurs qui les relient. Nous allons présenter, dans la section suivante, les divers modes d’interactions entre composants que l’on peut observer dans les plates-formes existantes.
4.2 Typologie des modes d’interaction 4.2.1
Définitions
Définition : On parle d’interaction par requête/réponse quand l’interaction entre entités logicielles est définie, à l’image des invocations de méthodes, par l’émission d’une requête relativement à laquelle l’ entité émettrice attend une réponse. On parle aussi d’interaction de type client/serveur. Définition : Un contrat logiciel est un engagement établi entre une entité logicielle qui émet une requête et l’entité logicielle destinataire de la requête. Le destinataire d’une requête, s’il accepte de la satisfaire, s’engage à retourner une réponse à l’émetteur correspondant quoi qu’il arrive durant le traitement de la requête [Mey92]. L’utilisation de contrats logiciels constitue donc un moyen efficace pour définir des interactions de type requête/réponse. Dans le contexte des composants logiciels, le besoin d’établir de tels contrats se fait ressentir quand un composant attend une valeur de retour après l’invocation d’une fonctionnalité 34
4. LES PLATES-FORMES À BASE DE COMPOSANTS LOGICIELS ou quand il a besoin d’un accusé de réception. La notion de contrat logiciel a été clairement explicitée en 1985 dans le contexte du langage Eiffel [Wik05a] avec le dépot de la marque “Design by contract” [Wik05b] par Eiffel Software, Inc. Une autre approche radicalement différente existe : les interactions par émission d’informations. Définition : Une interaction par émission d’informations s’établit entre n composants source qui produit une information qui sera notifiée aux composants qui se sont déclarés comme consommateurs d’une telle information. La particularité de ce type d’interaction réside dans le fait que l’émetteur d’une information n’attend pas de réponse en retour à cette émission. Quand une entité logicielle active doit émettre une information, elle encapsule cette dernière dans un objet avant de le soumettre au middleware qui se charge de la diffuser au(x) entité(s) logicielle(s) destinataire(s). Ce mécanisme s’avère utile quand on souhaite tout simplement notifier un changement d’état. Par exemple, dans le contexte d’un système B2B (Business to Business), une application peut avoir à notifier un changement de tarif sur un produit à un ensemble d’entités le référençant. Par ailleurs, les composants interagissant par informations sont moins couplés et peuvent donc facilement être assemblés sans avoir été initialement conçus dans cette optique. Notons que l’assemblage ne garantit en rien que l’on observe des interactions. Au delà de la distinction du mode d’interaction par requête/réponse ou par information, il convient également de distinguer deux méthodes de diffusion des messages : Point-to-Point (point à point) et Publish/Subscribe (Publication/Souscription) : – La diffusion d’un message m en mode Point-to-Point (P2P) assure qu’un seul destinataire, connu de l’émetteur, recevra m. – La diffusion en mode Publish/Subscribe (Pub/Sub) correspond à la notion de Broadcasting que nous avons introduite en section 1.2. Dans ce contexte, un composant peut souscrire à un abonnement (en se définissant comme écouteur d’une catégorie d’informations donnée ou en s’abonnant à un canal de diffusion) et recevra alors tous les messages correspondants. Si un ensemble de composants est défini comme écouteur d’une catégorie d’informations donnée ou abonné à un même canal de diffusion, les messages correspondants seront traités par chacun des composants concernés. Par la suite, nous distinguerons donc les différentes catégories de composants suivant quatre critères (cf. Figure 2.21) : 1. Le mode d’interaction (requête/réponse ou émission d’informations), 2. Le mode de diffusion (point-to-point ou publish/subscribe), 3. Le type de communication (synchrone ou asynchrone), 35
CHAPITRE 2. CONTEXTE D’ÉTUDE : LES PROGRAMMATIONS PAR AGENTS ET PAR COMPOSANTS 4. et, dans le cas des communications asynchrones, le type de consommation de messages qui peut être lui-même synchrone (cf. section 4.2.2) ou asynchrone comme dans les SMA (cf. figure 2.14). 4.2.2
Interactions par requête/réponse et communications synchrones
Ce type de composant que nous noterons par la suite “composants RRS” 4 (cf. Figure 2.21) ne se différencie de la programmation orientée-objets que par la mise en relation entre composants qui n’est pas assurée par des références comme dans les langages à objets mais pas des connexions abstraites entre composants au travers du middleware utilisé (cf. section 1 et figure 2.12).
F IG . 2.12 – Communication synchrone entre composants RRS A titre d’exemple, les EJB de type Session et Entity Beans sont des composants RRS proposés dans les plates-formes à base de composants logiciels J2EE [Sun04a]. Ils communiquent au travers d’un middleware RMI ou CORBA qui assure, en toute transparence (cf. section 1 et figure 2.13), la communication entre composants distribués par des mécanismes de sérialisation, transport et désérialisation des messages aussi bien pour les requêtes que pour les réponses correspondantes. // Code d’un composant ou d’une application client(e) utx.begin() ; // Début d’une transaction t1.buy(10) ; // requête émise à destination d’un Session Bean utx.commit() ; // Validation de la transaction ... // Méthode distante invoquée sur le Session Bean public void buy(int s) { newtotal = newtotal + s ; }
F IG . 2.13 – Exemple d’invocation d’une méthode Java d’un Session Bean 4
RRS pour “Request/Response interactions using Synchronous communications”
36
4. LES PLATES-FORMES À BASE DE COMPOSANTS LOGICIELS 4.2.3
Interactions par requête/réponse et communications asynchrones
Ce type de composants que nous noterons par la suite “composants RRA” 5 (cf. Figure 2.21), utilise un MOM (cf. section 1.2) pour l’envoi de requêtes. Ces composants sont donc développés par programmation orientée message. L’émission d’une requête dans ce contexte étant asynchrone, l’émetteur poursuit son exécution jusqu’à ce qu’il ait besoin de la réponse correspondante (cf. Figure 2.14). Nous allons voir au travers des exemples présentés dans cette section les divers patrons existants pour récupérer les réponses aux requêtes émises de manière asynchrone.
F IG . 2.14 – Interaction de type requête/réponse et communication asynchrone entre composants RRA Dans les plates-formes J2EE, les échanges de messages en mode asynchrone sont assurés par le service JMS (Java Messaging Service). Tout composant défini comme un client JMS peut utiliser ce service. Un mécanisme d’accusé de réception des messages est fourni par JMS et ses clients peuvent d’ailleurs automatiser son usage. Dans JMS, les deux modes de diffusion sont disponibles : – Le mode Point-to-Point (P2P) qui utilise la notion de file de réception (Queue). Dans ce contexte, un client JMS peut envoyer un message à un composant qui possède une Queue (dans le contexte de J2EE il s’agit d’un Message Driven Bean (MDB) [Sun04a]). – Le mode Publish and Subscribe (Pub/Sub) qui utilise la notion de liste de diffusion (topic). Les Message Driven Beans peuvent s’inscrire à un ensemble de topics (à l’image de l’adhésion à un rôle dans le modèle Agent/Groupe/Rôle présenté en section 3.2 ou des Objects Groups [PJA01]). Les clients du service JMS peuvent publier des messages à destination d’un des topics. Un tel message sera reçu par tout Message Driven Bean y ayant souscrit. Dans le contexte de J2EE, quand un message à destination d’un Message Driven Bean arrive au niveau du conteneur correspondant, ce dernier instancie un thread dédié à son traitement. Ce thread exécute alors la méthode onMessage du Message Driven Bean destinataire avec le message reçu pour paramètre. Ainsi, plusieurs activités concurrentes peuvent être exécutées par un même Message Driven Bean puisque plusieurs threads peuvent exécuter simultanément son code. Dans la mesure où l’arrivée d’un message JMS déclenche directement le comportement correspondant sans passer par 5
RRA pour “Request/Response interactions using Asynchronous communications”.
37
CHAPITRE 2. CONTEXTE D’ÉTUDE : LES PROGRAMMATIONS PAR AGENTS ET PAR COMPOSANTS un mécanisme de boîte aux lettres, on parle de mécanisme Push ou de consommation synchrone des messages (cf. Figure 2.15).
F IG . 2.15 – Traitement d’un message JMS L’usage le plus classique des MDB pour le traitement de requêtes envoyées de manière asynchrone est l’exploitation du patron Service Activator [AMC01]. Un MDB implémentant ce patron traite les requêtes de clients reçues sous la forme de message JMS en localisant un objet métier implémentant le service correspondant et en lui déléguant l’exécution comme présenté en figure 2.16. L’objet métier activé peut, par exemple être un Session Bean. JMS fournit également une classe-outil QueueRequestor pour simplifier la gestion des interactions requêtes/réponses. Elle permet, lors de l’émission d’une requête via JMS, la création d’une file de réception temporaire (TemporaryQueue) pour recevoir la réponse correspondante (l’équivalent de ce mécanisme Point-to-Point existe pour le mode Publish/Subscribe grâce aux classes correspondantes TemporaryTopic et TopicRequestor). Ces outils présentent un travers majeur : Il n’y a plus d’asynchronisme car, avec ce mécanisme, l’exécution de l’émetteur est suspendue jusqu’à réception de la réponse. L’usage de communication asynchrones ne présente alors plus d’intérêt. Autre exemple, la technologie propriétaire .NET de Microsoft [Mic04] fournit un mécanisme de communication asynchrone avec futur implicite tel que celui présenté en figure 2.17. Il permet à un composant client (que nous appellerons C1) d’invoquer une méthode (que nous appellerons md) 38
4. LES PLATES-FORMES À BASE DE COMPOSANTS LOGICIELS
F IG . 2.16 – Diagramme de classes du patron ServiceActivator d’un composant distant de manière asynchrone 6 en associant à cette invocation une méthode locale (que nous appellerons ml) qui prend en paramètre une variable dont le type est le type de retour de md. Après cette invocation, C1 poursuit son exécution. Lorsque la réponse à l’invocation de md est reçue par le conteneur de C1, ml est invoquée avec cette réponse pour paramètre. Le programmeur qui souhaite utiliser ce mécanisme appelé callback doit donc gérer lui-même certaines étapes de la synchronisation. Par exemple, le programmeur devra utiliser des variables globales du composant pour tester, au point d’exécution où C1 à besoin de la réponse à l’invocation de md, si la réponse a bien été reçue et traitée par ml pour qu’elle soit à disposition.
F IG . 2.17 – Communication semi-synchrone entre un client et un serveur En dehors du contexte des composants logiciels, il est intéressant d’observer le patron proposé dans la première version de ProActive 7 (Java Parallel) [web99, CKV98] qui permet des invocations asynchrones de méthodes Java par la combinaison des mécanismes JMS, RMI et d’une synchronisation par futur implicite. Les appels asynchrones de méthodes (éventuellement distantes) sont réifiés afin de pouvoir les manipuler au travers de RMI. Par exemple, la figure 2.18 montre comment répartir 6 7
Dans la mesure où des méthodes sont invoquées, on ne peut plus parler d’un MOM. ProActive intègre maintenant un modèle de composants [BCM03].
39
CHAPITRE 2. CONTEXTE D’ÉTUDE : LES PROGRAMMATIONS PAR AGENTS ET PAR COMPOSANTS sur deux processeurs le produit d’une matrice m0 par un vecteur v0. Pour ce faire, on découpe la matrice m0 en deux sous-matrices m1 et m2 qui sont ensuite converties en objets actifs par la méthode turnActive de Java Parallel et associées chacune à un processeur différent. Ainsi, quand la méthode de produit matrice-vecteur rightProduct d’une matrice m1 ou m2 est invoquée, elle l’est de manière asynchrone à futur implicite : l’exécution de la méthode main est bloquée au point d’exécution où l’on accède aux sous -résultats v1 et v2 jusqu’à ce que ces derniers soient retournés. On a ainsi une méthode dans laquelle les deux sous-produits sont évalués chacun sur un processeur différent pour gagner du temps d’exécution. public static void main (String args[]) { int n = 1000 ; // Taille de la matrice carrée int m ; // Nombre de lignes à traiter localement Matrix m0, m1, m2 ; Vector v0, v1, v2, v3 ; // Code d’initialisation de m0 et v0 dont on veut calculer le produit [...] // Création des sous-matrices de taille m et n-m m1 = m0.getBlock (0, 0, m, n-1) ; m2 = m0.getBlock (m+1, 0, n-1, n-1) ; //On rend les objets actifs m1 = (Matrix) turnActive(m1, remoteNode) ; m2 = (Matrix) turnActive(m2, localNode) ; // Calcul des deux produits v1 = m1.rightProduct(v0) ; v2 = m2.rightProduct(v0) ; v3 = v1.concat(v2) ; // résultat }
F IG . 2.18 – Exemple de code Java Parallel
4.2.4
Interaction par soumission d’information
Nous appellerons par la suite les composants interagissant par soumission d’informations (par abus de langage, on parlera d’interactions par informations) de manière synchrone des “composants ES”8 et ceux interagissant de manière asynchrone des “composants EA” 9 (cf. Figure 2.21). Il y a peu de différences, pour le développeur, entre communications synchrones (cf. figure 2.19(a)) et asynchrones (cf. figure 2.19(b)) dans les interactions par informations si ce n’est que l’utilisation de 8 9
ES pour “Event-based interactions using Synchronous communications” EA pour “Event-based interactions using Asynchronous communications”
40
4. LES PLATES-FORMES À BASE DE COMPOSANTS LOGICIELS communications asynchrones peut permettre de rendre le système plus réactif et/ou plus rapide. Par exemple, si le fait de cliquer sur un bouton d’un composant ES entraîne le lancement d’un calcul long par un autre composant ES, l’utilisateur perd la main sur l’application jusqu’à ce que ce calcul soit terminé. Par contre, avec des composants EA, l’utilisateur pourra continuer à exploiter l’application parallèlement à ce calcul.
(a) communications synchrones
(b) communications asynchrones
F IG . 2.19 – Communication synchrone entre composants interagissant par événements
Les Message Driven Beans que nous avons présentés en section 4.2.3 comme des composants RRA peuvent aussi être utilisés comme composants EA : la seule différence étant que dans le cadre des composants EA, les composants récepteurs d’une information ne renvoient pas de réponse. Ils interagissent alors de manière plus simple comme on peut le voir en figure 2.19(b). Sun propose aussi un modèle de composants ES (en dehors du contexte de J2EE) : les JavaBeans [Sun02]. Ces composants sont souvent utilisés dans des environnements de développement visuels dans lesquels le programmeur dispose de composants (parfois pourvus d’une représentation graphique) qu’il relie en connectant les composants producteurs d’événements à des composants consommateurs d’événements. Par exemple, “Le composant Animation_10 écoute l’événement pression que peut émettre le composant bouton_1. Si cet événement est perçu, invoquer la méthode m() de Animation_10.”. On notera toutefois que les JavaBeans de l’interface graphique (boutons, . . .) sont des composants EA. Dans ce contexte, on programme donc en indiquant les actions que doivent exécuter les entités définis comme écouteurs d’un type d’événement lorsque un tel événement survient lors de l’éxécution de l’application (cf. figure 2.20). Les composants logiciels peuvent donc être de natures très différentes au regard des critères évoqués dans cette section. Pour conclure, la figure 2.21 présente un récapitulatif de la classification que nous proposons. 41
CHAPITRE 2. CONTEXTE D’ÉTUDE : LES PROGRAMMATIONS PAR AGENTS ET PAR COMPOSANTS
F IG . 2.20 – Un événement déclenche l’exécution de comportements
4.3 L’exemple des agences de voyage dans une plate-forme à base de composants logiciels : choix de modélisation L’exemple des agences de voyages nécessite l’utilisation d’interactions de type requête/réponse et non par information. Deux implémentations sont possibles : on peut choisir une implémentation purement séquentielle avec des composants RRS comme les Entity et Session Beans ou induire de la concurrence à des fins d’optimisation (cf. section 2.1) avec des composants RRA comme les Message Driven Beans. Le cas séquentiel ne posant pas de difficultés en terme de définition des interactions entre composants logiciels, nous nous intéresserons ici à l’utilisation de composants communiquant de manière asynchrone. Plusieurs politiques sont envisageables : – soit l’émetteur ira consulter (en boucle jusqu’à satisfaction : mécanisme pull) une ressource partagée dans lequel le composant serveur est censé donner sa réponse une fois le traitement achevé comme présenté dans la figure 2.14. Cette technique de futur explicite permise, par exemple, par l’usage des Message Driven Beans peut poser de nombreux problèmes comme l’accès à des fichiers ou objets distants. – soit on utilise un mécanisme de callbacks comme dans la plate-forme .NET (cf. section 4.2.3 : mécanisme push). Les réponses ne sont pas reçues, et a fortiori pas traitées, dans la méthode qui a émis la requête correspondante. Il est alors nécessaire d’utiliser des variables globales du composant pour pouvoir exploiter ces résultats. – soit on attend la réponse sous la forme d’un message. Dans ce cas, chaque réception d’un message implique la création d’un processus dédié à sa gestion. On fait alors face au même problème qu’en utilisant le mécanisme des callbacks : il faut gérer le fait que les réponses sont traitées en dehors de la méthode dans laquelle la requête correspondante a été émise. 42
5. CONCLUSION
5 Conclusion Bien que basés sur des paradigmes différents, agents et composants logiciels partagent des propriétés. En effet, dans les deux cas, les communications reposent sur un middleware et l’on peut facilement voir les agents comme des composants communiquant de manière asynchrone par boîtes aux lettres interposées (on parle de mécanisme pull ou de consommation asynchrone des messages comme explicité en section 3.1). Le tableau 2.21(a) permet de mettre en évidence les différences existant entre ces deux paradigmes et les possibilités offertes par les solutions existantes en termes de modes de communication.
(a) Exemples typiques
(b) Catégories générales
F IG . 2.21 – Classification générale L’utilisation d’un middleware a pour principale qualité d’abstraire la distribution. Cette dernière ne sera donc plus vue comme une problématique dans la suite de ce mémoire. La tolérance aux pannes et, plus particulièrement, la fiabilité que peut apporter un système de gestion d’exceptions adapté aux systèmes multi-agents et aux plates-formes à base de composants sera au cœur de nos travaux. Nous verrons en quoi les propositions industrielles et expérimentales actuelles ne répondent pas encore à l’ensemble des besoins des programmeurs.
43
CHAPITRE 2. CONTEXTE D’ÉTUDE : LES PROGRAMMATIONS PAR AGENTS ET PAR COMPOSANTS
44
Chapitre 3
Gestion d’exceptions : état de l’art Sommaire 1
2
3
Systèmes de Gestion d’Exceptions (SGE) : motivations et définitions . . . . . .
46
1.1
Tolérance aux pannes : quelles solutions ? . . . . . . . . . . . . . . . . . .
46
1.2
Gestion d’exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
Gestion d’exceptions en programmation séquentielle . . . . . . . . . . . . . . .
50
2.1
Présentation d’un système de gestion d’exceptions typique . . . . . . . . .
50
2.2
Gestion d’exceptions dans le paradigme objet . . . . . . . . . . . . . . . .
51
Gestion d’exceptions en milieu concurrent . . . . . . . . . . . . . . . . . . . .
55
3.1
La gestion d’exceptions dans le cadre de la concurrence isolée : la cas typique des threads Java . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
Gestion d’exceptions dans des langages permettant la concurrence collaborative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
Des systèmes de gestion d’exceptions pour la concurrence coopérative . . .
58
Gestion d’exceptions dans les systèmes multi-agents (SMA) . . . . . . . . . . .
61
4.1
SMA sans SGE dédié . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.2
SMA avec gestion d’exceptions centralisée . . . . . . . . . . . . . . . . .
62
4.3
Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
Gestion d’exceptions dans les plates-formes à base de composants logiciels . .
65
3.2 3.3 4
5
5.1
Gestion d’exceptions pour les composants communiquant de manière synchrone et interagissant par requête/réponse . . . . . . . . . . . . . . . . .
65
Gestion d’exceptions pour les composants communiquant de manière asynchrone et interagissant par requête/réponse . . . . . . . . . . . . . . . . .
65
Gestion d’exceptions pour les composants interagissant par émission d’information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
Cahier des charges résultant de l’étude . . . . . . . . . . . . . . . . . . . . . .
70
6.1
Réactivité du système lors du signalement d’une exception . . . . . . . . .
70
6.2
Respect de la contextualisation lors du signalement des exceptions . . . . .
70
5.2 5.3 6
45
CHAPITRE 3. GESTION D’EXCEPTIONS : ÉTAT DE L’ART 6.3
Asynchronisme des communications et coordination des activités concurrentes lors d’un signalement d’exception . . . . . . . . . . . . . . . . . .
71
Concertation d’exceptions signalées par des activités concurrentes . . . . .
72
7
Travaux connexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
8
Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
6.4
Ce chapitre fait un tour d’horizon de la gestion d’exceptions en montrant tout d’abord quelles sont les motivations qui ont conduit à la spécification de systèmes de gestion d’exceptions. Nous verrons aussi comment ces idées ont été mises en pratique dans différents paradigmes de programmation. En particulier, nous nous pencherons sur les problèmes induits par la concurrence dans la gestion d’exceptions.
1 Systèmes de Gestion d’Exceptions (SGE) : motivations et définitions La tolérance aux pannes regroupe plusieurs catégories de techniques visant à rendre un système capable de surmonter les événements qui pourraient perturber son fonctionnement. Elle englobe aussi bien la tolérance aux pannes matérielles que logicielles. Ainsi, un logiciel tolérant aux pannes assure le fonctionnement du système comme spécifié même dans des conditions anormales [Gär99, PL90].
1.1 Tolérance aux pannes : quelles solutions ? Nous commençons par définir les termes d’exception et de système de gestion d’exceptions : Définition : Un événement exceptionnel, souvent abrégé exception, est l’occurrence d’un événement, survenant pendant l’exécution d’une instruction, et qui rend impossible la poursuite standard du calcul. Définition : Un Système de Gestion d’Exceptions (SGE) est un ensemble de structures de contrôle et de primitives intégrées à un langage de programmation pour détecter et traiter les exceptions.
Plusieurs mécanismes ont été proposés pour gérer les exceptions, c’est-à-dire les situations dans lesquelles un traitement particulier doit être exécuté : l’utilisation de branchements de type goto (dans les langages à labels), l’envoi de message à un objet (comme dans le langage Smalltalk originel [GR83, Gol84]) puis, de solutions ad hoc comme les codes de sortie, le renvoi de valeurs particulières et, enfin, des systèmes spécialisés appelés systèmes de gestion d’exceptions (SGE) [Goo75, LAB+ 78, Ano79, Mey88]. Dans cette section, nous présentons les raisons pour lesquelles les langages ont évolué vers l’intégration de systèmes de gestion d’exceptions tels que nous les connaissons. 46
1. SYSTÈMES DE GESTION D’EXCEPTIONS (SGE) : MOTIVATIONS ET DÉFINITIONS 1.1.1
Cahier des charges pour la gestion des exceptions
Afin de gérer efficacement les exceptions lors de l’exécution d’un logiciel, les programmeurs ont besoin de : – Distinguer clairement le code d’exécution standard de celui dédié au traitement des exceptions. En ce qui concerne la structure syntaxique des programmes, ce besoin s’explique non seulement par le fait que le programmeur écrit souvent le code standard avant de pouvoir évaluer les situations exceptionnelles qu’il devra traiter mais aussi parce qu’une telle distinction rend le code plus lisible et simplifie les tâches de réutilisation et de maintenance. – Traiter une exception à un autre niveau que celui de son point de détection. Par exemple, dans le cadre d’une procédure retournant le résultat de la division de deux réels qu’elle prend en paramètre, il semble impossible, a priori, de corriger une exception telle qu’une division par zéro dans la mesure où l’on ne sait pas, dans le contexte de cette procédure, dans quel but la division a été demandée. L’erreur doit être signalée. Le programmeur a donc besoin d’outils qui lui permettront de notifier des exceptions en dehors du contexte dans lequel elles sont apparues. Cette section présentera les diverses méthodes de traitements des exceptions au fil de l’évolution des langages de programmation. Les méthodes ont évolué non seulement avec le pouvoir d’expression des langages mais aussi avec les nouveaux besoins des programmeurs [Pit01]. Nous étudierons plus particulièrement dans quelle mesure ils répondent aux besoins que nous venons d’identifier. 1.1.2
Codes de sortie
Le mécanisme des codes de sortie consiste, lorsqu’une condition d’exception est détectée, à arrêter le programme défaillant et à notifier l’exception en retournant un code de sortie spécifique. Ce mécanisme est utilisable dans tout langage permettant d’associer un code de sortie à la primitive de sortie du programme. Dans le cadre d’un test de détection de situation exceptionnelle, l’exécution peut se poursuivre si l’exception est jugée bénigne et traitée de suite ou le programme peut être arrêté comme dans l’exemple en langage C (qui ne propose pas de SGE contrairement à C++) présenté en Figure 3.1. if (condition_erreur) { cerr < < "Attention erreur critique " < < endl ; exit(1) ; }
F IG . 3.1 – Exemple d’utilisation de code de sortie en C Cette pratique permet : – de spécifier un code particulier pour chaque exception, 47
CHAPITRE 3. GESTION D’EXCEPTIONS : ÉTAT DE L’ART – de terminer le programme en exécutant, si possible, une fonction destinée à effectuer des traitements préalables (telles que atexit en C) qui est invoquée lors de la demande de sortie du programme, – d’utiliser le code de sortie du programme (l’argument de la primitive de sortie) comme notification d’une exception que l’on peut traiter, par exemple, dans le cadre d’un traitement par lots (on peut en conditionner le comportement en fonction des codes de sortie des programmes qu’il exécute). 1.1.3
Renvoi de valeurs particulières
La manière la plus simple de signaler une exception à un appelant dans un monde fonctionnel est de rendre une valeur pré-définie identifiant la situation : une procédure peut notifier une exception en retournant une valeur spécifique distincte de l’ensemble des valeurs de retour standards. Cette pratique ne nécessite pas la maîtrise d’un mécanisme particulier du langage (cf. Figure 3.2). float racine_carree (float x) { if (x<0) return -1 else return sqrt(x) ; }
F IG . 3.2 – Exemple d’une procédure en C pouvant signaler une exception par une valeur de retour particulière L’utilisation de valeurs de retour particulières pose toutefois des problèmes : – Pour le signaleur, il faut trouver un résultat impossible à obtenir en fonctionnement correct : l’étendue des valeurs de retour pouvant exprimer une réponse standard peut réduire (voire réduire à néant) celle des valeurs de retour pouvant servir à notifier une exception, – Pour l’appelant, il est difficile d’obtenir des informations précises sur l’exception : ce mécanisme ne permet pas toujours d’accompagner la notification d’une exception d’informations qui pourraient être utiles à son traitement, – Il est nécessaire de traiter les exceptions à chaque niveau de la pile d’exécution : la propagation de l’exception jusqu’au top-level peut être fastidieuse, – Le traitement des réponses standards et des notifications d’exceptions ne sont pas explicitement distinctes dans le code appelant ce qui affecte la lisibilité, la réutilisabilité et la maintenabilité du programme.
1.2 Gestion d’exceptions Dans un SGE, les exceptions sont généralement différenciées par leur type, c’est-à-dire par la catégorie d’exception (division par zéro, dépassement de pile. . .) qu’elles représentent. 48
1. SYSTÈMES DE GESTION D’EXCEPTIONS (SGE) : MOTIVATIONS ET DÉFINITIONS Dans l’article fondateur du domaine [Goo75], J OHN B. G OODENOUGH a proposé une spécification qui a largement influencé les langages de programmation : la détection d’un événement exceptionnel doit être gérée par la levée d’une exception par le programmeur. Cette levée d’exception interrompt l’exécution standard du programme. Le SGE prends alors en charge la recherche d’un traitant (handler) défini comme étant capable de traiter les exceptions du type de celle qui est signalée (on parle de handler adapté) afin de l’exécuter : ce mécanisme de recherche est appelé signalement d’exception. L’ auteur préconise que les exceptions soient signalées au demandeur de l’opération défaillante qui aura la possibilité de traiter cette exception si un handler adapté lui a été associé ou de la signaler à son tour à son demandeur dans le cas contraire. Un SGE fait donc partie intégrante du modèle d’exécution du langage pour lequel il est défini et permet de fiabiliser les programmes en les faisant réagir de manière appropriée et standardisée en cas de défaillances. Cette réaction peut prendre diverses formes : poursuite de l’exécution après avoir effectué les traitements adéquats ou interruption de l’exécution après avoir remis les données dans un état cohérent. La nature des entités auxquelles on peut associer des handlers dépend de la spécification du SGE. Durant le processus de signalement, l’ensemble ordonné des entités successives auxquelles sera signalée l’exception définit le mécanisme de signalement. Lors d’un signalement d’une exception, un handler adapté est recherché parmi ceux qui sont associés à l’unité de programme à laquelle l’exception a été signalée. Si cette recherche aboutit, le handler trouvé est exécuté. Dans le cas contraire, la recherche se poursuit extérieurement à cette entité. L’endroit où la recherche se poursuit dépend du SGE et influence grandement la sémantique du langage. L’ensemble des unités de programme dont l’exécution peut provoquer un signalement d’exception débouchant sur l’invocation d’un handler donné est appelé la portée de ce handler. En fonction des systèmes, cette portée peut être soit : – dynamique(comme dans la plupart des cas) , i.e. basée sur l’historique des contextes d’exécution (généralement une pile d’exécution). Dans ce cas, le contexte d’exécution d’une unité de programme englobe celui des unités de programme qu’elle invoque et la recherche de handler se fait en remontant la pile d’exécution. La portée des handlers est alors déterminée non pas à la compilation mais à l’exécution [Goo75]. Par exemple, la portée d’un handler associé à une procédure couvre l’exécution de la procédure elle-même mais aussi celles des procédures qu’elle invoque (et ainsi de suite). – lexicale, c’est-à-dire sur la base de l’inclusion textuelle des blocs de code [Knu84, Knu87]. Dans ce cas, une unité de programme en englobe une autre si elle la contient textuellement. L’avantage de cette approche est qu’il est possible de savoir, par analyse statique, quel handler sera invoqué pour un signalement d’exception donné. Le rôle des handlers est, d’une part, de remettre le système dans un état cohérent et, éventuellement, de définir un comportement de substitution. Après l’invocation d’un handler, trois comportements sont possibles : 49
CHAPITRE 3. GESTION D’EXCEPTIONS : ÉTAT DE L’ART – Soit l’exécution reprend là où elle a été interrompue après que le contexte ait éventuellement été modifié par le handler invoqué. On parle de modèle avec reprise (cf. Figure 3.3 (a)). On en trouve des exemples dans [SSY01, Don01]. – Soit la poursuite de l’exécution standard (le point d’exécution courant de l’unité de programme à laquelle le handler invoqué est associée) est abandonnée et l’exécution reprend dans le contexte ayant demandé l’exécution de l’unité de programme défaillante après le point d’appel de cette dernière. On parle alors de modèle avec terminaison (cf. Figure 3.3 (b)). Les exemples les plus connus d’un tel SGE sont ceux des langages C++ et Java [KS89, Sun04b]. – Soit l’exécution reprend en un point qui a été défini lors de l’invocation comme point de reprise en cas d’échec du traitement de cette dernière. On parle de modèle avec continuation (cf. Figure 3.3 (c)). On en trouve une proposition dans [SSY01]. Notons que certains modèles, comme celui proposé pour le langage Béta, proposent d’offrir au programmeur le choix entre reprise et terminaison [Knu01].
2 Gestion d’exceptions en programmation séquentielle 2.1 Présentation d’un système de gestion d’exceptions typique Dans cette section, nous ne souhaitons pas réaliser un état de l’art exhaustif mais nous rappelons les pratiques les plus courantes. Un handler est associé, lors de sa définition, à une unité de programme (cf. section 1.2) dont la nature peut varier d’un système à l’autre. Le cas le plus classique est celui des systèmes dans lesquels les handlers sont associés à des blocs de code comme en C/C++/Java [Sun04b, KS89] mais on peut rencontrer des cas où les handlers sont associés à d’autres unités de programme [Don90] (procédures, instructions. . .). La figure 3.4 présente de manière abstraite ce mécanisme dans un système à terminaison où les handlers sont associés à des procédures : Une procédure A invoque une procédure B qui invoque elle-même une procédure C. Des handlers ont été associés à chacune de ces procédures. La notation Handler(type_x) est utilisée pour désigner un handler adapté au traitement d’une exception de type type_x. Dans le premier cas, aucune procédure ne signale d’exception (l’exécution se déroule normalement). Dans le second cas, une exception de type e3 est signalée à C pendant son exécution et aucun handler dédié au traitement des exceptions de type e3 n’est associé à C. L’exception est donc signalée à B, l’appelant de C. Un handler adapté au traitement des exceptions de type e3 étant associé à B, il est exécuté en remplacement du code standard de la procédure B compris entre le point d’appel de C et la fin de B (il faut pallier le fait que la procédure C n’a pas rendu le service attendu lors de son invocation). Après l’exécution du handler invoqué, le flot d’exécution retourne à A après le point d’appel de B et l’exécution standard reprend. Voyons maintenant un second exemple en langage C sur la figure 3.6. Dans ce langage, les unités 50
2. GESTION D’EXCEPTIONS EN PROGRAMMATION SÉQUENTIELLE
F IG . 3.3 – Les trois types de modèles de SGE de programme auxquelles on peut associer des handlers sont des blocs de code. Pour ce faire, on délimite une zone à laquelle on souhaite associer des handlers en l’encapsulant dans un bloc try {} à la suite duquel on insère la liste des handlers associés à ce bloc sous la forme présentée en figure 3.5. Dans l’exemple de la figure 3.6, si la procédure div ou ln signale une exception, elle sera signalée à la fonction main qui l’a invoquée. Cette politique a été largement adoptée dans les langages séquentiels fournissant un système de gestion d’exceptions et répond aux besoins des programmeurs.
2.2 Gestion d’exceptions dans le paradigme objet L’utilisation du paradigme objet a conduit à la représentation des types d’exceptions par des classes et donc des exceptions comme instances de classes (objets). Intégrer de la sorte les exceptions dans le paradigme objet a permis : 51
CHAPITRE 3. GESTION D’EXCEPTIONS : ÉTAT DE L’ART
Procédure A
Procédure B
Procédure C
Procédure A
Procédure B
Procédure C
invocation de B
invocation de B
invocation de C
invocation de C
signalement d’une exception de type e3
Handler (e1)
Handler (e1)
Handler (e1)
Handler (e1)
Handler (e1)
Handler (e1)
Handler (e2)
Handler (e3)
Handler (e4)
Handler (e2)
Handler (e3)
Handler (e4)
Exécution standard Légende
Flot d’exécution
Signalement et traitement d’une exception Invocation
Branchement du flot d’exécution
F IG . 3.4 – Exemples d’exécution de procédures en programmation séquentielle try { .... // Bloc de code .... } catch (type1) { // Traitement des exceptions de type 1 } catch (type2) { // Traitement des exceptions de type 2 } catch_any { // Handler par défaut // Traite toute exception qui n’est // ni de type 1 ni de type 2 } endtry ;
F IG . 3.5 – Structure d’un bloc de code auquel on associe des handlers en C – de construire des hiérarchies de type d’exceptions, – d’encapsuler, dans les exceptions : 1. des informations sur les événements exceptionnels qui surviennent, 52
2. GESTION D’EXCEPTIONS EN PROGRAMMATION SÉQUENTIELLE enum { E_invalid, E_zero_divide, E_domain_error, E_bad_alloc } exceptions ; double div(double a, double b) { if (b == 0.0) throw(E_zero_divide) ; return a/b ; } double ln(double a)
{
if (a <= 0.0) throw(E_domain_error) ; return log(a) ; } int main(void)
{
double a, b, c ; printf("a = ") ; scanf("%lf", &a) ; printf("b = ") ; scanf("%lf", &b) ; try { c = ln (div(a,b)) ; } catch(E_zero_divide) { c = 999999.9 ; printf("zero division\n") ; } catch(E_domain_error) { c = 0; printf("domain error\n") ; } catch_any { c = 0; printf("unknow exception %d\n", exception) ; } endtry ; printf("ln(%g/%g) = %g\n", a, b, c) return 0 ; }
F IG . 3.6 – Exemple de programme en C avec gestion d’exceptions 2. et des méthodes qui pourront être exploitées lors de leur traitement. – d’exploiter le polymorphisme pour définir des handlers plus ou moins génériques. Prenons pour exemple le cas d’une implémentation dans un langage séquentiel de l’exemple de l’agence de voyage. Intéressons-nous plus particulièrement au cas où le prestataire sélectionné propose un contrat non-conforme à l’offre qu’il a émise initialement. La figure 3.7 présente la définition de la classe des exceptions destinées à notifier ce problème (Exception_tarif_incorrect) et un exemple de levée d’une exception de ce type. Dans cet exemple, l’utilisation du paradigme objet permet : 53
CHAPITRE 3. GESTION D’EXCEPTIONS : ÉTAT DE L’ART public class Exception_tarif_incorrect extends Exception_Tarif { private int valeur_declaree, valeur_proposee ; private Prestataire mauvais_prestataire ; public Exception_tarif_incorrect (int v1, int v2, Prestataire p) { this.valeur_declaree = v1 ; this.valeur_proposee = v2 ; this.mauvais_prestataire = p ; } } ... throw (new Exception_tarif_incorrect(prix_annonce, prix_prestataire, prestataire_selectionne)) ; ...
F IG . 3.7 – Exemple d’utilisation d’un objet-exception encapsulant de l’information en Java – de faire transiter, par encapsulation de données, dans une instance de Exception_tarif_incorrect toutes les informations qui seront nécessaires à son traitement, – d’exploiter le polymorphisme car une instance de la classe Exception_tarif_incorrect pourra être traitée par des handlers définis pour traiter des exceptions instances des classes Exception_tarif_incorrect ou Exception_tarif. Le paradigme objet a aussi permis la spécification de systèmes de gestion d’exceptions innovants tels que celui proposé dans [Don88] pour le langage orienté-objet Lore. Cette proposition montre comment l’utilisation du paradigme objet permet de résoudre, de manière simple et efficace, quelques problèmes relatifs à la gestion des exceptions tels que la création d’une hiérarchie d’exceptions, le passage de paramètres aux handlers, etc. Par la suite, [Don90] propose le même type de SGE pour le langage Smalltalk. Ces deux articles proposent des systèmes dans lesquels le signalement des exceptions s’effectue classiquement le long de la chaîne d’invocation mais dont le mécanisme de recherche de handler est spécialisé. En effet, dans ces systèmes, on peut associer des handlers ayant une portée dynamique aux instructions, blocs d’instructions et classes. – Les handlers associés aux classes sont hérités par leurs sous-classes et y sont redéfinissables, – Lors du signalement d’une exception, si aucun handler adapté n’est trouvé dans l’unité de programme dans laquelle l’exception a été signalée, on réitère la recherche de handler au niveau de la classe de l’objet invoqué puis de ses super-classes en respectant la hiérarchie de classes définie avant de signaler l’exception au contexte appelant (cf figure 3.8(b)). Le fait de pouvoir ainsi associer des handlers aux classes permet au programmeur de spécifier, au niveau d’une classe, quelles exceptions peuvent être propagées en dehors des méthodes de celle-ci 54
3. GESTION D’EXCEPTIONS EN MILIEU CONCURRENT
(a) mécanisme classique
(b) Proposition de Ch. Dony
F IG . 3.8 – Différentes politiques de signalement des exceptions et de ses sous-classes. Il est alors possible de filtrer les informations qui sortent d’une classe tout en permettant, par exemple, l’application de traitements par un handler associé à une classe avant de signaler une nouvelle exception. Cet exemple nous montre qu’il est possible de définir un SGE dans lequel les exceptions sont signalées en remontant l’historique des contextes d’exécution tout en transitant par des entités intermédiaires. Par ailleurs, ces modèles de SGE ont la particularité de permettre à la fois la reprise et la terminaison durant le processus de signalement. Enfin, [Don01] propose une implémentation de ce SGE pour Objectworks Smalltalk en exploitant ses capacités en terme de réflexivité. Cette proposition peut donc être considérée comme un environnement de développement dédié à la conception de SGE. Il est très facile, par exemple, de dériver ce SGE pour en implémenter un autre ne permettant que la reprise ou que la terminaison. Il permet par ailleurs d’ajouter des méthodes aux classes d’exceptions pour définir des structures de contrôle dédiées. Cette approche peut ainsi répondre aux nouveaux besoins concernant les langages ouverts, réflexifs et dynamiquement typés comme ceux utilisés de nos jours pour l’assemblage de composants logiciels (cf. section 4 du chapitre 2).
3 Gestion d’exceptions en milieu concurrent Après avoir vu ces bases sur la gestion d’exceptions, nous nous intéressons maintenant à la problématique de la gestion d’exceptions en milieu concurrent. Nous commencerons par présenter des solutions techniques représentatives de l’existant pour ensuite expliquer comment la notion de concurrence coopérative (cf. section 2.2 du chapitre 2) peut être exploitée pour gérer les exceptions en milieu 55
CHAPITRE 3. GESTION D’EXCEPTIONS : ÉTAT DE L’ART concurrent.
3.1 La gestion d’exceptions dans le cadre de la concurrence isolée : la cas typique des threads Java Dans Java, la programmation concurrente est permise au travers de la définition et du lancement de processus légers (threads) [Sun04b]. Ce modèle est représentatif des langages permettant la concurrence isolée.Une exception levée dans le cadre d’un thread ne peut être traitée que localement à ce dernier puisque, dans ce modèle, chaque thread s’exécute isolément et est géré comme un programme séparé. En effet, suite à une levée d’exception dans un thread, l’exception est signalée classiquement : une recherche de handler adapté est effectuée en remontant la pile d’exécution du thread défaillant. Si un tel handler est rencontré avant le top-level du thread défaillant, il est invoqué, sinon, l’exception est signalée et traitée au niveau de la machine virtuelle qui interrompt alors l’exécution du thread défaillant. Ce mécanisme ne permet donc pas de prendre en compte les collaborations et coopérations entre threads.
3.2 Gestion d’exceptions dans des langages permettant la concurrence collaborative 3.2.1
Gestion d’exceptions dans Multilisp
[HL85] propose un système de gestion d’exceptions pour Multilisp, une variante de Lisp permettant de lancer des évaluations d’expressions de manière concurrente (cf. section 2.17 du chapitre 2) introduisant ainsi de nouvelles problématiques pour la gestion d’exceptions par rapport aux langages séquentiels. Le parallélisme y est permis par l’usage de la fonction future qui lance l’évaluation d’une expression parallèlement à l’exécution courante. Quand le résultat d’une évaluation lancée en parallèle devient indispensable à la continuation de l’exécution de son expression appelante, c’est l’opérateur touch qui est utilisé pour suspendre l’exécution jusqu’à ce que l’évaluation de l’expression attendue soit terminée et la valeur récupérée (cf. figure 3.9). Il s’agit donc d’un mécanisme à futur explicite (cf. section 1.2 du chapitre 2). (let ((V(future exp))) ( // suite du programme ne nécessitant pas V ) (touch V)
// synchronisation : attente de la fin de l’évaluation de V
F IG . 3.9 – Utilisation de future et touch dans Multilisp Deux cas de figure se présentent en cas de signalement d’exceptions : – Si une expression est self-contained, c’est-à-dire si son évaluation ne se termine qu’une fois que toutes les expressions dont elle a demandé l’évaluation en parallèle sont évaluées, toute 56
3. GESTION D’EXCEPTIONS EN MILIEU CONCURRENT exception signalée par une de ces expressions pourra être traitée. Par exemple, dans la figure 3.10 (a)), une expression E demande l’évaluation en parallèle d’une expression V. E ne peut se terminer avant la fin de l’exécution de V grâce à la clause de synchronisation touch(V). – Par contre, si une expression E exporte du parallélisme 1 , une exception peut être signalée par une évaluation d’expression qu’elle avait lancée en parallèle après le point de sortie de E et ne pas être traitée. Par exemple, en figure 3.10 (b), on voit que l’évaluation de l’expression E se termine avant celle de V. Cette dernière se termine exceptionnellement mais l’exception correspondante ne sera pas traitée faute d’appelant à qui signaler l’exception correspondante. Ce modèle ne permet donc pas d’assurer la propagation des exceptions en toutes circonstances.
F IG . 3.10 – Signalement des exceptions dans MultiLisp Ce mécanisme utilise donc au mieux, pour les expressions self-contained, les qualités du système séquentiel. Dans ce cas, le signalement d’une exception suspend l’évaluation de l’expression à laquelle 1
Si elle termine son exécution avant la fin de l’exécution de l’expression qu’elle a initiée en parallèle.
57
CHAPITRE 3. GESTION D’EXCEPTIONS : ÉTAT DE L’ART elle est signalée avant d’invoquer le handler qui lui est associé et qui peut avoir deux comportements : – après avoir effectuer un traitement, reprendre l’évaluation où elle en était, – ou terminer l’évaluation de l’expression en lui affectant une valeur particulière. Il s’agit donc d’un modèle qui autorise à la fois la reprise et la terminaison et qui permet également l’association d’un handler à une évaluation d’expression requise en parallèle comme présenté en figure 3.11. Un tel handler associé à une évaluation en parallèle est évalué si cette dernière signale une exception et le handler invoqué fournit une évaluation de substitution. L’évaluation de l’expression appelante n’est pas interrompue dans ce cas. Cette possibilité permet à une entité logicielle qui invoque des activités en parallèle de traiter une exception signalée par une d’elles sans fatalement interrompre son exécution standard. Par ailleurs, la possibilité d’associer un handler à une évaluation donnée permet d’associer différents handlers à chaque évaluation ainsi protégée. (future
expression
handler)
F IG . 3.11 – Association d’un handler à une expression à évaluer en parallèle dans MultiLisp
3.2.2
La concurrence dans ProActive
Une autre proposition, ProActive [web99, BCM03], permet l’introduction de concurrence dans le langage Java par l’invocation asynchrone à futur implicite appelée aussi attente par nécessité (cf. section 1.2 du chapitre 2) de méthodes Java [Car93] à l’image du mécanisme de futur proposé dans MultiLisp (cf. section 3.2.1). Cette version de ProActive n’offre pas de support pour gérer les exceptions signalées par des méthodes invoquées de manière asynchrone [CKV98] mais uniquement les exceptions non-fonctionnelles (c’est-à-dire celles qui sont signalées par le mécanisme d’invocation asynchrone). Suite à ces travaux, [CG03] propose d’introduire un moyen de gérer les exceptions dans ce contexte en permettant l’association de handlers aux invocations asynchrones de méthodes à l’image de ce qui se fait dans MultiLisp (cf. section 3.2.1). Les deux modèles présentés dans cette section, par leur mécanisme de futur, imposent la gestion de la synchronisation et la gestion individuelle des réponses tout en limitant la réactivité du système.
3.3 Des systèmes de gestion d’exceptions pour la concurrence coopérative 3.3.1
Le cas des Threadgroups Java
Pour pallier partiellement cette limitation, il est possible d’exploiter des groupes de processus (les ThreadGroups). Tout thread peut, lors de sa création, être rattaché à un ThreadGroup. Toute exception levée et non traitée dans un thread associé à un ThreadGroup est signalée à ce dernier. Il est possible de traiter cette exception au niveau du groupe et, par exemple, d’intervenir sur l’exécution 58
3. GESTION D’EXCEPTIONS EN MILIEU CONCURRENT d’autres processus appartenant au même groupe. Les groupes peuvent eux-mêmes être regroupés et une hiérarchie de groupes peut être définie pour représenter des coopérations entre threads mais de manière très limitée car ce principe qui préserve l’isolation des threads ne permet pas de représenter de collaborations entre threads (pas d’échanges d’informations lors du signalement d’une exception par un thread). 3.3.2
Une proposition permettant la concertation d’exceptions dans un langage à multi-procédures
Dans [Iss01], VALÉRIE I SSARNY s’intéresse à la problématique de la gestion d’exceptions dans les systèmes répartis concurrents. Elle a particulièrement étudié les complications induites par les interactions entre de multiples entités logicielles dans les applications distribuées sur un réseau local. Le modèle proposé s’applique aux multi-procédures 2 lancées concurremment (coordinated call) dans un langage où les communications sont synchrones : l’appel d’une multi-procédure entraîne l’interruption de l’exécution de l’activité l’ayant invoquée jusqu’à ce que toutes les composantes de la multi-procédure invoquée aient terminé leur exécution (on parle de synchronisation comme présenté en figure 3.12). Dans ce cadre, elle propose un modèle coopératif (cf. section 2.2 du chapitre 2) de système de gestion d’exceptions à terminaison “privilégiant la simplicité plus que la puissance” [Iss01]. Ce SGE permet la prise en compte du fait qu’un événement exceptionnel dans l’une des procédures exécutée peut interférer avec le comportement de celles qui s’exécutent en parallèle afin, par exemple, d’éviter des interblocages quand de tels événements empêchent la synchronisation des procédures concurrentes. Si l’on prend l’exemple des agences de voyages, on peut illustrer ce problème par le fait que, dans le cadre de la collecte des tarifs proposés, l’échec d’un prestataire qui traite une demande de tarif ne doit pas bloquer la collecte des tarifs auprès des autres prestataires. Une innovation majeure proposée dans ce modèle est la possibilité de prendre en considération, au niveau d’une multiprocédure M, différentes exceptions signalées concurremment par plusieurs procédures de M. Cette prise en compte est capitale car un tel phénomène relève généralement d’un problème global qui ne peut être détecté (et qui plus est correctement analysé) si l’on considère les exceptions signalées individuellement. Le modèle proposé dans cet article permet de définir, au niveau d’une multi-procédure, une fonction dite de concertation (resolution function) et parle plus généralement de concertation d’exceptions (concerted exception handling). La fonction de concertation permet d’évaluer de manière pertinente les signalements d’exceptions de la part des membres de la multi-procédure correspondante. A chaque multiprocédure M est associé un tableau d’exceptions dont chaque élément correspond à une procédure de M. A chaque signalement d’exception par une procédure de M, l’exception est stockée dans le tableau d’exceptions de M à la place correspondante. Au fil de l’exécution concurrente d’une multi-procédure que le tableau d’exceptions correspondant est rempli. 2
Ensembles de procédures exécutées en parallèle.
59
CHAPITRE 3. GESTION D’EXCEPTIONS : ÉTAT DE L’ART
F IG . 3.12 – Invocation synchrone d’une multi-procédure Une fois les procédures membres de M terminées, si au moins l’une d’entre elle a signalé une exception, la fonction de concertation de M est invoquée afin de : – signaler, si nécessaire, une exception concertée reflétant le véritable état du système et ainsi permettre l’invocation d’un handler adapté, – ou ne rien signaler, auquel cas le processus de signalement est interrompu et l’exception dont le signalement a déclenchée cette évaluation de la fonction de concertation reste dans le tableau associé à M pour pouvoir être prise en compte lors d’une prochain notification d’exception à M. Ce modèle exploite donc une représentation de l’activité collective des multi-procédures afin de mieux prendre en compte l’impact global des exceptions individuelles sur le contexte d’exécution englobant. 3.3.3
Un système distinguant les activités critiques et non-critiques dans le langage Guide
[Lac90] reprend la proposition de [Iss01] en l’appliquant à un des cas plus courants : il n’est pas toujours nécessaire que toutes les composantes concurrentes d’une activité globale se déroulent sans problème pour que cette dernière soit réussie. En effet, si certaines composantes d’une activité collective sont défaillantes, on peut parfois se contenter du résultat partiel que fournissent celles qui se sont bien déroulées. C’est pourquoi le SGE proposé pour le langage Guide dans [Lac90] distingue les activités critiques (celles dont la terminaison exceptionnelle interdit la poursuite de l’exécution standard de son activité appelante) des activités non-critiques (celles dont la terminaison exceptionnelle n’est pas fatale pour leur activité appelante). Il préconise que, lors du signalement d’une exception à une activité globale par une de ses sous-activités, le système réagisse en fonction de la criticité de la sous-activité défaillante (comme illustré en figure 3.13). 60
4. GESTION D’EXCEPTIONS DANS LES SYSTÈMES MULTI-AGENTS (SMA) method Main ; begin co_begin producer : ... consumer : ... co_end(producer and consumer) ; except JOIN_FAILED :
end Main ;
F IG . 3.13 – Exemple en langage Guide où les deux composantes d’une activité collective sont critiques Les trois SGE présentés dans cette section permettent une gestion synchrone des exceptions avec la possibilité de prendre en compte globalement des exceptions.
4 Gestion d’exceptions dans les systèmes multi-agents (SMA) Après avoir vu l’existant en terme de gestion d’exceptions dans les langages de programmation classiques, nous recensons dans cette section l’existant dans le cadre des systèmes multi-agents. Comme nous l’avons vu dans la section 3 du chapitre 2, nous considérons, dans ces travaux, les agents plus du point de vue du génie logiciel (AOSE : Agent Oriented Software Engineering [GB99, Woo02]) que de celui de leurs capacités cognitives. Les agents sont donc ici considérés comme des entités de plus haut niveau que les objets utilisant des mécanismes de communication et de gestion de l’exécution spécifiques pour se conformer au paradigme agent. Notre étude des SMA a mis en évidence trois catégories de SGE pour ces derniers : les systèmes n’offrant pas de SGE spécifique qui sont les plus courants [RD00] (MADKit[vD04], Jack [BRHL99], AgentBuilder [Ret99], . . .), les systèmes qui exploitent un agent superviseur pour gérer les exceptions et enfin, les systèmes utilisant la notion de gardien.
4.1 SMA sans SGE dédié Ces systèmes limitent leurs possibilités en terme de gestion d’exceptions à celles fournies par le langage avec lequel elles ont été implémentées (on parle de langage sous-jacent). Par exemple, MADKit [vD04] est une plate-forme multi-agents générique basée sur Java. Elle n’est pourvue que du SGE de ce langage sous-jacent sans proposer de fonctionnalités supplémentaires en terme de gestion des exceptions. Les activités des agents sont codées sous la forme de méthodes Java et les exceptions Java signalées durant leur exécution sont traitées par les handlers Java associés aux blocs de code de ces méthodes. Quand une exception ne peut être traitée par un de ces handlers, elle atteint le sommet de la pile d’exécution du thread dans lequel s’exécute l’agent défaillant. Ce thread (et l’agent correspondant) sont alors détruits par la machine virtuelle Java. 61
CHAPITRE 3. GESTION D’EXCEPTIONS : ÉTAT DE L’ART Du point de vue du SMA, ce phénomène correspond à la mort accidentelle de l’agent incriminé sans que les autres entités du système n’en soit informées. Ainsi, d’autres agents risquent d’essayer de contacter l’agent disparu en vain au lieu d’adapter leur comportement en fonction de la nouvelle configuration du SMA. D’autre part, l’absence d’un SGE dédié aux agents rend impossible la propagation d’une exception d’un agent vers un autre (typiquement, vers celui qui aurait commandité l’activité défaillante) car une exception Java n’est pas supposée être signalée en dehors du thread dans lequel elle a été signalée3 (cf. section 2). On peut avancer que c’est l’autonomie des agents (cf. section 3 du chapitre 2) qui empêche de gérer l’établissement de contrats logiciels (cf. section 4.2 du chapitre 2). Cependant, le traitement d’une requête émise par un agent client peut être essentielle pour la poursuite de ses activités. L’agent serveur contacté est libre de rejeter la requête mais, s’il accepte de la traiter, il doit remplir cet engagement. Ainsi, quand un agent serveur rencontre une exception qui l’empêche de traiter une requête qu’il a préalablement accepté de traiter, il doit en aviser l’agent client afin que ce dernier puisse réagir en conséquence et tenter d’obtenir satisfaction par un autre moyen. Les agents ont donc besoin d’un SGE dédié pour prendre en compte les exceptions dans la gestion de leurs collaborations. C’est pourquoi des SGE dédiés aux SMA issus de la recherche ont été proposés. A défaut, les exceptions qui ne peuvent être traitées au niveau de l’agent dans lequel elles ont été levées doivent être gérées par des solutions ad hoc comme le traitement de ces exceptions par des handlers locaux qui répondent à l’agent demandeur de l’activité défaillante par un message contenant une valeur particulière (cf. section 1.1.3).
4.2 SMA avec gestion d’exceptions centralisée Dans la section précédente, nous avons exposé le cas où la gestion des exceptions se fait isolément dans chaque agent. A l’opposé, nous présentons dans cette section deux modèles dits centralisés, c’est-à-dire des modèles dans lesquels la gestion des exceptions est déléguée à des entités dédiées. 4.2.1
SMA à superviseurs
Les superviseurs [KD99, KD03, KD01] sont des agents spécialisés dans le contrôle de l’activité des agents dont ils sont responsables afin de traiter les exceptions que ces derniers signalent. Dans ce modèle, on associe les handlers aux superviseurs. Une telle approche est adaptée au traitement de problèmes génériques au niveau du SMA, comme la mort des agents, en permettant, par exemple, que la mort d’un agent soit notifiée à l’ensemble des agents du système afin qu’ils ne cherchent plus à communiquer avec lui. Du point de vue des agents supervisés, les superviseurs sont des entités extérieures créées par le SMA alors que la gestion des exceptions liées aux activités internes des agents nécessite des handlers définis dans un contexte dans lequel on connaît l’impact précis des exceptions signalées 3
L’implémentation étudiée de MADKit n’utilise pas les ThreadGroup, vus dans la section 3.3.1, qui auraient pu permettre de pallier partiellement ce problème.
62
4. GESTION D’EXCEPTIONS DANS LES SYSTÈMES MULTI-AGENTS (SMA) sur l’activité des agents. Or, étant donné qu’il s’agit d’entités extérieures aux agents supervisés, il n’est pas possible d’associer aux superviseurs des handlers qui soient définis en fonction des activités des agents supervisés à moins de leur accorder la possibilité d’agir directement sur le comportement des agents supervisés ou de laisser les agents supervisés informer leur superviseur des traitements spécifiques à effectuer et, ainsi, de déléguer aux superviseurs une partie de leur comportement. Dans les deux cas, les principes d’encapsulation et d’autonomie des agents sont violés. L’intérêt d’un tel système réside donc dans son aspect préventif (plutôt que curatif). En effet, externaliser de la sorte la gestion des exceptions et autoriser un accès aux agents par les superviseurs peut servir à surveiller, voire à prévoir, les défaillances des agents. On peut par exemple exploiter la surveillance des agents pour anticiper des situations exceptionnelles par la reconnaissance de patrons répertoriés dans une base de données de situations exceptionnelles [KD00, KRA00]. 4.2.2
SMA avec gardiens
Dans [TM01], T RIPATHI ET M ILLER proposent un modèle dit “à gardien” permettant de construire des SMA intégrant une gestion d’exceptions centralisée. Ce modèle est bâti autour de trois notions : – un participant est un agent engagé dans une activité en coopération avec d’autres agents, – une exception globale est une exception concernant un ensemble d’agents en interaction, c’està-dire une exception relative à une activité collective et ne pouvant être traitée par l’agent dans lequel elle a été levée, – un gardien est une entité abstraite et composite qui est constituée d’un agent spécial (le leader) et d’un ensemble de participants auxquels le leader a accès au travers d’une interface dédiée à la gestion d’exceptions. Dans ce modèle, les exceptions globales levées par les participants sont signalées au leader correspondant (comme présenté en figure 3.14). En fonction de règles définies par le programmeur 4 , le leader signale une exception aux différents participants de cette activité (il peut s’agir d’une exception différente pour chacun des participants). Il s’agit d’un modèle où la gestion d’exceptions est distribuée (le gardien transforme une exception globale en un ensemble d’exceptions individuelles qui sont traitées par les handlers des participants) mais qui est très générique dans la mesure où il permet la construction de divers systèmes de gestion d’exceptions. Il est en effet possible de définir librement les règles de rétablissement à appliquer lors des signalements d’exceptions dans le cadre d’activités collectives et de définir des priorités sur ces règles. De plus, ce système utilise une structure de contextes d’exécution imbriqués pour le signalement des exceptions et permet donc la construction d’un SGE dans lequel les exceptions sont signalées le long de la chaîne des invocations. La possibilité de faire participer au traitement d’une exception signalée dans le contexte d’une activité globale l’ensemble des participants correspondants a déjà été proposée dans le contexte des CA Actions [RRS+ 97, XRR02] (cf. section 2.2 du chapitre 2). On y retrouve également les possibilités de 4
La définition de ces règles correspond, si on se projette dans la proposition de Valérie Issarny (cf. section 3.3) à la définition d’une fonction de concertation.
63
CHAPITRE 3. GESTION D’EXCEPTIONS : ÉTAT DE L’ART retryLabel : try { ... } catch (InternalException e) { ... } catch (GlobalException e) { // on notifie l’exception globale au gardien // et on récupère l’ordre qui en découle command = notifyGuardian(e) ; if (command == RETRY) goto retryLabel else if (command == TERMINATE) throw terminateException else if (command == REPORT) throw colocateException (report(e)) ; }
F IG . 3.14 – Exemple de gestion d’exceptions interne et globale dans le code Java d’un participant
signaler les exceptions en remontant les contextes d’exécution imbriqués et de concerter les exceptions signalées concurremment par plusieurs participants à une même CA Action (cf. section 3.3). [Rom97] propose une implémentation de ce modèle dans Ada95. Dans le même esprit, [GRRV04] présente une méthode de conception orientée-modèle pour les systèmes distribués fiables basée sur les CA actions avec une proposition d’implémentation sous le forme de classes Java.
4.3 Synthèse Les agents ont besoin d’échanger des informations sur leurs défaillances dans le cadre de leurs collaborations mais les SMA sans SGE dédié n’offrent aucun support pour automatiser cette démarche. Le programmeur doit alors traiter les situations exceptionnelles par des solutions ad hoc comme des échanges de valeurs particulières avec les problèmes que cette pratique induit (cf. section 1.1.3). Un modèle de gestion d’exceptions à superviseur permet aux agents de signaler des exceptions à leur superviseur qui peut alors exécuter des traitements. Le problème posé par cette approche réside dans le fait que, pour pouvoir définir des traitements pertinents au niveau d’un agent superviseur, un tel mécanisme ne respecte pas l’autonomie et le principe d’encapsulation des agents. Enfin, dans un modèle à gardien, le programmeur peut définir des règles qui lui permettront de gérer efficacement les exceptions signalées dans le cadre d’activités collectives mais la définition des règles de signalement pour chacune de celles-ci peut s’avérer fastidieux et ne garantit pas la vérification des qualités identifiées en section 1.1.1. 64
5. GESTION D’EXCEPTIONS DANS LES PLATES-FORMES À BASE DE COMPOSANTS LOGICIELS
5 Gestion d’exceptions dans les plates-formes à base de composants logiciels Après avoir vu l’existant en terme de gestion d’exceptions dans les langages de programmation classiques et les SMA, nous recensons dans cette section l’existant dans le cadre des plates-formes à base de composants logiciels. Pour structurer cette étude, nous reprenons la classification établie dans la section 4.2 du chapitre 2.
5.1 Gestion d’exceptions pour les composants communiquant de manière synchrone et interagissant par requête/réponse Pour les systèmes existants qui utilisent les composants de type RRS (communiquant de manière synchrone et interagissant par requête/réponse), les SGE proposés ne diffèrent pas, pour le programmeur, de ceux dont on dispose dans les langages séquentiels classiques dans la mesure où le middleware rend transparent la distribution lors des appels de méthodes et des envois des réponses correspondantes (cf. section 1 du chapitre 2) y compris quand il s’agit d’exceptions. Prenons l’exemple des Session Beans dans J2EE : ces composants interagissent par des appels de méthodes au travers d’un middleware (RMI ou CORBA) grâce à une représentation par proxy des composants distants. Les exceptions qui ne sont pas traitées par le composant serveur sont signalées au composant client au travers du middleware et du proxy. Voici par exemple, en figures 3.15 et 3.16 un exemple de traitement de situation exceptionnelle dans des Session Beans en J2EE.
F IG . 3.15 – Gestion d’exceptions dans un Session Bean
5.2 Gestion d’exceptions pour les composants communiquant de manière asynchrone et interagissant par requête/réponse Comme nous l’avons vu dans le chapitre précédent, il y a de nombreux points communs entre agents et composants RRA (communiquant de manière asynchrone et interagissant par requête/réponse). Dans cette section nous allons voir, cas par cas, que ces similitudes se retrouvent aussi au niveau de la gestion d’exceptions. 65
CHAPITRE 3. GESTION D’EXCEPTIONS : ÉTAT DE L’ART // Code d’un composant ou d’une application client(e) ... UserTransaction utx ; Operation t1 ; //EJBObject ... try{ utx.begin() ; // Début d’une transaction t1.buy(10) ; // requête à destination d’un Session Bean } catch (LimitedStockException exc) { int n = exc.getMessage() ; println("Buying only" + n + "units") ; t1.buy(n) ; } finally { utx.commit() ;// Validation de la transaction } ... // Méthode distante invoquée sur le Session Bean public void buy(int s) { if (s>newtotal) throw (new LimitedStockException (newtotal)) ; newtotal = newtotal - s ; }
F IG . 3.16 – Exemple de gestion d’exceptions dans le code Java d’un Session Bean 5.2.1
Le cas des MessageDrivenBeans (J2EE)
Les MessageDrivenBeans (MDB) et JMS sont présentés en section 4.2.3 du chapitre 2. Suite à une levée d’exception dans un traitement de message par un MDB, l’exception est signalée comme dans un thread Java classique : une recherche de handler adapté est effectuée en remontant la pile d’exécution du thread courant. Si un tel handler est rencontré avant le top-level de ce thread, il est invoqué, sinon, le message ayant initié le thread défaillant est à nouveau émis à l’identique modulo un flag notifiant que ce message est redélivré (cf. figure 3.17). Par conséquent, l’éventualité qu’un message puisse être redélivré doit être prise en compte. Le programmeur doit donc tester si un message à traiter est redélivré ou non. Si c’est le cas il doit effectuer un traitement ad hoc générique (cf. figure 3.18). Dans la pratique, les MDB sont utilisés pour traiter les messages en délégant le traitement à une entité telle qu’un Session Bean. Le traitement présenté en figure 3.18 correspond donc conceptuellement à la réaction en cas d’erreur lors de la délivrance du message à traiter. Dans cette situation, le programmeur ne pourra encore une fois qu’effectuer un traitement générique au travers d’un handler consommant toutes les exceptions (cf. figure 3.18). Les exceptions ne 66
5. GESTION D’EXCEPTIONS DANS LES PLATES-FORMES À BASE DE COMPOSANTS LOGICIELS
F IG . 3.17 – Gestion d’exception dans un Message Driven Bean public void onMessage(Message message) { try{ // Le programmeur teste si le message est redélivré if (message.getJMSRedelivered()) { System.err.println("Erreur lors de la délivrance de : " + message) ; notifier_erreur(message) ; } } catch (JMSException e) { System.err.println(e) ; notifier_erreur(message) ; } // Traitement d’un message non redélivré try { sb.method() ; } catch (Exception e){ System.err.println(e) ; notifier_erreur(message) ; } }
F IG . 3.18 – Traitement d’une erreur de délivrance de message dans le code Java d’un MDB peuvent donc pas être signalées à l’expéditeur du message ayant initié un traitement défaillant dans ce contexte. Le problème réside donc dans le fait que, JMS étant conçu pour assurer un découplage fort, il n’intègre pas de vrai mécanisme de requête/réponse. 67
CHAPITRE 3. GESTION D’EXCEPTIONS : ÉTAT DE L’ART Ceci est dû au fait que, dans le cadre de JMS, il n’y a pas de protocole permettant la représentation de la coopération entre composants induite par les échanges de messages JMS (cf. section 4.2.3 du chapitre 2). Ce service de messagerie n’est donc pas conforme aux prescriptions identifiées en section 2.2 du chapitre 2 en terme de représentation des activités collectives. On retrouve le problème déjà rencontré avec les SMA sans SGE dédié (cf. section 4.1). Remarque : Un client JMS peut utiliser JTA (Java Transaction API) ou JTS (Java Transaction Service) pour délimiter des transactions distribuées. Cette technique peut être utilisée pour garantir le maintien de la cohérence des données si une transaction échoue (sans pour autant offrir la possibilité de définir le traitement exceptionnel puisque un handler générique provoque systématiquement le rollback). Dans ce cas, on a un système où l’on gère la concurrence compétitive mais pas la concurrence coopérative (cf. section 2.2 du chapitre 2). Notons que ce type de mécanisme a également été utilisé (avec un système de réplication des données) dans le contexte des systèmes multi-agents dans le cadre de la plate-forme Mozart [Van99, AR00] basée sur le langage Oz. Ce modèle pose donc des problèmes similaires à ceux que l’on rencontre dans les SMA sans SGE dédié car, une fois encore, aucun mécanisme permettant de signaler une exception en dehors de l’entité active défaillante n’est intégré au modèle d’exécution.
5.2.2
Le cas des composants RRA dans .NET
Les composants RRA de .NET et CORBA sont présentés en section 4.2.3 du chapitre 2. Si une exception est signalée par une méthode invoquée de manière asynchrone dans .NET (mécanisme de callback vu en section 4.2.3 du chapitre 2), aucun comportement n’est prévu dans la spécification. Cette dernière invite d’ailleurs le développeur à veiller à ce qu’aucune exception ne puisse être signalée par une méthode invoquée de manière asynchrone car cela peut bloquer le système [Mic04].
5.2.3
Le cas des composants RRA dans CORBA
CORBA [LM97, Sie00] fournit deux mécanismes d’invocation asynchrone pour traiter les réponses après que l’information ait été diffusée et traitée : Dans le premier cas, au travers d’objets partagés qui possèdent une structure composite capable de stocker les réponses standards comme exceptionnelles (mécanisme pull). Dans le second cas, par un mécanisme de callback (mécanisme push, cf. section 4.2.3 du chapitre 2). Dans ce dernier cas, il est possible d’associer deux méthodes à un callback : une pour les réponses standards et une pour traiter les réponses exceptionnelles. Le principal biais de l’utilisation de ce modèle (comme pour .NET) est qu’il n’offre aucun moyen de représentation explicite et structurée des collaborations entre activités collectives : chacune des activités initiées de manière asynchrone est isolée et aucun mécanisme de propagation des exceptions n’est donc fourni. 68
5. GESTION D’EXCEPTIONS DANS LES PLATES-FORMES À BASE DE COMPOSANTS LOGICIELS 5.2.4
Le modèle à gardien pour composants RRA
Le système à gardien pour les composants logiciels proposé par A NAND T RIPATHI et ROBERT M ILLER [MT03] est comparable à celui qu’ils ont proposé pour les SMA (cf. section 4.2).
5.3 Gestion d’exceptions pour les composants interagissant par émission d’information Que ce soit dans le cadre de communications synchrones ou asynchrones, les entités logicielles communiquant par informations (c’est-à-dire par événements ou par abonnements à des canaux de communication), comme les composants ES et EA vus en section 4.2.4 du chapitre 2, ne posent pas de problèmes concernant la gestion des exceptions. En effet, dans tous les cas, l’émetteur d’une information n’attend pas de réponse, ni standard ni exceptionnelle, relative à l’émission de cette information y compris dans le cas des communications synchrones où l’entité émettrice attend que le middleware lui rende le flot d’exécution. Cette approche s’explique par le fait que les systèmes où les interactions sont à base d’informations ont été conçus pour découpler au maximum les entités logicielles. Par exemple, la spécification des JavaBeans précise qu’une exception signalée dans un composant suite à la notification d’un événement 5 est traitée par le répartiteur d’événements du middleware (cf. section 4.2.4 du chapitre 2 et Figure 3.19). Ce dernier traite généralement l’exception de manière très générique en écrivant l’état de la pile d’exécution d’un thread dans une console 6 .
(a) communications synchrones
(b) communications asynchrones
F IG . 3.19 – Gestion d’exceptions dans des composants interagissant par événements Dans le cadre des communications asynchrones, on peut prendre l’exemple des Message Driven Beans (MDB) utilisés en tant que composants EA (cf. section 4.2.4 du chapitre 2). Dans ce cas, les 5
Dans la spécification JavaBeans, les informations sont échangées entre composants sous la forme de notification d’événements. 6 Nous avons vérifié ce comportement avec le BDK (Beans Development Kit).
69
CHAPITRE 3. GESTION D’EXCEPTIONS : ÉTAT DE L’ART MDB utilisent le même modèle d’exécution que lorsqu’ils sont utilisés comme composants RRA. L’utilisation des MDB en tant que composants EA constitue leur utilisation principale. Cela justifie l’absence d’un vrai mécanisme de gestion d’interactions de type requête/réponse (cf. Figure 3.19(b)). La gestion d’exceptions dans le cadre des interactions par informations est donc pour ainsi dire inexistante. Il pourrait toutefois être intéressant d’étudier la possibilité d’intégrer à ce paradigme le signalement d’exceptions dans le cadre des modèles à continuation dans lesquels il est possible de préciser, pour chaque activité, à quelle entité une exception doit être signalée [The83] (cf. section 1.2). Cette perspective n’est pas étudiée dans cette thèse dans la mesure où cette dernière est axée autour de la problématique des interactions par requête/réponse.
6 Cahier des charges résultant de l’étude Notre étude est dédiée aux modèles dans lesquelles des entités actives interagissent par requête/réponse au travers d’un mécanisme de messagerie asynchrone pour établir des collaborations. Nous présentons dans cette section les qualités des SGE qui sont attendues pour répondre aux besoins des programmeurs dans un tel contexte.
6.1 Réactivité du système lors du signalement d’une exception Effectuer plusieurs traitements en concurrence dans une même entité logicielle active est possible si celle-ci peut créer un nouveau processus lors de l’arrivée d’un nouveau message pour le traiter. Ce principe permet de limiter les temps d’attente lors de l’émission d’une requête vers une entité logicielle déjà sollicitée. On imagine que le programmeur attende, dans le cadre d’un système concurrent, une telle réactivité y compris au niveau de la gestion des exceptions pour laquelle nous avons identifié deux qualités : – Les messages notifiant une exception doivent être prioritaires afin d’interrompre au plus vite l’exécution des activités devenues inutiles, – Le système de gestion d’exceptions doit interrompre l’exécution standard d’une activité dès que celle-ci entame un traitement exceptionnel.
6.2 Respect de la contextualisation lors du signalement des exceptions Dans le cas le plus classique, la réponse à une requête est traitée dans l’entité ayant émis la requête correspondante. Par exemple, dans un langage procédural, chaque appel d’une procédure définit un contexte d’exécution qui comprend : le nom de la procédure, les paramètres qui ont été passés lors de son invocation et les valeurs de ses variables locales. La pile des appels représente l’imbrication des contextes d’exécution. Retourner la réponse relative à une requête au contexte appelant permet d’assurer qu’elle puisse être traitée pertinemment (dans un contexte dans lequel on sait pourquoi et dans quelles conditions la requête correspondante a été émise). Les exceptions étant des réponses 70
6. CAHIER DES CHARGES RÉSULTANT DE L’ÉTUDE particulières, il convient qu’elles soient elles-aussi notifiées en remontant le long des contextes d’exécution [Mey88]. Une telle pratique garantit le respect de la contextualisation lors du signalement des exceptions et donc la possibilité de définir des handlers pertinents. Le contexte d’exécution dans lequel est levée une exception n’est pas celui dans lequel un handler correspondant peut être défini : si on savait comment traiter une situation particulière dans le contexte d’une activité donnée, on ne lèverait pas, par définition d’exception dans celle-ci. Par exemple, la procédure qui effectue une division ne peut retourner de réponse standard valide quand le dénominateur est nul et ne peut traiter ce cas particulier localement de manière pertinente puisque, dans le contexte de cette procédure, on ignore à quoi correspond le calcul demandé. C’est pourquoi le problème d’une demande de division avec dénominateur nul n’est pas traité au niveau de la procédure de division et que cette dernière lève alors une exception qui sera signalée à l’appelant correspondant. Nous prenons pour principe général que, quand une activité signale une exception, son activité appelante est le meilleur endroit où définir un traitement pour cette exception : le contexte d’exécution appelant est celui dans lequel on sait pour quelle raison on a fait appel à l’activité ayant signalé une exception et donc le contexte dans lequel on peut savoir comment traiter pertinemment l’exception signalée. Si l’on se réfère à l’exemple de l’agence de voyage présenté dans le chapitre précédent, il est nécessaire que l’échec du traitement d’une demande de tarif par une agence de voyage auprès d’un prestataire soit notifié à l’émetteur de la requête par un signalement d’exception car aucune autre entité n’est capable de traiter pertinemment une telle situation. Ce principe se différencie de celui proposé dans les systèmes à continuation dans des langages à acteurs comme Act1 et Act2 [The83, MNC + 89] ou dans certains langages à objets permettant des exécutions concurrentes comme ABCL/1 [IY91]. Le principe des systèmes à continuation est que, lors de l’envoi d’une requête, il est précisé dans cette dernière à quelle entité doit être retournée la réponse (cf. section 1.2). L’avantage de cette approche est que l’on peut distinguer l’entité à qui répondre en fonction du type de la réponse (standard ou exceptionnelle). La politique de respect de la contextualisation est devenue une norme dans les langages où la communication est synchrone et nous considérons que ce principe devrait être appliqué à toute interaction de type requête/réponse. Malheureusement, comme nous l’avons vu en sections 5.2 et 4, ce comportement n’est pas toujours adopté dans le cadre des interactions de type requête/réponse avec communications asynchrones, les réponses standards et exceptionnelles étant souvent traitées par des entités distinctes.
6.3 Asynchronisme des communications et coordination des activités concurrentes lors d’un signalement d’exception Du point de vue de la gestion d’exceptions, il est naturel que le développeur souhaite avoir la possibilité d’associer des handlers aux activités exécutées par les entités logicielles actives et de pouvoir exprimer et gérer l’impact d’une exception sur les activités concernées. Pour satisfaire pleinement 71
CHAPITRE 3. GESTION D’EXCEPTIONS : ÉTAT DE L’ART ce besoin, un mécanisme de signalement des exceptions adéquat doit être défini : le respect de la contextualisation peut être assuré par un signalement des exceptions à partir d’un contexte d’exécution local vers le contexte d’exécution de l’activité (collective) englobante et, récursivement, vers le contexte d’exécution plus global de l’activité (collective) englobante. Pour ce faire, il est nécessaire de représenter les activités comme des entités à part entière pouvant en encapsuler d’autres (celles qu’elles invoquent) afin de pouvoir contrôler leur exécution et de gérer la coordination entre activités concurrentes. Dans la section 2.2 du chapitre 2, nous avons conclu que la gestion de la concurrence coopérative induit un modèle d’exécution autorisant la représentation explicite des activités collectives et donc de l’imbrication de ces activités [RK01]. Il est donc nécessaire qu’un SGE s’intègre dans un tel modèle d’exécution pour être efficace en milieu concurrent. D’autre part, le système de gestion d’exceptions doit interrompre toutes les sous-activités qui sont englobées dans une activité (collective) et qui sont toujours en cours d’exécution lorsque l’activité englobante entame un traitement exceptionnel dans le cadre d’un SGE à terminaison. En effet, ces sous-activités sont alors obsolètes car leurs résultats ne seront pas exploités. Cette pratique permet d’éviter que des activités continuent à consommer inutilement des ressources. Mettre en place un système à terminaison en milieu concurrent implique donc l’extension des mécanismes de terminaison proposés pour les langages séquentiels. En reconsidérant l’exemple de l’agence de voyage, si une exception interrompt l’exécution standard de l’activité de mise en relation du client et du prestataire sélectionné, ses sous-activités (exécutées par le client et le prestataire sélectionné) relatives à l’établissement du contrat incriminé doivent également être interrompues.
6.4 Concertation d’exceptions signalées par des activités concurrentes Dans la mesure où, dans le contexte défini précédemment, une activité en cours d’exécution peut englober plusieurs activités qui s’exécutent concurremment, il est important de donner au programmeur des outils pour qu’il puisse prendre en compte, au niveau d’une activité globale, les signalements concurrents d’exceptions en provenance de ses sous-activités [CR86, BZC95, HA98, Iss01, TILR02]. Par exemple, une activité qui a envoyé des requêtes à un ensemble d’entités et qui reçoit en réponse une ou plusieurs exceptions ne doit pas réagir immédiatement tant que ces dernières n’empêchent pas son déroulement standard. Par contre, des exceptions n’ayant pas individuellement de pertinence peuvent relever d’un problème général si on les considère dans leur ensemble (elles peuvent par exemple toutes résulter d’un unique problème de fiabilité des communications). Cette problématique peut être gérée par un mécanisme de concertation à l’image de celui que nous avons présenté en section 3.3. Si l’on reprend l’exemple de l’agence de voyage, une exception signalée par un prestataire en réponse à une demande de tarif émise par une agence de voyage n’empêche pas fatalement le traitement de la demande du client correspondant. En effet, un résultat partiel peut suffire à répondre aux besoins du client. Par exemple, un bon compromis peut être d’attendre qu’un certain taux de réponses exceptionnelles soit atteint avant de considérer que l’exécution du traitement de la requête du client 72
7. TRAVAUX CONNEXES soit interrompue par une levée d’exception.
7 Travaux connexes Sun, dans sa nouvelle version de Java [Sun04b] (la version 1.5), parue après nos travaux sur SaGE, propose des outils de gestion de la concurrence qui n’étaient pas disponibles dans les versions 1.4 et antérieures. Le nouveau paquetage java.util.concurrent propose en effet de classiques outils de synchronisation par sémaphores mais aussi un mécanisme de futur permettant l’invocation asynchrone de tâches. Notons que le mécanisme proposé signale une exception quand une tâche invoquée de manière asynchrone se termine elle-même par un signalement d’exception. Dans une telle situation, il est d’ailleurs possible de récupérer des informations sur ce qui a provoqué cette interruption de l’exécution globale. Bien que cette bibliothèque ne permette pas encore de gestion globale d’exceptions dans le contexte d’une arborescence d’activités (et n’offre a fortiori pas de mécanismes tels que celui de la concertation d’exceptions signalées concurremment), nous observons la prise en compte de la problématique de la gestion d’exceptions dans le contexte d’activités concurrentes devient une demande forte de la part des industriels et que les éditeurs commencent à prendre en compte ce phénomène.
8 Synthèse Les SGE fournis avec les langages de programmation séquentiels comme C/C++ et Java respectent la contextualisation lors du signalement des exceptions et offrent de fait un pouvoir d’expression suffisant aux programmeurs dans les langages séquentiels (cf. sections 2 et 6 et Figure 3.20). Si l’on s’intéresse au cas des langages de programmation auxquels on a ajouté des outils permettant d’introduire de la concurrence (cf. Figure 3.20), Multilisp, langage pour lequel un SGE dédié a été proposé, ne garantit pas la propagation des exceptions si le programmeur exporte de parallélisme hors d’une évaluation (cf. section 3.2.1). Quant aux threads Java, aucun véritable outil de coordination des activités concurrentes, de concertation des exceptions, ni même de respect de la contextualisation ne leur est associé (l’entité qui a initié l’exécution d’un thread défaillant n’en sera en effet pas informée). Le mécanisme optionnel des ThreadGroups (cf. section 3.3.1) n’apporte qu’une réponse partielle à la problématique de la coordination d’activités concurrentes bien qu’il permettre la concertation (ad hoc) d’exceptions. Quand au SGE qui a été proposé pour ProActive, il ne permet pas de coordonner les activités concurrentes puisqu’aucune représentation des collaborations entre activités concurrentes n’y est permise. Un point faible commun de ces propositions de la section 3.2, réside donc dans le fait que les collaborations entre activités concurrentes ne sont pas gérées ou tout du moins pas de manière adaptée. Parmi les systèmes permettant des formes de concertation d’exceptions notifiées concurremment nous avons recensé, en section 3.3, deux modèles : 73
CHAPITRE 3. GESTION D’EXCEPTIONS : ÉTAT DE L’ART – celui de Valérie Issarny qui respecte la contextualisation et permet de coordonner les activités concurrentes mais qui a été proposé pour un langage dans lequel on invoque de manière synchrone des multiprocédures, – et celui de Serge Lacourte qui se contente de distinguer les activités concurrentes en fonction de leur criticité.
F IG . 3.20 – Récapitulatif des SGE dans la programmation classique Comme nous l’avons vu en section 6.2, les langages à acteurs comme Act1 et Act2, ancêtres des SMA, utilisent des modèles d’exécution à continuation pour transmettre les réponses aux requêtes ouvrant ainsi la porte au non-respect de la contextualisation lors de la gestion d’exceptions. Nous avons pu constater (cf. section 4) que les agents logiciels ont également hérité de ce défaut. Le problème est d’autant plus flagrant avec les SMA qui ne disposent pas d’un SGE dédié (cf. section 4.1). En effet, cette solution entre en contradiction avec les bonnes pratiques du génie logiciel qui recommandent que toute la gestion des exceptions se fasse au travers de mécanismes dédiés comme les SGE. Un SGE à superviseurs (cf. section 4.2) pour les SMA ne constitue pas une bonne solution parce qu’il ne répond pas au besoin de respect de la contextualisation et qu’il a besoin, pour être efficace de violer les principes d’encapsulation et d’autonomie des agents. Quant au modèle à gardien (cf. section 4.2), très générique, il impose une gestion ad hoc du mécanisme de signalement sans garantir la vérification des qualités identifiées en section 1.1.1. Dans le contexte des composants RRA, les solutions à gardiens posent le même problème que dans les SMA. Les MDB n’offrent pas de SGE a proprement parler et posent les même problèmes que les SMA sans SGE dédié. Dans le contexte de CORBA et de .NET, l’utilisation de callbacks ne permet pas de respecter la contextualisation lors de la réception des réponses. En effet, les exceptions sont bien signalées à l’entité appelante mais pas dans le contexte d’exécution appelant. De plus, aucune de ces platesformes ne propose de moyen de gérer la coordination des activités concurrentes ni de mécanisme ad hoc de concertation des exceptions. Enfin, les composants interagissant par informations ne disposent que de fonctionnalités très limitées en terme de gestion d’exceptions mais, comme nous l’avons souligné en section 5.3, cette limitation ne pose pas de problème dans la mesure où l’émission d’un événement n’implique pas d’attente de réponse. 74
8. SYNTHÈSE
F IG . 3.21 – Récapitulatif des SGE dans les SMA et systèmes à composants logiciels Dans ce chapitre, nous avons identifié les qualités attendues d’un système de gestion d’exceptions et observé dans quelle mesure les systèmes existants y répondent (cf. Figures 3.20 et 3.21). Nous avons pu observer un lien étroit entre SGE et modèle d’exécution dans la mesure où les handlers sont généralement associés aux unités de programme qui structurent les activités des entités logicielles actives. Nous avons également observé que pour traiter efficacement les exceptions dans un système faisant entrer en jeu de la concurrence coopérative, il était nécessaire de disposer d’une représentation globale des activités afin de pouvoir gérer le signalement des exceptions en remontant les contextes d’exécution (cf. sections 2.2 et 6.3).
75
CHAPITRE 3. GESTION D’EXCEPTIONS : ÉTAT DE L’ART
76
Chapitre 4
SaGE, un SGE dédié aux SMA et aux plates-formes à composants logiciels : Spécification Sommaire 1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
2
Hypothèses sur le contexte d’application . . . . . . . . . . . . . . . . . . . . .
78
3
Statut des exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
4
Définition et association des handlers . . . . . . . . . . . . . . . . . . . . . . .
80
4.1
Les handlers du langage sous-jacent . . . . . . . . . . . . . . . . . . . . .
80
4.2
Définition et association des handlers SaGE . . . . . . . . . . . . . . . . .
81
Signalement des exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.1
Levée des exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.2
Mécanisme de signalement . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.3
Concertation d’exceptions signalées par des activités concurrentes . . . . .
87
5.4
Algorithme de signalement . . . . . . . . . . . . . . . . . . . . . . . . . .
90
5.5
Traitements effectués par les handlers SaGE . . . . . . . . . . . . . . . . .
92
Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
5
6
Après avoir vu l’existant en termes de gestion d’exceptions dans les systèmes multi-agents et les plates-formes à base de composants logiciels dans le chapitre précédent, celui-ci présente SaGE (Système avancé de Gestion d’Exceptions) [SDUV03, SUVD03, SDUV04, SVUD04], un système de gestion d’exceptions dédié aux systèmes multi-agents et aux plates-formes à base de composants logiciels qui couvre les problématiques et les besoins identifiés en section 6 du chapitre 3. Nous présentons dans ce chapitre la spécification de SaGE puis, dans le chapitre suivant, nous décrirons comment nous l’avons conçu puis comment nous l’avons appliqué au paradigme multi-agents et à celui des composants logiciels. 77
CHAPITRE 4. SAGE, UN SGE DÉDIÉ AUX SMA ET AUX PLATES-FORMES À COMPOSANTS LOGICIELS : SPÉCIFICATION
1 Introduction Un système de gestion d’exceptions doit respecter non seulement le paradigme de programmation dans lequel il est intégré mais aussi un ensemble de critères que nous nous sommes efforcés d’identifier dans le chapitre précédent. En particulier, il convient de souligner la nécessité de garder en continu la trace des activités concurrentes collectives (cf. section 6.3 du chapitre 3). Ce pré-requis n’étant selon nous pas vérifié dans les plates-formes existantes (cf. chapitre 2), nous commençons par décrire la notion de service, que nous proposons comme base pour construire SaGE.
2 Hypothèses sur le contexte d’application Notre proposition vise à répondre aux besoins des programmeurs en termes de gestion d’exceptions dans le développement d’applications au sein desquelles des entités actives (agents ou composants logiciels) : – sont codées en programmation orientée-message, – s’exécutent concurremment, – interagissent par requêtes/réponses, – communiquent de manière asynchrone. Dans le cas des systèmes multi-agents, ces entités actives sont les agents. Dans le cas des plates-formes à base de composants logiciels, elles sont des composants répondant à ces mêmes critères. Par ailleurs, dans cette proposition, les canaux de communication sont supposés fiables et nous ne prenons donc pas en compte les éventuelles pertes de messages sur le réseau dans notre modèle. Cette problématique relève non pas de la programmation des entités logicielles mais de celle, à plus bas niveau, du middleware. Nous traitons dans ce chapitre le cas général (aussi bien les systèmes multi-agents que les platesformes à base de composants logiciels), le terme générique entité active sera utilisé en lieu et place d’agent ou de composant logiciel. Les spécificités éventuelles en fonction du paradigme seront explicitées dans le chapitre suivant dans lequel on trouve l’implémentation de SaGE dans le cadre de MADKit [vD04] pour les systèmes multi-agents en section 2 et dans le cadre de JOnAS [JOn04] pour les plates-formes à base de composants logiciels en section 3.
78
3. STATUT DES EXCEPTIONS Afin que SaGE puisse répondre à nos attentes, nous définissons les notions de service et de représentant de rôle : Définition : Un service – représente un savoir-faire d’une entité active, – contient les éléments nécessaires à sa propre exécution qui peut être contrôlée par son entité active propriétaire. Toute activité d’une entité active est représentée par l’exécution d’un service. Quand une requête émise par une entité active A est reçue et acceptée par son entité active destinataire B, l’exécution du service correspondant est initiée par B qui est l’entité active propriétaire de ce service. Ces invocations de services par d’autres en cascade engendrent une arborescence de services dont la construction et la gestion seront détaillés dans le chapitre suivant.
Définition : Un représentant de rôle – représente un ensemble d’entités actives remplissant une fonctionnalité commune (à l’image des rôles dans les communautés d’agents vues en section 3.2 du chapitre 2), – assure la gestion des requêtes groupées en les transmettant aux entités actives concernées et en récoltant les réponses correspondantes.
3 Statut des exceptions Une exception est conceptuellement la même chose dans le contexte qui nous intéresse que dans celui des langages classiques. Nous apprécions l’idée introduite dans [Nix83] de distinguer, pour toute exception, le concept de ses occurrences. Dans un langage à objets, cet article a proposé de représenter un concept (par exemple le concept de “division par zéro”) par une classe et une occurrence de ce concept (le signalement effectif d’une division par zéro) par une instance de cette classe. Nous souhaitons conserver cette vision dans notre SGE. Dans le cadre d’une implémentation du langage de programmation orientée-message au dessus d’un langage à objets (c’est les cas dans les plates-formes que nous étudions), il est possible de se greffer au système de classes d’exceptions sous-jacent. Les exceptions SaGE sont donc des instances de la classe SaGEException qui dérive de la classe racine des exceptions du langage sous-jacent correspondant. Par exemple, dans le cas d’une plate-forme basée sur le langage Java, la classe SaGEException est une sous-classe de la classe Exception (cf. Figure 4.1). Cette classe dédiée permet non seulement une intégration cohérente de SaGE dans le SGE du langage sous-jacent mais aussi la possibilité de définir dans cette classe des éléments spécifiques à SaGE comme la récupération de l’identité de l’entité active à l’origine de l’exception. 79
CHAPITRE 4. SAGE, UN SGE DÉDIÉ AUX SMA ET AUX PLATES-FORMES À COMPOSANTS LOGICIELS : SPÉCIFICATION public class SaGEException extends Exception { private SaGEActiveEntity signaledBy ; public SaGEException(String s) { super(s) ; // Récupération de l’entité défaillante signaledBy = getcurrententity() ; } public ActiveEntity getsignaler() { return signaledby ; } }
F IG . 4.1 – Définition de la classe SaGEException en Java
4 Définition et association des handlers Dans cette section, nous décrivons, d’une part, à quelles entités on peut associer des handlers et, d’autre part, à quelle utilisation les handlers sont destinés en fonction du type d’entité auquel ils sont associés. Un handler est classiquement défini par l’ensemble de types d’exceptions qu’il peut capturer et par le traitement associé.
4.1 Les handlers du langage sous-jacent Les handlers du langage sous-jacent sont associés à des blocs de code d’un service. Ils traitent les exceptions au niveau du langage de programmation et peuvent lever des exceptions au niveau du service dans le contexte duquel ils ont été définis (cf. figure 4.2). try{ // Tentative de réservation d’un voyage reserve(i) ; } catch (No_vacancy_Exception exc){ signal (new SaGEException (“No Vacancy”, this)) ; }
F IG . 4.2 – Cohabitation de SaGE et du SGE de Java
80
4. DÉFINITION ET ASSOCIATION DES HANDLERS
4.2 Définition et association des handlers SaGE Note : Par la suite, quand la recherche de handler se fait au niveau d’une entité logicielle, nous dirons que l’exception pour le traitement de laquelle un handler est recherché est notifiée à cette entité logicielle. Les handlers SaGE peuvent être associés à diverses unités de programme : 1. Un handler associé à un envoi de requête peut traiter une exception signalée dans le code exécuté suite à l’envoi de cette requête. Nous reprenons ici le principe vu en section 3.2.1 du chapitre 3 pour le langage MultiLisp (qui permet l’association d’un handler à une évaluation parallèle d’expression) en permettant l’association d’un handler à un envoi de requête. Une exception signalée dans un sous-service qui est par la suite notifiée à son service parent pourra être traitée par un tel handler. Cette capacité permet, par exemple, de réagir différemment lors de la notification d’une exception signalée en fonction, non seulement de la nature de l’exception signalée, mais aussi du sous-service par lequel elle a été notifiée. Un autre intérêt majeur de cette capacité réside dans le fait qu’elle permet le traitement d’une réponse exceptionnelle sans affecter l’exécution du service parent puisque ce traitement n’est relatif qu’à cette émission de requête et non au service dans son ensemble. On peut imaginer, en reprenant l’exemple de l’agence de voyage, que le programmeur souhaite associer un handler à la requête groupée émise par le service Demande de Tarifs de Agence afin de traiter une exception signalée par le représentant de rôle correspondant (cf. figure 4.3) en signalant au service une exception qu’il pourra traiter. envoyer_requete ("Prestataires", "Prix", "void handle (TooManyProvidersFailedException exc) { signal (new NetworkException()) }") ;
F IG . 4.3 – Exemple en pseudo-langage d’association d’un handler à une requête 2. Un handler associé à un service est conçu pour capturer et traiter toute exception notifiée à ce service ou signalée par lui-même. Dans le contexte de l’exemple de l’agence de voyages, on peut imaginer un handler associé au service initial du client, Organiser un voyage, pour capturer les exceptions atteignant la racine de l’arborescence des services (cf. figure 4.4). 3. Un handler associé à une entité active du système permet de capturer et de traiter toute exception notifiée par et durant l’exécution d’un service encapsulé par cette entité active. Par exemple, la destruction d’une entité active, la gestion de statistiques ou le maintien de la cohérence de ses données peuvent être gérés aux travers de tels handlers. 81
CHAPITRE 4. SAGE, UN SGE DÉDIÉ AUX SMA ET AUX PLATES-FORMES À COMPOSANTS LOGICIELS : SPÉCIFICATION Service "Organiser_un_voyage” { ... handle (SaGENetworkException exc){ afficher(“Impossible de répondre à la demande”) fermer_application } ... }
F IG . 4.4 – Exemple en pseudo-langage d’association d’un handler à un service Dans le cadre de l’exemple de l’agence de voyages, on peut imaginer l’association d’un tel handler à l’Agence afin de comptabiliser le nombre d’échecs rencontrés et de resignaler l’exception à traiter (cf. figure 4.5). Entité_Active "Agence" { ... handle (NetworkSaGEException exc){ //On comptabilise le nombre d’échecs afin de pouvoir // établir des statistiques de Quality of Service (QoS) incrémenter (nombre_échecs) // Puis on resignale l’exception resignaler (exc) } ... }
F IG . 4.5 – Exemple en pseudo-langage d’association d’un handler à une entité active
4. Un handler associé à un représentant de rôle permet de capturer et traiter toute exception signalée dans le code exécuté suite à un envoi de requête groupée. Par exemple, des résultats partiels ou des statistiques de qualité de service (Quality of Service (QoS)) [HHRS01, XNVW00, Hal00] peuvent être envoyés par de tels handlers. Dans le cadre de l’agence de voyage, on peut associer un tel handler au représentant de rôle des prestataires pour traiter toute exception signalée dans le cadre du traitement des réponses des prestataires (cf. figure 4.6) en envoyant des résultats partiels en cas de signalement d’exception. Maintenant que nous avons vu comment définir des handlers dans SaGE et à quelles entités on peut les associer, la section suivant présente le mécanisme de signalement des exceptions qui permet la recherche et l’invocation de ces handlers. 82
5. SIGNALEMENT DES EXCEPTIONS
Représentant_Role ...
"Prestataires" {
handle (FewBadProvidersException exc){ donner_réponses_disponibles() } ... }
F IG . 4.6 – Exemple en pseudo-langage de handler associé à un représentant de rôle
5 Signalement des exceptions 5.1 Levée des exceptions Les exceptions SaGE sont levées, à l’intérieur du code de services ou de handlers, par une primitive dédiée, à l’image du throw du langage Java,. Les deux systèmes de gestion d’exceptions cohabitent : les exceptions du langage sous-jacent, traitées par les handlers associés à des blocs de code, peuvent être transformées en exceptions de plus haut niveau par l’invocation de la primitive dédiée de SaGE dans un de ces handlers (cf. section 4.1). Cette primitive dédiée prend classiquement en paramètre l’exception à signaler et son invocation déclenche le mécanisme de signalement de SaGE.
5.2 Mécanisme de signalement 5.2.1
Signalement des exceptions
Le cœur d’un système de gestion d’exceptions est sa politique de recherche de handlers. Dans SaGE, quand une exception est signalée lors de l’exécution d’un service S’, le mécanisme de signalement suspend l’exécution de S’ puis le mécanisme de recherche de handler est initié. Avant de voir comment le mécanisme de signalement effectue la recherche de handler, notons ces remarques relatives au passage en traitement exceptionnel d’un service S’ : – Son exécution est interrompue (interruption de l’exécution standard et inhibition de l’écoute des messages entrants), – Les éventuels sous-services de S’ ne sont pas interrompus lors de cette première phase du traitement exceptionnel, – S’ entre en section critique : aucun signalement d’exception ultérieur ne déclenche à nouveau le mécanisme de traitement exceptionnel de S’, – Les autres services exécutées par l’entité active propriétaire de S’ ne sont pas affectés. Lors du signalement d’une exception à un service, un handler adapté au traitement de l’exception levée est tout d’abord recherché dans la liste des handlers associés au service défaillant. Si un tel 83
CHAPITRE 4. SAGE, UN SGE DÉDIÉ AUX SMA ET AUX PLATES-FORMES À COMPOSANTS LOGICIELS : SPÉCIFICATION handler est défini, il est invoqué. Sinon, la recherche se poursuit parmi les handlers associés à l’entité active A’ qui exécute S’. Qu’un tel handler soit défini ou non, S’ se termine.
F IG . 4.7 – Recherche de handler dans SaGE Comme illustré en figure 4.7, si aucun handler n’est trouvé au niveau de A’, la recherche se poursuit dans l’entité active qui a requis S’ . Notons que que c’est à cette étape du processus de recherche de handler que ce dernier se fait de manière asynchrone. En effet, ce dernier passe alors de l’entité active A’ à celle ayant déclenché l’exécution de S’ (entité appelante). Deux cas se distinguent : – Si S’ a été initié par une requête standard, la recherche se poursuit au niveau de la requête qui a initié le service défaillant S’ puis au niveau du service S qui a requis l’exécution de S’. – Si S’ a été initié par une requête groupée, la recherche se poursuit au niveau du représentant de rôle qui traite la requête groupée correspondante puis au niveau de la requête ayant initié la requête groupée concernée et ensuite au niveau du service S qui a émis cette dernière. Si aucun handler approprié n’est trouvé durant un tel cycle, le processus de recherche est réitéré (la démarche globale est illustrée en figure 4.8 (a) et (b)) jusqu’à ce qu’un handler approprié soit trouvé et invoqué ou le top-level (service initial) atteint. Dans ce dernier cas, l’entité active propriétaire du service initial est détruite par le handler par défaut (si le programmeur n’a pas redéfini ce dernier). Ce mécanisme de recherche de handler assure le respect de la contextualisation lors du signalement des exceptions (cf. section 6 du chapitre 3). 84
5. SIGNALEMENT DES EXCEPTIONS
F IG . 4.8 – Cheminement des exceptions dans SaGE Si une exception est signalée lors de l’exécution d’un handler H associé à une entité E, le mécanisme de recherche de handler reprend au niveau suivant celui de E dans le mécanisme de recherche pour exécuter un handler pouvant traiter cette nouvelle exception . 5.2.2
Terminaison des services
SaGE est un modèle à terminaison. Cela implique que les services au niveau desquels le mécanisme de recherche de handler passe se terminent systématiquement. On retrouve ici le même principe que dans les systèmes de gestion d’exceptions à terminaison des langages à objets dans lesquels on 85
CHAPITRE 4. SAGE, UN SGE DÉDIÉ AUX SMA ET AUX PLATES-FORMES À COMPOSANTS LOGICIELS : SPÉCIFICATION dépile les contextes d’exécution de la pile d’exécution pour rechercher les handlers. Dans la mesure où la recherche de handler s’effectue en remontant une arborescence de services, il se peut qu’un service se termine de manière exceptionnelle alors qu’il a encore des sous-services en cours d’exécution : on parle alors de sous-services pendants. De même, un service peut se terminer de manière standard alors qu’il a encore des sous-services pendants. C’est pourquoi, dans SaGE, quand un service termine son exécution, que ce soit de manière standard ou exceptionnelle, la terminaison de tous ses sous-services pendants est effectuée afin d’éviter que ces derniers ne consomment inutilement des ressources (cf. figure 4.9).
F IG . 4.9 – Exemple de terminaison forcée d’un service pendant Par ailleurs, dans la mesure où la réactivité du système est un des facteurs de qualité pris en compte dans la conception de SaGE, une réponse exceptionnelle doit faire l’objet d’un traitement immédiat. Cette politique assure que des services ne poursuivent pas de traitements inutiles (cf. section 6.1 du chapitre 3). Après avoir vu les mécanismes de signalement des exceptions et de terminaison des services, 86
5. SIGNALEMENT DES EXCEPTIONS voyons le mécanisme de concertation des exceptions signalées concurremment que nous avons intégré à SaGE.
5.3 Concertation d’exceptions signalées par des activités concurrentes 5.3.1
Principe général de la concertation des exceptions dans SaGE
Dans SaGE, une exception notifiée à un service n’est pas toujours fatale pour son exécution. En effet, un service peut envoyer de manière redondante des requêtes à de nombreuses entités actives pour obtenir de meilleurs résultats en terme de rapidité et/ou de fiabilité (cf. chapitre 2) et ne pas avoir besoin de l’intégralité des réponses correspondantes. C’est le cas, dans l’exemple de l’agence de voyages, quand un représentant de rôle gérant les requêtes groupées envoyées à destination de prestataires envoie n requêtes à n prestataires : la défaillance de peu d’entre eux n’est pas critique car seule celle de tous (ou d’un ratio suffisant d’entre eux) est préjudiciable. Cet exemple est illustré en figure 4.10.
F IG . 4.10 – Exemples de résultats de concertations d’exceptions Inspiré par [Iss01] et [Lac90], SaGE intègre un mécanisme de concertation dans le processus de signalement des exceptions qui permet de ne pas réagir face à des problèmes bénins et de collecter les exceptions notifiées pour mieux refléter les problèmes collectifs ou globaux. Ce mécanisme de concertation (cf. sections 6.4 et 3.3 du chapitre 3) est disponible au niveau des services et des représentants de rôles (seules entités auxquelles le programmeur peut associer des fonctions de concertation) car il n’est pas pertinent au niveau des entités actives, et des requêtes. En effet, l’association de handlers à une entité active revenant à l’associer à l’ensemble des services qu’elle exécute, les exceptions sont concertées au niveau des services correspondants par les fonctions de concertation qui leur sont associées. Les exceptions étant déjà concertées au niveau des services, il nous semble a priori inutile de 87
CHAPITRE 4. SAGE, UN SGE DÉDIÉ AUX SMA ET AUX PLATES-FORMES À COMPOSANTS LOGICIELS : SPÉCIFICATION reproduire ce mécanisme au niveau des entités actives qui encapsulent ces derniers. De même, on ne peut associer de fonction de concertation aux requêtes car celles-ci ne peuvent faire l’objet de notifications concurrentes d’exceptions. En effet, une requête correspond à l’invocation d’un seul service, y compris dans le cas d’une requête groupée adressée à un représentant de rôle (une seule réponse est attendue). Définition : Une fonction de concertation est une fonction : – associée à une entité X (service ou représentant de rôle) susceptible de se voir notifier des exceptions concurremment, – exécutée à chaque fois que X se voit notifiée une exception, – destinée à évaluer la pertinence d’un traitement suite au signalement d’exception survenu, – susceptible de générer une exception dite concertée représentant une ou plusieurs exceptions signalées. A chaque notification d’une exception à une entité X, la fonction de concertation f associée à X est invoquée. f évalue la situation au regard du journal de l’ensemble des exceptions qui ont été notifiées à X et retourne, si nécessaire, une exception concertée 1 qui sera alors signalée à X, déclenchant alors le processus de recherche de handler pour traiter l’exception concertée. Si f ne retourne pas d’exception concertée, l’exécution suit son cours de manière standard mais l’exception notifiée a été journalisée et pourra alors être prise en compte lors de la prochaine évaluation de f. 5.3.2
Concertation d’exceptions au niveau des services
Pour permettre la concertation, les exceptions notifiées à un service donné ne déclenchent pas directement le mécanisme de recherche de handler au niveau de ce dernier. Elles sont stockées dans un journal (log) qui lui est associé pour maintenir un historique des exceptions signalées. Chaque fois qu’une nouvelle exception est journalisée, la fonction de concertation associée à ce service est exécutée pour évaluer la situation, en jouant le rôle de filtre et de fonction de composition. Cette fonction détermine s’il est nécessaire de signaler une exception. Si c’est le cas, l’exception concertée peut être soit la dernière exception notifiée (si elle est assez critique pour cela) soit une nouvelle exception (concertée) évaluée à partir des exceptions journalisées et dont la conjonction relève d’une situation globale critique. On peut par exemple imaginer l’association d’une fonction de concertation à un service chargé de mettre en relation deux entités par l’envoi de deux requêtes. Si seule l’une d’elle échoue, elle pourra signaler une exception notifiant l’indisponibilité de cette entité alors que si les deux échouent, elle pourra en signaler une notifiant une défaillance réseau (DNS, ...) probable. Une fonction de concertation par défaut est associée aux services. Elle retourne la première exception notifiée. Dans ce cas, il n’y a pas de concertation et toute notification d’exception laisse le mécanisme de recherche de handler se poursuivre normalement. 1
La nature de cette exception est laissée au libre choix du programmeur. Il peut s’agir d’une exception déjà notifiée (resignalement) ou d’une nouvelle exception destinée à refléter une situation plus globale.
88
5. SIGNALEMENT DES EXCEPTIONS 5.3.3
Concertation d’exceptions au niveau des représentants de rôles
L’ensemble des requêtes émises par un représentant de rôle pour gérer une requête groupée est transparent pour l’entité active émettrice de cette dernière. Le représentant de rôle sert de collecteur de réponses pour en retourner une unique (composite) au demandeur. Nous avons transposé ce comportement à la gestion d’exceptions pour écrire la fonction de concertation par défaut des représentants de rôle. Cette fonction de concertation par défaut ne retourne aucune exception jusqu’à ce que toutes les sous-activités correspondantes soient terminées. Ceci fait, toutes les exceptions signalées durant le traitement collectif sont regroupées dans une unique exception composite signalée au demandeur. Bien sûr, le programmeur peut redéfinir la fonction de concertation et définir des handlers associés à un représentant de rôle pour, par exemple, signaler une exception concertée qui sera traitée par l’envoi de résultats partiels au demandeur. Par exemple, quand le service du représentant de rôle des Prestataires qui traite les requêtes groupées destinées à ces derniers envoie la demande de tarifs aux entités actives remplissant le rôle Prestataire, aucune de ces requêtes n’est critique individuellement. Ainsi, la fonction de concertation associée au représentant de rôle des prestataires (cf. Figure 4.11) collecte les exceptions signalées sans réagir jusqu’à ce qu’une certaine proportion de ces entités actives ait failli. Elle signale alors une exception concertée indiquant que trop peu de données seront collectées pour rendre le service. nb_exceptions = 0 ; pour i allant de 1 à sous_services.taille si sous_services[i] a signalé une exception incrémenter nb_exceptions si nb_exceptions > 0.3 * sous_services.taille retourner (TooManyProvidersFailedException) sinon retourner (null)
F IG . 4.11 – Exemple en pseudo-code de fonction de concertation associée au représentant des Prestataires Le mécanisme de concertation des exceptions que nous proposons est donc, dans son principe, proche de celui proposé par VALÉRIE I SSARNY dans [Iss01]. L’innovation que nous proposons est l’utilisation de la concertation dans un système où les requêtes, les réponses, et en particulier les exceptions, sont traitées de manière asynchrone. Ce mécanisme de concertation n’est pas, comme dans [Iss01], déclenché une fois pour toute au point de synchronisation des activités concurrentes mais mis en œuvre de façon répétée à chaque notification d’exception. Maintenant que nous avons vu, individuellement, les phases du mécanisme de signalement des exceptions de SaGE, nous pouvons les récapituler en présentant l’algorithme de signalement dans son ensemble. 89
CHAPITRE 4. SAGE, UN SGE DÉDIÉ AUX SMA ET AUX PLATES-FORMES À COMPOSANTS LOGICIELS : SPÉCIFICATION
5.4 Algorithme de signalement Nous avons vu l’ensemble des phases du mécanisme de signalement de SaGE : levée d’exception, recherche de handler, concertation des exceptions et terminaison des services. Nous décrivons dans cette section l’algorithme de signalement sous deux formes différentes afin de montrer, d’une part, l’algorithme de signalement tel qu’il est réparti sur l’ensemble du système et, d’autre part, sous forme récursive pour mieux comprendre son fonctionnement global. Notons que “faire passer un service en exécution exceptionnelle” correspond à changer le statut d’exécution de ce service de telle sorte qu’il vérifie les quatre critères identifiés au début de la section 5.2. Remarque : Tout SGE est doté d’un handler par défaut. Notre proposition ayant vocation à rester générique, nous considérons que le handler par défaut de SaGE ne fait que détruire l’entité active propriétaire du service initial lorsque le top-level est atteint mais qu’il est redéfinissable par le programmeur. Le mécanisme de signalement est déclenché par l’invocation de la primitive de signalement (cf. section 5.1), à l’image du throw du langage Java, qui est illustrée en figure 4.12. Cette primitive est commune aux deux formes d’algorithmes de recherche de handler présentés et est synchrone. signal(SaGEException exc) début le service passe en exécution exceptionnelle on exécute lookup_handler fin
F IG . 4.12 – Définition de la primitive de signalement La figure 4.15 présente, sous une forme récursive, l’algorithme de recherche de handler au niveau d’une unité de programme u pour traiter l’exception exc . Dans cet algorithme de signalement : – la procédure canHandle(SaGEException exc) retourne vrai si un handler adapté au traitement des exceptions du type passé en paramètre est associé à l’unité de programme au niveau de laquelle on recherche un handler, – la procédure exceptional_state(Service u) fait passer le service u en exécution exceptionnelle, – la procédure getCallingService(Request r) retourne le service qui a émis r, – la procédure getSignalingService(SaGEException exc) retourne le dernier service par lequel est passé le mécanisme de recherche de handler pour traiter exc, – la procédure getOwnerEntity(Service u) retourne l’entité active propriétaire de u, – la procédure getRequest(Service s) retourne la requête ayant initié s, – la procédure getSenderEntity(Request r) retourne l’entité active ayant émis r, 90
5. SIGNALEMENT DES EXCEPTIONS lookup_handler(SaGEException exc) début si il existe un handler H pour traiter exc au niveau du service courant alors invoquer H(exc) sinon si il existe un handler H pour traiter exc au niveau de l’entité active propriétaire du service courant alors invoquer H(exc) sinon si service appelant existe alors invocation asynchrone de recherche_asynchrone(exc, service appelant) sinon invoquer handler par défaut // top-level atteint finsi finsi finsi terminer le service courant fin
F IG . 4.13 – Définition du mécanisme de signalement (première partie) recherche_asynchrone(SaGEException exc, Service sa) début si il existe un handler H pour traiter exc au niveau de la requête émise par sa pour invoquer le service défaillant alors invoquer H(exc) sinon exc est ajoutée à la liste des réponses exceptionnelles reçues par sa on invoque la fonction de concertation de sa si elle retourne une exception concertée alors sa passe en exécution exceptionnelle on exécute lookup_handler(exc) sur sa finsi fin
F IG . 4.14 – Définition du mécanisme de signalement (deuxième partie) – la procédure addExceptionalResponse(Service u, Service s, SaGEException exc) modifie les informations sur les sous-services de u en journalisant le fait que son sous-service s s’est terminé exceptionnellement en raison du signalement de l’exception exc. 91
CHAPITRE 4. SAGE, UN SGE DÉDIÉ AUX SMA ET AUX PLATES-FORMES À COMPOSANTS LOGICIELS : SPÉCIFICATION Ces algorithmes donnent une vision globale du mécanisme de signalement et ont pour particularité de comporter un envoi de message asynchrone afin de respecter le paradigme utilisé lors de la recherche de handler sur plusieurs entités actives et de conserver dans le mécanisme de signalement les qualités offertes en terme de performance par l’asynchronisme des communications (cf. section 5.2). Notons que le représentant de rôle n’est pas mentionné ici car il ne constitue qu’un cas particulier dans lequel les services qu’il exécute sont des services auxquels sont conceptuellement associés la fonction de concertation associée au représentant de rôle correspondant. Il nous reste maintenant à voir quels traitements les handlers peuvent exécuter pour traiter une situation exceptionnelle.
5.5 Traitements effectués par les handlers SaGE Pour traiter une exception, un handler SaGE peut : – exécuter des traitements pour gérer les conséquences d’une interruption abrupte de l’exécution d’un service comme rétablir un état cohérent dans une entité active, envoyer des résultats partiels, . . . (cf. Figures 4.4 et 4.6), – ou re-signaler l’exception ou signaler à son tour une nouvelle exception notifiant qu’il n’est en fait pas capable de traiter celle qu’on lui a passée en paramètre (cf. Figures 4.5 et 4.3).
6 Synthèse Ce chapitre a présenté la spécification générale de SaGE. Nous avons, tout d’abord, présenté brièvement la notion de service sur laquelle SaGE s’appuie, nous avons présenté les fonctionnalités de SaGE en termes de gestion d’exceptions (statut des exceptions, sémantique des handlers, mécanisme de signalement). Par rapport aux systèmes de gestion d’exceptions que nous avons recensés dans le chapitre précédent, SaGE a pour essentiel avantage de répondre aux besoins des programmeurs en termes de respect de la contextualisation lors de la recherche de handler. De plus, SaGE permet la définition de handlers à divers niveaux de granularité : requêtes, services, entités actives, représentant de rôles donnant ainsi un plus grand pouvoir d’expression au programmeur. Dans le chapitre suivant, la conception de SaGE et ses deux implémentations sont présentées. La première dans le contexte de la plate-forme SMA MADKit (cf. chapitre 2) et la seconde dans celui de la plate-forme J2EE JOnAS (cf. chapitre 3).
92
6. SYNTHÈSE
lookingup_handler (SaGEException exc, ProgramUnit u) début Selon (getType(u)) cas Request si canHandle(u,getType(exc)) alors handle(u,exc) sinon lookingup_handler (getCallingService(u),exc) finsi cas Entity si canHandle (u,getType(exc)) alors handle (u,exc) sinon // si le service au niveau duquel on recherche un handler est // une racine, on ne peut pas rechercher de handler plus loin. si (getSignalingService(exc) is not root) alors sendMessage( getSenderEntity(getRequest(getSignalingService(exc))),exc) // Envoi asynchrone d’un message au service émetteur de la requête // qui a échoué. Ce message déclenche, à la réception, // l’équivalent de : // lookingup_handler (getRequest(getSignalingService(exc)),exc). finsi cas Service si (u == getSignalingService(exc)) alors // exc est une exception effective retournée par // la fonction de concertation si canHandle(u,getType(exc)) alors handle (u,exc) sinon lookingup_handler (getOwnerEntity(u),exc) finsi terminate(u) sinon addExceptionalResponse(u,getSignalingService(exc),exc) SaGEException cexc = concert(u) si (cexc != null) alors excpetional_state(u) lookingup_handler (u,cexc) finsi finsi fincas fin
F IG . 4.15 – Principe de l’algorithme de signalement
93
CHAPITRE 4. SAGE, UN SGE DÉDIÉ AUX SMA ET AUX PLATES-FORMES À COMPOSANTS LOGICIELS : SPÉCIFICATION
94
Chapitre 5
Conception et Implémentation Sommaire 1
2
3
Représentation des activités individuelles et collectives . . . . . . . . . . . . . .
96
1.1
Représentation des activités individuelles par des services . . . . . . . . .
96
1.2
Représentation des activités collectives par des arborescences de services .
98
1.3
Services et encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
1.4
Exécution concurrente des services dans les entités . . . . . . . . . . . . . 102
1.5
Traitement des requêtes groupées . . . . . . . . . . . . . . . . . . . . . . 104
1.6
Exemple complet d’une exécution standard . . . . . . . . . . . . . . . . . 106
1.7
Le mécanisme de terminaison . . . . . . . . . . . . . . . . . . . . . . . . 109
1.8
Réactivité du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Implémentations de SaGE dans une plate-forme SMA . . . . . . . . . . . . . . 111 2.1
Présentation de MADKit . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
2.2
Gestion des communications pour SaGE . . . . . . . . . . . . . . . . . . . 114
2.3
Définitions des agents SaGE et de leurs services . . . . . . . . . . . . . . . 114
2.4
Statut des exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
2.5
Gestion des requêtes groupées . . . . . . . . . . . . . . . . . . . . . . . . 117
2.6
Évaluation des résultats dans MADKit . . . . . . . . . . . . . . . . . . . . 117
2.7
Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Implémentation de SaGE dans une plate-forme à base de composants logiciels
122
3.1
Présentation de JOnAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
3.2
Définition des SaGEMDBs et de leurs services . . . . . . . . . . . . . . . 125
3.3
Gestion des communications par la modification du conteneurs d’EJB . . . 126
3.4
Gestion des requêtes groupées . . . . . . . . . . . . . . . . . . . . . . . . 129
3.5
Évaluation des résultats dans JOnAS . . . . . . . . . . . . . . . . . . . . . 129
3.6
Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
95
CHAPITRE 5. CONCEPTION ET IMPLÉMENTATION
Nous allons voir dans ce chapitre comment notre proposition, le modèle SaGE, a été conçue en explicitant comment nous avons mis en œuvre la notion de service (cf. section 1) puis nous verrons la mise en œuvre de SaGE [SDUV03, SDUV04, SVUD04] dans le cadre des systèmes multi-agents par une implémentation dans la plate-forme MADKit [vD04] (Multi-Agent Development Kit) en section 2 et dans la plate-forme JOnAS en section 3. Tout au long de ce chapitre, nous continuons à utiliser l’exemple des agences de voyage pour illustrer notre propos.
1 Représentation des activités individuelles et collectives Afin de pouvoir représenter les coopérations entre entités actives, nous avons besoin de modéliser explicitement les activités des entités actives. Pour ce faire, nous avons choisi d’abstraire la notion de service que nous modélisons tels les objets actifs dans le contexte de la programmation concurrente [BGL98, MY00]. Nous prenons alors un nouveau niveau d’abstraction dans la représentation de l’exécution : la granularité des programmes n’est plus la méthode mais le service.
1.1 Représentation des activités individuelles par des services On distingue deux catégories de services : - Les services atomiques dont l’exécution ne requiert pas celle d’autres services. Si on reprend l’exemple de l’agence de voyage utilisé dans les chapitres précédents, le service exécuté par un prestataire pour donner son tarif est atomique car il n’a pas besoin de sous-service pour mener à bien son exécution (cf. Figure 5.4), - Les services complexes dont l’exécution requiert celle(s) d’autre(s) service(s). Par exemple le service exécuté par une agence pour traiter la requête initiale d’un client en sollicitant l’exécution d’autres services pour satisfaire sa demande est un service complexe (cf. Figure 5.4). Tout service complexe maintient un journal (log) pour gérer ses interactions avec ses sous-services. A l’exécution, un service atomique n’établit pas d’autre communication que l’envoi de la réponse à son appelant après avoir effectué le traitement requis par ce dernier. Un service atomique peut donc être vu comme un simple thread qui exécute un traitement et envoie la réponse correspondante à son appelant alors que, a contrario, un service complexe doit être capable de déclencher l’exécution d’autres services et de récupérer leurs réponses. Un service complexe a donc des caractéristiques communes avec les entités actives1 car il doit être capable d’initier, de recevoir et de traiter des communications. Cette distinction conceptuelle permet en outre, au niveau du système, d’alléger la charge du système lors de l’exécution de services atomiques car ces derniers ne nécessitent pas la gestion d’un mécanisme de réception et de traitement des messages et donc pas la création, par exemple, d’un 1
Leurs différences sont expliquées dans la section 1.3.
96
1. REPRÉSENTATION DES ACTIVITÉS INDIVIDUELLES ET COLLECTIVES thread assurant cette charge. L’intérêt de cette distinction est donc d’effectuer des économies en terme de ressources systèmes. Un service S est défini par un ensemble de blocs de code (cf. figures 5.1, 5.2 et 5.3) dont au moins un bloc d’initialisation prenant en paramètre la requête ayant débouché sur l’exécution de S. Ce bloc est exécuté au lancement de S. Si S est complexe, ce bloc d’initialisation sert, par exemple, à envoyer les requêtes nécessaires à son exécution et S intègre également un bloc destiné aux traitements des réponses des sous-services. Dans tout les cas, un ou plusieurs handlers peuvent être associés à S.
F IG . 5.1 – Exemple de définition d’un service et d’un service complexe en pseudo-langage Quand une entité active initie l’exécution d’un service S, le bloc d’initialisation de ce dernier est exécuté et lance le traitement souhaité. Si S est atomique, il se termine une fois ce bloc exécuté (il sert généralement à envoyer la réponse à la requête correspondante). Si S est complexe, il persiste après l’exécution de ce code afin de traiter les réponses reçues grâce au bloc dédié à cet usage. S persiste alors jusqu’à ce qu’il ait retourné sa réponse à son appelant ou qu’il signale une exception (nous sommes dans un modèle à terminaison). 97
CHAPITRE 5. CONCEPTION ET IMPLÉMENTATION
F IG . 5.2 – Diagramme UML état-transition d’un service simple SaGE Dans la mesure où nous avons défini ce qu’était un service, afin de clarifier notre discours, nous utiliserons par abus de langage le terme service pour faire référence à exécution de service.
1.2 Représentation des activités collectives par des arborescences de services Les requêtes effectuées en cascade par les services complexes débouchent sur des créations de services en cascade formant la structure logique des contextes d’exécution imbriqués. Ainsi, une exécution de service définit un contexte d’exécution. La figure 5.4 montre le graphe des services résultant des requêtes en cascade dans l’exemple de l’agence de voyages. Cette structure, bien qu’arborescente, est comparable à la pile d’exécution utilisée dans la programmation séquentielle : Elle fournit une représentation explicite des activités individuelles (services atomiques) comme collectives (services complexes + sous-services correspondants) des entités actives, offrant ainsi la possibilité de gérer la concurrence coopérative (cf. section 2.2 du chapitre 2). On retrouve ici un principe de représentation de l’imbrication des activités comme dans le cadre des CA actions. Pour maintenir cette arborescence de services : – Quand une entité active reçoit et accepte une requête, elle initialise le service correspondant qui 98
1. REPRÉSENTATION DES ACTIVITÉS INDIVIDUELLES ET COLLECTIVES
F IG . 5.3 – Diagramme UML état-transition d’un service complexe SaGE
F IG . 5.4 – Exécution résultant d’une requête à l’agence de voyage prend note de l’entité cliente pour laquelle il s’exécute et l’identifiant de la requête correspondante afin de savoir à quelle entité la réponse doit être retournée et mettre en correspondance le message de réponse avec le message de requête correspondant. 99
CHAPITRE 5. CONCEPTION ET IMPLÉMENTATION – Quand une entité envoie avec succès une requête dans le cadre d’un des services complexes qu’elle exécute, elle maintient un journal (log) pour y stocker : 1. l’identifiant du service correspondant, 2. l’identifiant de la requête, 3. et l’identifiant de l’entité active qui traite la requête émise. En ce qui concerne l’initialisation des arborescences de services, elle est le résultat de l’exécution d’un service racine par une entité (pro-)active. Si l’on reprend le cas de l’agence de voyage, ce sont les clients qui, à leur initialisation, exécutent un service racine qui définit leur activité initiale.
1.3 Services et encapsulation A partir de ce point du manuscrit, nous parlerons, par abus de langage, d”’entité” pour désigner une “entité active”. Les services exécutés sont encapsulés dans leur entité propriétaire. Ils ne doivent pas interagir avec des entités extérieures à cette dernière de manière à ne pas violer le principe d’encapsulation et ainsi respecter le paradigme utilisé. C’est pourquoi, lorsqu’un service utilise le mécanisme de communication de la plate-forme, la communication passe par l’intermédiaire de son entité propriétaire (de manière transparente). Dans la mesure où les entités envoient des requêtes en fonction des demandes des services complexes qu’elles encapsulent, elles sont les récepteurs des réponses correspondantes et les retransmettent aux services demandeurs. Ainsi, comme illustré en figure 5.5, si le service S exécuté par l’entité A envoie un message (une réponse par exemple) au service S’ de l’entité B, le message transite par A puis par B. Au niveau de la plate-forme, seule une communication entre A et B est alors visible et le paradigme de la plate-forme utilisée est respecté.
F IG . 5.5 – Interaction transparente entre services Les principales différences entre entités et services sont donc que : – un service est encapsulé dans une entité (celle qui l’exécute et dont elle est de fait propriétaire), – un service ne communique jamais directement avec une autre entité du système (à part l’entité qui l’encapsule), 100
1. REPRÉSENTATION DES ACTIVITÉS INDIVIDUELLES ET COLLECTIVES – les services ont une durée de vie courte destinée au traitement d’une requête. Ce mécanisme d’interception des messages échangés entre services fournit aux entités des moyens génériques pour contrôler précisément les services qu’elles exécutent. Le programmeur peut aussi utiliser ce mécanisme pour développer d’autres politiques de gestion de l’exécution plus complexes. La représentation de l’exécution (l’arborescence de service) est globale mais n’est pas centralisée. Elle est en effet répartie sur les entités impliquées dans cette exécution globale : Au niveau de chaque service, on dispose des moyens d’identifier le service appelant et l’ensemble des sous-services appelés. Pour ce faire, à chaque service est associé un journal contenant les informations suivantes : – Les identifiants du service appelant, de son entité propriétaire et de la requête qui l’a initié, – Et, pour chaque sous-service, son identifiant, celui de son entité propriétaire et celui de la requête correspondante. Dans la figure 5.6, le service Organiser un voyage de l’entité Client émet une requête (1) à destination de l’entité Agence qui sera transmise par l’intermédiaire de Client (2). Cette requête contient les identifiants du service émetteur et de son entité propriétaire. A ce stade, le service Organiser un voyage crée une entrée supplémentaire dans son journal correspondant à la demande d’exécution de service émise. Les seules informations dont il dispose à ce stade sont donc l’identifiant de la requête envoyée et celui de l’entité destinataire.
F IG . 5.6 – Exemple d’interaction transparente 101
CHAPITRE 5. CONCEPTION ET IMPLÉMENTATION Suite à la réception de cette requête, Agence l’accepte et exécute en conséquence le service Rechercher un voyage pour y répondre (3). Le service Rechercher un voyage initialise alors son journal pour y stocker l’identifiant de son service appelant, celui de l’entité propriétaire de ce dernier et celui de la requête qui l’a initié. Ce journal est exploité immédiatement pour transmettre au demandeur de Rechercher un voyage la notification d’acceptation de la requête. Cette notification (3’) envoyée à l’entité ayant transmis la requête intègre l’identifiant de Rechercher un voyage et celui de la requête correspondante. Ainsi l’entité Client transmet cette notification à Organiser un voyage (3”) qui peut compléter l’entrée correspondante de son journal avec l’identifiant du service qui traite la requête émise. Une fois son objectif atteint, Rechercher un voyage retourne sa réponse à son entité propriétaire (4) qui la transmet à Client (5) qui peut la transmettre à son tour à celui de ses services ayant initialement émis la requête (6). Ces trois messages transitent suivant le même principe : on utilise les journaux associés aux services pour que ces derniers puissent échanger des messages sans violer le principe d’encapsulation des entités. La séquence de message correspondante est la suivante : 1 Le service Organiser un voyage envoie à l’entité Client : (idAgence, idRequete, Requete), 2 L’entité Client envoie à l’entité Agence : (idRequete, Requete), 3 L’entité Agence initialise le service Rechercher un voyage(Requete), 3’ L’entité Agence envoie à l’entité Client : (accept, idRequete, idService (Rechercher un voyage)), 3” L’entité Client envoie au service Organiser un voyage : (accept, idRequete, idService (Rechercher un voyage)), 4 Le service Rechercher un voyage envoie à l’entité Agence : (idClient, idRequete, Reponse), 5 L’entité Agence envoie à l’entité Client : (idRequete (Requete), Reponse), 6 L’entité Client envoie au service Organiser un voyage : (idRequete (Requete), Reponse),
1.4 Exécution concurrente des services dans les entités Une entité peut exécuter plusieurs services concurremment. On peut illustrer ceci par l’exemple de l’entité Agence durant l’exécution du service Rechercher un voyage. Ce service complexe requiert auprès de sa propre entité propriétaire l’exécution de trois sous-services (cf. Figure 5.4) : – Un service complexe Demande de tarifs pour recenser les offres existantes, – Un autre service complexe Mise en contact pour réunir les deux parties qui seront amenées à établir un contrat, – Un service atomique Sélection d’une offre qui choisit, parmi les offres disponibles la plus avantageuse. 102
1. REPRÉSENTATION DES ACTIVITÉS INDIVIDUELLES ET COLLECTIVES Entite_Active E { ... onRequest (Request r) { si (r.getType() == “Donner tarif”) alors executer(S1, r) sinon si (r.getType() == “Reserver”) alors executer(S2, r) } Service S1 { action() { reply(getTarif()) } } Service S2 { action () { si (getDispo()>1) alors reserver() sinon signaler (nouvelle SaGEException(“Plus de disponibilités”) } } }
F IG . 5.7 – Exemple de structure d’une entité en pseudo-code
Cet exemple permet la mise en évidence de la concurrence interne aux entités : quatre services s’exécutent concurremment dans l’entité Agence pour traiter la requête envoyée par une entité Client.
Par ailleurs, une entité est à l’écoute des requêtes entrantes même quand elle exécute déjà des services comme illustré en figure 5.8 où une entité B requiert un service auprès d’une entité C qui accepte cette requête alors qu’elle est déjà en train de traiter la demande de l’entité A. Le code d’une entité active peut donc être exécuté par plusieurs threads concurrents. On permet ainsi le traitement concurrent de plusieurs requêtes comme présenté en figure 5.9 où on peut voir plusieurs exécutions d’un même service. Par exemple, dans le code présenté en figure 5.7, plusieurs instances dans services S1 et S2 appartenant à la même instance de E peuvent être exécutés concurrement. Cette réactivité permanente des entités permet d’éviter des attentes inutiles en exploitant au mieux la concurrence. En effet, si, par exemple, Agence traitait les requêtes en provenance des clients une à une, les ressources qui lui sont allouées pendant la phase où il attend les réponses des prestataires seraient gaspillées. 103
CHAPITRE 5. CONCEPTION ET IMPLÉMENTATION
F IG . 5.8 – Exemple de requêtes traitées concurremment par une agence
1.5 Traitement des requêtes groupées 1.5.1
Les représentants de rôle
Dans la section 3 du chapitre 2, nous avons défini le concept de broadcasting vers un ensemble d’entités ayant une compétence commune pour atteindre, par l’émission d’une unique requête un ensemble d’entités. Afin de gérer de telles requêtes, nous devons définir des entités représentant de tels ensembles d’entités partageant une compétence commune (on parle de rôle dans le sens où nous les avons présentés en section 3.2 du chapitre 2). Au regard de l’exemple de l’agence de voyages, une telle entité doit être définie pour représenter l’ensemble des prestataires.
104
1. REPRÉSENTATION DES ACTIVITÉS INDIVIDUELLES ET COLLECTIVES
F IG . 5.9 – Exemple de traitement concurrent de deux requêtes par une agence Nous définissons ces entités comme des entités dédiées (représentants de rôle) qui ont pour fonction de : – Maintenir la liste des entités remplissant le rôle représenté, – Assurer la diffusion des requêtes groupées, – Collecter les réponses pour répondre aux émetteurs de requêtes groupées. Pour atteindre un ensemble d’entités partageant une compétence commune, une entité envoie une requête au représentant de rôle correspondant qui la traite en exécutant le service dédié présenté ciaprès. 1.5.2
Le service de Broadcasting
Quand un représentant de rôle reçoit une requête de la part d’une entité, il traite celle-ci grâce au service de Broadcasting qui est prédéfini dans l’architecture de SaGE et utilisable par tout représentant de rôle.
105
CHAPITRE 5. CONCEPTION ET IMPLÉMENTATION Le comportement de ce service se décompose en trois phases : 1. Émission de la requête groupée à traiter sous la forme d’un envoi de requête individuelle à chacune des entités remplissant le rôle correspondant (cf. Figure 5.10). Chaque exécution du service de broadcasting a donc autant de sous-services que d’entités remplissant le rôle correspondant. 2. Collecte des réponses retournées par les entités sollicitées. 3. Renvoi des réponses collectées composées en une réponse unique à l’émetteur de la requête groupée.
// Récupération de la liste des entités actives correspondantes Vecteur entites = recupererEntitesAvecRole(role) si entites est vide alors { // Levée d’une exception si aucune n’a été trouvée lever (SaGEException ("pas d’entités jouant le rôle "+role)) sortie } sinon { pour i allant de 1 à entites.taille { // Transmission de la requête groupée envoyerRequete (entites[i], requete) } }
F IG . 5.10 – Comportement d’initialisation du service de Broadcasting écrit en pseudo-langage Le service de Broadcasting est donc un service prédéfini servant d’outil d’automatisation de la gestion des requêtes groupées pour le programmeur. Les exécutions de ce service constituent donc des nœuds particuliers de l’arborescence de service. Nous proposons ici une extension des mécanismes de broadcasting traditionnels tel que celui que nous avons vu en section 3.2 du chapitre 2. En effet, notre approche permet une véritable intégration dans les langages où les entités interagissent par requête/réponse via des communications asynchrones puisqu’elle assure non seulement la diffusion des requêtes groupées mais aussi la collecte et la transmission des réponses correspondantes. Cet outil épargne par ailleurs au programmeur les tâches relatives à la gestion des rôles.
1.6 Exemple complet d’une exécution standard Afin de mieux illustrer la vision des services que nous proposons, voyons l’exemple d’exécution présenté en figure 5.4 en détaillant comment l’arborescence de services correspondante se construit et 106
1. REPRÉSENTATION DES ACTIVITÉS INDIVIDUELLES ET COLLECTIVES se détruit au fil de l’exécution. Nous présentons ici un cas où trois prestataires proposent une offre et où aucune exception n’est levée (cf. Figure 5.11) .
F IG . 5.11 – Arborescence de services (tous services représentés) Tout d’abord, un client initialise le service (racine de l’arborescence des services) Organiser un voyage pour requérir un voyage auprès de Agence. Ce dernier exécute en conséquence un service Rechercher un voyage qui requiert auprès de sa propre entité (Agence) l’exécution de trois sousservices représentant les trois phases de la recherche d’un voyage par une agence : Demande de tarifs pour recenser les offres disponibles, Sélection d’une offre pour choisir la plus avantageuse et Mise en contact pour faire établir un contrat aux deux parties concernées (le client et le prestataire sélectionné). A ce stade, l’arborescence de services correspond à l’état présenté en figure 5.12. Les services Mise en contact et Sélection d’une offre n’ont pas d’activité à leur initialisation puisqu’ils ont préalablement besoin des résultats issus de l’exécution de Demande de tarifs. Ce dernier doit envoyer une requête groupée à l’attention de l’ensemble des prestataires afin de connaître le prix de chacun d’entre eux. Pour ce faire, il envoie une requête de Demande de tarif au Représentant des prestataires. Ce dernier exécute alors un service de Broadcasting pour répondre à sa demande et transmettre la requête groupée aux prestataires qu’il référence (cf. Figure 5.13). Ces derniers exécutent 107
CHAPITRE 5. CONCEPTION ET IMPLÉMENTATION
F IG . 5.12 – Arborescence de services (première étape) alors leur service Donner Prix pour y répondre.
F IG . 5.13 – Arborescence de services (broadcasting) Suite à l’exécution de ces services, les prestataires répondent individuellement au représentant des prestataires en lui notifiant leur tarif. Le représentant des prestataires transmet ces réponses au service de Broadcasting correspondant qui les agrège en une réponse unique qu’il retourne à l’Agence qui la transmettra à son tour au service demandeur Demande de tarifs. A ce stade, l’arborescence des services revient à l’état présenté en figure 5.12 puisque tous les services de la sous-arborescence issue de la requête groupée qui a été émise ont maintenant achevé leur exécution. Une fois cette réponse agrégée reçue : 1. Demande de tarifs se termine en répondant à son service parent Rechercher un voyage. Cette réponse transite par l’intermédiaire de leur entité propriétaire (cf. figure 5.5). 108
1. REPRÉSENTATION DES ACTIVITÉS INDIVIDUELLES ET COLLECTIVES
F IG . 5.14 – Arborescence de services (établissement du contrat) 2. Rechercher un voyage transmet alors cette information à son sous-service Sélection d’une offre qui peut alors choisir le meilleur prestataire et terminer son exécution en retournant en réponse à son service parent Rechercher un voyage le couple (prestataire, prix) sélectionné. 3. Rechercher un voyage peut alors transmettre ce couple à son sous-service Mise en contact qui envoie une requête au prestataire sélectionné pour qu’il soit informé que le client demandeur d’un voyage souhaite profiter de son offre et une requête au client pour que ce dernier sache quel prestataire a été retenu et quel est son tarif. Les deux services résultants (Contacter le prestataire et Contacter le client) donnent alors lieu aux exécutions de services nécessaires à l’établissement du contrat entre le client et le prestataire sélectionné : Établir le contrat et les services Valider du client et du prestataire sélectionné (cf. Figure 5.14). Enfin les services qui constituent les feuilles de l’arborescence résultante se terminent, récursivement, de manière standard, jusqu’au service racine marquant alors la fin de l’exécution globale correspondante.
1.7 Le mécanisme de terminaison En ce qui concerne le mécanisme de terminaison des services (cf. section 5.2.2 du chapitre 4), quand un service S se termine (que ce soit de manière standard ou exceptionnelle), un message le notifie à son entité propriétaire. Cette dernière utilise alors le journal associé au service terminé pour 109
CHAPITRE 5. CONCEPTION ET IMPLÉMENTATION retrouver l’identifiant de l’entité A qui avait requis S et les identifiants des services (ainsi que ceux des entités correspondantes) qui ont été requis par S. L’entité propriétaire de S envoie alors un message informant A que S s’est terminé et un message, pour chacun des sous-services pendants, à destination des entités correspondantes, et, pour les informer que ces services sont devenus obsolètes et doivent donc être interrompus et détruits (en cascade). Ce mécanisme permet de prévenir d’inutiles consommations de ressources. Une fois ces messages destinés à interrompre les sous-services pendants envoyés, l’entité propriétaire de S ne reçoit plus de messages relatifs à ceux-ci (ni même de confirmation de leur terminaison) car c’est alors à leurs entités propriétaires respectives d’assurer leur terminaison. La figure 5.15 présente un exemple de tels échanges de messages. Ce cas de figure correspond à une situation dans laquelle le service Sélection d’une offre ne s’est pas déroulé correctement (terminaison exceptionnelle) empêchant ainsi le bon déroulement de Rechercher un voyage qui a dû se terminer lui-même de manière exceptionnelle. Le sous-service pendant de ce dernier, Mise en contact, est alors terminé à son tour par le processus de terminaison. Pour ce faire, le service Demande de tarifs notifie sa terminaison à son entité propriétaire Agence par le message M15. Agence notifie cette terminaison au service parent correspondant qui est encapsulé dans la même entité par M15’. Le service Sélection d’une offre notifie sa terminaison à son entité propriétaire Agence par le message M16. Une fois encore, Agence notifie cette terminaison au service parent correspondant qui est encapsulé dans la même entité par M16’. Ensuite, c’est ce service parent (Rechercher un voyage) qui se termine et qui le notifie à Agence par M17. Agence termine alors le sous-service de Rechercher un voyage devenu obsolète (Mise en contact) et notifie la terminaison de Rechercher un voyage par M17’ au Client qui transmettra cette notification au service demandeur Organiser un voyage par M17”. La notion de service décrite précédemment fournit un moyen de coordonner l’exécution des activités des entités. Nous l’exploitons pour intégrer SaGE dans les plates-formes cibles comme décrit dans les sections suivantes.
1.8 Réactivité du système SaGE garantit la réactivité des applications qui l’utilisent dans la mesure où : – Les services s’exécutent concurremment au sein de l’entité dans laquelle ils sont encapsulés, – Une entité reste toujours à l’écoute des messages qui lui sont destinés quelle que soit sa charge de calcul représentée par l’exécution des services qu’elle exécute, – Quand un service termine son exécution, que ce soit de manière standard ou exceptionnelle, la terminaison de tous ses sous-services pendants (c’est-à-dire toujours en cours d’exécution) est assurée de façon transparente pour le programmeur par SaGE afin d’éviter que ces derniers ne consomment inutilement des ressources système, – Une réponse exceptionnelle fait l’objet d’un traitement immédiat afin d’éviter que des services ne poursuivent des traitements standards inutiles (cf. section 5.2). 110
2. IMPLÉMENTATIONS DE SAGE DANS UNE PLATE-FORME SMA
F IG . 5.15 – Exemple d’échanges de messages concernant la terminaison Comme nous l’avons vu au fil de cette section, le seul type d’interaction possible avec une entité est l’envoi de messages de manière asynchrone. Une entité traitant ces messages selon sa propre définition, SaGE assure le respect de l’autonomie des entités qui est l’une des propriétés des systèmes multi-agents qu’il convient de respecter afin de ne pas modifier le paradigme agent. De même, SaGE respecte la notion d’encapsulation qui fait partie intégrante du paradigme agent comme de celui des composants logiciels.
2 Implémentations de SaGE dans une plate-forme SMA Pour cette première implémentation, nous avons choisi d’étendre MADKit sans en modifier le noyau pour limiter les effets de bord éventuels liés à la prise en compte d’une nouvelle version de la plate-forme. 111
CHAPITRE 5. CONCEPTION ET IMPLÉMENTATION
2.1 Présentation de MADKit 2.1.1
La plate-forme
MADKit est une plate-forme multi-agent libre 2 (développée en Java) qui est construite sur un modèle organisationnel : le modèle Agent/Groupe/Rôle [FG98] que nous avons introduit en section 3.2 du chapitre 2. Elle fournit les outils de gestion générale des agents (gestion du cycle de vie, passage de message, distribution. . . ) et tolère l’hétérogénéité des architectures d’agents, des langages de communication et d’autres éléments de configuration. MADKit est une plate-forme très générique : elle n’impose aucune contrainte sur la structure interne des agents, autorisant ainsi le programmeur à implémenter son propre modèle d’agents. C’est la raison pour laquelle nous nous sommes tournés vers MADKit pour implémenter SaGE dans le contexte des systèmes multi-agents. MADKit permet également de développer facilement des applications distribuées. Pour les programmeurs, toute considération sur les éléments relatifs à la distribution tels que les sockets et les ports est totalement transparente. MADKit intègre donc une couche middleware à messages. Une application initialement développée pour une exploitation locale peut être distribuée en toute transparence. MADKit est conçu autour du concept de micro-kernel et d’agentification des outils : Le noyau MADKit est assez petit mais des agents dédiés fournissent des outils de construction d’applications. La distribution, l’échange de messages entre agents distants, l’observation des agents, etc. . . sont assurés par des agents. De plus, MADKit fournit un ensemble de conteneurs (environnement d’exécution pour applications) pour permettre aux agents MADKit de fonctionner dans des contextes divers comme un environnement de développement ou un environnement d’exécution pour mettre en œuvre des applications embarquées ce qui conforte son caractère générique. Par exemple, en mode distribué, chaque noyau MADKit joue le rôle de noeud et les connections entre noyaux sont assurées par un agent spécifique appelé Communicator qui gère non seulement les communications entre agents situés dans des noyaux différents mais aussi la synchronisation des groupes (dans le sens défini par le modèle Agent/Groupe/Rôle) distribués sur plusieurs noyaux. 2.1.2
Les agents
Un agent MADKit codé en Java3 est constitué de quatre sections (sous forme de méthodes Java) optionnelles qui définissent sa structure de base et son cycle de vie (cf. Figure 5.16) : 1. La section activate qui contient du code qui sera exécuté lors de la création de l’agent. 2. La section live qui contient le code dit principal de l’agent. En général, le programmeur y définit une boucle décrivant le comportement de l’agent. 2 3
sous licence GPL/LGPL. On peut également coder des agents MADKit en Python, Scheme...
112
2. IMPLÉMENTATIONS DE SAGE DANS UNE PLATE-FORME SMA 3. La section end contient du code qui sera exécuté quand l’agent se termine (soit en raison de la fin de l’exécution de son comportement soit parce qu’il a été tué par l’environnement d’exécution) 4. La section initGUI utilisé comme interface graphique représentant l’agent et destinée à remplacer l’interface graphique par défaut.
import madkit.kernel.* ; import makdit.libs.messages.StringMessage; public class AgentCompteur extends Agent{ boolean counting = false ; public void activate(){ println("Je suis un compteur") ; createGroup(true,"demo",null,null); requestRole("demo","counter",null); } public void live(){ int n = 0 ; Message m ; while (true) { if ( !counting){ println("Arrêté et en attente d’un message de démarrage") ; m = waitNextMessage() ; handleMessage(m) ; } else { println("compte : " + n++) ; pause(1000) ; m = nextMessage() ; handleMessage(m) ; } } } void handleMessage(Message m){ if (m instanceof StringMessage){ String s = ((StringMessage)m).getString(); if (s.equals("start")) counting=true ; else if (s.equals("stop")) counting=false ; } } }
F IG . 5.16 – Exemple du code Java d’un agent MADKit traitant des chaînes de caractères 113
CHAPITRE 5. CONCEPTION ET IMPLÉMENTATION La figure 5.16 présente l’exemple simple d’un agent compteur. Il commence à compter à la réception d’un message “start” et s’arrête de compter quand il reçoit “stop”. Sa définition est simple, la méthode activate() crée un groupe appelé demo et affecte à l’agent le rôle de compteur dans ce groupe. Notons que le premier paramètre de createGroup vaut vrai pour permettre la distribution du groupe créé sur le réseau : le groupe demo sera donc visible de tout noyau connecté au noyau courant.
2.2 Gestion des communications pour SaGE Dans MADKit, le système affecte à chaque agent un identifiant abstrait (AgentAddress) qui sera utilisé comme référence sur sa boîte aux lettres afin que d’autres agents puissent lui envoyer des messages au travers du middleware. Pour implémenter SaGE, nous avons choisi d’étendre (cf. Figure 5.17) une classe particulière de messages définie dans l’API de MADKit, la classe ACLMessage, car elle assure la gestion automatisée de l’identification des expéditeurs et destinataire d’un message lors de son envoi. L’extension que nous proposons (SaGEMessage) permet l’encapsulation transparente d’informations relatives à notre proposition (cf. section 1.2 du chapitre 4) : – Les identifiants nécessaires au transfert des messages entre les diverses entités du modèle (par exemple, pour qu’un agent qui reçoit une exception puisse la transférer au service concerné), – La catégorie de message (requête, terminaisons, exceptions. . .).
2.3 Définitions des agents SaGE et de leurs services 2.3.1
Introduction technique : Implémentation des agents dans la plate-forme MADKit
Dans MADKit, la classe AbstractAgent est la classe de base des entités communicantes du système. Une instance de AbstractAgent : – se voit attribuer une adresse (AgentAddress) lors de son initialisation par la plate-forme. Cette adresse sera utilisée comme référence sur sa boîte aux lettres afin que d’autres entités puissent lui envoyer des messages (cf. section 2.2). – peut exploiter le middleware pour envoyer des messages à d’autres instances d’AbstractAgent par l’intermédiaire des méthodes sendMessage pour les envois de messages point-à-point et broadcast pour les diffusions groupées (cf. section 3.2 du chapitre 2), – peut lire les messages qu’elle reçoit dans sa boîte aux lettres grâce à la primitive nextMessage qui retourne le premier message de la boîte aux lettres ou null si cette dernière est vide. La classe Agent est la classe de base des entités du système. Un programmeur souhaitant définir un agent le définit donc dans une classe dérivant la classe Agent qui étend AbstractAgent par : – la méthode abstraite live que le programmeur doit redéfinir pour affecter un comportement à l’agent (cf. section 2.1.2), 114
2. IMPLÉMENTATIONS DE SAGE DANS UNE PLATE-FORME SMA
F IG . 5.17 – Diagramme UML de l’implémentation de SaGE dans MADKit – la méthode pause pour mettre l’activité de l’agent en suspens pendant un délai donné en paramètre, – et la méthode waitNextMessage qui suspend l’activité de l’agent jusqu’à ce qu’un message (qu’elle retourne) arrive dans sa boîte aux lettres.
2.3.2
Implémentation des agents SaGE
Dans la mesure où c’est la méthode live qui définit le comportement d’un agent dans la plate-forme MADKit, nous avons naturellement implémenté la classe des agents exploitant SaGE (SaGEAgent) comme dérivant de Agent. Le programmeur définit la méthode live() afin d’assurer l’aiguillage des messages (choix et lancement de service pour répondre à une requête. . .) car la gestion du cycle de vie n’a pas été automatisée dans cette première implémentation de SaGE. Pour ce faire, quand un message SaGE est reçu, il doit immédiatement être traité par la méthode handleSaGEMessage qui adoptera le comportement approprié en fonction du type du message reçu (requête, réponse, exception, . . .). 115
CHAPITRE 5. CONCEPTION ET IMPLÉMENTATION 2.3.3
Implémentation des services SaGE
En ce qui concerne la classe de base des services (Service), elle ne dérive pas de la classe Agent. En effet, on ne peut pas s’adresser directement à eux mais ils doivent pouvoir envoyer et recevoir des messages par l’intermédiaire de leur agent propriétaire, avoir un identifiant et une méthode principale d’exécution. Nous avions donc le choix entre créer de toute pièces une classe dédiée ou réutiliser par héritage les fonctionnalités de la classe AbstractAgent. Nous avons opté pour ce dernier choix pour assurer une meilleure intégration à MADKit et par souci de réutilisation tout en conservant une distinction claire entre services et agents. Sur le diagramme de classes présenté en figure 5.17, on peut observer qu’à une instance de ComplexService peuvent être associées une ou plusieurs instances de SubServiceInfo. Cette classe utilitaire est exploitée par les services pour référencer, dans leur journal (cf. section 1.2), les exécutions de services qu’ils ont requis afin de pouvoir gérer les réponses relatives aux requêtes envoyées (on peut par ailleurs associer à chaque envoi de requête correspondant un handler sous la forme d’une instance de la classe RequestHandler). On a donc, pour chaque requête émise, une instance de SubServiceInfo représentant le sous-service correspondant. Dans de telles instances sont stockées des informations telles que : – l’identifiant du sous-service, – l’identifiant de la requête correspondante, – des informations sur l’état de la phase d’exécution en cours (en traitement, réponse standard retournée, réponse exceptionnelle retournée. . .) comme illustré en figure 5.3. Par ailleurs, les services complexes implémentent la méthode handleSaGEMessage pour traiter les réponses qu’ils reçoivent en retour des requêtes qu’ils ont émises.
2.4 Statut des exceptions Dans SaGE, nous exploitons notre extension SaGEException de la classe standard Java Exception afin de : – différencier les exceptions du niveau du langage Java de celles du niveau du système multiagents, – encapsuler dans ces exceptions des informations qui pourront être utiles au programmeur telles que l’adresse de l’agent dans lequel l’exception a été initialement signalée, – rester compatible avec le système de gestion d’exception du langage Java afin que, au besoin, une exception du niveau du SMA puisse être considérée comme une exception standard et finalement capturée et traitée par un handler Java. 116
2. IMPLÉMENTATIONS DE SAGE DANS UNE PLATE-FORME SMA
2.5 Gestion des requêtes groupées Nous avons introduit, dans le chapitre précédent, la nécessité de définir des entités dédiées au traitement des requêtes groupées. Afin d’assurer au maximum la cohésion avec le paradigme agent, nous avons choisi de définir la classe RoleAgent dérivant de SaGEAgent pour gérer les requêtes groupées. Ces agents dédiés utilisent le service BroadcastService pour assurer le comportement souhaité : assurer la diffusion des requêtes groupées et collecter les réponses individuelles pour envoyer une réponse groupée. Nous avons donc redéfini le mécanisme de broadcasting de MADKit en l’implémentant dans les RoleAgents tout en continuant à exploiter la notion de rôle telle qu’elle est spécifiée par le modèle Agent/Groupe/Rôle de MADKit (cf. section 3.2 du chapitre 2). Pour ce faire, les rôles sont atteribués aux agents par le biais des méthodes prévues à cet effet dans MADKit mais l’envoi de requêtes collectives se fait par la méthode dédiée de SaGE. Par ailleurs, il est intéressant de noter que la classe RoleAgent est définie de telle manière que, pour le programmeur, définir un rôle dans une application exploitant SaGE revient à spécifier le rôle que le RoleAgent correspondant gère sous la forme d’une étiquette textuelle comme dans MADKit (cf. Figure 5.18) et, optionnellement, lui associer des handlers et/ou une fonction de concertation dédiée (cf. Figures 5.22 et 5.23). public class Prestataires_RoleAgent extends RoleAgent { public Provider_RoleAgent () { super("prestataire") ; } }
F IG . 5.18 – Définition de Prestataires_RoleAgent
2.6 Évaluation des résultats dans MADKit Après avoir implémenté SaGE dans MADKit, nous sommes naturellement passés à l’expérimentation avec l’exemple de l’agence de voyages (cf. Figure 5.19). 2.6.1
Définition des agents
Afin d’implémenter l’exemple de l’agence de voyage avec SaGE dans MADKit, nous avons défini les trois classes d’agents Client, Agence et Prestataire ainsi qu’un RoleAgent pour gérer les requêtes groupées : Prestataires_RoleAgent (cf. Figure 5.20). De plus, afin de permettre le debuggage de l’application, nous avons implémenté deux agents (qui ne sont pas des SaGEAgents) supplémentaires (cf. Figure 5.19) : 117
CHAPITRE 5. CONCEPTION ET IMPLÉMENTATION
F IG . 5.19 – Une fenêtre MADKit typique avec des instances de SaGEAgents
!!#"
F IG . 5.20 – Diagramme de classes de l’exemple dans l’implémentation de SaGE pour MADKit
– Un agent logger qui journalise, dans un fichier textuel, les actions relatives aux services SaGE (instanciations, initialisations, terminaison, signalement d’exceptions,. . . ), – Un agent ServiceTracer qui représente graphiquement et dynamiquement une arborescence de services dont la racine est le service lancé par le dernier agent Client instancié. Cet agent permet donc, pendant l’exécution de l’application, de voir non seulement comment l’arborescence de services se construit mais aussi de visualiser l’état de chacun des services représentés (cf. Figure 5.21). 118
2. IMPLÉMENTATIONS DE SAGE DANS UNE PLATE-FORME SMA
(a) Utilisation de résultats partiels
(b) Signalement d’une exception concertée
F IG . 5.21 – Exemples de concertation d’exceptions 2.6.2
Concertation d’exceptions
Dans l’exemple des agences de voyage, la concertation d’exceptions signalées concurremment est tout particulièrement pertinente au niveau de la collecte des réponses des prestataires à la requête groupée de demande de tarifs. En effet, ces prestataires peuvent être très nombreux et la possibilité d’obtenir des réponses exceptionnelles à une telle requête groupée est d’autant plus probable. Dans les exemples d’exécution représentés en figure 5.21, un service racine Organiser_un_voyage adresse une requête à un agent Agence pour lui demander un voyage. Le service Rechercher_un_voyage correspondant adresse alors une requête pour connaître les tarifs disponibles à Prestataire_RoleAgent. Il en résulte l’initialisation d’un service Broadcast dans ce RoleAgent. Parallèlement, le service Rechercher_un_voyage requiert l’initialisation d’un service Mise_en_contact qui attend le résultat de la demande de tarifs. Le service Broadcast émet une requête groupée aux prestataires concernés ce qui résulte en l’initialisation, dans chacun des agents prestataires d’un service Donner_Tarif pour répondre à la requête groupée. La figure 5.21 présente deux scenarii d’exécution : 1. Un cas où seulement quelques-uns des prestataires ne sont pas en mesure de fournir un tarif (levée d’une exception au cours de l’exécution du service Donner_Tarif ). 2. Un cas où plus d’un tiers des prestataires sollicités ne sont pas en mesure de fournir un tarif. 119
CHAPITRE 5. CONCEPTION ET IMPLÉMENTATION Le second cas de figure engendre le signalement d’une exception concertée qui sera capturée par le handler dont le code est présenté en figure 5.23. Ainsi : – Si peu de prestataires signalent une exception, des résultats partiels suffisent pour satisfaire la requête groupée et peuvent être exploités comme une réponse standard comme l’illustre la figure 5.21(a). Dans ce cas, le RoleAgent ayant géré la requête groupée répond en envoyant des résultats partiels. On observe alors que le service Broadcast se termine de manière standard et que l’exécution se termine normalement. – Si trop de prestataires signalent une exception, une exception concertée est signalée et ce jusqu’au niveau du client afin de notifier un problème global lors de l’exécution de l’application comme la figure 5.21 (b) l’illustre. En effet, le service Broadcast se termine de manière exceptionnelle et l’exception correspondante est alors signalée au service Rechercher_un_voyage qui, ne pouvant faire face à un problème de cette gravité, ne peut capturer cette exception qui est alors signalée jusqu’au niveau de la racine des services. Cette exécution échoue donc et la terminaison exceptionnelle du service Rechercher_un_voyage engendre la terminaison forcée de son sous-service pendant Mise_en_contact. public SaGEException broadcastconcert (Vector subServices) { int i = 0 ; int nbexc = 0 ; SaGEException concertedexception = null ; while (i (0.3*subServices.size())) // Levée d’un exception concertée concertedexception = new SaGEException("too_many_bad_providers",getAddress()); return concertedexception ; }
F IG . 5.22 – Fonction de concertation associée au code Java de Prestataires_RoleAgent
2.6.3
Terminaison
Quand un service termine son exécution, que ce soit de manière standard ou exceptionnelle, la terminaison de tous ses sous-services pendants (c’est-à-dire toujours en cours d’exécution) est réalisée de force par SaGE afin d’éviter que ces derniers ne consomment inutilement des ressources système 120
2. IMPLÉMENTATIONS DE SAGE DANS UNE PLATE-FORME SMA public void broadcasthandle (SaGEException exc,BroadcastService bs) { if (exc.getMessage().equals("too_many_bad_providers")) { // Resignalement de l’exception concertée sendMessage(bs.getparentowneraddress(),new SaGEMessage("exception",exc.getMessage(),bs.getrequestID())); bs.terminate() ; } else signal (exc) ; }
F IG . 5.23 – Handler associé au code Java de Prestataires_RoleAgent (cf. section 6 du chapitre 3). Par exemple, en figure 5.21(b), on voit que : 1. Une exception est propagée jusqu’au niveau de la racine de l’arborescence de services, 2. Chaque service au niveau duquel un handler adapté au traitement de cette exception est recherché se termine de manière exceptionnelle car on lui notifie une exception qu’il n’est pas capable de traiter, 3. La terminaison du service Rechercher_un_voyage force celle de son sous-service pendant Mise_en_contact. L’arborescence de services formée par les requêtes de services en cascade est donc utilisée “en remontant” pour gérer le signalement des exceptions et “en descendant” pour gérer la terminaison de l’exécution des sous-services devenus obsolètes (services pendants).
2.7 Bilan L’implémentation de SaGE dans MADKit et son expérimentation nous ont permis de démontrer la faisabilité de SaGE. En effet, nous avons pu y mettre en place la spécification présentée en chapitre 4 et nous assurer ainsi que nous répondions bien à tous les besoins identifiés en section 6 du chapitre 3. Pour ce faire, nous avons expérimenté un ensemble de scenarii impliquant un nombre variable de prestataires générant un nombre variable d’exceptions. D’autre part, comme nous l’avons vu en section 2.1.1 de ce chapitre, le noyau MADKit est assez petit mais des agents dédiés offrent les outils “agentifiés” pour construire des applications. Dans le même esprit, nous avons conçu les agents logger et tracer afin de répondre aux attentes spécifiques des développeurs utilisant SaGE pour debugguer les applications qu’ils développent et visualiser les différentes situations en fonction des levées d’exceptions. Après cette première expérimentation, nous avons porté SaGE dans le contexte de J2EE/JOnAS afin de valider notre proposition dans le contexte des plates-formes à base de composants logiciels. 121
CHAPITRE 5. CONCEPTION ET IMPLÉMENTATION
3 Implémentation de SaGE dans une plate-forme à base de composants logiciels Pour tester SaGE dans le cadre des plates-formes à base de composants logiciels, nous avons transposé les travaux exposés dans le chapitre précédent dans JOnAS [JOn04, SUVD03] (Java Open Application Server), une plate-forme libre implémentant les EJB (Enterprise JavaBeans) de J2EE (Java2 Enterprise Edition) [Sun04a, Sun03]. Ce portage de notre implémentation dans un autre paradigme nous permet non seulement de doter les composants communiquant de manière asynchrone d’un SGE efficace mais aussi de montrer la généricité de la solution que nous proposons. Dans cette autre implémentation de SaGE, le code des conteneurs J2EE a été modifié afin d’assurer une meilleure intégration de SaGE dans cette plate-forme. De plus, certaines fonctionnalités supplémentaires ont été automatisées pour rendre SaGE plus transparent pour le programmeur. Dans la mesure où SaGE est dédié aux entités communiquant de manière asynchrone, nous avons mis SaGE en œuvre pour les MessageDrivenBeans (cf. section 4.2.3 du chapitre 2).
3.1 Présentation de JOnAS 3.1.1
J2EE
La spécification J2EE de Sun [Sun04a] définit une architecture et des interfaces pour le développement et le déploiement d’applications Java distribuées sur la base d’une architecture multi-tiers. Cette spécification vise à faciliter et à standardiser le développement de serveurs applicatifs. Les applications résultantes sont généralement : – adaptées à une exploitation sur le web, – transactionnelles, – orientées base de données, – multi-utilisateurs, – sécurisées, – portables. La portabilité d’un composant J2EE ne se limite pas au fait qu’une application J2EE peut s’exécuter sur divers systèmes d’exploitation. En effet, un composant conforme à la spécification J2EE est portable d’une plate-forme J2EE à une autre. Un composant conçu dans JBoss [JBo] pourra par exemple être déployé dans JOnAS. Cette spécification se décompose en deux sections bien distinctes : 1. L’environnement d’exécution (le serveur J2EE), qui fournit les services requis comme le service de transaction, le service de persistance, le Java Message Service (JMS) pour les communications asynchrones et le service de sécurité. 122
3. IMPLÉMENTATION DE SAGE DANS UNE PLATE-FORME À BASE DE COMPOSANTS LOGICIELS 2. Les informations à destination du programmeur lui expliquant comment les composants logiciels doivent être développés, déployés et utilisés. Une application J2EE typique est composée de : 1. web components (Servlets et JSP4 ) qui définissent l’interface web de l’application, 2. enterprise components (les Enterprise Java Beans (EJB)[Sun03]) qui définissent la partie applicative. C’est le serveur J2EE qui fournit les conteneurs (cf. section 4.1 du chapitre 2) qui encapsulent les composants : les conteneurs web sont des environnements d’exécution pour les Servlets et les JSP alors que les conteneurs d’EJB sont des environnements d’exécution pour les Enterprise JavaBeans. Notons qu’un serveur J2EE peut également fournir un environnement d’exécution pour le déploiement de clients Java exploitants des EJB ; on parle alors de conteneur client. Un conteneur assure la gestion du cycle de vie et des interfaces des composants qu’il encapsule grâce aux services fournis par le serveur J2EE. 3.1.2
JOnAS
JOnAS est une implémentation open-source (sous licence GPL [Fou04]) de la spécification J2EE (cf. Figure 5.24) par ObjectWeb5 . Les divers projets open-source initiés par ObjectWeb sont les fruits d’une collaboration entre de nombreux partenaires dont Bull, France Telecom R&D et l’INRIA.
F IG . 5.24 – Architecture de JOnAS Les principales briques de JOnAS sont : 4 5
JavaServer Pages http ://www.objectweb.org/
123
CHAPITRE 5. CONCEPTION ET IMPLÉMENTATION – un service6 de déploiement (pour générer les archives EAR (Enterprise Archives)), – un service pour les conteneurs d’EJB qui fournit un ensemble de classes Java et un outil de génération des classes intermédiaires (JORM et MEDOR sont utilisés pour assurer la persistance au niveau des conteneurs), – un service de conteneur web pour exécuter les moteurs Servlet/JSP en tant que services JOnAS (Tomcat et Jetty), – un gestionnaire de transactions (JOTM) qui assure le support de la coordination des transactions distribuées, – un service JMS pour la messagerie asynchrone (JORAM), – un gestionnaire de base de données assurant la connectivité JDBC, – un service de sécurité, – un service d’administration de serveur utilisant JMX et fournissant une interface graphique, – un service d’envoi d’e-mails, – un service assurant le support des WebServices basé sur Axis, – Un middleware assurant la gestion de la distribution (RMI, cf. section 1 du chapitre 2). Après avoir vu ces généralités sur J2EE, nous présentons, dans la section suivante, les composants logiciels que ce standard permet de manipuler : les Enterprise JavaBeans. 3.1.3
Les composants EJB dans JOnAS
Comme nous l’avons vu dans la section précédente, les conteneurs d’EJBs sont un ensemble de classes Java implémentant la spécification J2EE et un ensemble de classes assurant l’interface entre les composants EJB et les services du serveur applicatif JOnAS. Ces classes d’interposition sont spécifiques à chaque composant EJB et sont générées par l’outil de déploiement. Il y a trois types d’EJB (cf. section 4.2 du chapitre 2) : – Les Session Beans qui ont un cycle de vie court. Ils représentent, dans le cas des stateful Session Beans l’état courant de la session du client correspondant et peuvent être exploités dans le cadre d’une transaction. Un Session Bean est donc instancié pour répondre au besoin d’un client à un moment donné. Les stateless Session Beans sont des composants instanciés par le conteneur au besoin pour répondre à un appel de méthode. Un même stateless Session Bean peut être utilisé pour plusieurs invocations de la même méthode. – Les Entity Beans sont des composants qui représentent des données persistantes. Ils peuvent être partagés par de nombreux clients et sont identifiés par une clé primaire. Le conteneur d’EJB est 6
Les services que nous citons dans cette liste ne sont pas des services tels que nous l’entendons dans SaGE mais des éléments logiciels des serveurs applicatifs J2EE.
124
3. IMPLÉMENTATION DE SAGE DANS UNE PLATE-FORME À BASE DE COMPOSANTS LOGICIELS responsable de la persistance de tels objets si on leur attribue la politique de persistance ad hoc 7 qui est totalement transparente au regard des clients qui les utilisent. – Les Message Driven Beans (MDB) sont des composants écouteurs de messages JMS (Java Message Service). Leur code est exécuté lors de la réception d’un message JMS qui leur est adressé par leur conteneur. Ils implémentent donc les entités répondant aux messages asynchrones dans un serveur J2EE. Dans la mesure où SaGE est dédié aux systèmes dans lesquels les communications sont asynchrones, l’implémentation de ce modèle dans le cadre de J2EE a été effectuée pour les composants MDB.
3.2 Définition des SaGEMDBs et de leurs services 3.2.1
Les “SaGEMDB”
Les MDB sont définis par des classes implémentant l’interface MessageDrivenBean (cf. Figure 5.26). C’est pourquoi, pour implémenter les SaGEMDBs, nous avons défini une classe implémentant cette interface de la manière suivante : – La méthode onMessage (cf. section 4.2.3 du chapitre 2 et figure 5.27) est définie dans la classe SaGEMDB afin d’affecter aux composants SaGE un comportement conforme à la spécification de SaGE. – Une méthode service_selector est définie comme abstraite et sert à associer, à la réception d’une requête, la création d’une occurrence du service correspondant pour y répondre. Elle doit donc être définie par le programmeur quand il implémente un SaGEMDB. La méthode service_selector d’un SaGEMDB est invoquée lors de la réception d’une requête. Elle prend en paramètre le message contenant la requête et retourne une référence vers le service qui est mis en œuvre pour traiter cette requête (cf. Figures 5.25 et 5.27). Nous verrons en section 3.3 comment elle est exploitée. Si les MDB classiques peuvent avoir différent modes d’utilisation (composants interagissant par échanges d’informations, Service Activator (cf. section 4.2.3 du chapitre 2), . . .), les SaGEMDB implémentent des interactions de type requête/réponse et constituent donc un nouveau type de composants qui standardise ce type d’interaction conformément au modèle présenté en section 1 du chapitre 4. 3.2.2
Définition des services SaGE
Comme dans MADKit, les classes de base définissant les services sont abstraites et identifient les outils nécessaires à l’exploitation des services SaGE (cf. section 2.3.3 du chapitre 2). En particulier, le programmeur doit, pour définir un service, définir les méthodes d’initialisation du service et de traitement des messages qui lui sont transférés. 7
CMP (Container Managed Persistence) en opposition à BMP (Bean Managed Persistence)
125
CHAPITRE 5. CONCEPTION ET IMPLÉMENTATION public JSaGEService service_selector (MapMessage m) { JSaGEService s = null ; try { if (m.getString("request").equals("chercher_voyage")) { cpt++ ; s = new BRequestService(this, m, cpt) ; } else if (m.getString("request").equals("chercher_tarifs")){ cpt++ ; s = new BCollectBidsService(this, m, cpt) ; } } catch (JMSException e) { e.printStackTrace() ; System.exit(2) ; } return s ; }
F IG . 5.25 – Exemple en code Java de méthode de sélection de service 3.2.3
Statut des exceptions et des messages
Les exceptions sont définies comme dans SaGE pour MADKit (cf. section 2.4 du chapitre 2 et figure 5.26). SaGE pour JOnAS utilise une classe de message particulière dérivée de MapMessage dérivant elle-même de JMSMessage. Les MapMessages s’apparentent en effet aux ACLMessages car ils encapsulent un ensemble de paires nom/valeur. On retrouve donc dans l’implémentation de SaGE pour JOnAS les mêmes choix techniques que dans MADKit pour ce qui est de la définition des exceptions et des messages.
3.3 Gestion des communications par la modification du conteneurs d’EJB Comme nous l’avons vu dans les sections précédentes, dans J2EE, les envois de messages asynchrones sont possibles à destination des composants MessageDrivenBeans (MDB). Ces derniers sont associés à une Destination JMS et leur méthode onMessage est invoquée (dans un nouveau thread dédié à cet usage) lors de la réception d’un message à cette destination (cf. Figure 2.15). C’est le service JMS qui assure le lancement du serveur JMS et qui gère le pool de connections et de threads. Pour ce faire, JOnAS interpose un objet de type JMessageDrivenBean spécifique à son implémentation de la spécification J2EE et c’est à son niveau que nous intervenons pour implémenter notre modèle. Ainsi, nous avons modifié JOnAS au niveau du conteneur d’EJB pour permettre l’exploitation transparente de SaGE dans JOnAS. Comme nous le voyons en figure 5.27, lorsqu’un message JMS spécifique à SaGE est reçu par 126
3. IMPLÉMENTATION DE SAGE DANS UNE PLATE-FORME À BASE DE COMPOSANTS LOGICIELS
F IG . 5.26 – Diagramme UML de classes de l’implémentation de SaGE pour JOnAS le conteneur, un comportement spécifique est alors mis en œuvre (on retrouve symétriquement ce comportement en section 3.2.1) : – Si ce message est une requête, on invoque la méthode service_selector du SaGEMDB destinataire pour initier et exécuter le service correspondant dans le cadre du SaGEMDB correspondant. – Si ce message est une réponse (standard ou exceptionnelle), il est transféré à la méthode onMessage de la classe SaGEMDB qui assurera la transmission de la réponse au service destinataire ou l’exécution du traitement adéquat. 127
CHAPITRE 5. CONCEPTION ET IMPLÉMENTATION Contrairement à notre implémentation dans MADKit où nous avions défini toute la mécanique de SaGE dans les classes SaGEAgent et Service, nous modifions ici le comportement de la plate-forme elle-même au niveau du conteneur d’EJB. Nous assurons ainsi une meilleure intégration de SaGE à la plate-forme et une exploitation de ce dernier plus transparente au regard du programmeur.
F IG . 5.27 – Gestion des messages JMS par le conteneur d’EJB JOnAS avec SaGE
128
3. IMPLÉMENTATION DE SAGE DANS UNE PLATE-FORME À BASE DE COMPOSANTS LOGICIELS
3.4 Gestion des requêtes groupées Comme nous l’avons vu en section 4.2.3 du chapitre 2, JMS permet le broadcasting auprès d’un ensemble de composants grâce à la notion de topic : un message envoyé à une Destination JMS de type Topic est délivré à l’ensemble des composants y ayant souscrit sans que l’expéditeur n’ait connaissance du nombre ou de l’identité des destinataires. Afin d’intégrer la notion de broadcasting le plus naturellement dans SaGE pour JOnAS, nous avons fait un choix technique similaire à celui fait pour MADKit (cf. section 2.5 du chapitre 2) : Nous n’avons pas utilisé le mécanisme intégré à JMS mais avons créé un composant dédié (Broadcaster) qui prend en charge les requêtes groupées par l’exécution d’un service dédié BroadcastService (cf. Figure 5.26). Comme dans l’implémentation de SaGE pour MADKit, une requête groupée est donc une requêté envoyée à un SaGEMDB dédié qui transmet la requêté aux SaGEMDB concernés puis collecte leurs réponses conformément à la spécification de SaGE.
3.5 Évaluation des résultats dans JOnAS Bien que notre implémentation de SaGE dans JOnAS ne propose pas d’interprétation graphique des résultats, nous avons validé notre prototype par des sorties dans la console du serveur JOnAS. Nous avons pu observer les mêmes résultats que dans MADKit (présentés en section 2.6).
3.6 Bilan Cette seconde expérimentation nous a permis de conforter nos résultats et de démontrer que SaGE était adaptable à plusieurs paradigmes. D’autre part, cette implémentation est plus aboutie dans la mesure où les opérations sont plus transparentes au regard de l’utilisateur que dans nos travaux sur MADKit. Par exemple, le programmeur doit, dans SaGE pour MADKit, spécifier le cycle de vie des agents SaGE en définissant la méthode live() pour qu’elle traite les messages reçus alors que, dans SaGE pour JOnAS, il lui suffit de définir la méthode service_selector() qui joue le rôle de table de correspondance entre nom de requête et nom de services.
129
CHAPITRE 5. CONCEPTION ET IMPLÉMENTATION
130
Chapitre 6
Conclusions et perspectives Sommaire 1
Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
2
Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Cette thèse étudie la gestion d’exceptions dans les systèmes multi-agents (SMA) et les platesformes à base de composants logiciels. La question initiale était celle de la définition d’un système de gestion d’exceptions (SGE) pour les SMA. Il est apparu que les difficultés portaient sur : – le respect du paradigme (autonomie des agents, . . . ) – et l’asynchronisme des communications [Gär99, KO02, CHS04]. Il est apparu que des problèmes identiques se posent dans les plates-formes à base de composants logiciels lorsque des communications asynchrones entrent en jeu.
1 Contributions Nous identifions tout d’abord les spécificités des mécanismes de communication entre entités logicielles qui ont permis d’introduire découplage, asynchronisme, parallélisme et concurrence dans les langages de programmation (cf. sections 1 et 2 du chapitre 2). Nous proposons ensuite une étude des aspects du processus de conception des SMA mettant en avant les modes d’interactions entre agents car c’est à ce niveau-là que l’on peut évaluer les besoins en terme de gestion d’exceptions. Nous faisons ensuite de même pour les plates-formes à base de composants logiciels en insistant sur le cas où des communications asynchrones entrent en jeu (cf. sections 3 et 4 du chapitre 2).
131
CHAPITRE 6. CONCLUSIONS ET PERSPECTIVES Le chapitre 3 présente un état de l’art de la gestion d’exceptions : – étude de base du domaine (cf. section 1), – étude des principaux SGE existant dans les langages séquentiels les plus classiques et ceux qui sont proposés pour des langages dans lesquels il est possible d’effectuer des traitements concurrents (cf. section 3). – étude des solutions proposées dans le contexte des nouvelles architectures logicielles (cf. sections 4 et 5). Ces propositions, souvent centralisées, violent certaines propriétés des paradigmes pour lesquels elles sont définies. Par exemple, une gestion d’exception centralisée est incompatible avec le paradigme agent dans la mesure où elle rend impossible le respect de l’autonomie des agents qui est un des fondements des SMA. Cette première étude nous permet de constater que, quel que soit le contexte, les SGE proposés pour les SMA et les plates-formes à base de composants logiciels ne respectent pas pleinement les bonnes pratiques en terme de gestion d’exceptions lorsque des communications asynchrones entrent en jeu (maintien de la réactivité, respect de la contextualisation, coordination des activités concurrentes durant le processus de signalement et concertation d’exceptions) et ne respectent pas toujours le paradigme auquel elles sont dédiées. Toutefois, dans les travaux sur les systèmes concurrents, deux notions retiennent tout particulièrement notre attention : – D’une part, la concertation d’exceptions qui permet de prendre en compte l’occurrence de multiples exceptions lors de la collecte des réponses à des requêtes envoyées concurremment afin de pouvoir les synthétiser en une exception unique plus globale et représentative de l’état général du système. – D’autre part, la notion de criticité des exceptions qui permet de définir si la notification d’une exception e est critique pour l’activité globale à laquelle l’activité ayant signalé e contribue. Nous élaborons, à partir de cet état de l’art, un cahier des charges identifiant un ensemble de qualités que devrait offrir un SGE pour ces systèmes : – Réactivité du système lors du signalement d’une exception : les messages notifiant une exception doivent être prioritaires afin d’interrompre au plus vite l’exécution des activités devenues inutiles et le SGE doit interrompre l’exécution standard d’une activité dès que celle-ci entame un traitement exceptionnel. – Respect de la contextualisation lors du signalement des exceptions : les exceptions doivent être signalées aux demandeurs de services. Une telle pratique garantit la possibilité de définir des handlers pertinents car dépendants du contexte d’exécution. – Coordination des activités concurrentes lors d’un signalement d’exception : possibilité de gérer les exceptions au niveau des activités des entités actives en prenant en compte les collaborations établies entre celles-ci par des mécanismes de concertation des exceptions et un mécanisme de signalement approprié. 132
1. CONTRIBUTIONS Notre contribution consiste donc en la spécification et la conception d’un système de gestion d’exceptions générique qui réponde à toutes ces attentes dans un contexte où des communications asynchrones sont utilisées. Le système résultant a été nommé SaGE (cf. chapitre 4). Au regard de l’état de l’art, nous voyons qu’un des principaux obstacles à la spécification d’un tel système est l’absence de représentation explicite des collaborations entre entités logicielles à l’image de la pile d’exécution qui représente les appels de méthodes imbriqués dans la programmation par objets séquentielle. Pour pallier ce défaut en permettant l’établissement d’un historique explicite de l’exécution prenant en compte l’asynchronisme des communications et la concurrence, nous avons choisi de définir la notion de service : – Un service décrit une aptitude d’une entité active à répondre à une requête, est exécutable et peut être contrôlé par son entité active propriétaire. – La représentation globale de l’exécution prend la forme d’une arborescence de services qui se forme au fil des émissions de requêtes émises, en cascade, par les services parents qui engendrent l’exécution de services fils. En passant de la granularité des méthodes à celles des services que se rendent les entités actives, nous pouvons définir un SGE exploitant un historique global et complet de l’exécution potentiellement réparti sur l’ensemble des entités actives impliquées. En particulier, cet historique permet la prise en compte du fait qu’un service peut avoir plusieurs sous-services en cours d’exécution, ce que ne permettent pas les représentations de l’exécution du monde séquentiel. Nous pouvons alors spécifier un SGE respectant la contextualisation lors de la propagation des exceptions (on connaît le service appelant d’un service donné) et permettant la coordination des activités concurrentes impliquées dans les coopération entre entités actives (on peut par exemple terminer des sous-services devenus inutiles). Les apports de SaGE, vis-à-vis des propositions existantes (modèles à superviseurs et à gardiens, SGE de base des plates-formes, . . . ) pour les SMA et les plates-formes à base de composants logiciels utilisant des mécanismes de communication asynchrone sont les suivants : – Compatibilité avec le paradigme utilisé afin de garantir l’encapsulation des comportements des composants logiciels ou agents (autonomie, découplage,. . . ), – Possibilité d’associer des handlers à différents niveaux de granularité (requêtes, services, entités actives et rôles) afin de permettre au programmeur de définir des traitements en fonction du niveau de granularité auquel il est le plus pertinent de traiter une exception donnée, – Coordination des activités des entités actives assurée par la représentation explicite de ces activités et par la définition d’outils de contrôle de leur exécution qui permet de surcroît d’assurer une meilleur réactivité du système et l’économie des ressources utilisées par des traitements devenus obsolètes ou inutiles,
133
CHAPITRE 6. CONCLUSIONS ET PERSPECTIVES – Possibilité d’adapter la politique de signalement des exceptions par la définition de fonctions de concertation d’exceptions afin que les exceptions qui sont critiques au regard de l’exécution courante puissent être traitées au plus vite tout en journalisant les exceptions mineures jusqu’à ce que leur conjonction permette un diagnostic éclairé. Comme les handlers, les fonctions de concertation peuvent être associées à divers types d’entités logicielles afin de permettre l’évaluation des situations exceptionnelles dans le contexte le plus adapté. Le cœur du système est un algorithme de signalement original (cf. section 5.2 du chapitre 4) prenant en compte l’ensemble des critères qualitatifs que nous avons identifiés précédemment. SaGE est un modèle générique qui peut être adapté à divers types de plates-formes et paradigmes faisant entrer en jeu des communications asynchrones pour des interactions de type requête/réponse. Afin de valider par la pratique l’intérêt de notre approche, nous avons implémenté et expérimenté notre modèle dans deux paradigmes : 1. Dans le paradigme agent avec la plate-forme multi-agents MADKit, 2. Et dans celui des composants logiciels MDB avec la plate-forme J2EE JOnAS. Les deux prototypes résultants sont opérationnels et disponibles en ligne1 . Ils nous ont permis de tester la validité du modèle SaGE dans deux plates-formes fondamentalement différentes par des jeux de tests sur un cas d’école bien connu de la communauté des SMA et d’y observer des résultats équivalents malgré les différences entre les deux paradigmes contribuant ainsi à démontrer la généricité de notre modèle. Du point de vue des principaux systèmes existants dans notre contexte (cf. sections 3.3 et 4.2 du chapitre 3), nous pouvons dire en résumé que : – Nous avons projeté la solution de Valérie Issarny [Iss01] dans notre contexte d’étude et l’avons étendue pour traiter l’asynchronisme des communications. – Nous nous démarquons de la solution de [MT03] qui consiste en un compromis, défini pour les plates-formes dans lesquelles les communications sont asynchrones, dans lequel on interrompt tout les services impliqués par un signalement d’exception pour traiter cette dernière ce qui permet de travailler sur un état stable du système. Toutefois, ce principe ne permet pas la prise en compte automatisée de signalements concurrents d’exceptions et affecte la réactivité du système. En synthèse, nous avons proposé un SGE générique adapté aux nouvelles architectures logicielles tout en respectant les bonnes pratiques en terme de gestion d’exceptions et le respect des paradigmes dans lequel on le projette.
1
http ://www.lirmm.fr/~fsouchon/
134
2. PERSPECTIVES
2 Perspectives Les travaux que nous présentons dans ce mémoire ouvrent des perspectives diverses dans le domaine de la gestion d’exceptions dans le cadre de l’usage de communications asynchrones. Tout d’abord, afin d’étendre le modèle, il serait possible de donner au programmeur le choix du mode de poursuite de l’exécution après le traitement d’une exception. En effet, dans son état actuel, SaGE n’offre que le mode le plus standard car c’est un modèle à terminaison (cf. section 1.2 du chapitre 3 et section 5.2 du chapitre 4) : tout service interrompt son exécution après avoir traité ou signalé une exception (sauf dans le cas de l’exécution réussie d’un handler associé à une requête). On pourrait donc imaginer un modèle permettant la reprise pour que l’exécution d’un service reprenne après qu’il ait traité une exception. Ensuite, pour ce qui est de la concertation des exceptions, on peut imaginer l’intégration de fonctions de concertation au niveau des entités non pas pour filtrer les exceptions émises par les services puisqu’elles sont signalées dans le cadre de chaînes d’exécution différentes mais pour évaluer, au regard de l’ensemble des exceptions signalées, le niveau de qualité de service offert par l’entité correspondante. Toujours dans le contexte de la concertation des exceptions, on peut imaginer des variantes sur deux thèmes : – Le moment auquel on invoque la fonction de concertation, – L’utilisation de fenêtres glissantes sur des tableaux d’exceptions afin de permettre la relativisation du comportement de la fonction de concertation en fonction de l’ancienneté des notifications d’exceptions. Sur un plan technique, dans le contexte des composants logiciels, on pourrait s’interroger sur les potentialités offertes par l’intégration de SaGE au niveau des WebServices [TILR02] et de la définition d’une table de correspondance entre types de requête et services non plus au travers d’une méthode à définir mais de façon déclarative au travers d’un descripteur de correspondances qui peut être écrit, par exemple, en XML. Dans le domaine de la conception, l’introduction d’outil de modélisation de la gestion d’exceptions (y compris dans le contexte des communications asynchrones) serait bienvenue dans la méthodologie UML afin de permettre aux concepteurs de prendre en compte cette problématique en amont de la phase de développement. De même, afin de permettre une exploitation plus approfondie de l’asynchronisme des communications, on pourrait envisager que des services puissent répondre à leur appelant non seulement par une réponse unique mais aussi par des trains de réponses afin de permettre à l’émetteur d’une requête de commencer à traiter des résultats partiels avant que le service traitant cette dernière n’ait terminé l’intégralité du traitement correspondant. Enfin, dans le but de normaliser la gestion d’exceptions, on pourrait établir une typologie d’exceptions qui embarqueraient des informations sur la stratégie de traitement. On peut prendre l’exemple d’informations relatives à la stratégie de poursuite de l’exécution (reprise, terminaison, . . .). 135
Index .NET, 38, 68
contrat logiciel, 34, 62
événement, 35
coordination, 25
événement exceptionnel, 46
CORBA, 68 critique, 60, 87
acteurs, 71 activités collectives, 67, 72
diffusion collective, 23, 30
agent, 26, 29
dynamique, 49
agent logiciel, 26
EJB, 123, 124
agentification, 112
encapsulation, 31, 63, 100
algorithme standard, 47
Entity Bean, 36, 124
asynchrone, 21
exception, 46, 116, 126
autonomie, 27, 63
fiabilité, 49
boite aux lettres, 114
filtre, 88
BroadcastService, 117
fonction de concertation, 87 futur, 22
callback, 68 classe, 51
gardien, 68
code de sortie, 47
gestionnaire de rôle, 105
composants logiciels, 31, 32
groupe, 29
composition, 88 concertation, 87, 119
handler, 49, 50, 80, 97, 116, 117
concurrence, 72
historique, 88
concurrence compétitive, 25
information, 40, 69
concurrence coopérative, 25, 98
instance, 51
concurrence disjointe, 25
introspection, 32
consommation asynchrone, 27 consommation synchrone, 38
J2EE, 37, 122
conteneur, 32, 124
Java, 56
contexte, 70
JavaBeans, 69
contexte d’exécution, 98
JMS, 37, 67, 122, 126
contextualisation, 70
JOnAS, 122
continuation, 50, 71
journal, 88, 100 136
INDEX RoleAgent, 117
langage sous-jacent, 116 levée, 49
sémantique, 48
levée d’exception, 83
SaGEAgent, 115
log, 88, 100
SaGEMDB, 125
MADKit, 16, 29, 30, 61, 78, 112, 121
self-contained, 57
maintenance, 47
semi-synchrone, 22
Message Driven Bean, 37, 65, 69, 125
serveur d’application, 32
micro-noyau, 112 middleware, 18
service, 116 Service Activator, 38
modèle coopératif, 59
service atomique, 96
modèle d’exécution, 49
service complexe, 96
MOM, 21
Session Bean, 36, 124
mort d’un agent, 61
signalement, 49
multi-procédures, 59
société d’agents, 29
MultiLisp, 81
statique, 49 superviseur, 62
noyau, 112
synchrone, 21 synchronisation, 59
objet, 51
terminaison, 50, 120
pile d’exécution, 98
ThreadGroups, 58
Point-to-Point, 37
threads, 56
portée, 49
topic, 37, 129
priorité, 27
traitant, 49
processus, 25
traitement, 49, 70, 80
Publish and Subscribe, 37
transactions distribuées, 68
Pull, 27 Push, 38
valeur particulière, 48, 62
QoS, 24, 82 queue, 37 Réactivité, 70 réactivité, 23, 25 réutilisation, 31, 47 rôle, 29, 82, 89, 117 reprise, 50 requête collective, 23, 104, 117, 129 ressources, 72 RMI, 19 137
INDEX
138
Bibliographie [AMBN02]
Matthieu Amiguet, Jean-Pierre Müller, José Báez, and Adina Nagy. The moca platform : Simulating the dynamics of social networks. In Jaime Simão Sichman, François Bousquet, and Paul Davidsson, editors, Multi-Agent-Based Simulation II, number 2581 in LNAI, pages 70–88. Springer-Verlag, 2002.
[AMC01]
Deepak Alur, Dan Malks, and John Crupi. Core J2EE Patterns : Best Practices and Design Strategies. Paperback, 2001.
[Ano79]
Anonymous. Rationale for the design of the ada programming language. ACM SIGPLAN Notices, 14(6A) :1–139, June 1979.
[AR00]
Iliès Alouini and Peter Van Roy. Fault-tolerant mobile agents in Mozart. In 2nd International Symposium on Agent Systems and Applications (ASA2000) and 4th International Symposium on Mobile Agents (MA2000), Zurich, Switzerland, September 2000. Poster presented at the conference.
[BBP86]
J-P. Banâtre, M. Banâtre, and F. Ployette. The concept of multi-functions, a general structuring tool for distributed operating system. In Proceedings of the Sixth Distributed Computing Systems Conference, Cambridge, MA, May 1986.
[BCF+ 97]
Jérôme Besancenot, Michèle Cart, Jean Ferrié, Rachid Guerraoui, Philippe Pucheral, and Bruno Traverson. Les systèmes transactionnels. Hermès Sciences, 1997.
[BCM03]
Francoise Baude, Denis Caromel, and Matthieu Morel. From distributed objects to hierarchical grid components. In International Symposium on Distributed Objects and Applications (DOA), Catania, Sicily, Italy, 3-7 November, Springer Verlag, 2003. Lecture Notes in Computer Science, LNCS.
[BGL98]
Jean-Pierre Briot, Rachid Guerraoui, and Klaus-Peter Löhr. Concurrency and distribution in object-oriented programming. ACM Computing Surveys, 30(3) :291–329, September 1998.
[BRHL99]
P. Busetta, R. Ronnquist, A. Hodgson, and A. Lucas. Jack intelligent agents - components for intelligent agents in java. AgentLink News, Issue 2, 1999.
[BZC95]
Chandrajit Bajaj, Peinan Zhang, and Alok Chaturvedi. Brokered collaborative infrastructure for cscw. In Proceedings of the fourth Workshop on Enabling Technologies : 139
BIBLIOGRAPHIE Infrastructure for Collaborative Enterprises (WET-ICE’95), pages 207–213, Berkeley springs, West Virginia, 1995. [Car93]
Denis Caromel. Toward a method of object-oriented concurrent programming. Communications of the ACM, 36(9) :90–102, 1993.
[CG03]
D. Caromel and A. Genoud. Non-functional exceptions for distributed and mobile objects. In Alexander Romanovsky, Christophe Dony, Jorgen Lindskov Knudsen, and Anand Tripath, editors, ECOOP 2003 Workshop on Exception Handling in Object Oriented Systems : towards Emerging Application Areas and New Programming Paradigms, July 2003. http ://homepages.cs.ncl.ac.uk/alexander.romanovsky/home.fo rmal/ehoos2003.html.
[CHS04]
Denis Caromel, Ludovic Henrio, and Bernard Serpette. Asynchronous and deterministic objects. In Proceedings of the 31st ACM Symposium on Principles of Programming Languages. ACM Press, 2004. To appear.
[CKV98]
D. Caromel, W. Klauser, and J. Vayssiere. Towards seamless computing and metacomputing in java. In Geoffrey C. Fox, editor, Concurrency Practice and Experience, volume 10, pages 1043–1061. Wiley and Sons, Ltd., September-November 1998.
[CR86]
R.H. Campbell and B. Randell. Error recovery in asynchronous systems. IEEE Transactions on Software Engineering (TSE), TSE-12 number 8 :811–826, August 1986.
[DF94]
A. Drogoul and J. Ferber. Multi-agent simulation as a tool for modeling societies : Application to social differentiation in ant colonies. In C. Castelfranchi and E. Werner, editors, Artificial Social Systems : Selected Papers from the 4th European Workshop on Modelling Autonomous Agents in a Multi-Agent World (MAAMAW’92), pages 3–23. Springer, Berlin, Heidelberg, 1994.
[Don88]
Christophe Dony.
An object-oriented exception handling system for an object-
oriented language. In Proceedings ECOOP ’88 (European Conference on ObjectOriented Programming), pages 146–161. Springer-Verlag, 1988. [Don90]
Christophe Dony.
Exception handling and object-oriented programming : to-
wards a synthesis.
ACM SIGPLAN Notices, 25(10) :322–330, October 1990.
OOPSLA/ECOOP ’90 Proceedings, N. Meyrowitz (editor). [Don01]
Christophe Dony. A fully object-oriented exception handling system : Rationale and smalltalk implementation. In A. Romanovsky, C. Dony, J. L. Knudsen, and A. Tripathi, editors, Advances in Exception Handling Techniques, LNCS (Lecture Notes in Computer Science) 2022. Springer-Verlag, 2001.
[Fer95]
Jacques Ferber. Les systèmes multi-agents, vers une intelligence artificielle distribuée. InterEditions, 1995. 140
BIBLIOGRAPHIE [FG98]
J. Ferber and O. Gutknecht. A meta-model for the analysis and design of organizations in multi-agent systems. In Third International Conference on Multi-Agent Systems (ICMAS98), pages 128–135, 1998.
[FIP00]
FIPA. FIPA Agent Management Specification, 2000.
[Fou04]
Free Software Foundation. Gnu general public license - gnu project, June 2004. http ://www.gnu.org/copyleft/gpl.html.
[Gär99]
Felix C. Gärtner. Fundamentals of fault tolerant distributed computing in asynchronous environments. ACMCS, 31(1) :1–26, March 1999.
[GB99]
Zahia Guessoum and Jean-Pierre Briot. From active objects to autonomous agents. IEEE Concurrency, 7(3) :68–76, /1999.
[Gol84]
Adele Goldberg.
SMALLTALK-80 : the interactive programming environment.
Addison-Wesley Longman Publishing Co., Inc., 1984. [Goo75]
John B. Goodenough. Exception handling : Issues and a proposed notation. Communications of the ACM, 18(12) :683–696, December 1975.
[GR83]
Adele Goldberg and David Robson. Smalltalk-80 : the language and its implementation. Addison-Wesley Longman Publishing Co., Inc., 1983.
[Gro01]
W. Grosso. Java RMI. O’Reilly, 2001.
[GRRV04]
N. Guelfi, R. Razavi, A. Romanovsky, and S. Vandenbergh. Drip catalyst : An MDE/MDA method for fault-tolerant distributed software families development. In Proceedings of the OOPSLA and GPCE Workshop on Best Practices for Model Driven Software Development, October 2004.
[HA98]
Claus Hagen and Gustavo Alonso. Flexible exception handling in the OPERA process support system. In International Conference on Distributed Computing Systems, pages 526–533, 1998.
[Hal00]
Aart Van Halteren. A reflective QoS provisioning service for object middleware. In Proceedings of the Workshop on Reflective Middleware held in conjunction with the IFIP/ACM International Conference on Distributed Systems Platforms and Open Distributed Processing, 2000.
[HHRS01]
Jun He, Matti A. Hiltunen, Mohan Rajagopalan, and Richard D. Schlichting. Providing QoS customization in distributed object systems. In Proceedings of the IFIP/ACM International Conference on Distributed Systems Platforms (Middleware 2001), Lecture Notes in Computer Science 2218, Springer-Verlag, 2001.
[Hil99]
R. Hilliard. Using the UML for architectural description. In Proceeding of ’99 The Unified Modeling Language : Beyond the Standard. 2nd International Conference, pages 32–48, 1999. Lecture Notes in Computer Science Vol. 1723. 141
BIBLIOGRAPHIE [HL85]
R. Halstead and J. Loaiza. Exception handling in multilisp. In 1985 Int’l. Conf. on Parallel Processing, pages 822–830, August 1985.
[HSB02]
Jomi Fred Hübner, Jaime Simão Sichman, and Olivier Boissier. Spécification structurelle, fonctionnelle et déontique d’organisations dans les SMA. In Philippe Mathieu and Jean-Pierre Müller, editors, Systèmes multi-agents et systèmes complexes, JFIASMA’02. Hermès, 2002.
[Iss01]
Valérie Issarny. Concurrent exception handling. In A. Romanovsky, C. Dony, J. L. Knudsen, and A. Tripathi, editors, Advances in Exception Handling Techniques, LNCS (Lecture Notes in Computer Science) 2022. Springer-Verlag, 2001.
[IY91]
Y. Ichisugi and A. Yonezawa. Exception handling and real-time features in an object oriented concurrent language. In Springer-Verlag, editor, Concurrency : Theory, Language and Architecture, pages 92–109, 1991.
[JBo]
The professional open source company. http ://www.jboss.org/.
[JOn04]
Java open application server (JOnAS) 4.1 : a J2EE platform, June 2004. http ://www.objectweb.org/jonas/current/doc/JOnASWP.html.
[JS96]
Yuh-Jzer Joung and Scott A. Smolka. A comprehensive study of the complexity of multiparty interaction. Journal of the ACM, 43(1) :75–115, January 1996.
[KD99]
Mark Klein and Chrysanthos Dellarocas. Exception handling in agent systems. In Oren Etzioni, Jörg P. Müller, and Jeffrey M. Bradshaw, editors, Proceedings of the Third Annual Conference on Autonomous Agents (AGENTS-99), pages 62–68, New York, May 1–5 1999. ACM Press.
[KD00]
Mark Klein and Chrysanthos Dellarocas. Towards a systematic repository of knowledge about managing multi-agent system exceptions, ASES working paper ASESWP-2000-01, 2000.
[KD01]
Mark Klein and Chrysanthos Dellarocas. Using domain-independent exception handling services to enable robust open multi-agent systems : The case of agent death. In Journal for Autonomous Agents and Multi-Agent Systems, 2001.
[KD03]
Mark Klein and Chrysanthos Dellarocas. Using domain-independent exception handling services to enable robust open multi-agent systems : The case of agent death. Journal for Autonomous Agents and Multi-Agent Systems, 7(1/2), 2003.
[Knu84]
J.L. Knudsen. Exception handling - a static approach. Software - Practice and Experience, 14(5) :429–449, May 1984.
[Knu87]
J.L. Knudsen. Better exception handling in block-structured systems. IEEE Software, 4(3) :40–49, May 1987.
[Knu01]
Jorgen Lindskov Knudsen. Fault tolerance and exception handling in beta. In A. Romanovsky, C. Dony, J. L. Knudsen, and A. Tripathi, editors, Advances in Exception 142
BIBLIOGRAPHIE Handling Techniques, LNCS (Lecture Notes in Computer Science) 2022. SpringerVerlag, 2001. [KO02]
Aaron W. Keen and Ronald A. Olsson. Exception handling during asynchronous method invocation. Euro-Par 2002 Parallel Processing, Lecture Notes in Computer Science series, pages 656–660, August 2002.
[KRA00]
Mark Klein and Juan Antonio Rodriguez-Aguilar. Using role commitment violation analysis to identify exceptions in open multi-agent systems, ASES working paper ASES-WP-2000-04, 2000.
[KS89]
A. R. Koenig and B. Stroustrup. Exception handling for C++. In Proceedings «C++ at Work» Conference, nov 1989.
[LAB+ 78]
Barbara Liskov, Russell Atkinson, Toby Bloom, Eliot Moss, J. Craig Schaffert, Robert Scheifler, and Alan Snyder. CLU Reference Manual. Computation Structures Group, Laboratory for Computer Science, MIT, Cambridge, Massachusetts, July 1978.
[Lac90]
S. Lacourte. Exceptions in Guide, an object-oriented language for distributed applications. In ECOOP 91, number 5-90 in LNCS, pages 268–287, Grenoble (France), December 1990. Springer-Verlag.
[Lis88]
Barbara Liskov. Distributed programming in Argus. Communications of the ACM, 31(3) :300–312, March 1988.
[LM97]
Sean Landis and Silvano Maffeis. Building reliable distributed systems with CORBA. Theory and Practice of Object Systems, 3(1) :31–43, 1997.
[LQ04]
Ph. Lahire and L. Quintian. New perspective to improve reusability in object-oriented languages. Research Report I3S/RR–2004-XX–FR, I3S laboratory (UNSA/CNRS), Sophia-Antipolis, France, September 2004. pages 20.
[Mey88]
Bertrand Meyer. Disciplined exceptions. Technical report tr-ei-22/ex, Interactive Software Engineering, Goleta, CA, 1988.
[Mey92]
Bertrand Meyer. Applying «design by contract». Computer, 25(10) :40–51, 1992.
[Mic04]
.NET Home Microsoft, 2004. http ://www.microsoft.com/net/.
[MNC+ 89]
G. Masini, A. Napoli, D. Colnet, D. Leonard, and K. Tombe. Les langages à objets : Langages de classes, langages de frames, langages d’acteurs. Intereditions, Paris, 1989.
[MT03]
Robert Miller and Anand Tripathi. Primitives and mechanisms of the guardian model for exception handling in distributed systems. In Exception Handling in Object Oriented Systems : towards Emerging Application Areas and New Programming Paradigms Workshop (at ECOOP’03 international conference) proceedings, 2003. 143
BIBLIOGRAPHIE [MY00]
Hidehiko Masuhara and Akinori Yonezawa. An object-oriented concurrent reflective language ABCL/R3 : Its meta-level design and efficient implementation techniques. In Jean-Paul Bahsoun, Takanobu Baba, Jean-Pierre Briot, and Akinori Yonezawa, editors, Object-Oriented Parallel and Distributed Programming, pages 151– 165. HERMES Science Publications, Paris, France, 2000.
[Nix83]
B.A Nixon. A taxis compiler. Technical report 33, University of Toronto, 1983.
[otOMG]
Overview
of
the
Object
Management
Group.
http ://www.omg.org/gettingstarted/gettingstartedindex.htm. [Pes00]
F. Peschanski. Comet : Architecture reflexive à base de composants pour la construction d’applications concurrentes et réparties. In LMO’00 Langages et Modèles à Objets. éditions Hermès, 2000.
[Pit01]
Kent M. Pitman. Condition handling in the lisp language family. In Advances in exception handling techniques, pages 39–59. Springer-Verlag New York, Inc., 2001.
[PJA01]
M. Patino-Martinez, R. Jimenez-Peris, and S. Arevalo. Exception Handling in Transactional Object Groups. In Advances in Exception Handling, LNCS-2022, pages 165–180. Springer, 2001.
[PL90]
T. Anderson P. Lee. Fault tolerance : Principles and practice. Dependable Computing and Fault-Tolerant Systems, 1990.
[RD00]
Pierre-Michel Ricordel and Yves Demazeau. From analysis to deployment : A multiagent platform survey. In Engineering Societies in the Agents World, volume 1972 of LNAI, pages 93–105. Springer-Verlag, December 2000. 1st International Workshop (ESAW’00), Berlin (Germany), 21 August 2000, Revised Papers.
[Ret99]
Reticular Systems, external documentation.
AgentBuilder User’s Guide, 1999.
http ://www.agentbuilder.com/. [RK00]
Alexander B. Romanovsky and Jorg Kienzle. Action-oriented exception handling in cooperative and competitive concurrent object-oriented systems. In Advances in Exception Handling Techniques, pages 147–164, 2000.
[RK01]
Alexander Romanovksy and Jörg Kienzle. Action-oriented exception handling in cooperative and competitive object-oriented systems. In A. Romanovsky, C. Dony, J. L. Knudsen, and A. Tripathi, editors, Advances in Exception Handling Techniques, LNCS (Lecture Notes in Computer Science) 2022. Springer-Verlag, 2001. Also available as Technical Report (EPFL-DI No 00/346).
[Rom97]
Alexander Romanovsky. Practical exception handling and resolution in concurrent programs. Computer Languages, 23(1) :43–58, 1997.
[RRS+ 97]
B. Randell, A. Romanovsky, R. J. Stroud, J. Xu, and A. F. Zorzo. Coordinated Atomic Actions : from Concept to Implementation. Technical Report 595, Department of Computing Science, University of Newcastle upon Tyne, 1997. 144
BIBLIOGRAPHIE [SDUV03]
F. Souchon, C. Dony, C. Urtado, and S. Vauttier. A proposition for exception handling in multi-agent systems. In Proceedings of the 2nd internationaal workshop on Software Engineering for Large-Scale Multi-Agent Systems at ICSE’03, pages 136–143, May 2003.
[SDUV04]
F. Souchon, C. Dony, C. Urtado, and S. Vauttier. Improving exception handling in multi-agent systems. Software engineering for multi-agent systems II, Research issues and practical applications, Carlos José Pereira de Lucena, Alessandro F. Garcia, Alexander B. Romanovsky, Jaelson Castro and Paulo S. C. Alencar Editors, Lecture Notes in Computer Science 2940, February 2004.
[Sie00]
J. Siegel. CORBA 3 Fundamentals and Programming. Wiley, 2000.
[SSY01]
Tatsurou Sekiguchi, Takahiro Sakamoto, and Akinori Yonezawa. Portable implementation of continuation operators in imperative languages by exception handling. Lecture Notes in Computer Science, Springer-Verlag, 2022 :217–, 2001.
[StOSSG00]
Richard Soley and the OMG Staff Strategy Group, November 2000. Model Driven Architecture, Whitepaper.
[Sun02]
Sun Microsystems, Mountain View, Calif. JavaSoft JavaBeans API Specification, 1.01 edition, November 2002. http ://java.sun.com/beans.
[Sun03]
Sun Microsystems, Mountain View, Calif. Enterprise JavaBeans (EJB) version 2.1, November 2003. http ://java.sun.com/ejb.
[Sun04a]
Sun Microsystems, Mountain View, Calif. Java 2 Platform, Enterprise Edition (J2EE) version 1.4, June 2004. http ://java.sun.com/j2ee.
[Sun04b]
Sun Microsystems, Mountain View, Calif. Java 2 Platform, Standard Edition (J2SE), June 2004. http ://java.sun.com/j2se.
[SUVD03]
F. Souchon, C. Urtado, S. Vauttier, and C. Dony. Exception handling in componentbased systems : a first study. In Proceedings of the Exception Handling in ObjectOriented Systems workshop : SELMAS’03, A. Romanovsky, C. Dony, JL. Knudsen and A. Tripathi Editors, pages 84–91, July 2003.
[SVUD04]
F. Souchon, S. Vauttier, C. Urtado, and C. Dony. Fiabilité des applications multiagents : le système de gestion d’exceptions sage. In Systèmes multi-agents défis scientifiques et nouveaux usages - Actes des Journées Francophones sur les Systèmes Multi-Agents (JFSMA 2004), pages 121–134, November 2004.
[Szy98]
Clemens Szyperski. Component Software : Beyond Object-Oriented Programming. ACM Press and Addison-Wesley, New York, NY, 1998.
[The83]
Daniel G. Theriault. Issues in the design and implementation of Act2. Technical Report TR 728, Massachusetts Institute of Technology, Cambridge, Massachusetts, June 1983. 145
BIBLIOGRAPHIE [TILR02]
F. Tartanoglu, V. Issarny, N. Levy, and A. Romanovsky. Dependability in the web service architecture. In Proceedings of WADS (Workshop on Algorithms and Data Structures), Orlando, Florida, 2002.
[TM01]
Anand Tripathi and Robert Miller. Exception handling in agent-oriented systems. In A. Romanovsky, C. Dony, J. L. Knudsen, and A. Tripathi, editors, Advances in Exception Handling Techniques, LNCS (Lecture Notes in Computer Science) 2022. Springer-Verlag, 2001.
[Vac00]
Julie Vachon. COALA : a Design Language for Reliable Distributed Systems. PhD thesis, Ecole Polytechnique Fédérale de Lausanne, CH-1015 Lausanne, December 2000.
[Van99]
Peter Van Roy. On the separation of concerns in distributed programming : Application to distribution structure and fault tolerance in Mozart. World Scientific, Tohoku University, Sendai, Japan, July 1999.
[vD04]
MADKit
version
3.1.
Documentation,
June
2004.
http ://www.madkit.org/madkit/doc/index.php3. [WC99]
Michael Wooldridge and P. Ciancarini. Agent-oriented software engineering. Handbook of Software Engineering and Knowledge Engineering. World Scientific Publishing Company, 1999.
[web99]
ProActive website. INRIA, 1999. http ://www-sop.inria.fr/oasis/ProActive.
[Wik05a]
Wikipedia, november 2005. http ://en.wikipedia.org/wiki/Eiffel_programming_language.
[Wik05b]
Wikipedia, november 2005. http ://en.wikipedia.org/wiki/Design_by_contract.
[WJK00]
Michael Wooldridge, N. R. Jennings, and D. Kinny. The Gaia methodology for agentoriented analysis and design. In AAMAS, Autonomous Agents and Multi-Agent Systems 3, 2000.
[Woo02]
Michael Wooldridge. Introduction to MultiAgent Systems. John Wiley and Sons ; First edition (June 12, 2002), 2002.
[WSPK01]
N. Wang, D. Schmidt, K. Parameswaran, and M. Kircher. Towards a reflective middleware framework for QoS-enabled CORBA component model applications, IEEE distributed systems online special issue on reflective middleware, 2001. http ://citeseer.nj.nec.com/wang01towards.html.
[WWWCW04] Extensible Markup Language (XML) World Wide Web Consortium (W3C), August 2004. http ://www.w3.org/XML/. [WX95]
B. Randell A. Romanovsky C.M.F. Rubira-Calsavara R.J. Stroud Z. Wu and J. Xu. From recovery blocks to concurrent atomic actions. In Predictably Dependable Computing Systems, ESPRIT Basic Research Series, pages 87–101, 1995. 146
BIBLIOGRAPHIE [XNVW00]
Dongyan Xu, Klara Nahrstedt, Arun Viswanathan, and Duangdao Wichadakul. QoS and contention-aware multi-resource reservation. In Proceedings of the ninth HPDC (High Performance Distributed Computing), pages 3–10, 2000.
[XRR+ 95]
Jie Xu, Brian Randell, Alexander B. Romanovsky, Cecilia M. F. Rubira, Robert J. Stroud, and Zhixue Wu.
Fault tolerance in concurrent object-oriented software
through coordinated error recovery. In Symposium on Fault-Tolerant Computing, pages 499–508, 1995. [XRR02]
J. Xu, B. Randell, and A. Romanovsky. A generic approach to structuring and implementing complex fault-tolerant software. In Proceedings of the 5th IEEE international Symposium on Object-Oriented Real-Time Distributed Computing (ISORC 2002). ACM Press, May 2002.
[YBS86]
A. Yonezawa, J. P. Briot, and E. Shibayama. Object-oriented concurrent programming in ABCL/1. In Proceedings of the 1986 Conference on Object-Oriented Programming Systems, Languages and Applications (OOPSLA’86), pages 258–268. ACM Press, November 1986.
[YT87]
A. Yonezawa and M. Tokoro. Object-oriented concurrent programming : An introduction. In A. Yonezawa and M. Tokoro, editors, Object-Oriented Concurrent Programming, pages 1–7. MIT Press, Cambridge, MA, 1987.
147
Résumé : La gestion d’exception est reconnue comme un mécanisme clé des langages de programmation pour la fiabilisation des programmes. Les paradigmes de programmation par agents et par composants fournissent des solutions pour bâtir des applications complexes (distribuées, concurrentes), à partir de constituants, faiblement couplés, qui collaborent en se rendant mutuellement des services. Ces applications ont des besoins aigus en termes de gestion d’exceptions : composées d’entités développées séparément, il est plus difficile de maîtriser leur contexte d’exécution. Paradoxalement, il existe assez peu de systèmes de gestion d’exceptions (SGE) spécifiques aux programmations par agents ou par composants. Le travail réalisé dans cette thèse a consisté tout d’abord à identifier l’influence des spécificités (autonomie des entités exécutables, asynchronisme des communications, collaborations) de ces paradigmes sur la gestion d’exception. Cette analyse a conduit à la proposition de SaGE, un SGE intégré à la gestion des collaborations entre entités, qui permet de traiter les exceptions signalant la défaillance d’un service dans le contexte où le résultat de ce service est attendu. SaGE permet la définition de handlers à différents niveaux de granularité (requêtes, services, agents/composants) pour offrir une palette de possibilités au programmeur. Son mécanisme de signalement d’exception exploite les communications asynchrones et la concurrence pour assurer un traitement réactif des exceptions. L’occurrence concurrente d’exceptions y est géré par un mécanisme de concertation permettant de regrouper des exceptions mineures en une exception unique, relevant d’une défaillance critique. SaGE a été validé par la pratique grâce à deux implémentations : dans le système à agents MADKit et, pour des composants MDB, dans l’implémentation de J2EE JOnAS. Mots-clés : système de gestion d’exceptions, concertation, coordination, concurrence, service, asynchronisme, agents, composants. Abstract : Exception handling is recognized as a key mechanism of programing languages to build reliable software. Agents-based and components-based coding paradigms provide solutions to build complex applications (distributed, concurrent), using parts, slightly coupled, which collaborate providing services to each other. These applications have strong requirements in terms of exception handling : composed of separately developed entities, it is more difficult to manage their execution context. Paradoxically, few exception handling systems exist (EHS) dedicated to agents or components programing exist. The work realized in this thesis first consisted to identify the impact of these paradigms specificities (autonomy of executable entities, communications asynchronism, collaborations) on exception handling. This analysis carried out to the SaGE proposition, an EHS integrated to inter-entities collaboration management, which allow the handling of exceptions notifying a service failure in the context in which the result was expected. SaGE allows the definition of handlers at various granularity levels (requests, services, agents/components) in order to offer a set of solutions to the programmer. Its exception signaling mechanism exploits asynchronous communications and concurrency to ensure a reactive exception handling. Concurrent exceptions occurrence is handled by a concertation mechanism allowing to group minor exceptions in an unique exception, related to a critical failure. SaGE has been validated by enactment thanks to two implementations : in the multi-agent platform MADKit and, for MDB components, in the JOnAS J2EE implementation. Keywords : exception handling system, concertation, coordination, concurrency, service, asynchronism, agents, components.
