Architecture d´ etaill´ ee du syst` eme de gestion

2.3 Architecture d´ etaill´ ee du syst` eme de gestion

Il a ´et´e choisi de concevoir l’architecture du syst`eme de gestion comme une architecture ayant un d´ecoupage identique `a celui du syst`eme informatique. Par ailleurs, le fait de concevoir le syst`eme de gestion de la mˆeme mani`ere que le SI permettra de l’implanter au sein du SI beaucoup plus facilement. Comme on peut consid´erer le SI et le syst`eme de gestion ´equivalents du point de vue de l’architecture, toutes les caract´eristiques du SI vont se retrouver dans le syst`eme de gestion d’infrastructure : une forte distributivit´e, une taille pouvant ˆetre importante, une forte h´et´erog´en´eit´e, une connectivit´e instable li´ee entre autre

`

a l’´evolutivit´e constante du syst`eme. Ce type de contraintes est courant dans le domaine de l’administration des r´eseaux, et notamment dans le domaine de l’administration proactive.

Nous avons vu au chapitre 3 de la premi`ere partie que les agents mobiles, s’ils sont correctement utilis´es, donnent des r´esultats tout `a fait int´eressant dans un tel contexte qu’il est tr`es difficile d’obtenir avec une architecture centralis´ee. Par rapport au type d’environnement et aux contraintes dans lequel nous concevons le syst`eme de gestion de l’infrastructure, une approche par agents mobiles semble tout `a fait appropri´ee.

Toutefois, comme il est soulign´e dans [SST04], pour tirer pleinement parti du para-digme des agents mobiles, il est n´ecessaire de faire une conception minutieuse et organis´ee.

Par ailleurs, le syst`eme de gestion est trop vaste et trop complexe pour que les agents soient libres d’´evoluer comme bon leur semble. Il y aurait peu de chance, si tel ´etait le cas, d’observer l’´emergence de propri´et´es int´eressantes. Nous avons donc choisi d’´etablir un serveur de gestion pour chaque zone du syst`eme de gestion, un agent ´evoluant toujours dans la zone o`u il a ´et´e cr´e´e. Ce serveur a la responsabilit´e de g´erer les agents d’une part, de corr´eler les donn´ees collect´ees, et d’´echanger des consignes avec les serveurs de gestion des autres zones du mˆeme niveau, mais aussi avec les serveurs des autres niveaux (figure 2.4).

2.4 Mise en œuvre du syst` eme de gestion de l’infra-structure via la plate-forme ”Aglets”

Par rapport `a l’´etude comparative des plates-formes d’agents mobiles du chapitre 2 de la premi`ere partie, nous avons choisi la plate-forme ”Aglets” [Ope] pour r´ealiser le syst`eme de gestion car c’est une plate-forme op´erationnelle, relativement compl`ete et gra-tuite, qui convient tout `a fait au prototypage du syst`eme de gestion de l’infrastructure.

Nous utilisons indiff´eremment les termesaglet ouagent pour d´esigner les agents mobiles de la plate-forme d’administration. Le Kit de D´eveloppement d’Aglets (ASDK) a ´et´e ini-tialement d´evelopp´e par IBM Research au Japon. Il est pass´e depuis dans le domaine du logiciel libre. L’ADSK est enti`erement ´ecrit en Java. Le mot ”aglet” est la contrac-tion de ”agent” et d’”applet” et d´esigne un code mobile ´ecrit en java fonctionnant sous l’environnement Aglet. Le transport et la communication des agents est bas´e sur le pro-tocole sp´ecifique ATP (Agent Transfer Protocol) qui est similaire au protocole HTTP.

L’ASDK est t´el´echargeable gratuitement et peut ˆetre utilis´e librement pour des projets non-commerciaux. Des informations suppl´ementaires peuvent ˆetre obtenues sur le site web de l’application ”Aglets” [Ope]. Actuellement, les aglets sont utilis´es dans beaucoup de

: Noeud administrable

Niveau opérationnel

Niveau tactique Niveau stratégique

: Serveur

d'administration : Transfert de

données

: limite inter-zone : consigne

Fig. 2.4 – Interactions entre les serveurs du syst`eme de gestion

2.4. Mise en œuvre du syst`eme de gestion de l’infrastructure via la plate-forme ”Aglets”

projets de recherche.

Environnement des agents

L’environnement d’ex´ecution : il est seulement compos´e d’un serveur d’aglets qui doit ˆetre ex´ecut´e sur tous les hˆotes sens´es accueillir des agents mobiles. Ce serveur ex´ecute un d´emon ATP recevant les aglets.

Les agents : l’ASDK fournit une structure claire et extensible pour programmer les aglets, avec une API pratique `a utiliser. Un aglet est un objet mobile Java qui peut migrer entre les nœuds ex´ecutant le service aglet. Chaque aglet ex´ecute son propre thread d’ex´ecution et est capable de r´epondre aux messages entrants. Un aglet est prot´eg´e de l’acc`es direct `a ses m´ethodes publiques grˆace `a l’utilisation d’objets proxy. Chaque aglet n’est accessible qu’`a travers son proxy correspondant. Le contexte d’un aglet est son espace de travail. Le contexte est un objet stationnaire qui fournit un environnement d’ex´ecution uniforme. Il permet la maintenance et la gestion des aglets en cours d’ex´ecution et prot`ege le syst`eme hˆote contre les aglets pirates.

