SaGE,unSystŁmedeGestiond’Exceptions

numéro d’identification :

ACADÉMIE DE MONTPELLIER

U N I V E R S I T É M O N T P E L L I E R I I— SCIENCES ET TECHNIQUES DU LANGUEDOC —

T H È S E

présentée à l’ Université des Sciences et Techniques du Languedoc

pour obtenir le diplôme de DOCTORAT

SPÉCIALITÉ : INFORMATIQUE

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

FRÉDÉRIC SOUCHON

Soutenue le 5 Décembre 2005 devant le jury composé de :

M. Olivier BOISSIER, Professeur, École des Mines de Saint-Étienne, RapporteurM. Philippe LAHIRE, MDC HDR, Université de Nice Sophia Antipolis, RapporteurM. Alexander ROMANOVSKI, Professor, University of Newcastle upon Tyne, UK, ExaminateurMlle. Christelle URTADO, MDC École des Mines d’Alès, ExaminateurM. Jacques FERBER, Professeur, Université Montpellier II, ExaminateurM. Christophe DONY, Professeur, Université Montpellier II, 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éa-

lisable 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’aidequ’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écia-

lement à 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 Introduction 131 Contexte et objet de ce mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Organisation du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 Contexte d’étude : les programmations par agents et par composants 171 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

2 Concurrence et asynchronisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.1 Possibilité de définir des activités concurrentes . . . . . . . . . . . . . . . . 23

2.2 Coordination des activités concurrentes . . . . . . . . . . . . . . . . . . . . 25

3 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 demodélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 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 L’exemple des agences de voyage dans une plate-forme à base de composants

logiciels : choix de modélisation . . . . . . . . . . . . . . . . . . . . . . . . 42

5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3 Gestion d’exceptions : état de l’art 451 Systèmes de Gestion d’Exceptions (SGE) : motivations et définitions . . . . . . . . . 46

1.1 Tolérance aux pannes : quelles solutions ? . . . . . . . . . . . . . . . . . . . 46

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

1.2 Gestion d’exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2 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

3 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

3.2 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

3.3 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.3.3 Un système distinguant les activités critiques et non-critiques dans

le langage Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4 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

4.3 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5 Gestion d’exceptions dans les plates-formes à base de composants logiciels . . . . . 65

5.1 Gestion d’exceptions pour les composants communiquant de manière syn-

chrone et interagissant par requête/réponse . . . . . . . . . . . . . . . . . . 65

5.2 Gestion d’exceptions pour les composants communiquant de manière asyn-

chrone 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

5.3 Gestion d’exceptions pour les composants interagissant par émission d’infor-

mation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6 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

6.4 Concertation d’exceptions signalées par des activités concurrentes . . . . . . 72

7 Travaux connexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

8 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4 SaGE, un SGE dédié aux SMA et aux plates-formes à composants logiciels : Spécification 771 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

5 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

5.3 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

6 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5 Conception et Implémentation 951 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 Réactivité du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

2 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 plate-

forme MADKit . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

2.3.2 Implémentation des agents SaGE . . . . . . . . . . . . . . . . . . 1152.3.3 Implémentation des services SaGE . . . . . . . . . . . . . . . . . 116

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.6.1 Définition des agents . . . . . . . . . . . . . . . . . . . . . . . . 117

2.6.2 Concertation d’exceptions . . . . . . . . . . . . . . . . . . . . . . 119

2.6.3 Terminaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

2.7 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

3 Implémentation de SaGE dans une plate-forme à base de composants logiciels . . . . 122

3.1 Présentation de JOnAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

3.1.1 J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

3.1.2 JOnAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

3.1.3 Les composants EJB dans JOnAS . . . . . . . . . . . . . . . . . . 124

3.2 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

6 Conclusions et perspectives 1311 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 re-

tour 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 . . . . . . . . . . . . . . . . . . 103

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

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 . . . . . . . . . . . . . 1115.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 para-

digmes 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 éven-

tuellement faire entrer en jeu des communication asynchrones (une entité logicielle qui émet un mes-

sage de manière asynchrone poursuit son exécution sans attendre la réponse correspondante). La mo-

dularité, 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 informa-

tiques (cf. chapitre 2).

Les systèmes multi-agents sont constitués d’un ensemble d’entités logicielles actives et indépen-

