Partie III Exp´ erimentations 117
8.5 D´eveloppement d’une application de gestion
Le travail d’agr´egation des donn´ees de gestion effectu´e par le gestionnaire nous a permis de d´evelopper une application de gestion qui, comme le montre la figure 8.10, offre `a un administra-teur une v´eritable interface de supervision de la plate-forme. Dans cette section, nous d´etaillons chacune des fonctionnalit´es qu’elle offre.
8.5. D´eveloppement d’une application de gestion
8.5.1 D´ecouverte des gestionnaires
L’application est con¸cue pour fonctionner de mani`ere ind´ependante des groupes de pairs qu’elle supervise. Elle peut en effet superviser simultan´ement plusieurs groupes, chacun ayant son propre gestionnaire. Pour pouvoir acc´eder aux donn´ees h´eberg´ees par un gestionnaire particulier, l’application doit se connecter `a lui. Nous proposons deux mani`eres d’effectuer cette connexion. La premi`ere est manuelle et n´ecessite de connaˆıtre l’adresse RMI du gestionnaire. La seconde est effectu´ee automatiquement par la d´ecouverte de l’ensemble des gestionnaires des groupes visibles et accessibles. Pour ce faire, durant cette phase, l’application de gestion ex´ecute un pair Jxta qui va scruter les diff´erents groupes accessibles et chercher au sein de chaque groupe l’existence d’un gestionnaire. Chaque gestionnaire pr´esent r´epond `a cette requˆete de d´ecouverte en indiquant son adresse RMI. Une fois l’op´eration de recherche effectu´ee, le pair est arrˆet´e.
Fig.8.10 – Un aper¸cu de notre application de gestion pour Jxta
8.5.2 Trac´e d’une vue topologique
Les fonctions offertes par notre application s’articulent principalement autour d’une vue topologique des pairs de la communaut´e supervis´ee. Les donn´ees de gestion r´ecup´er´ees aupr`es du gestionnaire nous autorisent `a distinguer les diff´erents types de pairs et les diff´erents liens topologiques. Concernant la nature des pairs, l’application fait ainsi la distinction entre les pairs simples, de rendez-vous et relais, et, du point de vue des relations topologiques, elle distingue
les liens de connexion d’un pair `a son pair de rendez-vous, les liens d’un pair `a un pair relais et les liens entre pairs de rendez-vous.
8.5.3 Monitorage de la plate-forme
Les fonctions de surveillance propos´ees par notre application permettent de s’abonner `a une des m´etriques8 propos´ees dans les donn´ees de gestion et de surveiller sa valeur. Le trac´e de son ´evolution au cours du temps est possible mais l’aspect le plus int´eressant concerne la possibilit´e de fixer un seuil qui, lorsqu’il est franchi, d´eclenche une alarme. Cette alarme peut ˆetre de diff´erentes natures : l’inscription dans un fichier journal, l’apparition d’un message dans l’application ou l’envoi d’un mail `a l’administrateur.
D’un point de vue de la r´ealisation, nous avons confi´e l’int´egralit´e de la tˆache de surveillance `
a notre application de gestion. Ainsi, elle interroge r´eguli`erement le gestionnaire pour r´ecup´erer la valeur courante de la m´etrique et, si un seuil est fix´e, elle compare cette valeur avec celui-ci.
8.5.4 Interaction avec la plate-forme
Enfin, la derni`ere fonctionnalit´e offerte par notre application concerne le contrˆole de la plate-forme Jxta. A ce jour, la seule action que avons rendue possible concerne, pour un pair donn´e, le d´emarrage et l’arrˆet de services `a distance. Cette fonctionnalit´e, combin´ee `a celle de surveillance d’une m´etrique, permet de cr´eer des r`egles de fonctionnement que la plate-forme va devoir appliquer. Par exemple, imaginons qu’un pair mal intentionn´e rejoigne une communaut´e et tente une attaque de d´eni de service en saturant de trafic les pipes qu’il a ´etablis avec ses voisins. La surveillance de la m´etrique NumMessagesSent de la classe JxtaOutputPipeEndPoint va permettre la d´etection de cette saturation et l’application de gestion va alors provoquer l’arrˆet du service de pipe du pair concern´e pour mettre en d´eroute cette attaque.
8.6 Synth`ese
La r´ealisation d’une infrastructure de supervision pour Jxta s’inscrit dans le cadre de la validation du mod`ele de l’information g´en´erique que nous avons propos´e, et dans le cadre du projet Safari. La sp´ecialisation de notre mod`ele de l’information et sa mise en œuvre dans la plate-forme Jxta a montr´e que notre mod`ele pouvait parfaitement int´egrer les sp´ecificit´es de cette plate-forme.
L’infrastructure que nous avons mise en œuvre se compose de trois ´el´ements : un agent de gestion int´egr´e aux pairs Jxta qui h´eberge une vue locale du mod`ele de l’information ; un gestionnaire, lui aussi h´eberg´e dans un pair dont le rˆole est l’agr´egation des donn´ees fournies par les agents ; et une application de gestion qui interagit avec le gestionnaire et qui offre une interface de supervision `a un administrateur.
L’ensemble de cette r´ealisation a ´et´e d´evelopp´ee en langage Java. Nous avons choisi ce langage pour sa portabilit´e et pour garantir l’int´egration des fonctions de supervision dans les pairs Jxta. En outre, nous avons utilis´e la technologie JMX comme cadre de d´eveloppement de nos agents et du gestionnaire. Cette technologie, d´edi´ee `a la supervision des applications Java s’est montr´ee parfaitement appropri´ee `a notre travail.
8
`
Chapitre 9
Conclusions et perspectives
Sommaire
9.1 Un mod`ele de l’information de gestion . . . 135