« Centreon Status Map » Conception et développement … de stage - Epitech 3.pdf · RAPPORT DE...

RAPPORT DE STAGE :

« Centreon Status Map » Conception et développement d’une application

j2se

Du Mardi 1 mai au Mercredi 31 octobre 2007.

Jean-Baptiste Lamotte

lamott_j

Effectué à :

Société Merethis

12 avenue Raspail

94270 Gentilly – France

Société Merethis Origine :

LAMOTTE Jean-Baptiste

« Centreon Status Map » Conception et développement d’une application j2se

Domaine :

Mémoire de stage

Mémoire de stage de 3e année. sur 54

Remerciements :

Je remercie toute l’équipe et ses responsables qui m’ont permis d’effectuer ce stage dans de

bonnes conditions :

- Romain Lemerlus, mon tuteur de stage, directeur des projets, et cofondateur de

Merethis

- Julien Mathis, directeur technique, et cofondateur de Merethis

- Cedric Facon, architecte web et formateur,

- Mathavarajan Sugumaran, formateur,

- William Lienard, développeur,

- Sylvestre Ho-Tam-Chay, web designer,

- Thierry Bernardini, administrateur.




Domaine :

Mémoire de stage


Table des matières Remerciements : ................................................................................................................... 2

1. Résumé ......................................................................................................................... 4

2. Présentation de l’entreprise ........................................................................................... 6

2.1. Secteur d’activité ..................................................................................................... 6

2.2. L’entreprise ............................................................................................................. 6

2.3. Les services ............................................................................................................ 7

2.3.1. Formation ......................................................................................................... 7

2.3.1. Support ............................................................................................................ 7

2.3.2. Edition .............................................................................................................. 7

2.4. Le positionnement du stage dans l’entreprise .......................................................... 8

3. Travail effectué .............................................................................................................. 9

3.1. Cahier des charges ................................................................................................. 9

3.1.1. But général ....................................................................................................... 9

3.1.2. Explication détaillée des résultats à obtenir .....................................................10

3.2. Compte rendu d’activité ..........................................................................................12

3.2.1. Axe d’étude et de recherche choisis ................................................................12

3.2.2. Déroulement concrets des études. ..................................................................15

3.2.3. Interprétation et critique des résultats ..............................................................49

4. Conclusion générale .....................................................................................................50

5. Bibliographie & webographie ........................................................................................51

5.1. Bibliographie ..........................................................................................................51

5.2. Webographie ..........................................................................................................51

6. Glossaire ......................................................................................................................52




Domaine :

Mémoire de stage


1. Résumé

Le stage de 6 mois a été effectué chez Merethis, société créée en 2005 par d’anciens

élèves d’Epitech, spécialisée dans la supervision réseau open source.

La supervision réseau est un domaine en pleine expansion. En effet, toutes les

entreprises ont aujourd’hui un besoin croissant en informatique, et le nombre d’équipements

ne cesse d’augmenter. De même, les réseaux transmettent de plus en plus d’informations.

Cela permet à l’informatique d’occuper une place décisive dans les entreprises. Toutefois,

cela rend les infrastructures plus sensibles.

La supervision réseau permet de surveiller le bon fonctionnement de ces ressources

et ainsi de prévenir d’éventuelles pannes, ou de les détecter dans les plus brefs délais, avant

qu’elles n’aient des répercutions plus importantes.

Merethis a initialement créé Oreon, une solution de monitoring complète et open

source. Ce logiciel open source tire sa force d’une grande communauté d’utilisateurs des

logiciels, mais créé aussi une faiblesse pour l’entreprise qui ne génère des bénéfices que par

son support.

Le but du stage était de reprendre le développement d’une application de

cartographie avancée, visant à rendre la supervision accessible à un néophyte une fois le

parc informatique correctement configuré dans Centreon, et optimiser le temps d’accès à

l’information via une application centralisant tout ce qui concerne le monitoring et laissant de

coté la configuration à Centreon. Cette application se nomme Centreon Status Map.

Cette première application possédait malheureusement de nombreux défauts et

n’était pas commercialisable en l’état.

De nombreuses phases d’études, de tests, et de tâtonnements permirent d’aboutir à

une version finale de Centreon Status Map 2.

Il y eu 4 phases directives qui composèrent ce stage.




Domaine :

Mémoire de stage


Apres une première phase d’étude de Centreon Status Map 1.x, il était évident que

toute la conception était à revoir. L’application fut recommencée. Le but était de reproduire

toutes les fonctionnalités présentes, de les améliorer, et d’en créer de nouvelles, sans les

problèmes de performances, et bug de cette première version.

La seconde phase fut d’étudier le framework eclipse RCP, et de démarrer le

développement de Centreon Status Map 2.x. La richesse de ce framework n’est pas encore

épuisée, mais tout au long du stage, mes connaissances se sont améliorées.

La troisième phase d’étude fut consacrée à l’exploration des technologies XML avec

JAVA. Je conçus plusieurs modèles de flux XML permettant de transférer l’information entre

le serveur de supervision utilisant Centreon, et l’application Centreon Status Map.

La dernière phase fut d’implémenter un éditeur graphique reposant sur le framework

GEF. Ce framework aux multiples possibilités est malheureusement très mal documenté.

Son étude demanda beaucoup d’assiduité afin d’aboutir à un résultat exploitable.

Après de nombreuses phases de test, la version 2.0.0 de Centreon Status Map était

enfin disponible. Cette version fut testée par plusieurs grands groupes (souhaitant garder

l’anonymat), utilisant Centreon comme base de monitoring. Il y eu des retours, sur des

améliorations fonctionnelles.

Chacune des demandes de ces entreprises fut satisfaite, afin d’aboutir aujourd’hui à

Centreon Status Map 2.1.1. Un produit leur apportant pleine satisfaction.

L’entreprise Merethis m’a proposé un contrat en alternance après le stage, et m’a

placé à la tète ce projet. Il comptera très bientôt de nouveaux développeurs afin d’accélérer

son évolution. Le développement de Centreon Status Map a encore un bel avenir devant lui,

afin de répondre à tous les nouveaux besoins des entreprises.




Domaine :

Mémoire de stage


2. Présentation de l’entreprise

Le stage a été effectué durant 6 mois à la société Merethis.

2.1. Secteur d’activité

Les entreprises et organisation ont aujourd’hui de plus en plus d’équipement informatique

et électronique, et leurs surveillances (état de fonctionnement, qualité de fonctionnement

etc..) ne peuvent être effectuées manuellement tant leur nombre est élevé. C’est pourquoi il