dantes (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 en-

trer en jeu des communications asynchrones, éventuellement dans le cadre de la programmation orien-

tée message, constituent autant de raisons pour lesquelles il n’est pas possible, dans un tel contexte, de

considérer la gestion d’exceptions1 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 para-

digmes 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’ac-

tivité 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 acti-

vité 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 ex-

ploité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

1Une 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 program-

mation. 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 re-

pré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épen-

dance 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 informa-

tions 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 ges-

tion 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 indispen-

sables à 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 in-

té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 im-

plémenté dans deux plates-formes. Notre première expérimentation, dans le cadre des sys-

tè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 programmationspar agents et par composants

Sommaire

1 Les middlewares : une solution aux limites de la programmation distribuéeclassique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.2 Les modes de communication dans les applications . . . . . . . . . . . . . 21

2 Concurrence et asynchronisme . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.1 Possibilité de définir des activités concurrentes . . . . . . . . . . . . . . . 23

2.2 Coordination des activités concurrentes . . . . . . . . . . . . . . . . . . . 25

3 Les Systèmes Multi-Agents, un exemple typique de la programmation orientéemessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 demodélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 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 compo-sants logiciels : choix de modélisation . . . . . . . . . . . . . . . . . . . . 42

5 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 (pos-

sibilité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 PARCOMPOSANTS

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 dis-tribué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].

FIG. 2.1 – Place du middleware dans les couches logicielles

Les entreprises exploitent de multiples applications qui ont été construites indépendamment en utili-

sant 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 PROGRAMMATIONDISTRIBUÉE CLASSIQUE

applications en interaction peuvent ne pas être exécutées sur la même machine, le mécanisme d’in-

vocation 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éca-

nismes, 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 fonctionnali-

tés des objets accessibles à des objets distants. Pour masquer les sérialisation/désérialisation1 (mar-

shalling/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 in-

vocation 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 corres-

pondante (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’ex-

ception 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 appli-

cations 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 communi-

cation multi-systèmes d’exploitation et multi-langages qui offre, grâce au langage IDL2 (on retrouve

1La sérialisation est un mécanisme qui permet de représenter un objet à envoyer comme paramètre dans le cadre d’uneinvocation de méthode distante sous une forme transportable (chaîne de bytes) pour le middleware utilisé. La désérialisationest le mécanisme inverse qui permet de reconstruire, à partir des données transmises par le middleware, une copie locale del’objet attendu.

2Interface Definition Language, qui est exploitable dans tout langage de programmation offrant une connectivité au buslogiciel CORBA.

19


FIG. 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 im-

plé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.

FIG. 2.3 – Représentation simplifiée du bus CORBA

20

1. LES MIDDLEWARES : UNE SOLUTION AUX LIMITES DE LA PROGRAMMATIONDISTRIBUÉE CLASSIQUE

De tels systèmes assurent une totale transparence de la distribution sans pour autant assurer l’inter-

opé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 pren-

drons 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++.

Invocation

Retour

Client Server

Communication

Entité logicielle exécutable

Exécution de code

Attente du retour

FIG. 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


Communication

Entité logicielle exécutable

Exécution de code

Message

Client Server

FIG. 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 non-

dé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 semi-synchrone. 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 destinataires3 . 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é concur-

remment 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évelop-

pement 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 plus3On peut rapprocher cette vision de la notion de groupes d’objets (Object Groups) [PJA01].

23


é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).

FIG. 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 =

∑n

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 = maxn

i=0 ti).

D’autre part, le programmeur se voit pourvu d’un pouvoir d’expression plus complet qu’en program-

mation 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 : “At-

tendre 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 (sou-

vent 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], ALEXANDER ROMANOVSKY et

JÖRG KIENZLE proposent une classification qui distingue trois types de gestions de la concurrencequi 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 par-

tagé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 tra-

vaillant 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


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 éten-dant 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 parta-

gé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 res-

pectant 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 programmationorienté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 adopteun 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 pro-

cessus 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 PROGRAMMATIONORIENTÉ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 mes-

sage).

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 di-

rectement 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).

FIG. 2.7 – Envoi asynchrone d’un message à destination d’une boîte aux lettres

27


Définition : On appelle système multi-agents (SMA) un ensemble d’agents qui agissent (et inter-

agissent) 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èmesmulti-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 électro-

nique 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 PROGRAMMATIONORIENTÉ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 plate-

forme 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é.

FIG. 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 quedeux 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 identifi-

cation 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


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éli-sation

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

FIG. 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éuti-

lisables 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 im-

pose 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 com-

pré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’as-

semblage 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


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’in-

té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 partiel-

lement 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 en-

capsulé 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


< ?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"><ejb-jar>

<description>Deployment descriptor for the eb JOnAS example</description><display-name>eb example</display-name><enterprise-beans>

<entity><description>Deployment descriptor for the AccountExpl bean JOnAS example</description><ejb-name>AccountExpl</ejb-name><home>eb.AccountHome</home><remote>eb.Account</remote><ejb-class>eb.AccountExplBean</ejb-class><persistence-type>Bean</persistence-type><prim-key-class>java.lang.Integer</prim-key-class><resource-ref>

<res-ref-name>jdbc/AccountExplDs</res-ref-name><res-type>javax.sql.DataSource</res-type><res-auth>Container</res-auth>

</resource-ref></entity>

<entity><description>Deployment descriptor for the AccountImpl bean JOnAS example</description><ejb-name>AccountImpl</ejb-name><home>eb.AccountHome</home><remote>eb.Account</remote><ejb-class>eb.AccountImplBean</ejb-class><persistence-type>Container</persistence-type><prim-key-class>java.lang.Integer</prim-key-class><cmp-field> <field-name>accno</field-name> </cmp-field><cmp-field> <field-name>customer</field-name> </cmp-field><cmp-field> <field-name>balance</field-name> </cmp-field><primkey-field>accno</primkey-field>

</entity></enterprise-beans><assembly-descriptor>

<container-transaction><method> <ejb-name>AccountExpl</ejb-name> <method-name>*</method-

name> </method></container-transaction><container-transaction><method> <ejb-name>AccountImpl</ejb-name> <method-name>*</method-

