Rapport scientifique et technique Dates du stage du 17/02/2014 au 14/08/2014 Stage projet de fin d’études Année 2013/2014 Stagiaire : Koenig Arnaud Spécialité : ETI-SID Confidentialité du ra Développement d’un pp„. to nextggge Development of a Jav Entreprise : Avisto Telecom Ville : Vallauris (06) Maitre de stage : Pierre Pacchioni / Arnaud Gastinel Pays : France Fonction : Responsable Technique / Chef d’équipe projet de fin d’études Arnaud Koenig Projet de fin d’études Gestionnaire d’alarmes 9 1 . . 2. Représentation graphique du reseau Etude de faisabilité : présentation des différentes solutions pour IO Développement 2 2. 1. 2. 1. 1. la partie back-end . 2. 1. 2. 12 Etude fonctionnelle/étude technique : présentation de la solution retenue 2. 1. 3. Tests de la partie Back-End . 20 2. 1. 4. Conclusion de la partie Back- End.. 21 15 PAGF OF Front-end…….. . 29 2. 3. Développement Back-End Développement Front-End 2ème partie – représentation graphique du réseau — 30 2. . 1. Introduction et cahier des charges 2. 3. 2. Etude de falsabillté : 2. 3. 3. présentation des différentes solutions — 3 2. 3. 4. Tests 35 2. 3. 5. 32 6 Figure 2 : Principe de fonctionnement du client java JNLP et du client web Figure 3 : Fenêtre regroupant les évènements dans le client graphique actuel Figure 4 : représentation actuelle d’un réseau dans le client J N LP • • • • • • • • • • • • • • • • 10 end…. 22 23 Figure 5 : Schématisation globale de l’application web Figure 6 : Schéma de l’application au niveau back- 14 Figure 7 : Evolution du trafic de recherches Google pour SOAP webservice et REST webservice Figure 8 : Schéma fonctionnel du projet 19 Figure 9 : Exemple d’une requête GET réalisée avec l’extension Chrome Advanced REST Client Figure 10 : Schéma de l’application au niveau Front- nd Figure 1 1 : Maquette avant développement de l’interface du gestlonnaire d’alarmes Figure 12 : Exemple du rendu de l’arbre de l’inventaire 25 Figure 13 : Aperçu de l’interface finale arbre + grille avec les alarmes relative à l’élément sélectionné par l’utilisateur 27 Figure 14 : Analy 6 Figure 14 : Analyse de la requête ajax relative au chargement d’un paquet de 1000 alarmes 28 Figure 15 : Fenêtre pour la validation des alarmes sélectionnées Figure 16 : Maquette avant développement de l’interface . Figure 17 : Exemple du rendu de la représentation graphique d’un réseau 34 4 Remerciements En introduction à ce rapport je tiens à remercier les personnes suivantes qui m’ont accueilli et guidé au cours de mon stage. Florian Darnand et Cyril Blanchet (responsables d’affaires) : Pour m’avoir offert l’opportunité de réaliser ce stage au sein d’Avisto et m’avor donné un projet valorlsant se basant sur les technologies qui m’intéressaient. Pierre Pacchioni (responsable technique) : pour l’accueil au sein de son équipe et ses conseils sur comment mener à bien mon projet.
Arnaud Gastinel et Laurent Baye (ingénieurs logiciel) : Pour leur aide quotidienne (technique et organisationnelle) our le développement et la gestion des différentes étapes du projet. Je remercie également l’ensemble des ingénieurs de l’agence de Sophia Antipolis – notamment Jonathan et Samuel – pour leur accueil et la bonne ambiance de travail qui y régnait. PAGF s 6 gérer les équipements du réseau, de superviser et de diagnostiquer des problèmes réseau et matériels à distance. JNLP : Java Network Launching Protocol : JNI_P est un format de fichier Java décrivant une application pouvant être déployée depuis un navigateur web et fonctionnant dans l’environnement Java du poste client. Enterprise JavaBeans : EJB est une architecture de composants logiciel coté serveur en Java.
Plus généralement, un EJB est un objet java représentant des données de la couche métier du logiciel, accessible à distance par son nom JNDI. Network Element, Composant matériel dédié à des fonctions JAX-RS : API Java permettant de créer des services web normalisés sur une architecture REST JNDI : Java Naming and Directory Interface : API Java EE offrant des mécanismes de nommage uniformisé, d’indexage et de recherche via un annuaire pour les objets. un ensemble d’associations nom/objet forme un contexte. JSON : JavaScript Object Notation : Format de données textuelles permettant de représenter de l’information de manière structurée. AJAX Asynchronous JavaScript and XML .
Acronyme utilisé pour désigner les échanges entre navigateur et serveur effectués de manières asynchrones après le chargement de la page. contexte AViSTO Telecom est une société de services en informatique (SSII), développant des logiciels applicatifs. Les domaines d’expertise des ingénieurs de la société sont principalement les systèmes d’information, le web, les télécoms, le logiciel industriel, l’applicatif embarqué et les éseaux. Avisto dispose de centres techniques dans les grandes villes de France, notamment à Sophia Antipolis (Alpes maritimes) où s’est déroulé ce stage. L’entreprise est membre d’ADVANS GROUP, qui réunit aussi des sociétés d’expertise en électronique et en mécanique.
Cela permet notamment à Avisto de développer des projets denvergure en collaboration avec la filiale électronique du groupe : ELSYS DESIGN. Le support logiciel de ce projet est le Framework NemSiS qui permet de réaliser des solutions de supervision de réseaux. Il s’agit d’un Framework générique qui doit être instancié n fonction des équipements à superviser. Ce Framework a été par exemple utilisé pour superviser des équipements de type DVB-SH (Alcatel) ou des équipements d’optimisation de réseau de type SDH/Sonet (Ekinops). Il fournit l’ensemble des fonctionnalités de la gestion réseau résumé sous le terme FCAPS (fault, configuration, accountinB performance, security).
NemSiS s’adresse particulièrement aux équipementiers de réseau de télécommunications. Figure 1 : Architecture de NemSiS 7 L’architecture de NemSiS est une architecture distribuée assez classique. Le cœur fonctio erveur PAGF 7 OF via JNLP (téléchargement de l’application sur le serveur JBoss puis exécution dans le contexte JNLP de la JVM de la machine), qui communique avec les composants serveurs via EJBs contenus dans le serveur d’application JBoss. Le client et le serveur de NemSiS fonctionnent tous deux avec la version 6 de Java. A savoir que la dernière version stable de java pour les utilisateurs est la version 7, et que la version 8 est d’ores et déjà proposée aux développeurs.
Ce projet s’inscrit donc dans le cadre d’un POC (Proof of Concept ou démonstration de faisabilité) visant la éalisation d’une application web qui rassemblerait une partie des fonctionnalités du client graphique JNLP, en particulier la gestion des Alarmes, application clef dans la gestion de réseau. Ceci permettrait aux utilisateurs de disposer d’une partie des services de NemSiS en s’affranchissant de nombreux problèmes de compatibilité et d’installation sur leurs machines. En effet, il est beaucoup plus facile de mettre à jour et de déployer une application web, notamment car il n’y a rien à installer sur les postes clients et que l’on s’abstrait de la version de java installée sur ces postes.
L’avantage d’une technologie web en opposition au client JNLP sera non seulement une plus grande flexibilité au niveau des contraintes réseau et machine (le client actuel demande l’ouverture d’une trentaine de ports réseau), mais aussi l’utilisation de technologies plus récentes pour la réalisation d’interfaces « user-friendly » en HTML5. Serveur JBoss Conteneur Web Requête http – Réponse htt 8 6 Cahier des charges Ce projet vise à reproduire deux des fonctionnalités clés du client graphique dans une interface web. Ces deux fonctionnalités sont le gestionnaire d’alarmes et la représentation graphique d’un réseau. . 2. 1 Gestionnaire d’alarmes Le protocole SNMP permet d’envoyer des évènements asynchrones (Traps) depuis les équipements réseaux vers le manageur (ici le framework NemSiS).
Ces évènements représentent en général des erreurs et sont mappés sur des objets « Alarmes Les alarmes sont des messages qui indiquent à l’opérateur du réseau qu’un changement d’état non désiré a eu lieu sur un élément du réseau. Chaque alarme rassemble plusieurs informations, comme l’objet concerne, la sévérité de l’alarme, la cause la plus probable, la date, etc. La figure suivante donne un aperçu de l’interface du gestionnaire ‘évènements du client graphique. L’utilisateur peut choisir l’équipement qu’il souhaite visualiser depuis un arbre qui présente l’ensemble du réseau de manière hiérarchique (on parlera d’inventaire), afin d’afficher les alarmes relatives à cet équipement ainsi qu’? tous les équipements se trouvant en dessous hiérarchiquement. De plus, une des fonctionnalités clés de NemSiS est d’acquitter (acknowledge) une alarme.
Lors ue l’a érateur acquitte une alarme, cela vue et prise en compte PAGF l’ensemble du réseau dans un arbre Afficher le détail des alarmes survenues sur un élément du réseau donné C] Pouvolr acquitter des alarmes depuls l’interface web 1. 2. 2. Représentation graphique du réseau La seconde partie du projet est de reproduire une représentation graphique du réseau (« map »), où l’utilisateu peut placer les éléments sur une carte. Il peut ainsi visualiser les liens topologiques entre équipements, afin d’avoir une vue d’ensemble sur le réseau et les zones où il y a un haut niveau de criticité des alarmes. Les liens topologiques sont des représentations abstraites du concept physique de lien réseau. Et sont définis dans le client graphique.
Figure 4 : représentation actuelle d’un réseau dans le client JNLP L’objectif de cette seconde partie est donc de parvenir ? représenter graphiquement le réseau sur une page web. Les fonctionnalités majeures à implémenter sont les suivantes Cl Pouvoir déplacer à la sourls les éléments du réseau avec un système de « drag & drop » Représenter les liens topologiques entre nœuds (et s’assurer que ceux-ci suivent les déplacements) Cl Pouvoir changer l’image de fond (pour afficher une carte géographique par exemple) Cl Pouvoir enregistrer la représentation graphique dans un fichier de sauvegarde (pour la passer d’une machine à l’autre par exemple) 10