existe des solutions de monitoring réseau.

Merethis se place au cœur de ces systèmes de surveillance, en proposant de nombreux

outils, afin de surveiller efficacement l’ensemble de ces équipements.

2.2. L’entreprise

Merethis a été créé en 2005, à la suite d’un projet de fin d’étude effectué par 5 étudiants

de l’Epitech.

Le projet initial consistait à créer une surcouche au célèbre ordonnanceur Nagios afin de

simplifier sa configuration. Ce projet s’appelle Oreon, puis deviendra Centreon en 2007. Ce

projet est open source, et dispose d’une forte communauté.

Seul 2 anciens étudiants ont souhaité continuer le projet, et créer la société Merethis :

Romain Lemerlus

Julien Mathis

Aujourd’hui, Merethis développe toujours Centreon, pour la communauté open-source,

mais propose également des applications payantes, complémentaires à Centreon, pour les

entreprises nécessitant des résultats plus poussé de leur monitoring.

Cartographie avancé (Centreon Status Map)

Qualité de service (Meta service)




Domaine :

Mémoire de stage


Merethis propose également des solutions complètes préinstallées, pour surveiller tout

un parc informatique, avec sa « Meribox ».

Enfin, Merethis propose un support et des formations à Centreon, afin d’aider les

entreprises à utiliser Centreon plus efficacement.

2.3. Les services

2.3.1. Formation

Merethis propose toute une gamme de formations dédiées à la supervision réseau Open Source.

Il existe actuellement 4 types de formation :

Exploitation Centreon Nagios – 2 jours

Bases de la supervision – 3 jours

Supervision avancée – 3 jours

Expert Centreon Nagios – 5 jours

2.3.1. Support

Merethis propose un support afin de résoudre des problèmes d’utilisation et/ou bug

d’Oreon.

Problème Mineur Majeur Bloquant

Délai d'acquittement - contournement 8 heures 4 heures 2 heures

Solution corrective 5 jours 48 heures 24 heures

Crédits 6 crédits 10 crédits 16 crédits

Ce support fonctionne par un système de crédits qui s’achètent au forfait, par lot de

50, 100, 200, 400, 500.

2.3.2. Edition

Merethis a depuis peu, un service d’édition, s’occupant de créer des logiciels et

complément à Centreon, répondant aux besoins des entreprises.




Domaine :

Mémoire de stage


2.3.2.1. Cartographie avancée (Centreon Status Map)

Centreon Status Map, aussi appelé OSM dans le jargon de Merethis, est une

application Java permettant de surveiller efficacement l’état d’un ensemble d’équipements

que ce soit à l’échelle locale ou mondiale, via un système d’arborescence.

Les différents types d’éléments (host, hostgroup, service, servicegroup, metaservice,

osl) possèdent des formes simples rendant leurs identifications faciles, et un système de

coloration selon leurs états.

On peut y ajouter facilement des éléments graphiques, pour rendre la visualisation

plus explicite, tels que des cartes, des plans etc.

2.3.2.2. Qualité de service (Meta Service)

La mesure de la qualité de service n'est pas une fonctionnalité native de Nagios ;

agréger au sein de l'outil les états des éléments supervisés n'existe pas.

L'outil Centreon propose une solution pour exploiter les données de performance

entre elles avec le plugin des Meta Services, il propose également de suivre dans le temps

l'évolution des métriques, mais pas d'informations sur des états agrégés.

2.4. Le positionnement du stage dans l’entreprise

Merethis avait jusque là une faible activité dans le domaine de l’édition. Le

développement d’applicatifs permet à Merethis de diversifier ses offres, en proposant autre

chose que du service.

Le stage s’inscrit donc au cœur de l’activité Merethis, permettant de répondre à ce

manque dans l’édition, par le développement de Centreon Status Map.




Domaine :

Mémoire de stage


3. Travail effectué

3.1. Cahier des charges

3.1.1. But général

Le cahier des charges détaillé n’existait pas au départ, et s’est construit au fur et à mesure

de l’avancement de la mission.

La mission comportait 2 objectifs :

Analyser une application dont Merethis est propriétaire : Oreon Status Map 1.x

(OSM 1.x)

Reprendre le développement d’OSM 1.x afin d’optimiser les performances, et

y ajouter de nouvelles fonctionnalités.

Le second objectif deviendra après l’analyse :

Développer OSM 2.x “from scratch” (à partir de rien), afin d’avoir un cœur

d’applications plus performant que la précédente mouture.

Note : Oreon Status Map 2.x deviendra Centreon Status Map 2.x (que l’on surnomme

toujours OSM 2.x)




Domaine :

Mémoire de stage


3.1.2. Explication détaillée des résultats à obtenir

3.1.2.1. Analyser l’existant

Ce premier objectif consistait à prendre connaissance de l’application OSM 1.x.

OSM 1.x souffrait de problèmes de performance, et d’un manque de certaines

fonctionnalités :

Très grande lenteur lorsque beaucoup d’éléments étaient présents

« Freeze » de l’application lors des rafraîchissements de statuts et des

téléchargements d’images

Stockage des informations sur la structuration de la cartographie en

local (via un import / export)

Problème de synchronisation des données (un élément supprimé dans

Oreon toujours présent dans Oreon Status Map)

Problème de duplication de données

Nombreux petits bugs non bloquants

Apres cette première analyse, il était évident que ces problèmes étaient liés à la conception

même d’OSM 1.x. Il fallait reprendre le développement depuis le début.

3.1.2.2. Développement de l’application Centreon Status Map 2.x

Apres cette première analyse, ce second objectif visait à corriger les différents problèmes

d’OSM 1.x, et d’y ajouter de nouvelles fonctionnalités :

Développer une application multithreadé où tous les traitements

sont effectués en tâche de fond

Stocker les informations du côté serveur afin d’avoir l’information

toujours disponible où que l’on se trouve.

Etablir un protocole de communication pour l’échange de données

client / serveur, en utilisant un flux XML pour le transfert de

données.




Domaine :

Mémoire de stage


Retrouver toutes les fonctionnalités présentes dans la version

précédente d’OSM.

Ajouter de nouvelles fonctionnalités.




Domaine :

Mémoire de stage


3.2. Compte rendu d’activité

Tout d’abord, quelques chiffres : Centreon Status Map 2.x, c’est 49 packages, 261

classes, 1628 méthodes, et 18 277 lignes de code, par conséquent, seul un regard