name> </method></container-transaction>

</assembly-descriptor></ejb-jar>

FIG. 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 intercon-

necté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


FIG. 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 logiciellesest 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


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 consom-

mateurs 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 changementd’é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’assem-blage 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


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).

FIG. 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), lacommunication entre composants distribués par des mécanismes de sérialisation, transport et déséria-

lisation 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 transactiont1.buy(10); // requête émise à destination d’un Session Beanutx.commit(); // Validation de la transaction...

// Méthode distante invoquée sur le Session Beanpublic void buy(int s) {

newtotal = newtotal + s;

}

FIG. 2.13 – Exemple d’invocation d’une méthode Java d’un Session Bean

4RRS pour “Request/Response interactions using Synchronous communications”

36


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.

FIG. 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 to-

pics. 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 ni-

veau 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 Dri-

ven 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 par5RRA pour “Request/Response interactions using Asynchronous communications”.

37


un mécanisme de boîte aux lettres, on parle de mécanisme Push ou de consommation synchrone des

messages (cf. Figure 2.15).

FIG. 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’asyn-

chronisme 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


FIG. 2.16 – Diagramme de classes du patron ServiceActivator

d’un composant distant de manière asynchrone6 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.

FIG. 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 ProActive7 (Java Parallel) [web99, CKV98] qui permet des invocations

asynchrones de méthodes Java par la combinaison des mécanismes JMS, RMI et d’une synchronisa-

tion 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épartir6Dans la mesure où des méthodes sont invoquées, on ne peut plus parler d’un MOM.7ProActive intègre maintenant un modèle de composants [BCM03].

39


sur deux processeurs le produit d’une matrice m0 par un vecteur v0. Pour ce faire, on découpe la ma-

trice 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éeint m; // Nombre de lignes à traiter localementMatrix 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-mm1 = m0.getBlock (0, 0, m, n-1);

m2 = m0.getBlock (m+1, 0, n-1, n-1);

//On rend les objets actifsm1 = (Matrix) turnActive(m1, remoteNode);

m2 = (Matrix) turnActive(m2, localNode);

// Calcul des deux produitsv1 = m1.rightProduct(v0);

v2 = m2.rightProduct(v0);

v3 = v1.concat(v2); // résultat

}

FIG. 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

8ES pour “Event-based interactions using Synchronous communications”9EA pour “Event-based interactions using Asynchronous communications”

40


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

FIG. 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 Java-

Beans [Sun02]. Ces composants sont souvent utilisés dans des environnements de développement vi-

suels dans lesquels le programmeur dispose de composants (parfois pourvus d’une représentation gra-

phique) qu’il relie en connectant les composants producteurs d’événements à des composants consom-

mateurs 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 Ani-

mation_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 del’é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 évo-

qués dans cette section. Pour conclure, la figure 2.21 présente un récapitulatif de la classification que

nous proposons.

41


FIG. 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 logi-ciels : 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 pro-

prié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 exis-

tant 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

FIG. 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


44

Chapitre 3

Gestion d’exceptions : état de l’art

Sommaire

1 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

2 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

3 Gestion d’exceptions en milieu concurrent . . . . . . . . . . . . . . . . . . . . 55

3.1 La gestion d’exceptions dans le cadre de la concurrence isolée : la cas ty-pique des threads Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.2 Gestion d’exceptions dans des langages permettant la concurrence collabo-rative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.3 Des systèmes de gestion d’exceptions pour la concurrence coopérative . . . 58

4 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

5 Gestion d’exceptions dans les plates-formes à base de composants logiciels . . 65

5.1 Gestion d’exceptions pour les composants communiquant de manière syn-chrone et interagissant par requête/réponse . . . . . . . . . . . . . . . . . 65

5.2 Gestion d’exceptions pour les composants communiquant de manière asyn-chrone et interagissant par requête/réponse . . . . . . . . . . . . . . . . . 65

5.3 Gestion d’exceptions pour les composants interagissant par émission d’in-formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6 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

45

CHAPITRE 3. GESTION D’EXCEPTIONS : ÉTAT DE L’ART

6.3 Asynchronisme des communications et coordination des activités concur-rentes lors d’un signalement d’exception . . . . . . . . . . . . . . . . . . 71

6.4 Concertation d’exceptions signalées par des activités concurrentes . . . . . 72

7 Travaux connexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

8 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Ce chapitre fait un tour d’horizon de la gestion d’exceptions en montrant tout d’abord quelles sontles 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 ducalcul.

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 les-

quelles 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 particu-

liè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 lan-

gages 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, à ar-

rê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);}

FIG. 3.1 – Exemple d’utilisation de code de sortie en C

Cette pratique permet :

– de spécifier un code particulier pour chaque exception,

47


– de terminer le programme en exécutant, si possible, une fonction destinée à effectuer des trai-

tements 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 notifi-

cation 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 -1else return sqrt(x);}

FIG. 3.2 – Exemple d’une procédure en C pouvant signaler une exception par une valeur de retourparticuliè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éca-

nisme 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], JOHN B. GOODENOUGH a proposé une spécifi-

cation qui a largement influencé les langages de programmation : la détection d’un événement ex-

ceptionnel 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 trai-

