• Aucun résultat trouvé

Fabrication de l’itinéraire

Programmation d’agents mobiles pour l’administration système et

6.2 Fabrication et suivi d’itinéraires .1Architecture générale.1Architecture générale

6.2.2 Fabrication de l’itinéraire

Le fonctionnement général de notre système de fabrication d’itinéraire, implé-menté par la classe ItineraryManager est décomposé en deux grandes parties. La première partie consiste en la localisation du bon ItineraryServer, c’est-à-dire celui qui est responsable de la supervision d’un sous-réseau donné. Pour ce faire, et grâce à la technologie Jini, notre ItineraryManager va d’abord récupérer la liste complète de tous les ItineraryServers (ces références sont automatiquement obtenues par le Lookup Service). Ainsi, pour obtenir la référence vers l’Itine-raryServer responsable du bon sous-réseau, il suffit de filtrer la liste résultante et de ne conserver que celui qui est intéressant pour construire la première por-tion de l’itinéraire (méthode getLocalItineraryServer, cf. code figure 6.3). Dès la référence de l’ItineraryServer connue, l’ItineraryManager collecte la liste des éléments SNMP et la liste des nœuds ProActive détectés par l’algorithme de construction de la topologie pour ce sous-réseau.

La deuxième partie est la partie qui est propre à chaque type de gestionnaire d’itinéraire. Pour chacune des sous-classes de l’ItineraryManager la manière dont doit être suivi l’itinéraire est définie. Par exemple, celui-ci peut n’incorpo-rer que des nœuds de la plate-forme, qu’une liste d’agents SNMP à visiter, ou un mélange particulier des deux. Ainsi chaque sous-classe permet de fabriquer un iti-néraire en alimentant une liste de Destinations représentant les Destinations qui doivent être prises en compte lors du suivi de l’itinéraire. Cette liste de Destinations est stockée dans le MigrationStrategyManager dont la tâche est d’assurer les opérations liées au suivi de l’itinéraire.

6.2.2.1 Un itinéraire avec des éléments de même classe de service

Avec notre modèle et les informations que nous connaissons sur les éléments qui composent le réseau, il est relativement aisé d’implémenter une classe, par exemple ItineraryManagerForNetworkPrinter (cf. figure 6.4) qui donnerait un

public abstract class ItineraryManager implements java.io.Serializable { protected MgtMigrationStrategyManagerImpl mgtMigrationStrategyManager; protected MigrationStrategy myItinerary;

protected ItineraryServerList othersItineraryServer; protected Body b; // is the Body of the mobile code protected Destination lastDestination;

private ArrayList myItineraryServerList=new ArrayList(); /** Constructor */

public ItineraryManager() {}

/** Locate the ItineraryServer and prepare an Itinerary */ abstract public void prepareItinerary();

abstract public void prepareItinerary(ItineraryServer itineraryServer) ; /** which method to call at the end ? */

public void setLastDestination(Destination aDestination) { this.lastDestination=aDestination;

}

/** start itinerary */ public void startItinerary() {

try {

mgtMigrationStrategyManager.startStrategy(b); } catch (Exception e) {e.printStackTrace();} }

/** Get the current NodeDestination */ public Destination getCurrentDestination() {

return mgtMigrationStrategyManager.getCurrentDestination(); }

/** Add an Urgent Node to visit */

public void addUrgentDestination(Destination node) { myItinerary.addNext(node);

}

/** return an ItineraryServerList of all ItineraryServers found, except current one */

public ItineraryServerList getOthersItineraryServer() { return othersItineraryServer;

} }

Fig. 6.2 – Les méthodes publiques de la classe de l’ItineraryManager

itinéraire pour n’administrer que des éléments ayant le port TCP 5151 d’ouvert. Il s’agit uniquement de redéfinir la méthode prepareItinerary de la classe ItineraryManager pour obtenir l’itinéraire désiré.

6.2.2.2 Un itinéraire couvrant l’ensemble du réseau

Lorsque nous souhaitons bâtir des itinéraires couvrant plusieurs sous-réseaux (cf. figure 6.5), alors la méthode prepareItinerary a un fonctionnement parti-culier. Comme nous voulons des itinéraires les plus à jour possible, la méthode prepareItinerary sera appelée plusieurs fois pendant le déroulement du suivi de l’itinéraire. En effet, à chaque fin de itinéraire correspondant à un sous-réseau, la destination ISDestination sera insérée pour que

l’ItineraryMana-1Le numéro de port 515 définissant le service associé à un service d’impression IP (protocole lpr/lpd [47]).

// create a MigrationStrategyManager instance private void createMigrationStrategyManager() {

b = ProActive.getBodyOnThis();