conceptuel sera porté sur le projet.

3.2.1. Axe d’étude et de recherche choisis

Il y eu plusieurs phase d’étude, et d’expérimentation avant d’aboutir à un produit final,

vendable.

Toutes ces phases d’étude furent effectuées plus ou moins en même temps, chacune

se complétant et s’enrichissant mutuellement.

3.2.1.1. Etude d’Oreon Status Map 1.x

L’étude de cette application fut brève. Un peu de manipulation du programme, afin de

voir ce qu’il permet de faire, de trouver ses limitations, et ses bugs.

Cette étude va mener à la décision de reprendre le développement de Centreon

Status Map au point de départ.

Je suis revenu plusieurs fois dessus, afin de garder le même esprit de

fonctionnement de l’application.

3.2.1.2. Etude du Framework Eclipse RCP

L’étude de ce framework se fera après l’étude d’Oreon Status Map 1.x, et durant

toute la durée du stage.

Le Framework Eclipse RCP est un puissant Framework, simplifiant la tâche de

création d’application de type client lourd, ou client riche. Il dispose de nombreuses librairies

permettant d’implémenter rapidement des boites de dialogue, des menus, etc.…

C’est cette richesse qui va permettre de découvrir de jour en jour de nouveaux

concepts, devenant par la suite indispensable.




Domaine :

Mémoire de stage


Eclipse, basé sur le Framework Eclipse RCP.

3.2.1.3. Etude du Framework JDom

Quelques temps après la découverte du framework Eclipse RCP, il fallut se pencher

sur le problème d’un bon framework permettant de manipuler du XML. C’est le framework

JDom qui sera élu après la lecture de documentation sur divers forums, pour ses

performances, et son api performante.




Domaine :

Mémoire de stage


3.2.1.4. Etude du Framework GEF

Enfin, la dernière phase d’étude se fit quelques mois après la création de la majeure

partie de l’application. Il ne manquait que l’éditeur, contenant des éléments graphiques.

Ce Framework graphique de type MVC (modèle-vue-contrôleur) correspondait parfaitement

au besoin graphique de l’application. De plus, celui-ci a fait ses preuves dans de

nombreuses applications, aussi bien chez IBM que de petites entreprises.




Domaine :

Mémoire de stage


3.2.2. Déroulement concrets des études.

3.2.2.1. Etude et test d’Oreon Status Map 1.x

Au départ, le développement d’Oreon Status Map 1.x devait être repris. Une phase

de test s’imposa, afin de déterminer les problèmes de performance, limitation, problème

d’évolutivité, et enfin les bugs.

3.2.2.1.1. Test de performance

Divers tests de montée en charge permirent de mettre à jour de graves problèmes de

performances. En voici des exemples :

Test de montée en charge

Le premier test effectué, fut d’ajouter de très nombreux « host » dans Oreon, afin de voir

comment réagissait l’application :

Lancement de l’application

Identification

Téléchargement des ressources

Blocage de l’application le temps du téléchargement des ressources

Plantage si interaction de la part de l’utilisateur

Conclusion : un thread effectuant cette tâche en arrière plan pourrait corriger le

problème.




Domaine :

Mémoire de stage


Test de téléchargement d’images volumineuses

Le second test, fut d’ajouter des cartes de grande taille, demandant plus de temps à

télécharger :


Identification

Téléchargement des images



Conclusion : un thread effectuant cette tache en arrière plan pourrait corriger le

problème.

Test d’ajout de nombreux éléments sur la carte

Le troisième test fut d’ajouter de très nombreux éléments sur la carte, tout en gardant un très

petit nombre de ressources :


Identification

Téléchargement des images



Conclusion : un thread effectuant cette tâche en arrière plan pourrait corriger ce

problème.

Tous les tests mirent en évidence la nécessité d’avoir une application multithreadé afin

d’effectuer les traitements en tâche de fond, sans que l’application ne bloque, ou plante à la

moindre action de l’utilisateur.




Domaine :

Mémoire de stage


3.2.2.1.2. Limitation

Gestion des « vues »

OSM 1.x avait une gestion des vues relativement basique. Chaque vue était importée et

exportée dans un fichier XML, qui pouvait ne plus correspondre du tout à ce qu’il y a dans

Oreon, après de nombreuses modifications, non répercutées sur ces fichiers XML.

Impossibilité d’ajouter plusieurs images à un éditeur

Chaque éditeur était limité à une seule image, affichée en arrière plan, impossible à

déplacer.

Remontée des statuts

La remontée des statuts était imprécise, « confondant » aussi bien un statut « WARNING »

qu’un statut « CRITICAL ».

Mémorisation d’un seul utilisateur et/ou proxy

L’interface d’accueil ne permettait de mémoriser que les paramètres de connexion du dernier

utilisateur. Le même problème se posait pour la gestion du proxy.

La nature même de l’implémentation d’OSM 1.x rendait difficile l’évolution de ces limitations.

3.2.2.1.3. Bug

Gestion des « vues »

La gestion des vues posait un double problème, à la fois d’évolutivité, mais aussi

génératrice de bug. En effet, la moindre suppression d’un élément dans Oreon rendait

inexploitable OSM 1.x, celui-ci « cherchant » des éléments qu’il ne trouvait pas, lors de la

mise à jour des statuts, provocant une erreur qui ne permettait pas de finir cette mise à jour

de statuts.

Montée en charge

OSM 1.x finissait systématiquement par planter, lorsqu’il y avait trop de ressources,

d’éléments, ou de cartes volumineuses.




Domaine :

Mémoire de stage


Drag-n-Drop

Le drag-n-drop des ressources dans l’éditeur se retrouvaient au mauvais endroit lorsque le

zoom était activé.

XML non valide

Les flux XML utilisés pour le transfert de ressource, et le stockage de la vue courante

n’étaient pas normalisés, provocant des erreurs aléatoires, dans certains cas particuliers.

La correction de tous ces bugs aurait demandé beaucoup de temps à être localisés

précisément dans le code, puis corrigés.




Domaine :

Mémoire de stage


3.2.2.1.4. Bilan sur Oreon Status Map 1.x

OSM 1.x souffrait de nombreux défauts, tant sur le plan de la conception que sur le

plan de l’implémentation :

Le pire défaut était bien évidemment le fait que l’application soit mono threadée,

provocant des blocages et plantages lorsqu’on montait légèrement en charge.

C’est après cette analyse, que je pris la décision de baser Oreon Status Map 2.x sur