tant (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 lasignaler à 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écu-

tion (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 pro-

cé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


– 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 contexteayant 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 pro-

grammeur 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 nor-

malement). 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

FIG. 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 excep-

tions dans le paradigme objet a permis :

51


Procédure A Procédure B Procédure C Procédure A Procédure B Procédure C

Exécution standard Signalement et traitement d’une exception

Légende

Handler (e1)

Handler (e2)

Handler (e1)

Handler (e3)

Handler (e1)

Handler (e4)

invocationde B

invocationde C

Handler (e1)

Handler (e2)

Handler (e1)

Handler (e3)

Handler (e1)

Handler (e4)

invocationde B

invocationde C

Flot d’exécution Invocation Branchement du flot d’exécution

de type e3d’une exception

signalement

FIG. 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;

FIG. 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;}

FIG. 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é pro-

pose 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


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));...

FIG. 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 Excep-

tion_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 pro-

gramme 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

FIG. 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 termi-

naison 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 environ-

nement de développement dédié à la conception de SGE. Il est très facile, par exemple, de dériverce 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 pro-

blé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 concur-

rence coopérative (cf. section 2.2 du chapitre 2) peut être exploitée pour gérer les exceptions en milieu

55


concurrent.

3.1 La gestion d’exceptions dans le cadre de la concurrence isolée : la cas typique desthreads 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 concur-

rence 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 permet-

tant 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

FIG. 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


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élisme1 , 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.

FIG. 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 à laquelle1Si elle termine son exécution avant la fin de l’exécution de l’expression qu’elle a initiée en parallèle.

57


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 égalementl’association d’un handler à une évaluation d’expression requise en parallèle comme présenté en fi-

gure 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’expres-

sion 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)

FIG. 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 ex-

ceptions signalées par des méthodes invoquées de manière asynchrone [CKV98] mais uniquementles exceptions non-fonctionnelles (c’est-à-dire celles qui sont signalées par le mécanisme d’invoca-

tion 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


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 ISSARNY 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édures2 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 concur-

rentes. 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 pro-

cé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 ni-

veau 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.

2Ensembles de procédures exécutées en parallèle.

59


FIG. 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é col-

lective 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 stan-

dard 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 : <handler>

end Main;

FIG. 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 programma-

tion 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 deplus haut niveau que les objets utilisant des mécanismes de communication et de gestion de l’exécu-

tion 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


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 pro-

pagation 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 pro-

blè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 à com-

muniquer 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

3L’implémentation étudiée de MADKit n’utilise pas les ThreadGroup, vus dans la section 3.3.1, qui auraient pu permettrede 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], TRIPATHI ET MILLER 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 correspon-

dant (comme présenté en figure 3.14). En fonction de règles définies par le programmeur4 , 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 construc-

tion 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 de4La 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


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écoulecommand = notifyGuardian(e);if (command == RETRY) goto retryLabelelse if (command == TERMINATE) throw terminateExceptionelse if (command == REPORT) throw colocateException (report(e));

}

FIG. 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 col-

laborations 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 su-

perviseur 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 excep-

tions 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 COMPOSANTSLOGICIELS

5 Gestion d’exceptions dans les plates-formes à base de composants lo-giciels

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 synchroneet interagissant par requête/réponse

Pour les systèmes existants qui utilisent les composants de type RRS (communiquant de ma-

nière synchrone et interagissant par requête/réponse), les SGE proposés ne diffèrent pas, pour le pro-

grammeur, 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 exceptionnelledans des Session Beans en J2EE.

FIG. 3.15 – Gestion d’exceptions dans un Session Bean

5.2 Gestion d’exceptions pour les composants communiquant de manière asynchroneet 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


// Code d’un composant ou d’une application client(e)...UserTransaction utx;Operation t1; //EJBObject...try{

utx.begin(); // Début d’une transactiont1.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 Beanpublic void buy(int s) {

if (s>newtotal)

throw (new LimitedStockException (newtotal));

newtotal = newtotal - s;}

FIG. 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


FIG. 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);

}

}

FIG. 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


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 roll-

back). 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 signa-

lé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 ex-

