Transcript PAO - BERNARDIN Benoit

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
Outil d’inventaire
du parc informatique
(GLPI + OCS Inventory)
OUTILS A DEVELOPPER
SUPERVISION
du PARC
INFORMATIQUE
Outil de supervision
des alertes dites « SNMP »
Outil de centralisation
des logs machines
BERNARDIN Benoît
Système dynamique de
représentation des
ressources critiques
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
PRESENTATION
Limites des outils actuels
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 Toulouse
Agence de
Bordeaux
Agence de
Clermont-Ferrand
1
INTERFACE
1
SUPERVISEUR
2
1
1
1
Agence de
Toulouse
1
Agence de
Montpellier
Site de Marguerittes
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
Naming
RMIREGISTRY
(Serveur de noms)
JVM SERVEUR
Naming
5
Stub
4
Lookup()
Client
Serveur
6
Installation
7
Stub
Skeleton
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.
Classe « ReseauLocalmpl »
ReseauLocalImpl
dateMAJ : String
tabNoeuds : Vector
tabSwitchs : Vector
tabLiens : Vector
Initialisation « tabNoeuds » :
Lecture du fichier
Création d’un nœud
pour chaque ligne
renseignée
Ajout du nœud dans
« tabNoeuds »
BERNARDIN Benoît
Classe « Noeud»
Noeud
adresseMAC : String
adresseIP : inetAddress
type : String
fonction : String
descrpiton : String
nomHote : String
ping : Boolean
icone : imageIcon
Université de Franche-Comté – Année 2008/2009
REALISATION DE L’APPLICATION
Détails de la construction d’une agence (Agent Distant)
Initialisation « tabSwitchs » :
Extraction des switchs
présents dans
« tabNoeuds »
Mise à jour des tables de
correspondances des
switchs
Création de la topologie
entre les 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
Initialisation « tabLiens » :
Parcours des tables de
correspondances des
switchs
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
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