une nouvelle base.

Le choix des Framework suivant est conservé :

Eclipse RCP

GEF

Le Framework permettant de gérer le XML est en revanche remplacé par JDom.




Domaine :

Mémoire de stage


3.2.2.2. Etude du Framework Eclipse RCP

Le Framework eclipse rcp est une puissante collection d’objets, permettant de créer

rapidement une application java. C’est un peu la réponse de java, aux solutions que propose

Microsoft dans son IDE visual studio.

C’est à partir du célèbre IDE Eclipse, que le Framework Eclipse RCP a été créé.

3.2.2.2.1. Le choix d’Eclipse RCP

Ce choix s’est imposé de lui-même. Il avait permis de créer la version précédente

d’Oreon Status Map.

3.2.2.2.2. Une première application Eclipse RCP

Apres avoir étudié en profondeur les défauts d’OSM 1.x, il était temps de se lancer

dans le développement d’OSM 2.x, en tenant compte des problèmes de la précédente

version.

Une simple application « hello world » fut alors créée :

C’est sur cette petite application que reposera par la suite tout OSM 2.x




Domaine :

Mémoire de stage


3.2.2.2.3. L’étude des perspectives d’eclipse RCP.

Eclipse RCP propose une notion appelée perspective. Il s’agit d’une représentation

des éléments que l’ont peut voir à l’écran.

Les perspectives sont des conteneurs de vue et d’éditeur. Ils permettent de

positionner où bon lui semble, au développeur, les différents éléments visibles dans la

perspective. Le but originel des perspectives est de permettre à l’utilisateur de switcher de

l’une à l’autre, en gardant les mêmes fenêtres ouvertes, mais placé à des endroits

radicalement différents.

C’est l’utilisation de ces perspectives qui va permettre de créer les différents

morceaux de l’application :

La perspective d’accueil,

La perspective de sélection des vues,

La perspective de monitoring.

3.2.2.2.4. L’étude des éditeurs et vues d’Eclipse RCP

Afin de peupler les perspectives, il existe 2 types de « fenêtre » :

Les éditeurs,

Les vues.

Les éditeurs sont des fenêtres plutôt destinées à l’édition, c'est-à-dire à contenir des

éléments destinés à être déplacés, modifiés et c…

Les vues quant à elles servent plutôt à afficher des éléments. Il est évidemment possible

comme pour les éditeurs d’y mettre des éléments modifiables, mais ce n’est pas le but

premier.




Domaine :

Mémoire de stage


3.2.2.2.1. La première perspective, et sa première vue

Après avoir compris ces notions clé de perspective, éditeur et vue, il était temps de créer une

première perspective, peuplée par une vue.

Cela se déroula sans encombre grâce à l’api bien documenté d’Eclipse RCP, et quelques

jours de test.

L’application ressemblait désormais à ceci :

L’application finale, sur la perspective d’accueil, avec la vue Centreon Status Map.

Il n’y avait pas encore de menu ni de barre d’outils, mais il n’était pas encore temps de se

pencher sur ce problème.




Domaine :

Mémoire de stage


3.2.2.3. Etude du Framework JDom

3.2.2.3.1. Le choix de JDom

Le Framework JDom est un ensemble de classes permettant de manipuler des

données de type XML.

Ses avantages sont les suivants :

Plus simple à utiliser que les API Sun grâce à une abstraction de plus haut

niveau

Respecte les spécifications DOM du W3C, rendant son utilisation facile à tout

développeur objet ayant déjà utilisé une api respectant ces spécifications dans

un autre langage.

Ce sont principalement ces 2 caractéristiques qui ont motivé le choix de ce Framework plutôt

qu’un autre.

3.2.2.3.2. Une première implémentation de JDom

La première utilisation de JDom fut pour le stockage des profils de connexion en

local.

L’objectif était simple, avoir un conteneur (XML) ordonné, et extensible à volonté.

Ce modèle sera par la suite étendu afin d’enregistrer les proxys.

Grâce à ce modèle, la fenêtre de dialogue de connexion allait pouvoir être créée.




Domaine :

Mémoire de stage


3.2.2.4. La fenêtre de dialogue de connexion

3.2.2.4.1. Implémentation du menu de connexion

La fenêtre dialogue de connexion corrige les erreurs de la précédente version. Celle-

ci permet d’enregistrer des profils de serveur et/ou d’utilisateur.

La boite de dialogue de connexion finale

Chacune des informations visibles dans la boite de dialogue est enregistrée dans le fichier

XML créé précédemment.

Différentes fonctionnalités y seront ajoutées au cour du projet :

- Le mode administrateur,

- Le proxy,

- Le Timer




Domaine :

Mémoire de stage


3.2.2.5. Création d’une méthodologie pour la transmission de données

Afin de pallier aux problèmes de la précédente version, qui enregistrait ses

informations dans un fichier XML stocké en local, il fallut réfléchir à comment échanger les

données avec le serveur, afin que celles-ci soient gardées sur celui-ci.

3.2.2.5.1. Choix du protocole

Le choix du protocole http, avec l’envoi de xml fut rapide pour plusieurs raisons :

Centreon a besoin d’un serveur Apache (serveur http) pour fonctionner.

Le xml transite facilement par le protocole http

Le xml est un excellent conteneur de données ordonnées.

3.2.2.5.2. Normalisation des échanges via XML

Afin de créer un parseur générique, il fallait définir un certain nombre de balises

communes à tous les flux XML.

Des modifications seront apportées tout au long du projet à ces balises, afin de

répondre aux besoins croissants d’informations de l’application.

Les spécifications finales seront les suivantes :

Balise <data> encapsulant tout flux

Balise <DESCRIPTIVE>, qui décrit le type de flux envoyé

o Host, Hostgroup, ServiceGroup, MetaService, OSL, Image pour les

listes des ressources

o all, add, rem, mod, pour l’arborescence et les modifications liées à

cette arborescence.

Balise <ctn>, qui décrit l’élément ainsi que tous ses attributs.

Chaque balise <ctn> peut avoir une infinité d’enfants, aussi bien pour les

ressources que pour l’arborescence.




Domaine :

Mémoire de stage


3.2.2.5.3. Récupération des ressources

3.2.2.5.3.1. Flux XML

Centreon Status Map est composé des mêmes éléments que ceux contenus dans

Centreon. (Host, hostgroup, service, servicegroup, metaservice, osl).

Pour chacune de ces ressources, il fallut donc créer 5 modèles XML, permettant d’envoyer