ceptionnelles (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.2.4 Le modèle à gardien pour composants RRA

Le système à gardien pour les composants logiciels proposé par ANAND TRIPATHI et ROBERT

MILLER [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’informa-tion

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 informa-

tion 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énement5 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 console6 .

(a) communications synchrones (b) communications asynchrones

FIG. 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

5Dans la spécification JavaBeans, les informations sont échangées entre composants sous la forme de notification d’évé-nements.

6Nous avons vérifié ce comportement avec le BDK (Beans Development Kit).

69


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. Ceprincipe 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 pro-

cé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 pre-

nons pour principe général que, quand une activité signale une exception, son activité appelante estle 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 estné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 in-

teraction 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 concurrenteslors d’un signalement d’exception

Du point de vue de la gestion d’exceptions, il est naturel que le développeur souhaite avoir la pos-

sibilité 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


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écu-

tion 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 collec-tives 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 terminaisonproposés pour les langages séquentiels.

En reconsidérant l’exemple de l’agence de voyage, si une exception interrompt l’exécution stan-

dard de l’activité de mise en relation du client et du prestataire sélectionné, ses sous-activités (exécu-

té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 program-

meur 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 traite-

ment 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 syn-

chronisation 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 ma-

niè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écu-

tion 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 pro-

blé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 res-

pectent la contextualisation lors du signalement des exceptions et offrent de fait un pouvoir d’expres-

sion 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 permet-

tant 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


– celui de Valérie Issarny qui respecte la contextualisation et permet de coordonner les activi-

té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é.

FIG. 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 ou-

vrant 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 plates-

formes 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 li-

mité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

FIG. 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ésentationglobale 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


76

Chapitre 4

SaGE, un SGE dédié aux SMA et auxplates-formes à composants logiciels :Spécification

Sommaire1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782 Hypothèses sur le contexte d’application . . . . . . . . . . . . . . . . . . . . . 783 Statut des exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794 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

5 Signalement des exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.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

6 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

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 programma-

tion 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’excep-

tions dans le développement d’applications au sein desquelles des entités actives (agents ou compo-

sants 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 plates-

formes à 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 ex-

plicité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 gref-

fer 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 correspon-

dant. 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


public class SaGEException extends Exception {

private SaGEActiveEntity signaledBy;public SaGEException(String s) {

super(s);// Récupération de l’entité défaillantesignaledBy = getcurrententity();

}

public ActiveEntity getsignaler() {

return signaledby;

}

}

FIG. 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 voyagereserve(i);

}catch (No_vacancy_Exception exc){

signal (new SaGEException (“No Vacancy”, this));

}

FIG. 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())

}");

FIG. 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 excep-

tion 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


Service "Organiser_un_voyage” {...

handle (SaGENetworkException exc){

afficher(“Impossible de répondre à la demande”)fermer_application

}

...}

FIG. 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’ex-

ception à 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’exceptionresignaler (exc)

}

...}

FIG. 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 signa-

lé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()

}

...}

FIG. 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 primi-

tive dédiée, à l’image du throw du langage Java,. Les deux systèmes de gestion d’exceptions coha-

bitent : 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 signa-

lement 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 rela-

tives 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 trai-

tement 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


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.

FIG. 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 pour-

suit 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 signale-

ment des exceptions (cf. section 6 du chapitre 3).

84


FIG. 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éca-

nisme 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éca-

nisme 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


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).

FIG. 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 comptedans 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


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.

FIG. 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 concer-

tation (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 asso-

ciées. Les exceptions étant déjà concertées au niveau des services, il nous semble a priori inutile de

87


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 notifi-

cations 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ée1 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.1La 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.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 com-

portement à 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 grou-pées destinées à ces derniers envoie la demande de tarifs aux entités actives remplissant le rôle Pres-

tataire, 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)

FIG. 4.11 – Exemple en pseudo-code de fonction de concertation associée au représentant des Pres-tataires

Le mécanisme de concertation des exceptions que nous proposons est donc, dans son principe,

proche de celui proposé par VALÉRIE ISSARNY 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


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 exceptionnelleon exécute lookup_handler

fin

FIG. 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


lookup_handler(SaGEException exc)début

si il existe un handler H pour traiter exc au niveau du service courant

alors invoquer H(exc)sinonsi 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 derecherche_asynchrone(exc, service appelant)

sinon invoquer handler par défaut // top-level atteint

finsi

finsi

finsiterminer le service courant

fin

FIG. 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 exceptionnellesreçues par saon invoque la fonction de concertation de sasi elle retourne une exception concertée

alors

sa passe en exécution exceptionnelleon exécute lookup_handler(exc) sur sa

finsi

fin

FIG. 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


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écu-

tion 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écanismede 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ébutSelon (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 concertationsi canHandle(u,getType(exc)) alors handle (u,exc)sinon lookingup_handler (getOwnerEntity(u),exc)finsiterminate(u)

sinon

addExceptionalResponse(u,getSignalingService(exc),exc)SaGEException cexc = concert(u)si (cexc!= null)

alorsexcpetional_state(u)lookingup_handler (u,cexc)

finsi

finsi

fincasfin

FIG. 4.15 – Principe de l’algorithme de signalement

93


94

Chapitre 5

Conception et Implémentation

Sommaire

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.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

2 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

3 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 concur-

rente [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 ser-

vice 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 ser-

vice 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 ap-

pelant 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 sys-

tè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

1Leurs 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.

FIG. 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


FIG. 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 (servicescomplexes + 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


FIG. 5.3 – Diagramme UML état-transition d’un service complexe SaGE

FIG. 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 correspon-

dante 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


– 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’encap-

sulation 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é pro-

prié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 cor-

respondantes 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é.

FIG. 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


– 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 re-

quê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.

FIG. 5.6 – Exemple d’interaction transparente

101


Suite à la réception de cette requête, Agence l’accepte et exécute en conséquence le service Re-

chercher 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 avan-

tageuse.

102


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”)

}

}

}

FIG. 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


FIG. 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


FIG. 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 fonc-

tion 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é ci-

aprè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


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 corres-

pondant.

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 correspondantesVecteur entites = recupererEntitesAvecRole(role)si entites est vide alors {

// Levée d’une exception si aucune n’a été trouvéelever (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éeenvoyerRequete (entites[i], requete)

}

}

FIG. 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 in-