if (mgtMigrationStrategyManager == null) {

mgtMigrationStrategyManager = new MgtMigrationStrategyManagerImpl((Migratable) b); myItinerary = mgtMigrationStrategyManager.getMigrationStrategy();

} }

/** Service lookup Discovery */

protected ArrayList getLookupServices(String services) { ServiceLookup sl = new ServiceLookup(services); ArrayList listOfService = new ArrayList(); try {

sl.waitForLastDiscovery();

listOfService.addAll(sl.getServices()); } catch (Exception e) {e.printStackTrace();} }

/** locate our local ItineraryServer */

protected ItineraryServer getLocalItineraryServer() {

IpAddress myAddress = new mgt.ip.InetInfo().getHostIpInfo(); ItineraryServer localItineraryServer=null;

for (int i=0;i<myItineraryServerList.size();i++) { try {

ItineraryServerProxy isp =( ItineraryServerProxy) myItineraryServerList.get(i); if (!isp.getSubNetworkDescription().isInNetwork(myAddress)) othersItineraryServer.add(new ISDestination( (ItineraryServer)ProActive.lookupActive("ItineraryServer", isp.toString()))); else localItineraryServer = (ItineraryServer)ProActive.lookupActive( "mgt.itinerary.ItineraryServer", isp.toString());

} catch (Exception e) {e.printStackTrace();} }

if (localItineraryServer != null) return localItineraryServer; // at this point, no itineraryServer is active for my local network // Create one, and wait for data ready

ArrayList myNetworkList=new ArrayList(getLookupServices("NetworkDescription")); SubNetworkDescription subNetDescr=null;

for (int i=0;i<myNetworkList.size();i++) {

NetworkDescription NetDescr =( NetworkDescription) myNetworkList.get(i); if (NetDescr.getSubNetworkDescription(myAddress) != null)

SubNetDescr = NetDescr.getSubNetworkDescription(myAddress); }

// try to create an ItineraryServer for local network ItineraryServer itineraryServer=null;

try {

Node nodeToStart = JiniNodeFactory.getDefaultNode(); itineraryServer =

(ItineraryServer) ProActive.newActive("ItineraryServer",null,nodeToStart); if (subNetDescr != null)

itineraryServer.setSubNetworkDescription(subNetDescr); else

System.out.println("No configuration Found. "+

Please contact your system administrator !!!"); return ItineraryServer;

} catch (Exception e) {e.printStackTrace();} }

Class ItineraryManagerForPrinter extends ItineraryManager{ public void prepareItinerary (....)

// Prepare the itinerary

public void prepareItinerary(ItineraryServer iS) { createMigrationStrategyManager()

iS.getSnmpNodes();

// éliminer les éléments qui ne conviennent pas

// c’est-à-dire prendre les éléments qui fournissent le service. // Host.getTcpService contient lpr/lpd, port 515

//parmis ceux qui restent

SnmpDestination dest = new SnmpDestination(host, community, "printerOnArrival"); // c’est ici que l’on détermine le nom de la méthode qui sera invoquée :

// dans ce cas, la méthode appelée "printerOnArrival" }

}

Fig. 6.4 – Un ItineraryManager pour la collecte de données sur des imprimantes du sous-réseau représenté par un ItineraryServer

ger puisse enrichir l’itinéraire courant. Il y aura un appel de méthode, comme pour une NodeDestination qui engendrera l’appel sur la méthode prepare-Itinerary de l’prepare-ItineraryManager. Ainsi l’prepare-ItineraryManager enrichira l’itiné-raire courant avec les Destinations du nouveau sous-réseau à visiter. Et ce, tant qu’il existe des ItineraryServers dans la liste obtenue via Jini. Un pro-blème technique est que l’on ne peut pas placer, dès la construction initiale de l’itinéraire, toutes les ISDestinations dans l’itinéraire car sinon on ne pour-rait plus insérer les éléments correspondant à chaque sous-réseau. On ne place donc à la suite de la liste des éléments du sous-réseau courant que la prochaine destination de type ISDestination. Lorsque le MigrationStrategyManager dé-clenche la méthode associée à cette ISDestination sur l’agent, cela dédé-clenchera l’exécution de prepareItinerary pour le réseau associé à cet ItinerarySer-ver. A nouveau, après insertion des éléments de ce réseau (liste récupérée dy-namiquement auprès du ItineraryServer), on rajoute si besoin la prochaine ISDestination, et ainsi de suite. S’il n’y a plus de ISDestination, la méthode prepareItinerary rajoute, le cas échéant, la destination indiquée par la méthode setLastDestination.

Remarque : Toutefois, si l’ItineraryServer n’existe pas pour le réseau cible, son instanciation est initiée afin de pouvoir créer un itinéraire une fois que les informations auront été collectées.