ces informations, basés sur les spécifications précédentes.

Chacune des ressources possède une balise « ctn », composée de plusieurs attributs :

- Nom,

- alias,

- adresse IP,

- ID,

- type d’éléments

Ces ressources ont également des enfants, qui sont encapsulé dans la première balise

« ctn ». Seuls les enfants du niveau immédiatement en dessous sont renvoyés.

La requête permettant d’obtenir les hosts retourne donc une liste d’host, et ses services

enfants.

Il en va de même pour les autres éléments :

Liste d’hostgroup et leurs host enfants

Liste de servicegroup et leurs services enfants

Liste de metaservice, sans les enfants (qui ne doivent pas être affiché dans OSM)

Liste d’osl, sans les enfants (qui ne doivent pas être affiché dans OSM)

Il n’existe pas de requête permettant de récupérer la liste des services, ceux-ci étant

envoyés via la requête de récupération des hosts.




Domaine :

Mémoire de stage


3.2.2.5.3.2. Méthode de récupération des flux XML

Afin d’envoyer ces flux XML, un fichier PHP fut mis en place du côté du serveur par

Romain Lemerlus en respectant les spécifications que j’avais établies.

Une requête web simple de type GET est effectuée, prenant en paramètre une clé indiquant

le type de ressources à récupérer.

Exemple : getOSMResources.php?key=200 permet de récupérer la liste d’host et leurs

services enfants.

3.2.2.5.4. Récupération des éléments d’une vue

3.2.2.5.4.1. Flux XML

Comme pour la récupération des ressources il fallait créer un modèle de flux XML. Cette fois

ci, tous les enfants devaient être renvoyés quel que soit l’élément, afin de construire une

arborescence dans OSM 2.x.

On passe simplement une clé en paramètre, et un argument correspondant à l’id de

l’élément à récupérer.




Domaine :

Mémoire de stage


Exemple :

http://192.168.1.240:80/oreon/modules/osm/webServices/getOSMTopology.php?ke

y=100&args[0]=152

Le flux xml renvoyé est parfaitement structuré. Chaque niveau d’indentation montre un

niveau dans l’arbre qui sera créé dans la perspective de monitoring.




Domaine :

Mémoire de stage


3.2.2.6. Création de la perspective de sélection des vues

3.2.2.6.1. Objectif de cette perspective

Cette perspective permet de sélectionner la vue que l’on souhaite afficher, dans la

perspective de monitoring.

Aucune fonctionnalité similaire n’était présente dans la version précédente.

Cette perspective a plusieurs avantages :

Possibilité de changer radicalement d’environnement de monitoring en quelques

clics.

Possibilité pour un « super » administrateur, de visualiser l’ensemble des vues,

disponible aux différents sous-administrateurs surveillant leurs domaines spécifiques

(base de données, réseau, etc.)

Corrige le défaut de la version précédente, qui obligeait à charger / décharger

manuellement un fichier XML, pour changer de vue.

3.2.2.6.2. Composition

3.2.2.6.2.1. Vue

Cette perspective est composée d’une unique vue (RCP), contenant une liste de vues (de

monitoring). Un double click permet d’ouvrir la perspective de monitoring, basé sur cette vue.

La vue (RCP) de sélection des vues (de monitoring) de l’application finale.




Domaine :

Mémoire de stage


Note : les vues du Framework eclipse rcp ne sont pas à confondre avec le nom choisi

pour les vues (de monitoring).

Cette vue récupère son contenu via le flux XML établi précédemment.

Afin de ne pas ralentir l’exécution de l’affichage, un thread est utilisé pour le chargement du

flux XML, palliant au problème d’OSM 1.x qui ralentissait ou bloquait, lorsqu’il y avait trop

d’informations à récupérer.

3.2.2.6.2.2. Menu

Différents menus sont également ajoutés à cette perspective afin d’effectuer les actions

courantes de l’application.

Menu de l’application finale.

La fonctionnalité permettant de rafraîchir les informations est utilisée dans le cas où 2

administrateurs ou plus effectuent des créations de vue.

3.2.2.6.2.3. Barre d’outils

Afin de satisfaire les utilisateurs les plus pressés, une barre d’outils contenant les actions les

plus courantes est ajoutée.

Barre d’outils de l’application finale.




Domaine :

Mémoire de stage


3.2.2.6.2.4. La fenêtre de création des vues

La fenêtre de création des vues va à l’essentiel. Elle permet de créer 3 types de vue.

A l’heure actuelle, il n’existe que la perspective géographique, c’est pourquoi les vues métier

et network sont désactivées (grisé). Celles-ci seront implémentées dans les mois à venir,

après le stage.

Cette fenêtre subira également un « relooking ».

La fenêtre de création de vue finale.




Domaine :

Mémoire de stage


3.2.2.7. Création de la perspective de monitoring (géographique)

3.2.2.7.1. Objectif de cette perspective

La perspective de monitoring est la plus importante. C’est dans celle-ci que l’on

pourra observer les états des différents équipements supervisés.

3.2.2.7.2. Composition

La perspective de monitoring finale, et ses vues.




Domaine :

Mémoire de stage


Cette dernière contient tous les éléments nécessaires au monitoring :

Un arbre (en haut à gauche) pour se déplacer dans les éléments

Une minimap (au milieu à gauche) pour se repérer lorsque les cartes sont trop

grandes

Plusieurs vues contenant les ressources à dropper dans l’éditeur (en bas à

gauche)

Une vue synthétique (en haut à droite)

Une vue avec les graphes (historiques) de l’état de fonctionnement des

éléments supervisés (à droite)

Un éditeur qui contient les images, et les différentes ressources surveillées

(également présentes dans l’arbre).

Cette perspective représente la phase la plus difficile du stage, mais également la plus

intéressante.




Domaine :

Mémoire de stage


3.2.2.7.2.1. Les vues de ressources

Ces vues sont au nombre de 6. Ce sont elles qui contiennent tous les éléments présents

dans Oreon, que l’on peut drag-n-dropper dans l’éditeur et l’arbre.

Les vues de ressources finales.

Cette vue récupère son contenu via le flux XML établie précédemment.

Au départ, ces vues n’affichent que la liste brut de chaque catégorie d’éléments. Par la suite,

elle fut modifiée, afin d’afficher leurs enfants respectifs, et le flux XML modifié en

conséquence, afin de renvoyer ces informations complémentaires.

Le flux XML est récupéré via un thread, en arrière plan, afin de ne pas ralentir l’exécution de