tégration dans les langages où les entités interagissent par requête/réponse via des communicationsasynchrones puisqu’elle assure non seulement la diffusion des requêtes groupées mais aussi la col-

lecte 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


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) .

FIG. 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 sous-

services 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 puis-

qu’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


FIG. 5.12 – Arborescence de services (première étape)

alors leur service Donner Prix pour y répondre.

FIG. 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


FIG. 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 correspon-

dante.

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


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 in-

formant 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’en-

tité 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 (ter-

minaison 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 ter-

minaison 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 ac-

tivité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

FIG. 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


2.1 Présentation de MADKit

2.1.1 La plate-forme

MADKit est une plate-forme multi-agent libre2 (développée en Java) qui est construite sur unmodè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 pro-

grammeurs, 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 transpa-

rence.

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écu-

tion 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 distri-

bué, 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.

2sous licence GPL/LGPL.3On peut également coder des agents MADKit en Python, Scheme...

112


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 à rempla-

cer 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;

}

}

}

FIG. 5.16 – Exemple du code Java d’un agent MADKit traitant des chaînes de caractères

113


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’informa-

tions 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 sys-tè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


FIG. 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 para-

mè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


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 Com-

plexService 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 ser-

vices 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 multi-

agents,

– 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.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 trai-

tement des requêtes groupées. Afin d’assurer au maximum la cohésion avec le paradigme agent, nousavons 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é : assu-

rer 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 atteri-bué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");}

}

FIG. 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érimen-

tation 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


FIG. 5.19 – Une fenêtre MADKit typique avec des instances de SaGEAgents

��

� ��

��

�� !�!#"

FIG. 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 deservices 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


(a) Utilisation de résultats partiels (b) Signalement d’une exception concertée

FIG. 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 cor-

respondant 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 Re-

chercher_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


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 jus-

qu’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 ex-ceptionnelle 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<subServices.size()) { // On compte le nombre d’exceptions

if (((SubServiceInfo)(subServices.elementAt(i))).getException()!= null) nbexc++;

i++;

}if (nbexc > (0.3*subServices.size()))

// Levée d’un exception concertéeconcertedexception =

new SaGEException("too_many_bad_providers",getAddress());

return concertedexception;

}

FIG. 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


public void broadcasthandle (SaGEException exc,BroadcastService bs) {

if (exc.getMessage().equals("too_many_bad_providers")) {

// Resignalement de l’exception concertéesendMessage(bs.getparentowneraddress(),new

SaGEMessage("exception",exc.getMessage(),bs.getrequestID()));bs.terminate();

}else signal (exc);

}

FIG. 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 recher-

ché 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 re-montant” 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 chapitre4 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


3 Implémentation de SaGE dans une plate-forme à base de composantslogiciels

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 pa-

radigme 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 estdé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évelop-

pement 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 ap-

plications 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 por-

table 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 communica-

tions asynchrones et le service de sécurité.

122

3. IMPLÉMENTATION DE SAGE DANS UNE PLATE-FORME À BASE DE COMPOSANTSLOGICIELS

2. Les informations à destination du programmeur lui expliquant comment les composants logi-

ciels 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 ap-

plicative.

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.

FIG. 5.24 – Architecture de JOnAS

Les principales briques de JOnAS sont :

4JavaServer Pages5http ://www.objectweb.org/

123


– 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 declasses 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

6Les 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


responsable de la persistance de tels objets si on leur attribue la politique de persistance ad hoc7

qui est totalement transparente au regard des clients qui les utilisent.

– Les Message Driven Beans (MDB) sont des composants écouteurs de messages JMS (Java Mes-

sage 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.

7CMP (Container Managed Persistence) en opposition à BMP (Bean Managed Persistence)

125


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;

}

FIG. 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 asyn-

chrones 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


FIG. 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 destina-

taire pour initier et exécuter le service correspondant dans le cadre du SaGEMDB correspon-

dant.

– Si ce message est une réponse (standard ou exceptionnelle), il est transféré à la méthode onMes-

sage de la classe SaGEMDB qui assurera la transmission de la réponse au service destinataire

ou l’exécution du traitement adéquat.

127


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.

FIG. 5.27 – Gestion des messages JMS par le conteneur d’EJB JOnAS avec SaGE

128


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


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 plates-

formes à 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. sec-

tions 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 incompa-

tible 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 du-

rant le processus de signalement et concertation d’exceptions) et ne respectent pas toujours le para-

digme auquel elles sont dédiées.

Toutefois, dans les travaux sur les systèmes concurrents, deux notions retiennent tout particulière-

ment notre attention :

– D’une part, la concertation d’exceptions qui permet de prendre en compte l’occurrence de mul-

tiples 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 excep-

tion 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’excep-

tions 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 en-

gendrent 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 acti-

vité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’éva-

luation 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 tes-

ter 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 équiva-

lents malgré les différences entre les deux paradigmes contribuant ainsi à démontrer la généricité denotre 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 inter-rompt 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.

1http ://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 do-

maine 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 fonc-

tions 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é cor-

respondante.

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 relativisa-

tion du comportement de la fonction de concertation en fonction de l’ancienneté des notifica-

tions 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’excep-