Le cycle de vie de l’agent

Un aglet peut seulement ˆetre cr´e´e dans le contexte d’aglet local. Le process de cr´eation assigne `a chaque aglet un identificateur unique de mani`ere globale (GUID) et fournit la r´ef´erence du nouvel aglet au proxy. Une primitive de clonage permet la cr´eation d’une copie identique d’un aglet. Seul l’identificateur diff`ere (il doit ˆetre unique), et l’ex´ecution red´emarre `a l’´etat initial dans le nouvel aglet. Un aglet peut ˆetre d´esactiv´e pour un temps pr´ed´etermin´e, ou jusqu’`a ce qu’un autre aglet demande sa r´eactivation via le proxy. La d´esactivation retire l’aglet du contexte courant et le stocke dans une m´emoire secondaire.

Mobilit´e des agents

Les aglets peuvent migrer vers un autre contexte en appelant la m´ethode dedispatching avec l’URL de l’hˆote distant comme argument. Les aglets et les objets de donn´ees de l’aglet seront s´erialis´es. Les classes n´ecessaires pour construire l’aglet dans le nouveau contexte seront charg´ees par le”class loader” `a partir du”code base” donn´e. Un aglet peut migrer de sa propre volont´e, il peut ´egalement y ˆetre forc´e par un autre aglet ou par l’utilisateur.

Il peut ´egalement ˆetre r´ecup´er´e si on utilise la m´ethode de r´etraction (”retract”). En plus, l’ASDK fournit une classe java codant les itin´eraires, ce qui permet d’´elaborer des trajets complexes.

Communication des agents

Les aglets communiquent entre-eux en s’envoyant des messages. Cela permet la com-munication dynamique avec des aglets connus ou inconnus. La comcom-munication est bas´ee sur un m´ecanisme simple obligeant un aglet `a impl´ementer des fonctions de gestion (”hand-lers”) n´ecessaires pour chaque type de message. Les messages sont envoy´es en invoquant

la m´ethode d’envoi de messages du proxy. Les proxys permettent la localisation transpa-rente des aglets. Pour communiquer, le fait qu’un aglet soit local ou distant ne fait aucune diff´erence. Il existe des classes permettant de construire des messages pr´ed´efinis. L’ASDK supporte les messages synchrones, asynchrones ainsi que la diffusion(multicast). Tous les messages entrants sont stock´es dans une file de messages et g´er´es ensuite un par un. Cette configuration peut ˆetre modifi´ee et il est possible d’affecter des priorit´es aux messages (file

`

a priorit´e). L’ASDK d´efinit un nombre de m´ethodes qui sont appel´ees lors des ´ev´enements majeurs (par exemple pour la cr´eation d’un aglet, son clonage, ou encore son arriv´ee sur un nœud). Ces m´ethodes peuvent ˆetre surcharg´ees par le d´eveloppeur selon les besoins.

Fonctionnalit´es de s´ecurit´e

L’ASDK fournit un gestionnaire des politiques de s´ecurit´e pour les aglets qui est bas´e sur le gestionnaire de s´ecurit´e de Java. Le gestionnaire de s´ecurit´e contrˆole les acc`es des aglets aux m´ethodes critiques et peut ˆetre utilis´e pour d´evelopper des politiques de s´ecurit´e sp´ecifiques. Chaque aglet contient des informations sur sa propre identit´e et celle de son propri´etaire, mais cette information n’est pas utilis´ee pour l’authentification de l’aglet.

Il n’y a donc que deux niveaux de confiance possibles pour les aglets (aglet sˆur et aglet non-sˆur). Tous les aglets g´en´er´es localement et qui sont lanc´es localement sont consid´er´es comme sˆurs. Tous les autres aglets ne sont pas consid´er´es comme sˆurs. Il n’y a que les aglets sˆurs qui peuvent cr´eer d’autres aglets sˆurs sur un mˆeme hˆote. Le gestionnaire d’agents global sur chaque hˆote (Tahiti), accessible `a l’utilisateur, fournit une base de donn´ees simple pour customiser certaines permissions des aglets sˆurs et non-sˆurs. L’ASDK n’utilise pas la cryptographie et ne fournit donc pas de m´ecanismes d’authentification, de transport s´ecuris´e des agents et de leurs communications, de d´etection d’attaques par rejouage.

Conclusion

La plate-forme”Aglets” offre toutes les possibilit´es dont on a besoin pour impl´ementer le syst`eme de gestion de l’infrastructure. Toutefois, la conception du syst`eme de gestion de l’infrastructure est ind´ependante de la plate-forme d’impl´ementation du syst`eme. Il sera tout `a fait possible dans le futur de changer de plate-forme d’agents mobiles, si le besoin s’en faisait sentir. Les paragraphes concernant la conception du syst`eme qui suivent sont donc ind´ependants de la plate-forme d’impl´ementation.