l’application et provoquer des blocages.




Domaine :

Mémoire de stage


3.2.2.7.2.2. La vue arborescente

Cette vue permet de visualiser rapidement la liste de toutes les ressources monitorées. Elle

permettra de se repérer dans l’éditeur, et via un menu contextuel, lancer différentes actions.

La vue arborescente finale.

Cette vue, comme les précédentes, récupère ses informations via un flux XML, en arrière

plan, grâce à un thread.

Une erreur sera commise lors de sa création : elle est créée en implémentant un

arbre reposant sur JFace, une surcouche de SWT, l’environnement graphique du framework

Eclipse RCP. L’éditeur à ce moment-là n’existe pas encore, mais celui-ci repose sur le

framework GEF, il fut alors nécessaire de refaire cet arbre, en se reposant également sur le

même framework, afin de synchroniser la sélection dans l’éditeur, et l’arbre. (Le menu se

déroule alors tout seul, en se déplaçant dans l’éditeur).

Cette erreur fit perdre 1 semaine de développement.




Domaine :

Mémoire de stage


3.2.2.7.2.3. La vue tableau synthétique

L’éditeur graphique est la fonctionnalité la plus intéressante pour visualiser où se

trouvent les éléments défaillants, mais certaines sociétés possèdent des parcs informatiques

énormes, et il peut parfois être difficile de trouver rapidement tous les éléments défectueux.

Il fallait donc pallier à ce manque, en créant une vue synthétique. Cette vue contient

les mêmes informations que celles contenues dans l’éditeur, mais organisées en colonne.

On peut trier les éléments par nom, alias, type d’élément, statut, et statut des enfants.

Le principal intérêt étant de pouvoir trouver immédiatement les éléments ayant un statut

critique, grâce au tri par statut.

La vue tableau synthétique finale.

Par la suite, une petite fonctionnalité fut ajoutée, afin de simplifier la navigation : un cadenas,

permettant de verrouiller ou déverrouiller la vue.

Lorsque la vue est déverrouillée, le simple click sur un élément dans l’arbre ou l’éditeur

permet de changer le contenu de cette vue, en affichant instantanément les enfants de

l’élément sélectionné.




Domaine :

Mémoire de stage


3.2.2.7.2.4. La vue des graphes

Il existe dans Centreon, une page permettant d’afficher des graphes sur l’état de

fonctionnement dans le temps d’un service. L’intégrer à Centreon Status Map semblait une

excellente idée, et très « simple » à mettre en œuvre. Il suffisait simplement d’appeler un

navigateur web embarqué dans l’application, et d’appeler l’adresse permettant d’afficher le

graphe correspondant.

La vue des graphes finale

Comme pour la vue synthétique, une fonctionnalité permettant de verrouiller et déverrouiller

la vue fut implémentée.




Domaine :

Mémoire de stage


3.2.2.7.2.5. Les menus

Le menu général permettant d’effectuer la navigation standard fut ajouté, comme

pour la perspective de sélection des vues.

Un menu option, contenant une action permettant de forcer le rafraîchissement manuel des

statuts, fut également ajouté.

Enfin, une action permettant de rafraîchir tous les éléments en rechargeant toute la liste fut

ajoutée, afin de permettre à 2 administrateurs d’effectuer simultanément des modifications

sur la même vue, sans devoir relancer l’application.

Les différents menus de la perspective de monitoring.

Un menu contextuel fut également créé, réagissant au click droit sur un élément, que ce soit

dans l’éditeur ou l’arbre.

Le menu contextuel d’un host, dans l’application finale.

Ce menu est créé dynamiquement, son contenu variant selon que l’action peut être effectuée

sur l’élément ou non. La détermination de la possibilité d’utiliser une action ou non se fait

grâce aux editpolicy du framework GEF. Ce menu n’est au départ pas dynamique, et affiche

toutes les actions pour tous les éléments, même si cela n’est pas possible. Le problème était

le même que pour la vue arborescente, créé via JFace, et non GEF.




Domaine :

Mémoire de stage


3.2.2.7.2.6. La barre d’outils

Comme pour la vue de sélection des vues, une barre d’outils pour les utilisateurs pressés

(« power users ») est créée.

Celle-ci contient les actions les plus couramment utilisées.

Des outils supplémentaires sont également disponibles. Ceux-ci n’effectuent que des actions

qui influent sur l’affichage de l’éditeur.

La barre d’outils de la perspective de monitoring.




Domaine :

Mémoire de stage


3.2.2.8. Etude du Framework GEF

Une fois toutes les vues créées, il était temps de passer à l’éditeur, qui allait contenir

les éléments graphiques, tels que les images, et des icones représentatives de chacun des

éléments.

Avant d’implémenter cet éditeur, il fallait étudier le framework graphique GEF.

3.2.2.8.1. Le choix de GEF

GEF avait été utilisé dans la précédente version de Centreon Status Map. Il avait

prouvé qu’il pouvait produire un visuel agréable. De plus, GEF a été utilisé dans de

nombreuses applications commerciales avec succès.

Son seul défaut est qu’il est très peu documenté, rendant la tâche ardue à quelqu’un qui le

découvre.

3.2.2.8.2. Fonctionnement de GEF

Le Framework GEF est un Framework de type Model-View-Controller (MVC).

Celui-ci est complété par le toolkit Draw2d (sorte de mini Framework), dédié aux affichages

en 2 dimensions.