tions (y compris dans le contexte des communications asynchrones) serait bienvenue dans la métho-dologie 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’excep-

tions 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

événement, 35

événement exceptionnel, 46

acteurs, 71

activités collectives, 67, 72

agent, 26, 29

agent logiciel, 26

agentification, 112

algorithme standard, 47

asynchrone, 21

autonomie, 27, 63

boite aux lettres, 114

BroadcastService, 117

callback, 68

classe, 51

code de sortie, 47

composants logiciels, 31, 32

composition, 88

concertation, 87, 119

concurrence, 72

concurrence compétitive, 25

concurrence coopérative, 25, 98

concurrence disjointe, 25

consommation asynchrone, 27

consommation synchrone, 38

conteneur, 32, 124

contexte, 70

contexte d’exécution, 98

contextualisation, 70

continuation, 50, 71

contrat logiciel, 34, 62

coordination, 25

CORBA, 68

critique, 60, 87

diffusion collective, 23, 30

dynamique, 49

EJB, 123, 124

encapsulation, 31, 63, 100

Entity Bean, 36, 124

exception, 46, 116, 126

fiabilité, 49

filtre, 88

fonction de concertation, 87

futur, 22

gardien, 68

gestionnaire de rôle, 105

groupe, 29

handler, 49, 50, 80, 97, 116, 117

historique, 88

information, 40, 69

instance, 51

introspection, 32

J2EE, 37, 122

Java, 56

JavaBeans, 69

JMS, 37, 67, 122, 126

JOnAS, 122

journal, 88, 100

136

INDEX

langage sous-jacent, 116

levée, 49

levée d’exception, 83

log, 88, 100

MADKit, 16, 29, 30, 61, 78, 112, 121

maintenance, 47

Message Driven Bean, 37, 65, 69, 125

micro-noyau, 112

middleware, 18

modèle coopératif, 59

modèle d’exécution, 49

MOM, 21

mort d’un agent, 61

multi-procédures, 59

MultiLisp, 81

noyau, 112

objet, 51

pile d’exécution, 98

Point-to-Point, 37

portée, 49

priorité, 27

processus, 25

Publish and Subscribe, 37

Pull, 27

Push, 38

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

RoleAgent, 117

sémantique, 48

SaGEAgent, 115

SaGEMDB, 125

self-contained, 57

semi-synchrone, 22

serveur d’application, 32

service, 116Service Activator, 38

service atomique, 96

service complexe, 96

Session Bean, 36, 124

signalement, 49

société d’agents, 29

statique, 49

superviseur, 62

synchrone, 21

synchronisation, 59

terminaison, 50, 120

ThreadGroups, 58

threads, 56

topic, 37, 129

traitant, 49

traitement, 49, 70, 80

transactions distribuées, 68

valeur particulière, 48, 62

137

INDEX

138

Bibliographie

[AMBN02] Matthieu Amiguet, Jean-Pierre Müller, José Báez, and Adina Nagy. The moca plat-

form : Simulating the dynamics of social networks. In Jaime Simão Sichman, Fran-

çois Bousquet, and Paul Davidsson, editors, Multi-Agent-Based Simulation II, num-ber 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 SIG-

PLAN 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 In-

ternational 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 Distri-

buted 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 distri-

bution 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 - com-ponents for intelligent agents in java. AgentLink News, Issue 2, 1999.

[BZC95] Chandrajit Bajaj, Peinan Zhang, and Alok Chaturvedi. Brokered collaborative infra-

structure for cscw. In Proceedings of the fourth Workshop on Enabling Technologies :

139

BIBLIOGRAPHIE

Infrastructure for Collaborative Enterprises (WET-ICE’95), pages 207–213, Berke-

ley springs, West Virginia, 1995.

[Car93] Denis Caromel. Toward a method of object-oriented concurrent programming. Com-

munications of the ACM, 36(9) :90–102, 1993.

[CG03] D. Caromel and A. Genoud. Non-functional exceptions for distributed and mobile ob-

jects. 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 Pa-

radigms, July 2003. http ://homepages.cs.ncl.ac.uk/alexander.romanovsky/home.formal/ehoos2003.html.

[CHS04] Denis Caromel, Ludovic Henrio, and Bernard Serpette. Asynchronous and determi-

nistic objects. In Proceedings of the 31st ACM Symposium on Principles of Program-

ming Languages. ACM Press, 2004. To appear.

[CKV98] D. Caromel, W. Klauser, and J. Vayssiere. Towards seamless computing and meta-

computing 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 socie-

ties : 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 Object-

Oriented 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. Tri-

pathi, 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 distri-

buée. InterEditions, 1995.

140

BIBLIOGRAPHIE

[FG98] J. Ferber and O. Gutknecht. A meta-model for the analysis and design of organi-

zations 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 asynchro-nous 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. Commu-

nications of the ACM, 18(12) :683–696, December 1975.

[GR83] Adele Goldberg and David Robson. Smalltalk-80 : the language and its implementa-

tion. 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 Dri-

ven Software Development, October 2004.

[HA98] Claus Hagen and Gustavo Alonso. Flexible exception handling in the OPERA pro-

cess 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. Pro-

viding 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 structu-

relle, 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, JFIAS-

MA’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 ob-

ject 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 know-

