BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009 Projet de création d’un système dynamique de représentation d’un parc informatique _________________________________ Licence professionnelle CDOAM Conception et Développement Orientés Objets d’Applications Multi-tiers Maitre de stage : GAVARRET Benoit – Tuteur : GREFFIER Françoise BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

PRESENTATION La société SCAM Travaux Publics : - Activité - Localisations - Effectifs représentatifs Environnement / lieu de réalisation : - Le service informatique (localisation, effectifs, gestion…) Le projet de création d’un système dynamique de représentation d’un parc informatique : - Objectif principal : Créer une interface capable de représenter les ressources critiques du réseau informatique et de mettre en évidence les machines non connectées. BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

PRESENTATION Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

ANALYSE PREALABLE AU PROJET Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

ANALYSE PREALABLE AU PROJET Les application de supervision existantes OUTILS EXISTANTS OUTILS A DEVELOPPER Outil d’inventaire du parc informatique (GLPI + OCS Inventory) SUPERVISION du PARC INFORMATIQUE Outil de supervision des alertes dites « SNMP » Système dynamique de représentation des ressources critiques Outil de centralisation des logs machines BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

ANALYSE PREALABLE AU PROJET Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

ANALYSE PREALABLE AU PROJET Limites des outils actuels PRESENTATION Outil d’inventaire du parc informatique (GLPI) Aucune dynamique : l’outil doit être mis à jour quotidiennement par les administrateurs Outil de supervision des alertes dites « SNMP » Aucune globalité : chaque alerte concerne une et une seule machine. Ces dernières ne sont pas regroupées, par agence par exemple. Outil de centralisation des logs machines Aucune optimisation : tous les logs générés sur le parc sont remontés. Aucun tri n’est effectué, par importance par exemple. En bref, les deux principales limites sont les suivantes : Aucune représentation dynamique du réseau : Les outils utilisés ne permettent pas d’avoir une visualisation de l’ensemble du parc. Aucune visualisation rapide de l’état du réseau : Les administrateurs ne peuvent pas savoir, de manière efficiente, les machines qui ont un problème. BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

ANALYSE PREALABLE AU PROJET Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

ANALYSE PREALABLE AU PROJET Besoins exprimés pour la future application L’application doit permettre de : - Représenter graphiquement et dynamiquement l’ensemble des ressources critiques du parc informatique de la société - Visualiser toutes les machines (ressources critiques) recensées par agence grâce à une image descriptive et le nom de la machine - Générer l’état des machines selon leur réponse à la commande « ping » - Mettre en évidence l’état des machines grâce à un code de couleurs ou autres. BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

ANALYSE PREALABLE AU PROJET Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

ANALYSE PREALABLE AU PROJET Choix de développement Langage de programmation utilisé : JAVA Justifié par : - Son orientation « objet » - Sa portabilité - Sa facilité de réutilisation - Son orientation « client/serveur » Environnement de développement : Eclipse Ganymède 3.4 Justifié par : - Sa communauté active - Son environnement modulaire (ajout de plug-ins) BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

REALISATION DE L’APPLICATION Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

REALISATION DE L’APPLICATION Principe de fonctionnement du système dynamique de représentation L’application est divisée en trois programmes distincts : - L’AGENT DISTANT qui construit l’image de l’agence sur laquelle il est implanté, puis la met à disposition. - LE SUPERVISEUR qui centralise les images de toutes les agences, puis met à disposition un tableau de ces images - L’INTERFACE c’est-à-dire le programme qui se charge de récupérer le tableau « d’images » pour ensuite les afficher dans une fenêtre. BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

REALISATION DE L’APPLICATION Principe de fonctionnement du système dynamique de représentation Schéma représentatif AGENT DISTANT Agence de Bordeaux Agence de Toulouse Agence de Clermont-Ferrand 1 INTERFACE 1 SUPERVISEUR 2 Agence de Montpellier 1 1 Site de Marguerittes 1 1 Agence de Toulouse 1 Site de Marguerittes Site de Marguerittes BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

REALISATION DE L’APPLICATION Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

REALISATION DE L’APPLICATION Application orientée « réseau » L’application repose sur l’API Java* RMI (Remote Method Invocation). Définition générale Cette bibliothèque permet de manipuler des objets distants (sur une autre machine du réseau) de manière transparente c’est-à-dire comme s’ils étaient sur la même machine. Description L’architecture RMI repose sur trois acteurs : le serveur (qui met à disposition l’objet), le client (qui demande l’objet) et le registre de noms (qui gère les références entre les divers objets). Dans le cadre de l’application, RMI sera utilisé entre : - l’agent distant (serveur) et le superviseur (client) pour récupérer les images de toutes les agences. - le superviseur (serveur) et l’interface (client) pour l’affichage des machines BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