Le principe objet MVC permet de séparer complètement les données graphiques (« vue »,

des propriétés de ces objets (modèle). Afin de lier les données graphiques aux propriétés, on

utilise un contrôleur.




Domaine :

Mémoire de stage


Ce schéma résume brièvement le fonctionnement de GEF.

Voici une vulgarisation du fonctionnement :

L’utilisateur effectue une action, sur la vue (view).

Celle-ci est transmise au contrôleur (controller)

Le contrôleur créé une requête (requests)

La requête (requests) vérifie via les editpolicy si celle-ci est autorisée.

Si la requête est autorisée, par les editpolicy, celles-ci créent une commande

(commands) qui effectue la modification dans le modèle (model).

Le Model transmet alors au contrôleur la modification, qui modifie à son tour la vue

(view).

C’est cette phase d’étude qui a demandé le plus de temps avant de produire un visuel lié au

modèle (créé via les flux XML précédents).




Domaine :

Mémoire de stage


3.2.2.8.3. Etude du toolkit Draw2d

Gef utilisant le toolkit Draw2d pour son visuel, il fallut également étudier le

fonctionnement de ce dernier.

Les « Figures », sont les éléments graphiques de base de draw2d.

On peut créer les formes que l’on souhaite avec, et pour les formes plus complexes, on

utilise un empilement de figures.

Draw2d a 2 règles de fonctionnement essentielles :

La précédente figure d’un même niveau de parenté est cachée par la suivante.

Chaque niveau de parenté est caché par la partie visible du niveau enfant.

Si un enfant dépasse de la zone de son parent alors la zone en dehors du parent est

cachée.




Domaine :

Mémoire de stage


3.2.2.9. Création de l’éditeur

3.2.2.9.1. Gestion des images

L’étude du framework GEF allait enfin permettre de construire l’éditeur. De nombreux

tests furent encore effectués avant d’arriver à un éditeur viable.

Dans un premier temps, il fallut ajouter la gestion des images, et par la même occasion,

régler les problèmes de la précédente version, de blocage de l’application lors du

chargement, et la possibilité de n’afficher qu’une seule image par éditeur

Chaque image est chargée via un thread dédié, en arrière-plan. Une petite image d’un

travailleur est affichée durant le chargement des images.

3.2.2.9.2. Gestion des différents éléments

Chaque élément droppé dans l’éditeur devait être positionné précisément.

Deux problèmes se posèrent :

Drag-n-Drop avec le zoom activé

Drag-n-Drop dans l’arbre

Pour le premier problème, les coordonnées du drop étaient mauvaises, ne prenant pas en

compte la gestion du zoom. Ce problème était déjà existant dans la version précédente. Gef

n’est pas prévu pour gérer ce type de cas. Il fallut contourner le fonctionnement de GEF, par

un calcul à partir des coordonnées de la fenêtre.

Pour le second problème, il n’existait pas de coordonnée, puisque droppé directement dans

l’arbre.

Cela impliqua la création d’un système de placement automatique des icones.




Domaine :

Mémoire de stage


Chaque drop d’élément, ou déplacement d’élément créé une requête envoyée au serveur,

via un flux XML, qui renvoie à son tour un flux XML, pour signaler la modification, qui n’est

effectuée qu’une fois approuvée par le serveur.

Cette requête est encore une fois effectuée dans un thread, afin de ne provoquer aucun

blocage de l’application.

3.2.2.9.3. Pop-Up de légende des icones

Une petite fenêtre de légende de la forme des icones a également été ajoutée, accessible

via le menu d’aide, afin d’aider les utilisateurs débutants à connaître la correspondance des

icones dans l’éditeur.




Domaine :

Mémoire de stage


3.2.2.9.4. Zoom

Dans le cas où de très grandes cartes étaient utilisées, il pouvait être intéressant de pouvoir

dézoomer afin de se déplacer plus facilement dans l’éditeur.

Cette fonctionnalité fut implémentée.

3.2.2.9.5. Placement automatique

Le placement automatique dispose de 2 modes :

Un placement automatique de tous les éléments lorsque celui-ci est activé

Un placement automatique des éléments n’ayant pas de coordonnées, lorsque celui-

ci est désactivé.

Le placement automatique d’éléments activés, dans l’éditeur final.

Ce système de placement automatique est utile dans le cas d’un hostgroup possédant de

très nombreux host, amené à évoluer souvent.




Domaine :

Mémoire de stage


3.2.2.9.6. Afficher / masquer le texte

Dans le cas où des images en arrière plan avaient du texte, il pouvait être utile de ne

pas afficher le texte des icones. Cette fonctionnalité fut également implémentée.

Le nom des éléments masqués, dans l’éditeur final.

3.2.2.9.7. Enregistrement des propriétés de l’éditeur

Les propriétés de zoom, d’affichage de la police, et de placement automatique n’étaient pas

enregistrées au départ. Dans le cas de la fermeture de l’application, l’administrateur perdait

tous ses paramètres d’éditeur.

Une fonctionnalité permettant de les mémoriser à la demande de l’utilisateur fut ajoutée.

Celle-ci ne fut pas gérée de façon automatique, afin de minimiser les requêtes vers le

serveur, et de permettre à l’utilisateur de retrouver un environnement par défaut, s’il ne

souhaitait pas mémoriser sa dernière utilisation.




Domaine :

Mémoire de stage


3.2.2.9.8. « MiniMap »

La dernière fonctionnalité ajoutée fut la minimap. Cette vue affiche une représentation

miniature de l’éditeur actif. Elle permet de se déplacer rapidement dans l’éditeur, lorsque de

grandes images sont utilisées, accélérant l’accès à une zone particulière de l’éditeur.

Un rectangle est affiché dans la minimap, représentant la zone visible de l’éditeur.

La minimap de l’application finale.




Domaine :

Mémoire de stage


3.2.2.10. Remontée des statuts

Afin que notre perspective de monitoring soit utile, il fallait bien évidemment remonter

les statuts des éléments, afin de savoir s’ils sont opérationnels (statut OK), demandant une

attention particulière (statut WARNING), ou demandant une intervention immédiate (statut

CRITICAL).

Cette remontée d’informations se fait bien évidemment à l’aide d’un flux XML, et d’une

requête régulièrement envoyée au serveur afin de récupérer ce flux.

Les statuts sont affichés par un système de coloration des éléments :

Etat OK -> vert

Etat WARNING -> Orange

Etat CRITICAL -> Rouge

Etat UNKNOW -> Noir

Etat PENDING -> Bleu

Les statuts sont remontés de fils en père, jusqu’aux éléments à la racine de l’arbre. Le pire

statut est remonté, et les statuts UNKNOW (inconnu) et PENDING (en suspend) sont

ignorés dans cette remontée.

L’implémentation de l’application permet de faire évoluer facilement l’algorithme de remontée

des statuts, afin de proposer plusieurs algorithmes à l’utilisateur.

Pour le moment, il n’existe que celui remontant le pire des statuts.




Domaine :

Mémoire de stage


3.2.3. Interprétation et critique des résultats

L’objectif de départ était d’améliorer le logiciel existant Oreon Status Map 1.x.

Apres la phase d’analyse de ce logiciel, il paraissait évident que le développement ne

pouvait continuer sur une base aussi buggué et dont la conception ne permettrait jamais de

monter fortement en charge.

Le développement d’une nouvelle version fut démarré. Le but était de conservé le même

esprit d’application, sans reproduire les erreurs de performance de la première version.

Afin d’arriver au résultat final, d’une application vendable, il y eu des petites phases de

tâtonnement et d’erreur. La découverte du framework GEF me montra qu’il ne fallait pas

toujours se lancer immédiatement dans un développement. En effet, procéder de cette façon

me fit perdre 1 semaine de développement à recommencer un arbre en changeant le

framework utilisé.

Globalement, pour le reste, cela fut très positif, tous les défauts de la précédente version

n’ayant pas été reproduit, et de nombreuses amélioration ajoutées. Ces erreurs auraient

peut être été commise si cette première version n’avait pas existé, mais tirer profit des

erreurs de quelqu’un d’autre est tout aussi profitable que de ses propres erreurs.

Le but premier a finalement été dépassé dans un nouveau produit commercialisé et attractif.




Domaine :

Mémoire de stage


4. Conclusion générale

L’objectif était de continuer le développement de Centreon Status Map 1.x. Cette

objectif fut rapidement revu après l’étude de ce dernier. Le nouvel objectif était de recréer

une nouvelle application Centreon Status Map 2.x, en gardant les idées de la première

version, mais en évitant de reproduire les mêmes problèmes.

Le stage s’est effectué en plusieurs phases d’étude : l’étude de la précédente

mouture et l’étude des framework Eclipse RCP, JDom, et GEF.

Chaque pas dans ces études permit de découvrir de nouvelles possibilités

complétant les précédentes, ou parfois les remettant en question, aboutissant enfin à une

version finale.

Centreon Status Map 2.x est désormais commercialisé et représente une part

importante dans l’activité économique de Merethis, attirant également de nouveaux clients

ne trouvant pas de logiciel équivalent dans la concurrence.

Ce stage m’a permis d’éveiller mes connaissances dans le développement Java, et la

supervision réseau. Il m’a placé à la tète d’un projet d’envergure, dont je poursuivrai les

futures évolutions dans le cadre de mon contrat en alternance, et prochainement avec l’aide

de nouveau développeurs que j’encadrerai.




Domaine :

Mémoire de stage


5. Bibliographie & webographie

5.1. Bibliographie

Eclipse 3 pour les développeurs Java

Développez des plug-ins et des applications « client riche »

Auteur : Berthold Daum, traduit de l’allemand par Claude Raimond.

Marque : Dunod

Collection : InfoPro

5.2. Webographie

Le site officiel d’Eclipse : www.eclipse.org pour le téléchargement de l’IDE eclipse, et

des plugins nécessaires au projet OSM 2.x, ainsi que pour son excellente API en

ligne.

Le site de la communauté de développeurs français : www.developpez.com

http://www.eclipse.org/

http://www.developpez.com/




Domaine :

Mémoire de stage


6. Glossaire

API : Application Programming Interface, est un terme courant pour designer la

documentation accompagnant un Framework. L’ensemble des classes et interfaces y sont

regroupé, afin de trouver immédiatement l’information recherché.

Centreon : Centreon est un logiciel de surveillance et de supervision réseau, basé sur le

moteur de récupération d'information libre Nagios.

Drag-n-Drop : Glisser, déposer.

Framework : un Framework est un ensemble de bibliothèques, d’outils et de convention

permettant le développement rapide d’applications. Il fournit un ensemble de brique à

compléter, permettant de créer des applications. Chaque Framework évolue de son coté,

indépendamment des applications l’utilisant, mais conserve généralement une opérabilité

avec ses versions précédentes.

IDE : Integrated Development Environment, est un terme qui désigne un environnement de

développement, c'est-à-dire un programme regroupant un éditeur de texte, un compilateur,

divers outils d’automatisation, et un débogueur.

Java : Le java est à la fois un langage de programmation orienté objet, et un environnement

d’exécution informatique multi plateforme.

JDK : Java Developement Kit, le JDK est l’environnement dans lequel le code Java est

compilé pour être transformé en bytecode, afin que la JVM (via une JRE) soit capable de

l’interpréter quel que soit la plateforme.

JFACE : JFace est une bibliothèque graphique Java pour le projet Eclipse qui s'appuie sur la

bibliothèque SWT pour fournir des interfaces utilitaires plus structurées.




Domaine :

Mémoire de stage


JRE : Java Runtime Environment, la JRE est un environnement d’exécution permettant

l’exécution de programme sur toutes les plates formes supportées. Cette dernière est

constituée d’une JVM, et d’une bibliothèque standard utilisée comme base dans la plupart

des programmes java.

JVM : Java Virtual Machine, la machine virtuelle est un programme qui interprète le code

java, et le convertie en code natif, propre à la plateforme sur laquelle il est exécuté.

Oreon : Oreon a été renommé en Centreon en 2007.

OSM 1.x : Oreon Status Map 1.x.

OSM 2.x : Centreon Status Map 2.x, anciennement appelé Oreon Status Map.

Proxy : Un proxy est un serveur informatique qui a pour fonction de relayer des requêtes http

entre un post client et un serveur. Ils sont couramment utilisés dans les grandes entreprises

afin de bloquer les attaques extérieures.

RCP : Rich Client Platform, est un Framework open source proposant de nombreux outils

pour accélérer le développement d’application riche.

Socks : Un sock est très similaire à un proxy, si ce n’est que le socks permet de laisser

passer tous type d’information, contrairement au proxy qui ne laisse passer que les requêtes

http.

Thread : Un processus léger, également appelé fil d'exécution (autres appellations connues:

unité de traitement, unité d'exécution, fil d'instruction, processus allégé), est similaire à un

processus car tous deux représentent l'exécution d'un ensemble d'instructions du langage

machine d'un processeur. Du point de vue de l'utilisateur, ces exécutions semblent se

dérouler en parallèle. Toutefois, là où chaque processus possède sa propre mémoire

virtuelle, les processus légers appartenant au même processus père se partagent sa

mémoire virtuelle. Par contre, tous les processus légers possèdent leur propre pile système.




Domaine :

Mémoire de stage


XML : Extensible Markup Language, est un langage informatique de balisage générique.

Celui-ci respecte des normes precises de balisage, utilisé dans d’autres langages de

balisages (XHTML, SVG, XSLT…). Son objectif initial est de faciliter l’échange automatisé de

contenus entre systèmes d’informations hétérogènes.

« Centreon Status Map » Conception et développement … de stage - Epitech 3.pdf · RAPPORT DE...

Documents

Transcript of « Centreon Status Map » Conception et développement … de stage - Epitech 3.pdf · RAPPORT DE...