by Table of contents 1 Introduction...2 1.1 Contexte du projet... 2 1.2 Objectif du document... 2 2 Prototypage... 2 2.1 Objectif... 2 2.2 Application web...2 2.3 Client serveur...2 3 Conception detaillée...3 3.1 Architecture... 3 3.2 Deploiement et organisation des classes... 7 3.3 Description de la base de données...9 3.4 Définition des paquetages...14 3.5 Interaction entre paquetages... 16 3.6 Topographie du reseau... 16 3.7 Collecter des informations synchrones...17 3.8 Contrainte machine...19 4 Contrainte de réalisation... 19 4.1 Langages et solutions... 19
1. Introduction 1.1. Contexte du projet Pour mener à bien toutes les tâches d'administration d'un réseau, un administrateur a besoin de données fiables, précises et à jour sur tous les éléments du réseau. Pour cela IPFRED se veut être l'outil qui lui permettra de collecter ces données et de les stocker. IPFRED permettra de sonder le réseau afin d'en obtenir sa topographie IPFRED permettra d'obtenir des informations sur chacun de ces éléments sondés IPFRED fournira également un journal des évènements intervenant sur le réseau. 1.2. Objectif du document Ce document présente la conception de l'application IPFRED. L'architecture de l'application IPFRED est constituée des éléments suivants : un serveur d'application avec les objets métiers, des agents sur chaque équipement disposant d'une jvm (Java Virtual Machine) permettant de recueillir des informations, une base de données. 2. Prototypage 2.1. Objectif L'objectif du prototypage est de tester diverses technologies afin de faire communiquer une application web accessible depuis un navigateur avec un programme tournant potentiellement sur une machine distante. L'application web devra également enregistrer le résultat de la requête dans une base de données. 2.2. Application web Une applicatoin Web peut être utilisée de n'importe quelle machine du réseau et sur n'importe quelle OS. Un navigateur web sera nécessaire à l'administrateur pour utiliser cette application web. Le prototypage pour cette partie a consisté à tester le frameworks STRUTS pour faire communiquer l'application web avec un serveur installé sur une autre machine. 2.3. Client serveur 2.3.1. Objectif L'application doit communiquer avec les différents agents déployés sur les équipements du réseau afin d'obtenir de leur part des informations. Il faut donc définir un mode de communication client serveur. Page 2
2.3.2. Etude du protocole SOAP à travers l'implementation AXIS d'apache Les services web permettent l'appel d'une méthode d'un objet distant en utilisant le protocole "http" pour le transport et XML pour formater les échanges. Axis (Apache extensible Interaction System) est un projet open-source du groupe Apache. Il propose un ensemble d'outils pour faciliter le développement, le déploiement et l'utilisation des services web écrits en java. Pour son utilisation, Axis nécessite un JDK 1.3 au minimum et un conteneur de servlet (tomcat). Nos tests pour utiliser Axis ont été concluant, mais ont fait apparaître un inconvénient majeur : Un conteneur de servlet genre Tomcat doit être installé sur chaque machine où l'on désire installer un agent qui sera également notre serveur. Cette solution nous a paru trop contraignante. Une autre solution pour utiliser Axis sans installer Tomcat sur chaque machine où l'on désire installer un agent aurait été que l'agent soit le client et l'application web le serveur, mais cela ne nous a pas paru judicieux, étant donné que c'est l'application web qui interroge l'agent, et non l'inverse. Nous avons donc étudier un autre protocole d'appel de procédure distante Java RMI. 2.3.3. Etude de java rmi (Remote Method Invocation) Le but de RMI est de permettre l'appel, l'exécution et le renvoi du résultat d'une méthode exécutée dans une machine virtuelle différente de celle de l'objet l'appelant. Cette machine virtuelle peut être sur une machine différente pouvu qu'elle soit accessible du réseau. La machine sur laquelle s'exécute la méthode distante est appelée serveur. L'appel côté client consiste à obtenir une référence sur l'objet distant puis à simplement appeler la méthode à partir de cette référence. Contrainte : les objets échangés entre l'aplication et le serveur doivent être sérialisables. 2.3.4. Conclusion Nous avons eu le temps de tester la communication entre une ébauche d'application Web réalisée avec Struts et un serveur grâce à RMI. Dans nos tests, l'utilisateur fournit une adresse IP à l'application qui appelle l'agent pour lui demander des informations sur un Ordinateur. L'agent récupère le nom de l'os de la machine sur laquelle il est installé et renvoie un objet de type Ordinateur. L'application forunit à la vue l'objet Equipement et la vue affiche le nom de l'os dans une page. 3. Conception detaillée 3.1. Architecture 3.1.1. MVC (Modèle Vue Controleur) Page 3
L'architecture MVC est constituée de trois ensembles d'éléments qui possèdent les caractéristiques suivantes : Model : Le modèle contient les fonctionnalités de l'application et encapsule l'état de cette application. View : La vue fournit une présentation du modèle, il s'agit de l'apparence de l'application. Controler : Le controleur réagit en fonction des informations fournies par l'utilisateur. Il créé, initialise et modifie le modèle, puis le transfère à la vue qui se charge de l'afficher. MVC constitue une séparation entre l'affichage des données et leur gestion au niveau métier/applicatif. Schéma de l'architecture MVC dans une application Web (extrait du livre Struts de James Turner et Kevin Bedell des éditions CampusPress) Le traitement s'effectue comme suit: 1. Le navigateur client envoie une requête à l'application 2. Le composant Controleur reçoit la requête. Il commence alors à prendre des décisions sur la façon de continuer, en fonction des règles de gestion qui y sont encodées. 3. Les composants "Modèle" interagissent avec le stockage de données persistantes ou le sytème distant. 4. En fonction des résultats du traitement et des données retournées par les composants Modèle, le Controleur détermine le composant Vue, qui servira à afficher les données à l'utilisateur. Les données sont préparées pour l'objet Vue, qui les affichera. 5. Le composant Vue choisi génère la réponse HTTP à renvoyer à l'utilisateur. 3.1.2. Modele MVC avec struts Struts fournit une implémentation des parties contrôleur et vue, c'est ensuite au développeur de créer le modèle Struts implémente donc l'architecture MVC comme suit : Modèle : Java bean à la charge du développeur Page 4
Vue : JSPs, ActionForms Struts, Taglibs Struts Contrôleur : ActionServlets Struts, RequestProcessor Struts, Action Struts Les schémas ci-dessous illustrent l'architecture Struts (extraits de documents de travail professionnel) Page 5
Ce type d'architecture est un modèle MVC2 (le modèle MVC1 fusionnait les rôles de la servlet et de la JSP) Struts fait partie des projets Jakarta de la communauté Apache Software Foundation. Page d'accueil de Struts : http://jakarta.apache.org/struts/ La version utilisée pour le projet est la version 1.2.4, cette version est compatible avec les spécifications suivantes : Java 1.2 ou plus (nous utiliserons la 1.4) Servlet API Specification : version 2.2 ou plus JavaServer Pages (JSP) spécification : version 1.1 ou plus Tomcat 4.01ou plus : nous utiliseront la version 5 3.1.3. Architecture de l'applicaton Page 6
3.2. Deploiement et organisation des classes Ipfred.war contiendra l'application ainsi que la librairie libipfred.jar Les classes nécesaires à l'agent seront contenues dans un zip serveur, zip qui devra être dézippé sur chaque machine dont l'administrateur via l'application web IPFRED désirera obtenir des informations. 3.2.1. Ipfred.war Page 7
1. Arborescence / : contient la page index.jsp qui redirige sur la page adaptée ainsi que le fichier build.xml qui permet de générer war de l'application /modules /collecte : contient les pages jsp relatives à la collecte /commun : contient les pages jsp qui contiennent le menu, l'en-tête et le pied de page /welcome : contient les pages d'acueil et de connexion /images : contient les images de l'ihm /css : contient les feuilles de styles css de l'appication /WEB-INF : contient les fichiers de description de l'application web /lib contient les librairies nécessaires à l'application /src contient les sources de l'application /META-INF : contient le manifeste de la librairie 2. Définition Ipfred.war correspond à l'application web Ipfred 3.2.2. libipfred.jar 1. Arborescence / : contient les sources de l'application (package agent et équipement) ainsi que le fichier build.xml nécessaire à la compilation par ant de la librairie /META-INF : contient le manifeste de la librairie 2. Définition Contient les classes communes entre l'application web Ipfred et les agents 3.2.3. serveur.zip 1. Arborescense / : contient les classes nécessaires à l'agent (package agent et équipement) ainsi que le script serveur.bat ou serveur.sh qui permet de lancer le serveur. Après avoir dézipper le dossier par exemple dans un répertoire serveur, il faut ouvrir 2 fenêtres consolese et dans chacune : - il faut se positionner dans ce répertoire, - dans l'une executer : rmiregistry - et dans l'autre : java "chemin/programme à lancer" 2. Définition Code de l'agent. Page 8
3.3. Description de la base de données 3.3.1. Les tables Par rapport à Equipement Equipement nomeq varchar(50), nomreseau varchar(50) REFERENCES Reseau (nomreseau), type varchar(50), adresseip varchar(20) PRIMARY KEY -------------------------------------------------------------------------------------------------------- Un Equipement contient : Memoire idmemoire serial PRIMARY KEY, tailledisque bigint, frequence int, adresseip varchar(50) REFERENCES equipement (adresseip) OS idos serial PRIMARY KEY, nomos varchar(50), type varchar(20), version varchar(20), adresseip varchar(50) REFERENCES equipement (adresseip), nomreseau varchar(50) Processeur idprocesseur serial, nompro varchar(50), modele varchar(20), marque varchar (20), frequence float, adresseip varchar(50) REFERENCES equipement (adresseip), PRIMARY KEY (idprocesseur,nompro) Page 9
-------------------------------------------------------------------------------------------------------- Un Equipement appartient à un: Reseau nomreseau varchar(50) PRIMARY KEY, etat varchar(20), masquesousreseau varchar(20), adresseipini varchar(20), adresseipfin varchar(20) -------------------------------------------------------------------------------------------------------- Un Equipement est un (héritage exclusif): NOTE : Les tables routeur, switch, imprimante, serveur, service seront utilisées si nous avons le temps de spécifier les objets correspondants dans l'application web IPfred. Routeur nomrouteur : index tableroutage listeport nomeq : lien avec Equipement Switch nomswitch : index listeport nomeq : lien avec Equipement Imprimante nomimpr : index type nomeq : lien avec Equipement Ordinateur nomordi varchar(50), description varchar(50), nomeq varchar(50), adresseip varchar(50) REFERENCES equipement (adresseip), PRIMARY KEY(adresseIp) -------------------------------------------------------------------------------------------------------- Page 10
Le Serveur spécialise (ou "hérite de" ) Ordinateur : Serveur nomserveur : index listenomservices : lien avec Services par nomservices nomordi : lien avec Ordinateur -------------------------------------------------------------------------------------------------------- Le Serveur propose des services : Services nomservices : index + lien avec Serveur pour la liste de services port nomordi : lien avec serveur -------------------------------------------------------------------------------------------------------- L'Ordinateur contient un ou plusieurs disques Disque iddisque serial, nomdisque varchar (50), nomordi varchar (50) REFERENCES ordinateur(adresseip), taille bigint, espacelibre bigint, nbrpartition int, PRIMARY KEY (iddisque,nomdisque) -------------------------------------------------------------------------------------------------------- Par rapport à la collecte... Collecte nomcollecte varchar(50) PRIMARY KEY, datec date, adresseipini varchar(20), adresseipfin varchar (20) Remarque : La Collecte lance le "scan" du Réseau directement. -------------------------------------------------------------------------------------------------------- La Collecte initialise un : Page 11
Agent nomagent varchar(50) PRIMARY KEY, nomordi varchar (50) REFERENCES ordinateur(adresseip), frequence int, nomcollecte varchar(50) Remarque : L'Agent renvoie des données Asynchrones et des données Synchrones à la collecte. -------------------------------------------------------------------------------------------------------- La Collecte est constituée de : Evenements adresseip varchar(50) REFERENCES equipement (adresseip), date date, nom varchar(50), valeur varchar(50), PRIMARY KEY (adresseip, date,nom,valeur) Donnees_Synchrones donsynch varchar(50), datec date, adresseip varchar(50) REFERENCES equipement (adresseip), nomcollecte varchar(50) REFERENCES collecte (nomcollecte), type varchar(20), valeur varchar(50), PRIMARY KEY (donsynch,datec, adresseip, valeur) -------------------------------------------------------------------------------------------------------- On peut visualiser les informations de la collecte. 3.3.2. Les relations entre les tables Le schéma suivant montre les relations détaillées entre les tables de la partie précédente : Page 12
3.3.3. Le modèle de données associé Le Schéma suivant montre les liens entre les tables et leurs attributs : Page 13
3.4. Définition des paquetages Les packages sont des groupes de classes qui sont cohérants. Ils proposent des fonctionnalités de haut niveau. 3.4.1. fr.cnam.ipfred.exploitation Liste des classes composant le package Exploitation : Page 14
- Evenement - Journal - Reseau L'adminstrateur peut afficher le journal des évènements. Pour cela, il peut paramétrer les affichages qu'il souhaite, concernant une collecte particulière, ou encore un type d'évènements particuliers, comme tout évènement provenant d'un agent, ou du système directement. Quelques exemples d'évènements: - Mesure sur équipement PC IP:192.168.62.10: Charge Processeur 33% - Mesure sur Imprimante IP:192.168.63.12: Impression document Les Packages.xml depuis PC IP:192.168.62.10 - Calcul sur équipement PC IP:192.168.62.10: Charge moyenne du processeur 18% L'administrateur peut egalement afficher la topographie du réseau (classe Reseau) 3.4.2. fr.cnam.ipfred.equipement Le package Equipement regroupe la classe Equipement ainsi que toutes ses classes dérivées - Equipement 3.4.2.1. fr.cnam.ipfred.equipement.elementequipement - Memoire - Equipement - Equipement 3.4.2.2. fr.cnam.ipfred.equipement.equipementreseau - Imprimante - Routeur - Switch 3.4.2.3. fr.cnam.ipfred.equipement.ordinateur - Disque - Ordinateur - Serveur - Service 3.4.3. fr.cnam.ipfred.collecte Le package Collecte regroupe les classes Collecte et Agent Page 15
Liste des classes composant le package Collecte: - Collecte - Agent L'administrateur peut définir une collecte, en créant une stratégie de collecte. Il peut effectuer une collecte sur un réseau ou sous réseau, définir une plage IP, il peut aussi décider d'effectuer une collecte sur un équipement ou sur un groupe d'équipements particulier, et choisir les mesures qui seront faites. Une fois la stratégie définie, il peut lancer sa collecte quand il le désire, puis l'arrêter. C'est la collecte qui effectue le transport des données depuis un agent, ou bien directement depuis un équipement vers le système avant qu'elles ne soient envoyées vers la base de données. 3.5. Interaction entre paquetages Paquetage collecte avec paquetage equipement La classe Collecte dialogue avec la classe agent en passant un objet Ordinateur. La classe Collecte initialise la classe Ordinateur, la classe Agent renseigne les mesures de la classe Equipement et renvoie cet objet. Paquetage collecte avec paquetage exploitation La classe Collecte génère des Evenements à partir des objets Ordinateur que l'agent lui renvoie. Ces évènements seront ensuite enregistrés dans la base de données. La classe collecte renseigne l'objet Reseau lorsque l'administrateur demande une analyse du réseau, ou lorsqu'il demande d'afficher un réseau déjà sondé au préalable 3.6. Topographie du reseau La topographie du réseau sera effectué grâce à NMAP. Nmap permet de sonder un réseau et d'obtenir entre autre les adresses IP présentes sur le réseau, les services ouverts sur sur chaque adresse IP Voici une liste des commandes NMAP pouvant être utiles : nmap -sp -ox /usr/local/nmapresult1.xml 195.220.28.0-255 : permet de découvrir les adresses IP comprises entre 195.220.28.0 195.220.28.255 nmap -O -ox /usr/local/nmapresult2.xml 195.220.28.0-255 : permet de découvrir les adresses Os des adresses IP comprises entre 195.220.28.0 195.220.28.255 Le résultat sera stocké sous forme XML ex : fichier pour une liste d'adresses IP <?xml version="1.0"?> <!-- nmap 3.30 scan initiated Mon Feb 7 19:09:31 2005 as: nmap -sp -ox /usr/local/nmapresult.xml 195.220.28.0-255 --> <nmaprun scanner="nmap" args="nmap -sp -ox /usr/local/nmapresult.xml 195.220.28.0-255" start="1107799771" version="3.30" xmloutputversion="1.0"> <verbose Page 16
level="0" /> <debugging level="0" /> <host> <status state="down" /> <address addr="195.220.28.0" addrtype="ipv4" /> </host> <host> <status state="down" /> <address addr="195.220.28.1" addrtype="ipv4" /> </host>... <host> <status state="down" /> <address addr="195.220.28.255" addrtype="ipv4" /> </host> <runstats> <finished time="1107799927" /><hosts up="0" down="256" total="256" /> <!-- Nmap run completed at Mon Feb 7 19:12:07 2005; 256 IP addresses (0 hosts up) scanned in 156.119 seconds --> </runstats> </nmaprun> L'affichage de la topographie du réseau sera fait grâce à une applet et l'utilisation de la classe JTree qui permet d'afficher des informations sous forme d'arbre. 3.7. Collecter des informations synchrones L'application IPFRED interrogera un agent en lui fournissant un objet Ordinateur initialisé avec son adresse IP. L'agent sera interrogé grâce à java RMI. L'agent renseignera toutes les mesures qui sont définies pour l'objet Ordinateur et renverra à l'application un objet Ordinateur complet. La collecte d'informations pourra être faite de deux manières différentes : La collecte d'informations exclusivement faite en java, qui sera priviligiée car indépendante du système La collecte d'informations en utilisant l'exécution de commandes externes 1. Collecte d'informations en java Java permet d'obtenir sur un sytème les informations suivantes : java.runtime.name=java(tm) 2 Runtime Environment, Standard Edition sun.boot.library.path=c:\program Files\Java\j2re1.4.2_03\bin java.vm.version=1.4.2_03-b02 shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/lib/*.jar java.vm.vendor=sun Microsystems Inc. java.vendor.url=http://java.sun.com/ path.separator=; java.vm.name=java HotSpot(TM) Client VM file.encoding.pkg=sun.io user.country=fr sun.os.patch.level=service Pack 2 java.vm.specification.name=java Virtual Machine Specification user.dir=c:\soft\eclipse Page 17
java.runtime.version=1.4.2_03-b02 java.awt.graphicsenv=sun.awt.win32graphicsenvironment java.endorsed.dirs=c:\soft\apache\tomcat 5.0\common\endorsed os.arch=x86 java.io.tmpdir=c:\soft\apache\tomcat 5.0\temp line.separator= java.vm.specification.vendor=sun Microsystems Inc. user.variant= java.naming.factory.url.pkgs=org.apache.naming os.name=windows XP java.library.path=c:\program... java.specification.name=java Platform API Specification java.class.version=48.0 java.util.prefs.preferencesfactory=java.util.prefs.windowspreferencesfactory os.version=5.1 user.home=c:\documents and Settings\Philippe Grisolano user.timezone=europe/paris catalina.usenaming=true java.awt.printerjob=sun.awt.windows.wprinterjob file.encoding=cp1252 java.specification.version=1.4 catalina.home=c:\soft\apache\tomcat 5.0 user.name=philippe Grisolano java.class.path= C:\soft\apache\Tomcat 5.0\bin\bootstrap.jar;C:\Program Files\Java\j2re1.4.2_03\lib\tools.jar java.naming.factory.initial=org.apache.naming.java.javaurlcontextfactory package.definition=sun.,java.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,org.apache.jasper. java.vm.specification.version=1.0 sun.arch.data.model=32 java.home=c:\program Files\Java\j2re1.4.2_03 java.specification.vendor=sun Microsystems Inc. user.language=fr awt.toolkit=sun.awt.windows.wtoolkit java.vm.info=mixed mode java.version=1.4.2_03 java.ext.dirs=c:\program Files\Java\j2re1.4.2_03\lib\ext sun.boot.class.path=c:\soft\apache\tomcat 5.0\common\endorsed\xercesImpl.jar;C:\soft\apache\Tomcat... java.vendor=sun Microsystems Inc. Page 18
server.loader=${catalina.home}/server/classes,${catalina.home}/server/lib/*.jar catalina.base=c:\soft\apache\tomcat 5.0 file.separator=\ java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport.cgi common.loader=${catalina.home}/common/classes,${catalina.home}/common/endorsed/*.jar,${catalina.home}/com sun.cpu.endian=little sun.io.unicode.encoding=unicodelittle package.access=sun.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,org.apache.jasper.,sun.beans. sun.cpu.isalist=pentium i486 i386 2. Collecte d'informations en exécutant des commandes externes L'exécution d'un programme externe se fait grâce à la méthode exec(java.lang.string commande) de la classe java.lang.runtime Ex : try { Process proc = Runtime.getRuntime().exec("commande paramétrée"); } catch (IOException e) { } Communication : Il est possible de communiquer avec l'application grâce à l'objet java.lang.process : destroy() pour tuer l'application fille. waitfor() pour attendre la fin de l'application fille geterrorstream(), getinputstream() et getoutputstream() pour communiquer avec l'application. exitvalue() pour connaître l'état de sortie de l'application Il nous reste encore à définir les commandes à utiliser en fonction des mesures à effectuer ainsi que du système d'exploitation Ex :System.getProperty("os.name") donne : Windows XP 3.8. Contrainte machine L'application IPFRED devra être installée sur une machine linux, nous avons choisi la distribution Suse 9.2 (Cette application devrait pouvoir tourner sur n'importe quel OS linux ou Windows) L'agent pourra être installé sur n'importe quel OS La base de données Postgrest version 8.0.1 devra être installée sur une machine linux, nous avons choisi la distribution Suse 9.2. (Une version existe également pour Windows mais ce n'est pas la cible) 4. Contrainte de réalisation le serveur sur lequel tourne IPFRED et les autres contraintes 4.1. Langages et solutions 4.1.1. Conception Page 19
La conception a été réalisée grâce à UML. Le modèle de données a été réalisé grâce à Merise 4.1.2. Developpement IPFRED est développé à l'aide du langage Java 2, avec le JDK 1.4 4.1.3. Serveur d'application Tomcat sera le conteneur de servlet, nous utiliseront la version 5 de tomcat 4.1.4. Base de donnée Nous utiliserons la base de données PostGrest dans sa version 8.0.1 4.1.5. Client serveur RMI (Remote Method Invocation) est une technologie développée et fournie par Sun à partir du JDK 1.1 pour permettre de mettre en oeuvre des objets distribués. Le but de RMI est de permettre l'appel, l'exécution et le renvoi du résultat d'une méthode éxécutée dans une machine virtuelle différente de celle de l'objet l'appelant. La machine sur laquelle s'exécute la méthode distante est appelée serveur. La communication entre l'application WEB et les agents sera faite grâce à RMI. L'agent sera considéré comme serveur. Les classes communes à l'agent et l'application seront contenues dans une librairie : libipfred.jar 4.1.6. Struts Struts est un framework de développement pour les applications Web. Il s'agit d'une implémentation open source du modèle de conception MVC. Il propose des outils pour la partie Vue et Controleur et laisse la charge du Modèle au développeur. 4.1.7. Nmap NMAP est utlisé pour sonder le réseau afin d'afficher sa topographie 4.1.8. Applet Un applet sera éventuellement utilisée (si on a le temps de mettre cela en place) pour afficher la topographie du réseau. On utilisera pour cela la classe Jtree. 4.1.9. Snmp SNMP est un protocole de gestion de réseau. Il permet de contrôler un réseau à distance en interrogeant les stations qui en font partie. SNMP sera utilisé uniquement pour effectuer des mesures que nous ne pourrons effectuer par les autres moyens décrits dans ce document. Page 20
Nous utiliserons si besoin SNMP par le biais de la librairie SNMP4J. 4.1.10. Gestion des logs Dans la programmation d'un projet informatique, il serait illusoire de penser que l'application créée puisse s'exécuter sans le moindre problème.il est parfois difficile de comprendre d'où vient un bug si on manque d'informations sur les circonstances dans lesquelles celui-ci a eu lieu. LOG4J est une librairie OpenSource qui permet d'afficher des logs dans des fichiers qui sont paramétrables. Le niveau des logs est également paramétrables. Un niveau de log différent pourra ainsi être utilisé entre le développement et l'exploitation du service. 4.1.11. Gestion XML DOM4J est une bibliothèque opensource permettant de travailler avec du XML grâce à java grâce à l'appui de DOM, SAX et JAXP. Dans le cadre du projet, DOM4J nous servira essentiellement à analyser les fichiers xml créés par NMAP afin de construire la topographie du réseau (renseignement de l'objet Reseau) 4.1.12. Compilation et déploiement Ant est un outil, open source développé par la fondation Apache. Il permet de compiler des sources java et d'assembler des fichiers dans des war, jar,ear. Pour Ipfred, Ant nous servira à : Compiler les classes de l'agent avec rmic Générer la librairie IpfredLib.jar utilisée à la fois par l'agent et l'application Générer le war de l'application prêt à être déployé sur le conteneur de servlet tomcat.(windows ou Linux) Page 21