REALISATION DE L’APPLICATION Application orientée « réseau » ARCHITECTURE RMI (Mise à disposition de l’objet par le serveur) : JVM CLIENT RMIREGISTRY (Serveur de noms) JVM SERVEUR 2 Naming Stub 1 rebind() Client Serveur 3 Mise à disposition Skeleton Stub Etape n°0 : A la création de l’objet, un stub et un skeleton sont créés, coté serveur. Etape n°1 : L’objet serveur s’enregistre auprès du Naming de sa JVM : méthode rebind(). Etape n°2 : Le Naming enregistre le stub de l’objet auprès du serveur de noms (rmiregistry). Etape n°3 : Le serveur de noms est prêt à donner des références à l’objet distant. BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

REALISATION DE L’APPLICATION Application orientée « réseau » ARCHITECTURE RMI (Appel de l’objet par le client) : JVM CLIENT RMIREGISTRY (Serveur de noms) JVM SERVEUR Naming Naming 5 Stub 4 Lookup() Client Serveur 6 Installation 7 Skeleton Stub Etape n°4 : L’objet client fait appel au Naming pour localiser l’objet serveur : « lookup() ». Etape n°5 : Le Naming récupère le stub vers l’objet serveur. Etape n°6 : Le Naming installe l’objet Stub et retourne sa référence au client. Etape n°7 : Le client effectue l’appel à l’objet serveur par appel à l’objet Stub. BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

REALISATION DE L’APPLICATION Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

REALISATION DE L’APPLICATION Détails de la construction d’une agence (Agent Distant) L’image construite d’une agence est un objet de type « ReseauLocalImpl ». Ces attributs sont initialisés, en partie, à l’aide d’un fichier de configuration. Initialisation « tabNoeuds » : Classe « ReseauLocalmpl » ReseauLocalImpl dateMAJ : String tabNoeuds : Vector tabSwitchs : Vector tabLiens : Vector Lecture du fichier Classe « Noeud» Création d’un nœud pour chaque ligne renseignée Noeud adresseMAC : String adresseIP : inetAddress type : String fonction : String descrpiton : String nomHote : String ping : Boolean icone : imageIcon Ajout du nœud dans « tabNoeuds » BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

Initialisation « tabSwitchs » : Initialisation « tabLiens » : REALISATION DE L’APPLICATION Détails de la construction d’une agence (Agent Distant) Initialisation « tabSwitchs » : Initialisation « tabLiens » : Extraction des switchs présents dans « tabNoeuds » Mise à jour des tables de correspondances des switchs Création de la topologie entre les switchs Parcours des tables de correspondances des switchs Création d’un lien entre le switch concerné et le nœud présent dans sa table de correspondance Ajout de l’objet « Liens » créé dans le tableau de liens Ces étapes passées, l’image de l’agence peut ensuite être mise à disposition sur le réseau. BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

RESULTATS OBTENUS Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

RESULTATS OBTENUS Objectifs réalisés ? Objectifs réalisés : - L’objectif principal a été correctement mis en place - L’application est réutilisable à tout moment, pour poursuivre la supervision globale du parc Limites : - L’application cible que les ressources critiques - La dynamique n’est pas entièrement complète (fichier de configuration) BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

RESULTATS OBTENUS Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

RESULTATS OBTENUS Evolutions possibles Les évolutions possibles, qui conviendraient à l’entreprise, sont les suivantes : - Mise en place d’un historique : Il serait logique que les administrateurs puissent revoir l’état du réseau à un moment donné passé (ex : le semaine précédente). - Création d’une vue fonctionnelle : Cette fonctionnalité permettrait une représentation du réseau en arborescence (comme l’explorateur Windows). Ainsi, lors du clic souris sur une machine précise, le détail de sa configuration matérielle et logicielle apparaitrait. A cela s’ajoute, l’intégration des outils existants. En effet, il reste encore de nombreuses possibilités d’évolutions pour cette application, afin d’arriver à l’objectif d’une supervision du parc informatique de la société. BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

CONCLUSION PERSONNELLE Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

CONCLUSION PERSONNELLE Difficultés rencontrées Difficultés basiques avec le langage de programmation Java Réalisation de l’algorithme d’architecture des Switchs L’interface graphique en elle-même avec la superposition de couches Apports personnels Un apport de connaissances incontestable Des compétences renforcées et de nouvelles créées Une motivation encore plus forte quant à mon objectif professionnel BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009 Projet de création d’un système dynamique de représentation d’un parc informatique _________________________________ Licence professionnelle CDOAM Conception et Développement Orientés Objets d’Applications Multi-tiers Maitre de stage : GAVARRET Benoit – Tuteur : GREFFIER Françoise BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009