ledge about managing multi-agent system exceptions, ASES working paper ASES-

WP-2000-01, 2000.

[KD01] Mark Klein and Chrysanthos Dellarocas. Using domain-independent exception hand-

ling 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 hand-

ling 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 Expe-

rience, 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. Ro-

manovsky, C. Dony, J. L. Knudsen, and A. Tripathi, editors, Advances in Exception

142

BIBLIOGRAPHIE

Handling Techniques, LNCS (Lecture Notes in Computer Science) 2022. Springer-

Verlag, 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, Ro-

bert 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 appli-

cations. 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 mo-

del for exception handling in distributed systems. In Exception Handling in Object

Oriented Systems : towards Emerging Application Areas and New Programming Pa-

radigms Workshop (at ECOOP’03 international conference) proceedings, 2003.

143

BIBLIOGRAPHIE

[MY00] Hidehiko Masuhara and Akinori Yonezawa. An object-oriented concurrent reflec-

tive language ABCL/R3 : Its meta-level design and efficient implementation tech-

niques. In Jean-Paul Bahsoun, Takanobu Baba, Jean-Pierre Briot, and Akinori Yo-

nezawa, 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 construc-

tion 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 Tran-

sactional 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 multi-

agent 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 avai-

lable 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 Soft-

ware 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 is-

sues and practical applications, Carlos José Pereira de Lucena, Alessandro F. Gar-

cia, Alexander B. Romanovsky, Jaelson Castro and Paulo S. C. Alencar Editors, Lec-

ture 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 imple-

mentation 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 component-

based systems : a first study. In Proceedings of the Exception Handling in Object-

Oriented 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 multi-

agents : 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 : Applica-

tion 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. Hand-

book of Software Engineering and Knowledge Engineering. World Scientific Publi-

shing 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 agent-

oriented analysis and design. In AAMAS, Autonomous Agents and Multi-Agent Sys-

tems 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 midd-

leware framework for QoS-enabled CORBA component model applications, IEEE

distributed systems online special issue on reflective middleware, 2001. http ://cite-

seer.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 Com-

puting 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 im-

plementing complex fault-tolerant software. In Proceedings of the 5th IEEE inter-

national 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 program-ming 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 intro-

duction. In A. Yonezawa and M. Tokoro, editors, Object-Oriented Concurrent Pro-

gramming, 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 program-mation pour la fiabilisation des programmes. Les paradigmes de programmation par agents etpar composants fournissent des solutions pour bâtir des applications complexes (distribuées,concurrentes), à partir de constituants, faiblement couplés, qui collaborent en se rendant mu-tuellement des services. Ces applications ont des besoins aigus en termes de gestion d’ex-ceptions : composées d’entités développées séparément, il est plus difficile de maîtriser leurcontexte 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é danscette thèse a consisté tout d’abord à identifier l’influence des spécificités (autonomie des entitésexécutables, asynchronisme des communications, collaborations) de ces paradigmes sur la ges-tion d’exception. Cette analyse a conduit à la proposition de SaGE, un SGE intégré à la gestiondes collaborations entre entités, qui permet de traiter les exceptions signalant la défaillance d’unservice dans le contexte où le résultat de ce service est attendu. SaGE permet la définition dehandlers à différents niveaux de granularité (requêtes, services, agents/composants) pour offrirune palette de possibilités au programmeur. Son mécanisme de signalement d’exception ex-ploite les communications asynchrones et la concurrence pour assurer un traitement réactif desexceptions. L’occurrence concurrente d’exceptions y est géré par un mécanisme de concerta-tion permettant de regrouper des exceptions mineures en une exception unique, relevant d’unedéfaillance critique. SaGE a été validé par la pratique grâce à deux implémentations : dansle système à agents MADKit et, pour des composants MDB, dans l’implémentation de J2EEJOnAS.

Mots-clés : système de gestion d’exceptions, concertation, coordination, concurrence, service, asyn-chronisme, agents, composants.

Abstract : Exception handling is recognized as a key mechanism of programing languages to buildreliable software. Agents-based and components-based coding paradigms provide solutions tobuild complex applications (distributed, concurrent), using parts, slightly coupled, which col-laborate providing services to each other. These applications have strong requirements in termsof exception handling : composed of separately developed entities, it is more difficult to managetheir execution context. Paradoxically, few exception handling systems exist (EHS) dedicatedto agents or components programing exist. The work realized in this thesis first consisted toidentify the impact of these paradigms specificities (autonomy of executable entities, commu-nications asynchronism, collaborations) on exception handling. This analysis carried out to theSaGE proposition, an EHS integrated to inter-entities collaboration management, which allowthe handling of exceptions notifying a service failure in the context in which the result was ex-pected. 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 sig-naling mechanism exploits asynchronous communications and concurrency to ensure a reactiveexception handling. Concurrent exceptions occurrence is handled by a concertation mechanismallowing to group minor exceptions in an unique exception, related to a critical failure. SaGEhas been validated by enactment thanks to two implementations : in the multi-agent platformMADKit and, for MDB components, in the JOnAS J2EE implementation.

Keywords : exception handling system, concertation, coordination, concurrency, service, asynchro-nism, agents, components.

Documents

SaGE,unSystŁmedeGestiond’Exceptions