RapporT Allagui AMAL

Remerciements
est avec plaisir que je rserve cette page en signe de gratitude et de profonde reconnaissance tous ceux qui mont aid raliser ce travail.
Je tiens remercier les membres de Jury pour lhonneur quils mont fait pour avoir accept de juger ce travail.
Je tiens galement remercier Monsieur Imed BEN MIMOUN (Directeur de dpartement Recherche et Dveloppement), Mademoiselle Amira ALOUI (Consultante IT) et et Monsieur Adel ELJ (Superviseur des stagiaires chez Vermeg) pour leurs efforts et leurs conances. Jatteste notamment ma profonde gratitude tout le personnel de la socit pour leur accueil chaleureux et leur esprit de collaboration.
Je remercie sincrement Madame Minyar SASSI HIDRI, pour son encadrement, son assistance, son soutien et ses prcieux conseils durant tout notre travail..
Enn, jadresse mes sincres remerciements lensemble des enseignants de lEcole Nationale dIngnieurs de Tunis et tous ceux qui ont contribu au soutien de la lire informatique.
Dedicaces
Je ddie ce modeste travail A ma chre mre En tmoignage de ma profonde gratitude et de mon incontestable reconnaissance, pour tous les sacrices quelle me contente, toute la conance quelle maccorde et tout lamour dont elle mentoure. A mon cher pre Qui est le plus bon pre dans ce monde, grce son encouragement, sa conance et son soutien moral et matriel et pour son amour inni en exprimant mes gratitudes, mon profond amour et ma passion. A ma chre sur Asma, elle ma toujours aim, encourag et soutenu. A mon cher frre Oussema, notre bienaim tous, pour son affection et son amabilit. A chaque membre de ma famille pour leurs encouragements et leur continuel soutien. . . A mes amis, tous mes professeurs de lENIT et tous ceux qui me sont chers, Je vous ddie ce travail.
Allagui Amal
Resum
Pour faire face la complexit croissante des systmes informatiques, de nombreux travaux et
recherches portent sur la mise en place des outils de supervision dont le rle est de surveiller et grer ltat des ressources des applications. Cest dans ce cadre que sinscrit notre projet de n dtudes qui sintitule Conception, dveloppement et intgration dun outil de resource monitoring au sein du framework Palmyra .
Abstract
In
order to cope the complexity of information systems, a lot of research studies aims to establish monitoring tools that supervise and manage application resources state. Our graduation project is about this topic. It consist on implementing resource monitoring tool and integrating it in Palmyra Framework.
Liste des abrviations

UML
JEE MVC EJB JMX API EAR JMS JDBC ORB JNDI GWT Unied Modeling Language Java Entreprise Edition Modle Vue Contrleur Entreprises Java Bean Java Management Extension Application Programming Interfaces Enterprise Application Archive Java Message Service Java DataBase Connectivity Object Request Broker Java Naming and Directory Interface Google Web Toolkit
TABLE DES MATIRES
Amal Allagui
Table des matires
Remerciements Dedicaces Resum Liste des abrviations Table des gures Liste des tableaux Introduction gnrale 1 Cadre gnral du projet 1.1 Prsentation de lentreprise daccueil . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 1.1.2 1.1.3 1.1.4 1.2 Lorganisation de Vermeg Services . . . . . . . . . . . . . . . . . . . . Les activits de Vermeg Services . . . . . . . . . . . . . . . . . . . . . Les produits de Vermeg . . . . . . . . . . . . . . . . . . . . . . . . . Les clients de Vermeg . . . . . . . . . . . . . . . . . . . . . . . . . .
i ii iii iv x xi 1 3 3 3 4 4 5 5 5 6 6 7 7 v
Le Framework PALMYRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 1.2.2 1.2.3 1.2.4 Dnition dun Framework . . . . . . . . . . . . . . . . . . . . . . .
Le Framework PALMYRA . . . . . . . . . . . . . . . . . . . . . . Architecture de PALMYRA . . . . . . . . . . . . . . . . . . . . . . . Environnement de dveloppement . . . . . . . . . . . . . . . . . . . .
1.3
Prsentation du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TABLE DES MATIRES 1.3.1 1.3.2 1.3.3 1.4
Amal Allagui 7 8 9
Problmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Etude et critiques de lexistant . . . . . . . . . . . . . . . . . . . . . . Solutions et objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . .
La mthodologie adopte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.4.1 1.4.2 Introduction la mthodologie Scrum . . . . . . . . . . . . . . . . . . 10 Le choix de la mthodologie Scrum . . . . . . . . . . . . . . . . . . . 11 13
Etat de lart 2.1
Les serveurs dapplications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 JEE et serveurs dapplications . . . . . . . . . . . . . . . . . . . . . . 13 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Fonctionnalits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Les serveurs dapplication tudis . . . . . . . . . . . . . . . . . . . . 16
2.2
Etude du concept Resource Monitoring . . . . . . . . . . . . . . . . . . . . . 17 2.2.1 2.2.2 Concept de monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Outils de Resource Monitoring existants sur le march . . . . . . . . . 18 2.2.2.1 2.2.2.2 2.2.2.3 2.2.2.4 2.2.3 Les Solutions fournies par dfaut . . . . . . . . . . . . . . . 18 Les Solutions Open Source . . . . . . . . . . . . . . . . . . 18 Les Solutions Commerciales . . . . . . . . . . . . . . . . . 19 Etude comparative . . . . . . . . . . . . . . . . . . . . . . . 19 . . . . . . . . . . . . . . . . . . 20
Synthse des ressources superviser
2.3
Java Management Extension( JMX ) . . . . . . . . . . . . . . . . . . . . . . . 24 2.3.1 2.3.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Instrumentation de ressources dans les serveurs dapplications JEE via JMX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.3.2.1 2.3.2.2 JMX dans larchitecture technique de JBossAS . . . . . . . . 26 JMX dans larchitecture technique de Websphere . . . . . . 28
Vermeg Services
vi
TABLE DES MATIRES 3 Analyse et Spcication des besoins 3.1
Amal Allagui 30
Etude des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.1.1 3.1.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2
Etude dtaille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.2.1 Cas dutilisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.2.1.1 3.2.1.2 3.2.1.3 3.2.2 Identication des acteurs . . . . . . . . . . . . . . . . . . . 34 Cas dutilisation globale Cas dutilisation rafns . . . . . . . . . . . . . . . . . . . 34 . . . . . . . . . . . . . . . . . . . 35
Enchainement de scnarios systme . . . . . . . . . . . . . . . . . . . 42 3.2.2.1 3.2.2.2 3.2.2.3 3.2.2.4 3.2.2.5 Supervision de ltat de serveur . . . . . . . . . . . . . . . . 42 Visualisation des informations des Queues . . . . . . . . . . 43 Modication des informations des Queues . . . . . . . . . . 44 Visualisation des pools de connexion JDBC . . . . . . . . . 45 Modication des pools de connexion JDBC . . . . . . . . . 46 49
Conception 4.1
Conception gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.1.1 Architecture du systme de monitoring . . . . . . . . . . . . . . . . . 49
4.2
Conception dtaille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.2.1 4.2.2 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Enchainement des scnarios objet . . . . . . . . . . . . . . . . . . . . 54 4.2.2.1 Visualisation des informations des pools des connexions JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Modication des informations des pools des connexions JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Visualisation des informations des Queues . . . . . . . . . . 56 Modication des informations des Queues . . . . . . . . . . 57
4.2.2.2
4.2.2.3 4.2.2.4 4.2.3 4.2.4
Diagramme de dploiement . . . . . . . . . . . . . . . . . . . . . . . 58 Diagramme de composants . . . . . . . . . . . . . . . . . . . . . . . . 60
Vermeg Services
vii
TABLE DES MATIRES 5 Ralisation, test et intgration 5.1
Amal Allagui 62
Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.1.1 5.1.2 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Outils logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 . . . . . . . . . . . . . . . . . . . 64
5.2
Implmentation et intgration des modules 5.2.1 5.2.2
Prsentation des modules implments . . . . . . . . . . . . . . . . . 64 Intgration des Modules . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3 5.4 5.5
Test et validation de loutil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Problmes rencontrs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 78 80 82
Conclusion gnrale References Annexe A
Vermeg Services
viii
TABLE DES FIGURES
Amal Allagui
Table des gures

1.1 1.2 1.3 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 Organigramme de lentreprise . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture du Framework Palmyra[1] . . . . . . . . . . . . . . . . . . . . . La solution propose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Elments de resource monitoring 4 7 9
. . . . . . . . . . . . . . . . . . . . . . . . 13
Architecture 3 niveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Architecture des applications JEE . . . . . . . . . . . . . . . . . . . . . . . . 15 Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Topic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Les types dEJB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Architecture du JMX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Le serveur JMX dans un serveur JEE . . . . . . . . . . . . . . . . . . . . . . 26
JMX dans larchitecture de JBoss . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.10 Architecture de WebSphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.1 3.2 3.3 Les differents modules de loutil de monitoring . . . . . . . . . . . . . . . . . 31 Diagramme de cas dutilisation globale du systme . . . . . . . . . . . . . . . 35 Diagramme de cas dutilisation Superviser lApplication Palmyra X sous JBoss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Diagramme de cas dutilisation Superviser les Queues Palmyra . . . . . . . 38 Diagramme de cas dutilisation Superviser lApplication Palmyra X sous Websphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Diagramme de cas dutilisation Superviser les pools des connexions JDBC Palmyra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Diagramme de squence systmeSuperviser ltat de serveur . . . . . . . . 43 ix
3.4 3.5
3.6
3.7
TABLE DES FIGURES 3.8 3.9
Amal Allagui . . 44
Diagramme de squence systmeVisualiser les informations des queues
Diagramme de squence systmeModier les informations des Queue Palmyra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 46
3.10 Diagramme de squence systmeVisualiser les pools de connexion JDBCL
3.11 Diagramme de squence systmeModier les pools de connexion JDBCL . 47 4.1 4.2 4.3 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Diagramme de Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Diagramme de squence du cas dutilisation Visualiser les informations des pools des connexions JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Diagramme de squence du cas dutilisation Modier les informations des pools des connexions JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Diagramme de squence du cas dutilisation Visualiser les informations des queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Diagramme de squence du cas dutilisation Modier les informations des queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Diagramme de dploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4
4.5
4.6
4.7 4.8 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9
Diagramme de composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Architecture dun EAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Interface daccueil JBoss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Interface daccueil WebSphere . . . . . . . . . . . . . . . . . . . . . . . . . . 66 le monitoring console integr dans les applications Palmyra . . . . . . . . . . . 68 Interface daccueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Interface Liste des sources de donnes . . . . . . . . . . . . . . . . . . . . 70 Interface Monitoring dun pool JDBC . . . . . . . . . . . . . . . . . . . . 71 Interface Message de conrmation . . . . . . . . . . . . . . . . . . . . . . 72 Interface Listes des Queues . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.10 Interface Monitoring dune queue . . . . . . . . . . . . . . . . . . . . . . . 74 5.11 Informations sur les threads . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.12 Interface Informations sur la mmoire JVM . . . . . . . . . . . . . . . . . 76 5.13 Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Vermeg Services
LISTE DES TABLEAUX
Amal Allagui
Liste des tableaux

2.1 2.2 2.3 2.4 Les services dinfrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Les services de communication . . . . . . . . . . . . . . . . . . . . . . . . . 16 . . . 20
Tableau comparatif entre les outils de monitoring existants sur le march
Les composants de larchitecture JBossAS . . . . . . . . . . . . . . . . . . . . 27
xi
INTRODUCTION GENERALE
Amal Allagui
Introduction gnrale
e nos jours, il est impossible dimaginer une entreprise, quel que soit sa taille et son domaine, sans systme dinformation. En effet, ce systme reprsente le cur de lorganisme contenant lensemble des informations, des processus mtiers et des logistiques de ce dernier. Par ailleurs, les organisations dpendent de plus en plus du bon fonctionnement des composants des systmes dinformations quelles utilisent et des services rendus par ces derniers.
Et pour tre de plus en plus performante, lentreprise est dans lobligation damliorer ces processus mtiers et de suivre les volutions de son poque pour satisfaire une clientle de plus en plus exigeante en termes de qualit et de dlais. Ce qui implique la ncessit de modier le systme dinformation pour rpondre ces besoins. Paralllement cette optique, la complexit grandissante des environnements des technologies informatiques ncessaires latteinte des objectifs daffaires dune entreprise continuent rendre larchitecture des applications des entreprises de plus en plus complexe et distribue. En effet, pour suivre la demande croissante dun maximum de fonctionnalits et de cycles de dveloppement plus rapide, les application se trouvent constitue dune agglomration de composantes et de ressources tels que les bus message (JMS), linterface daccs aux services dannuaires (JNDI, SLP), laccs aux bases de donnes (JDBC), les services transactionnels (JTS), les architectures de serveurs applicatifs (EJB), les supports de communication (TCP, SNMP, HTTP.) et les bus logiciels standards tel que RMI, etc. Et vu que les applications reprsentent lessence du service fournissant un systme dinformation aux utilisateurs naux et au mtier, il savre indispensable i) davoir une visibilit globale, instantane des ressources quelles consomment, ii) de dtecter un dysfonctionnement, ii) dintervenir dans le cadre dune procdure de rsolution et iv) dalerter les quipes applicatives. Cette ncessit a amen les directions informatiques considrer la problmatique de supervision et de gestion de linfrastructure applicative comme un enjeu majeur. Ds lors, les entreprises ont cherch implanter et utiliser des outils de monitoring de faon superviser, maximiser et optimiser lutilisation de ces ressources essentielles. Dans sa qute dune meilleur efcacit et productivit de son Framework Palmyra , et 1
Liste des Abrviations
Amal Allagui
dune meilleure satisfaction de ses clients, la socit Vermeg Services au sein de laquelle nous effectuons notre projet, souhaite disposer dun outil de supervision prenne. Comme cet organisme assure le dveloppement et la commercialisation des logiciels informatiques, la mise en place dun systme qui suit le bon fonctionnement et la disponibilit des applications reprsente un choix stratgique voire invitable, pour garantir un niveau de maturit suprieur de son infrastructure applicative. Cest dans ce cadre que sinscrit ce projet de n dtudes, qui vient couronner les tudes dingnierie, de concevoir et de mettre en place un tel outil de supervision et de gestion des ressources bases sur les services de la spcication JMX de la communi Java Community Process et qui sera capable de suivre le fonctionnement de toutes applications gnres par le Framework de lentreprise. A travers ce rapport, seront prsentes les tapes suivies pour mener terme ce projet. Pour ce faire, cet ouvrage sarticule autour de cinq chapitres. Le premier prsente lorganisme daccueil et nonce le sujet. Le deuxime permet une meilleure comprhension du concept de la supervision et dcrit ce qui va tre supervis et le mcanisme utilis. Dans le troisime chapitre nous faisons une analyse dtaille permettant llaboration de la solution de supervision. Le quatrime chapitre dtaillera la conception de notre application et dcrira le processus suivi lors de son dveloppement. Enn, le dernier chapitre prsentera la phase de ralisation, de tests et dintgration dans le Framework Palmyra.
Vermeg Services
CHAPITRE 1. CADRE GNRAL DU PROJET
Amal Allagui
Chapitre 1 Cadre gnral du projet

Introduction
Au cours de ce chapitre, nous allons situer le projet dans son cadre gnral. Nous allons commencer par prsenter lorganisme daccueil. Ensuite, nous allons introduire le Framework Palmyra utilis dans la socit. Enn, nous allons spcier le cadre technologique et les objectifs atteindre par ce projet tout en analysant la problmatique et offrant les solutions envisages.
1.1
Prsentation de lentreprise daccueil
Le projet a t ralis au sein de la socit Vermeg Services situe aux Berges du Lac. Vermeg , est une socit de services et dingnierie informatique dont lactivit majeure est axe sur ldition de logiciels et lintgration de systmes. Elle a t fonde en 1994 en mains prives, elle est inscrite au registre en France et aux Pays-Bas. Elle emploie prs de 250 personnes rparties dans plusieurs siges : Tunis, Paris, Madrid, Luxembourg, Londres (Sige de vente seulement) et Johannesburg (Partenariat local).
1.1.1
Lorganisation de Vermeg Services
La socit Vermeg Services est compose de quatre dpartements : Dpartement Administratif. Dpartement de dveloppement. Dpartement dEtudes et de Consulting. 3
CHAPITRE 1. CADRE GNRAL DU PROJET Dpartement Commercial.
Amal Allagui
F IGURE 1.1 Organigramme de lentreprise
1.1.2
Les activits de Vermeg Services
Vermeg Services est incluse dans le ple de recherche et de dveloppement du groupe. Elle est principalement considr comme tant un diteur de progiciels bancaires. Les domaines dactivits de Vermeg sont les suivants : Asset Management (Front et Back-ofce) : Le Front Ofce (appel galement Front line) dsigne la partie frontale de lentreprise, visible par la clientle et en contact direct avec celle ci, comme les quipes de marketing, de support utilisateur ou de service aprs-vente. Le Back Ofce linverse dsigne lensemble des parties du systme dinformation auxquelles lutilisateur nal na pas accs. Il sagit donc de tous les processus internes lentreprise (production, logistique, stocks, comptabilit, gestion des ressources humaines, etc.). Titres : Clearing, OST 1, Ngo : oprations sur les titres. Tl compensation et RTGS 2 : Tl compensation ou clearing : Opration de mise jour des virements et prlvements bancaires entre tablissements nanciers, effectue travers un rseau.
1.1.3
Les produits de Vermeg
Vermeg Services offre une gamme de solutions logicielles pour les gestionnaires des actifs, les banques et les institutions nancires impliques dans la gestion de portefeuille et ladministration de fonds. Vermeg Services 4
Amal Allagui
MEGALEND : cest une solution globale pour la gestion des changes nanciers scuriss, les emprunts et les repos. Cette solution est destine aux banques, aux compagnies dassurance et aux gestionnaires de fonds. OMEGA : cest une suite de solutions logicielles ddies au march de gestion des capitaux, fournissant les fonctionnalits front, middle et back ofce. MEGARA : cest une suite des composants de solutions traitant la pleine porte des services de scurit et de la gestion de portefeuille. MEGACOR : cest une solution permettant dautomatiser entirement le processus de gestion des actions dentreprise.
1.1.4
Les clients de Vermeg
Les produits de Vermeg Services ont t choisis par plus de 100 organismes bancaires et nanciers dans le monde entier situs dans plus de 15 pays et rpartis sur quatre continents. La liste suivante prsente les principaux clients de Vermeg : Socit Gnrale (Londres, Madrid, Athnes, Kiev, Bucarest, Afrique du sud) . Banque de France. Banque Nationale de Paris (BNP Paribas). Banque de Luxembourg (Belgique). Credit Suisse Asset Management. Banque et Caisse dEpargne de lEtat (BCEE, Luxembourg). Banco Santander Central Hispano (BSCH, Madrid). Banco Bilbao Vizcaya Argentaria (BBVA, Madrid). BNP (Hong Kong, Taipei, Montral, New York).
1.2
1.2.1
Le Framework PALMYRA
Dnition dun Framework
Un Framework est une bibliothque de classes fournissant une structure gnrale pour le dveloppement dune application dans un domaine particulier. Les Frameworks facilitent le travail des dveloppeurs en fournissant un squelette dapplication quil suft de remplir pour ladapter leurs besoins[1]. Vermeg Services 5
Amal Allagui
1.2.2
Le Framework PALMYRA
An de faciliter la tche pour ses dveloppeurs, Vermeg Services a dcid de dvelopper son propre Framework. Lobjectif principal tant de gnrer automatiquement toute une application partir dun simple modle UML . Les applications que gnre PALMYRA visent principalement les mtiers de la banque et de la bourse et utilisent des SGBDs relationnels. Le but du Framework est de rduire la redondance du code et faire crotre sa portabilit. La portabilit se manifeste par lindpendance de tout systme dexploitation, de tout serveur dapplication et de tout systme de gestion de base de donnes. Il repose sur lanalyse et la conception oriente objet, et utilise des modles et des outils standards tels que le modle UML et le standard J2EE. En Novembre 2007, Le label IBM SOA Exploit a t dcern au Framework PALMYRA, aprs plusieurs suites de tests techniques et mtier, faisant ainsi de ce Framework la base du concept darchitecture oriente services des applications de "Vermeg Services"[1].
1.2.3
Architecture de PALMYRA
Larchitecture de PALMYRA prsente un systme orient service pour le dveloppement dapplications nancires sur un environnement distribu pour rpondre aux contraintes business ainsi quaux contraintes de technologie. Cette plateforme est la base de dveloppement des produits Vermeg qui possde une architecture N-tiers base sur le standard J2EE conue par la socit elle mme an de rpondre aux spcications.
Vermeg Services
Amal Allagui
F IGURE 1.2 Architecture du Framework Palmyra[1] Larchitecture N-tiers de PALMYRA est conforme au design pattern MVC. Une couche View pour la prsentation des interfaces Homme Machine, une couche Model pour les donnes et les traitements de lapplication, et une couche control pour les interactions entre le modle et la vue. Un avantage apport par ce modle est la clart de larchitecture quil impose. Ceci simplie en effet la tche du dveloppeur qui tenterait deffectuer une maintenance ou une amlioration sur le projet.
1.2.4
Environnement de dveloppement
La plateforme PALMYRA prsente un environnement de dveloppement bas sur des langages de conception et de dveloppement tels que UML et JAVA et intgre des technologies diffrentes, notamment des logiciels de conceptions, de dveloppement, et des serveurs Web qui sont associs chacun un produit assurant leurs efcacits lors du dploiement[1].
1.3
1.3.1
Prsentation du travail
Problmatique
Le resource monitoring (supervision des ressources ou bien supervision applicative), devient une ncessit, de nos jours dans les grandes entreprises. Il sagit principalement de la Vermeg Services 7
Amal Allagui
surveillance dune application autant au niveau des composantes individuelles ncessaires son opration quau niveau de lexprience client qui rsulte de son utilisation. La surveillance a pour but de quantier la disponibilit et la performance des ressources utiliss par les applications selon certaines mesures cibles vers les points de contrle appropris dans le but de respecter lentente de niveau de service tablie avec le client utilisateur de lapplication [2]. En raison de la complexit et de lhtrognit du patrimoine applicatif de lentreprise, et en adoptant une dmarche de supervision, de gestion et doptimisation de lutilisation des ressources, de nombreuses organisations doivent mettre en uvre des solutions de monitoring, cest dans ce cadre que se situe notre projet de n dtude. Dans le paragraphe suivant nous allons dcrire la dmarche de monitoring qui existe dans lentreprise, puis nous prsenterons notre projet et ses objectifs pour ramener lentreprise de ce quil existe ce quelle attend du dveloppement de notre projet .
1.3.2
Etude et critiques de lexistant
Cette tape sert essentiellement tudier les mthodes de monitoring qui existent dj au sein de Vermeg an de bien xer les objectifs, la valeur ajoute apporter ainsi que lensemble des fonctionnalits dvelopper. Le Framework Palmyra est la base de dveloppement des produits Vermeg, les applications quil gnre utilisent principalement JBoss et WebSphere comme serveurs dapplications. Au cours de lamlioration de cette plateforme, lquipe "Palmyra" qui est une quipe de recherche et dveloppement de "Vermeg Services" et avec laquelle nous effectuons notre projet de n dtude, a dgag quelques lacunes portant sur labsence de contrle, ladministration et la supervision des ressources consommes par les applications dployes sur ces serveurs. Les utilisateurs de ce Framework ne dispose pas dun outil de supervision des ressources. Cependant, ils utilisent les consoles dadministrations fournis par dfaut par les serveurs dapplications. De ce fait, ils ne peuvent superviser que les ressources des applications dployes sur JBoss puisque ce dernier offre une console libre, ce qui nest pas le cas avec Websphre. Donc, du point de vue utilisateur, il est clair que cette approche actuelle est trs limite et insufsante pour : offrir la visibilit et le contrle ncessaire des ressources Palmyra, suivre de bout en bout le fonctionnement des applications Palmyra par rapport linfrastructure applicative, optimiser la ractivit et donc permettre davoir une vision globale de la performance de cette plateforme. Vermeg Services 8
Amal Allagui
Par consquent, labsence dans le Framework Palmyra dun outil qui surveille les applications, en offrant les fonctionnalits cit ci-dessus, affecte ngativement sa robustesse, sa disponibilit et sa performance. Ces critres sont critiques pour nimporte quelle application dentreprise et plus spciquement pour linfrastructure applicative de Palmyra.
1.3.3
Solutions et objectifs
Le sujet propos est donc de compenser ces lacunes par la mise en place dun outil de supervision applicative permettant linstrumentation des ressources des applications mtiers et la surveillance de leur disponibilit. Il sagit concrtement de concevoir et de dvelopper une outil de monitoring (voir gure 1.3) extensible et gnrique vis--vis des serveurs dapplications (JBoss ,Websphere) en utilisant les technologies qui seront voqus dans la section suivante JMX et GWT. Ainsi lutilisateur pourra vrier continuellement et aisment le bon fonctionnement de linfrastructure applicative et par consquence il pourra anticiper, prvenir les pannes, identier le disfonctionnement et en informer les administrateurs concerns.
F IGURE 1.3 La solution propose Vermeg Services 9
Amal Allagui
Notre travail consiste donc en la concrtisation de la solution cit ci-dessus, en fournissant un outil simple, intgrable dans la Framework et riche en fonctionnalits. Les objectifs du projet sont : Ltude des besoins internes de supervision applicative de lentreprise. Ltude des diffrentes notions des ressources des applications JEE (Queue, Database Connection, Connection Pool, etc). Ltude des diffrents serveurs dapplications tel que JBoss et Websphere . La surveillance des applications et des services quelles rendent. La vrication de la disponibilit des ressources des applications. Le contrle de performance des applications, en vriant si les temps de rponses rpondent aux exigences. Lexpos de certains paramtres et informations de fonctionnement des applications. Lafchage des graphes de temps de rponse et des rapports de disponibilit. Lalerte des administrateurs en cas de problmes (indisponibilit, temps de rponse trs long, etc).
1.4
La mthodologie adopte
Aprs avoir prsent le travail demand, il est crucial de choisir une mthodologie adquate en vue dorganiser le travail, dassurer le bon droulement de notre projet et de garantir le meilleur rsultat. Pour ce faire, nous adopt Scrum comme tant une approche de gestion de projet . La Mthode Agile est un ensemble de mthodologies de dveloppement logiciel bas sur le dveloppement itratif et incrmental mene dans un esprit collaboratif, o les exigences du client et les solutions voluent grce la collaboration entre lauto-organisation [3].
1.4.1
Introduction la mthodologie Scrum
Le terme Scrum (qui signie mle en rugby) se rapproche plus dune gestion de ressources humaines plutt que dune relle mthode de dveloppement. Il sagit ici de ne pas oublier le ct humain du dveloppement. Les principales caractristiques de Scrum permettent de[3] :
Vermeg Services
10
CHAPITRE 1. CADRE GNRAL DU PROJET Identier les changements trs tt. Donner toute la conance aux dveloppeurs et les laisser faire leur travail.
Amal Allagui
Faire des itrations variantes (gnralement de 30 jours), appels aussi sprints pour laisser le temps de coder. Chaque itration a un objectif bien prcis ou backlog et fournit une nouvelle fonctionnalit teste (une dmonstration est faite la n de chaque sprint). Faire des runions tous les jours (daily meeting) et chaque semaine (weekly meeting) pour encadrer les quipes et recaler les objectifs.
1.4.2
Le choix de la mthodologie Scrum
Davantage quune mthode formelle, Scrum peut tre vu comme un Framework mthodologique dont limplmentation doit tre ajuste en fonction des caractristiques techniques, organisationnelles et culturelles des projets qui souhaitent la mettre en uvre (Scrum, au demeurant, ne limite pas son champ dapplication aux seuls projets informatiques : ses principes sont applicables pour toute activit visant produire un rsultat). Dans ses grandes lignes, Scrum dnit un jeu minimal dacteurs, de crmonies et dartefacts qui permettent de relever les ds principaux du dveloppement incrmental : la planication, la gestion du temps et la gestion des obstacles. Scrum est entirement pilot par la Valeur Mtier. La gestion des risques, en particulier, est ralise au travers de ce prisme. Scrum identie trois acteurs [3] : Le Product Owner (Directeur de Produit), qui possde lexpertise fonctionnelle et ralise les arbitrages ncessaires la priorisation des dveloppements. Son rle est absolument essentiel, et son respect des rgles du jeu est la pierre angulaire du succs dun projet agile. Le Scrum Master, membre de lEquipe, et dont la tche principale est doptimiser la capacit de production de lEquipe en laidant travailler de faon autonome et samliorer constamment. Il est galement le garant de la bonne implmentation de Scrum. Lquipe, dont la taille doit tre rduite, et qui prend en charge le dveloppement du produit (planication, conception, codage, tests, documentation) sans spcialisation des rles. La particularit dune Equipe Scrum est dtre auto-organise , et donc dpourvue de hirarchie. Cet aspect constitue une rupture radicale avec les approches Vermeg Services 11
Amal Allagui
managriales traditionnelles, qui privilgient un contrle centralis gnralement incarn par le Chef de Projet.
Conclusion
Ce chapitre aborde le contexte gnral de notre projet. La prsentation de lentreprise daccueil Vermeg Services et de son Framework Palmyra a t suivie dune brve analyse des besoins de la socit en termes dintgration des services ainsi quune description relativement dtaille de la problmatique et des objectifs du projet propos. Il savre, en effet, important de tracer les grandes lignes de notre travail pour comprendre les raisons de ce projet et ainsi faciliter son laboration. Il convient dintroduire, dans le chapitre suivant quelques notions prliminaires visant expliquer les technologies utiliser dans ce projet.
Vermeg Services
12
CHAPITRE 2. ETAT DE LART
Amal Allagui
Chapitre 2 Etat de lart

Introduction
Notre projet se base sur des concepts assez rcents qui ncessitent une tude approfondie an de mieux les adopter dans notre travail. Le prsent chapitre prsente les principales technologies tudier avant de continuer llaboration du projet. Dans une premire partie, nous expliquons le principe dun serveur dapplication, puis nous prsentons la notion de la supervision applicative (Ressource Monitoring). Finalement, nous allons dtailler le concept de JMX. Le schma ci aprs montre en clair les diffrents lments que nous aborderons dans ce deuxime chapitre.
F IGURE 2.1 Elments de resource monitoring
2.1
2.1.1
Les serveurs dapplications

JEE et serveurs dapplications
Lvolution des nouvelles technologies, les limitations des modles client/serveur et des modles objets distribus ont favoris les architectures multi nivaux. La plate forme Java EE est la version entreprise de Java prsent par Sun, dans le but de spcier un standard de dveloppement dapplications distribus et multi-niveaux dentreprises. 13
Amal Allagui
Les applications JEE sont considres des applications 3-tiers puisque elles sont rparties sur 3 localisations diffrentes : le systme dinformations (base de donnes, etc), le serveur JEE et les machines clientes[4]. Le gure suivante prsente les 3 niveaux de cette architecture.
F IGURE 2.2 Architecture 3 niveau Cette architecture trois niveaux a pour objectifs : Optimiser la rpartition des charges entre le poste de travail et le serveur par linsertion dun niveau intermdiaire (serveur frontal). Amliorer la disponibilit des applications. Sparer la prsentation, les traitements et les donnes : modle MVC. Permettre une volution des niveaux indpendamment des autres.
2.1.2
Architecture
Une application JEE sexcute dans un serveur dapplications qui reprsente le noyau des architectures multi niveaux. Le rle dun tel serveur est dassurer la logique mtier des applications en dcouplant celle-ci des prsentations et des accs aux donnes. Dans un serveur dapplications JEE, les services standards sont regroups dans des conteneurs reprsents dans la gure ci-dessous, savoir [4] : Un conteneur web : Gre lexcution des composants Web (Servlet ,JSP,etc). Un conteneur dEJB : Gre lexcution des composants mtiers appels EJB.
Vermeg Services
14
Amal Allagui
F IGURE 2.3 Architecture des applications JEE En se rfrant cette architecture, les serveurs dapplications fournissent plusieurs services (JNDI, JMS,. . .), assurant plusieurs fonctionnalits travers les APIs JEE. En effet, il existe deux types de services et nous allons les aborder dans la section suivante.
2.1.3
Services
Les services fournis par tout serveur certi JEE sont[4] : Services dinfrastructure : le tableau suivant prsente la description de ce type de service.
Nom de lAPI JDBC (Java DataBase Connectivity) JNDI(Java Naming and Directory Interface) JTA/JTS(Java Transaction API/ Java Transaction Services) JCA (JEE Connector Architecture)
Description API de connexions des bases de donnes. API daccs aux services de nommage et aux annuaires dentreprises (LDAP,..). API dnissant des interfaces standards avec un gestionnaire de transaction. API de connexion au systme dinformation dentreprise (ERP,. . .).
TABLE 2.1 Les services dinfrastructure Services de communication : le tableau suivant prsente la description de ce type de service.
Vermeg Services
15
Amal Allagui
Nom de lAPI JAAS(Java Authentication and Authorization Service) RMI(Remote Method Invocation) JMS(Java Message Service) JavaMail
Description API de gestion de lauthentication et des droits daccs. API permettant la communication synchrone entre objets. API de communication asynchrone par message . API de gestion des mails.
TABLE 2.2 Les services de communication
2.1.4
Fonctionnalits
On sappuyant sur ses API, le conteneur dEJBs offre de nombreuses fonctionnalits, savoir[4] : La prise en compte des transactions. La gestion des ressources : Le pooling de connexions, threads, sockets, mmoire, etc. Gestion du cycle de vie des composants (La cration et la destruction des instances des EJBs). Gestion de ltat des composants. Clustering (Utilisation dun cache pour viter laller retour vers la base de donnes). La communication asynchrone (La mise en le dattente les messages). La scurit.
2.1.5
Les serveurs dapplication tudis
Au cours de notre projet, nous avons tudi deux serveurs dapplication JBoss AS (Jboss Application server) et Websphere AS (Websphere Application server) : JBoss AS : JBoss AS est une plate-forme Java EE certie, entirement crit en Java et libre pour dvelopper et dployer des applications dentreprise Java, les applications Web et les portails, JBoss Application Server offre la gamme complte des fonctionnalits Java EE ainsi que des services dentreprise tendue[5]. Vermeg Services 16
Amal Allagui
Les dveloppeurs de JBoss sont employs par une socit de services appele JBoss Inc rachet par Red Hat en avril 2006. Le projet est sponsoris par un rseau mondial de partenaires et utilise un business model bas sur le service[6]. IBM Websphere AS : Le serveur dapplication Websphere de IBM est une plateforme applicative gnrique couvrant un ensemble de solutions dveloppes qui permettent de dvelopper, de dployer et dutiliser des applications dentreprise, mme dans des cas complexes faisant appel des applications et des matriels htrognes. Le serveur dapplication Websphere JEE aide amliorer lintgration avec les clients, les fournisseurs, et les associs avec lappui complet de services de Web. Websphere couvre une gamme doutils de dveloppement bass principalement sur le socle de dveloppement Eclipse et le langage Java [7].
2.2
Etude du concept Resource Monitoring
Dans cette partie nous allons nous focaliser sur le concept de resource monitoring, qui est le mcanisme assurant la supervision des ressources au sein des serveurs dapplications.
2.2.1
Concept de monitoring
Le monitoring (supervision) peut tre dni comme tant un mcanisme qui permet de surveiller le bon fonctionnement dun systme ou dune activit. Il permet mme de rapporter et dalerter les fonctionnements normaux et anormaux. Il concerne lacquisition des donnes (mesures, alarmes, retour dtat de fonctionnement) et des paramtres de commande des processus. La supervision est par consquent une technique qui comprend les activits suivantes : surveiller, visualiser, analyser, agir. La supervision est donc un domaine assez vaste et vague. En effet, Il existe deux types de supervision : la supervision technique et la supervision applicative[1]. Supervision technique Il sagit de la supervision des composants techniques, la surveillance permanente de linfrastructure, rseau, et les machines du systme dinformation. Son rle est de collecter les informations, alerter et anticiper sur des problmes techniques. Supervision applicative Nous pouvons lappeler aussi supervision de ressources (resource monitoring), cest une technique qui permet de vrier le bon fonctionnement des applications hberges sur les serveurs et de monitorer leur disponibilit en termes des ressources et services rendus. Vermeg Services 17
Amal Allagui
Le but de ce type de supervision est de surveiller les applications mtiers en temps rel an de rpondre aux exigences des contrats de services. Notre projet se situe dans ce contexte. En effet nous allons enrichir le Framework Palmyra de lentreprise par la mise en place dun outil de resource monitoring. Dans la partie qui suit, nous allons tudier les outils de resource monitoring les plus rpandus sur le march.
2.2.2
Outils de Resource Monitoring existants sur le march
Le but de cette tude est dextraire le maximum de fonctionnalits pour les implmenter dans notre projet. Pour arriver cette nalit, nous allons procder de la manire suivante, nous allons prsenter les diffrentes solutions existantes sur le march, laborer un comparatif entre ces outils et enn consacrer une dernire partie pour les fonctionnalits dgages. Plusieurs solutions sont envisageables pour ce genre dadministrations. 2.2.2.1 Les Solutions fournies par dfaut
Les consoles dadministration des serveur JEE Une console dadministration, est une application Web fournie avec chaque serveur dapplication pour ladministration et le monitoring de ce dernier. Elle est accessible aprs le dmarrage du serveur via un navigateur. Les consoles dadministration des diffrents serveurs dapplications assurent plusieurs fonctionnalits tels que : Le dploiement, lannulation du dploiement et la mise jour des applications dentreprises, la conguration des ressources, etc. JConsol JConsol est fournie avec le JDK (Java Development Kit) partir de la version 5, pour superviser les machines virtuelles Java JVM dans le but de fournir des informations sur les performances et la consommation des ressources des applications excutes sur la plateforme Java en utulisant La technologie JMX [8]. 2.2.2.2 Les Solutions Open Source
Plusieurs outils de monde libre ont vu le jour dans le domaine de la supervision technique, mais moins dans la supervision applicative. Parmi ceux qui supervisent les applications on trouve : Vermeg Services 18
CHAPITRE 2. ETAT DE LART JOPR :
Amal Allagui
JOPR est une application Open Source de Monitoring, simple utiliser, dveloppe avec des technologies rcentes, des interfaces graphiques ergonomiques. Elle permet de superviser plusieurs types de ressources, de parcourir les applications dployes et de consulter leurs statistiques, de consulter les tats des ressources et elle permet aussi daccder certaines informations standard de la JVM [9]. Hyperic HQ Open Source Edition Hyperic HQ est une application Web dadministration et de Monitoring, qualie comme le meilleur outil de Monitoring Open Source. Elle rpond aux besoins croissants des entreprises adoptant les nouvelles technologies Web comme le Cloud Services, et elle offre des fonctions de contrles et de gestions puissantes avec une dtection automatique des ressources grer[10].
2.2.2.3
Les Solutions Commerciales
Hyperic HQ Entreprise Edition Cette dition assure les fonctionnalits de ldition Open source, mais elle couvre de plus, des environnements plus larges et complexes, elle supporte le mode Cluster, elle offre la possibilit de faire des congurations persistantes et de la gnration dtat (Reporting)[10].
2.2.2.4
Etude comparative
Les solutions voques prcdemment prsentent des limitations que nous pouvons rsumer comme suit : dune part, les outils de monitoring open source sont rares et leur documentation est gnralement soit inexistante soit insufsante, ce qui rend leur extension trs difcile. Pour les logiciels propritaires existant sur le march, leur cot dacquisition est lev et ainsi que celui de support . Dautre part, lentreprise vise mettre en place un outil de monitoring qui rpond au critres suivants : support des serveurs dapplications JBoss et Websphere, extensibilit en cas dajout dun autre serveur, des interfaces dveloppe avec le Framework GWT, monitoring distance et des notications congurables. De ce fait, aprs avoir bien les tudier et en se rfrant au tableau 2.3, les solutions prcdentes ne sont pas satisfaisantes car aucune noffre tout ces critres demands.
Vermeg Services
19
Amal Allagui
Console des serveur JEE Chaque console Serveurs dapplication supporte uniquesupports ment son propre serveur. Extensibilit
JOPR
Hyperic RH Open Source JBoss Websphere
JBoss
Hyperic Rh Entreprise Edition JBoss Websphere
GWT
Persistance du conguration
Notications Congurables
Monitoring distance TABLE 2.3 Tableau comparatif entre les outils de monitoring existants sur le march La programmation dune application par nos soins en utilisant les technologies que nous avons voques prcdemment, reprsente la meilleure solution en termes de satisfaction des besoins demands par lentreprise.
2.2.3
Synthse des ressources superviser
Daprs ltude de diffrentes solutions de supervision applicative, nous avons pu dgager des diffrentes ressources que nous sommes amens monitorer. Dans ce paragraphe, nous allons expliquer chaque type ressource [11], JMS Pour avoir des traitements asynchrones en JEE, une des manires consiste en lutilisation dun MOM (Message Oriented Middleware), qui sagit dun systme bas sur lchange Vermeg Services 20
Amal Allagui
de messages. Cette API permet lchange de messages de manire asynchrone entre applications et composants Java et garantit la bonne livraison avec des notions de persistance : tant que le message ne peut pas tre dlivr, il est stock (en base de donnes mmoire ou bien chier). Il existe de mode de consommation de message : Point point : une application produit un message destin un seul consommateur, il sagit du concept de Queue (voir gure 2.4) .
F IGURE 2.4 Queue Publish /Subscribe :une application produit un message qui devra tre diffus auprs de plusieurs applications, cest le concept de Topic (voir gure 2.5).
F IGURE 2.5 Topic JDBC Concernant lAPI JDBC, nous nous sommes interress au ressources suivantes : Datasource : Une Datasource est une interface qui reprsente une source de donnes. Cette dernire est une simple fabrique de connexions vers la source de donnes physiques (base de donnes). Vermeg Services 21
Amal Allagui
Un pool de connexion : Cest en fait un mcanisme qui permet de rutiliser les connexions dj cres, pour viter la cration systmatique de nouvelles instances de connexion, qui pourra tre lourd en consommation de ressources.
EJB Les Entreprises JavaBean sont des composants Java portables, rutilisables et dplorables qui peuvent tre assembls pour crer des applications. Ils sexcutent dans un conteneur EJB qui va leur fournir des services tel que, les transactions, la persistance, etc. Les trois types dEJB (voir gure 2.6) : Les Session Bean soccupent des traitements, et ils peuvent tre deux types : Stateless qui ne conservent pas leur tat entre deux appels, et stateful qui le conservent. Les Entity Bean reprsentent des objets persistants et soccupent des donnes. Les EJB entit sont deux sortes : CMP (container Managed Persistence) les beans dont la persistance est gr par conteneur EJB et BMP (bean Managed Persistence ) les beans dont la persistance est gr par le dveloppeur. Les Messages-Driven Bean (MDB), permet lapplication de traiter des messages de manire asynchrone, cet EJB va ragir aux messages reus au travers de JMS.
F IGURE 2.6 Les types dEJB Les EJBs sont accessibles distance et sont rpertoris dans un annuaire. Ils sexcutent dans le serveur dapplication . Thread Un thread est une partie des instructions du processus qui est en cours dexcution. Contrairement au processus, les threads peuvent partager le mme espace mmoire et les mmes ressources. Par consquent, chaque thread peut excuter une tache spcique
Vermeg Services
22
Amal Allagui
en parallle des taches des autres threads. Un processus peut contenir un ou plusieurs threads pouvant sexcuter simultanment. Mise en cache Cest un systme qui permet une utulisation efcace des donnes ( les rsultats des requtes ) et par suite une amlioration des performances des applications en stockant les donnes de faon transparente an que les futures demandes soient servies plus rapidement. Mise en cache dynamique La mise en cache des rsultats des requtes amliore les performances. Le regroupement de plusieurs oprations de mise en cache en un seul service est appel mise en cache dynamique. Dans un serveur dapplications, ces oprations sassocient pour partager les paramtres de conguration du service qui les regroupent, ce qui permet de plus damlioration des performances. Le mcanisme de service de cache dynamique fonctionne dans la JVM du serveur dapplications et intercepte les appels des objets pouvant tre stocks en cache. ORB Un ORB est lensemble de fonctions (classes Java , bibliothques, etc) qui implmentent un bus logiciel par lequel des objets peuvent envoyer et recevoir des requtes et des rponses, dune manire transparente et portable. En fait , il sagit de linvocation distance dune mthode dun objet distribu par un autre objet. Ces objets sont souvent des services. JNDI Cest une API de connexion des annuaires permettant daccder des services. Lannuaire JNDI reprsente un composant central des serveurs dapplications JEE. Il sert rfrentiel de conguration aux applications et au serveur dapplications lui mme, en fait il permet de relier un nom une information ou une ressources (queue, mdb, datasource..). Transaction Une transaction correspond une srie de taches formant un ensemble indivisible et sexcutant dune faon atomique : Soit toutes les oprations ont lieu (commit) Si une choue, toutes chouent (rollback). Les transactions sont utiles pour manipuler le traitement complexe des applications.
Vermeg Services
23
Amal Allagui
Dans la partie suivante , nous allons prsenter la technologie que nous avons adopt pour superviser ces diffrentes ressources.
2.3
Java Management Extension( JMX )
La technologie JMX dnit une architecture et un ensemble de services permettant ladministration des rseaux et des applications Java. JMX a t adopt par la plupart des serveurs dapplication pour ladministration des services JEE [12].
2.3.1
Architecture
Pour tre administrable, les ressources logicielles ou matrielles doivent tre instrumentes sous la forme de composants MBean. En effet, le concept de base de larchitecture JMX est le MBean, qui est littralement un objet gr, simple implmenter, qui reprsente une ressource pour ses besoins de supervision ou un service utile la supervision. Ces composants fournissent une interface dadministration et linstrumentation ncessaire permettant de contrler les ressources associes. La technologie JMX propose une architecture en trois couches , dveloppe dans la gure 2.7, pour permettre des applications de gestion de grer des ressources [13] :
Vermeg Services
24
Amal Allagui
F IGURE 2.7 Architecture du JMX Le niveau instrumentation : Ce niveau correspond linstrumentation des ressources sous la forme de MBeans. Un MBean contient la logique dadministration permettant de contrler la ressource associe au travers de linterface dadministration. Cette instrumentation a pour rle : Dabstraire ltat dune ressource et de permettre de manipuler son tat. Dmettre des notications lorsque certains vnements associs la ressource se produisent. Le niveau agent : Les agents dadministration contrlent les MBeans et les rendent accessibles aux applications dadministration distantes. Chaque agent a la responsabilit dun ensemble de MBeans. Toutes les oprations dadministration requises sur un MBean doivent passer par un agent. Le niveau service distribu : Ce niveau spcie des composants particuliers, administrables distance par le biais de protocoles (RMI, Corba) ou adaptateurs (HTML) permettant aux applications de gestion Vermeg Services 25
CHAPITRE 2. ETAT DE LART daccder distance aux agents JMX.
Amal Allagui
2.3.2
Instrumentation de ressources dans les serveurs dapplications JEE via JMX
Pratiquement tous les serveurs dapplications JEE prsentent une administration accessible via JMX. Notamment, JBossAS et WebSphereAS possdent chacun un serveur JMX appel aussi serveur des MBeans qui est lintermdiaire entre le client (Console dadministration) et les MBeans qui instrumentent les ressources (voir la gure 2.8)[13].
F IGURE 2.8 Le serveur JMX dans un serveur JEE
2.3.2.1
JMX dans larchitecture technique de JBossAS
Cette partie dcrit de manire plus dtaille larchitecture du serveur dapplication JBoss qui se base principalement sur lAPI JMX[5]. En fait, la gure 2.9 montre bien que le JMX joue le rle dune colonne vertbrale ou le bus dans larchitecture de JBoss.
Vermeg Services
26
Amal Allagui
F IGURE 2.9 JMX dans larchitecture de JBoss JBoss propose de nombreux modules dont chacun joue un rle dans cette architecture . Le tableau 7.4 dcrit chaque composant. Composant JBoss Server Description Il constitue le cur du JBoss, son rle est la gestion du noyau grce au JMX et aussi de fournir les conteneurs EJB. Ce composant, la diffrence des autres serveurs dapplication JEE, permet de dployer et redployer automatiquement des nouvelles applications sans avoir stopper ou arrter le serveur. Ce composant implmente LAPI Java Message Services (JMS). Ce composant gre la scurit grce lAPI JAAS, et il fournit une implmentation standard de scurit JEE. Ce composant permet le support des moniteurs de transaction avec les API JTA/JTS. Ce module permet de grer la connexions au bases de donnes grce au connecteur JDBC. Les datasources reprsentent ce composant. JbossCX permet de grer les connecteurs aux systmes dinformations de lentreprise . Cest le serveur web , et il est gr laide de deux produits Jetty et Tomcat.
JBossMQ JBossSX
JBossTX JBossCMP JbossCX
Web Server
TABLE 2.4 Les composants de larchitecture JBossAS
Vermeg Services
27
Amal Allagui
Les services principaux du serveur JBoss sont dvelopps comme des units dintgration JMX appels MBean (Managed bean). Tous ces services sont inscrits dans la mme instance MbeansServer du JMX qui prsente le cur du JBoss et permet lajout de nouveaux services ainsi que laccs tous les services enregistrs. Une fois ces Mbeans chargs dans le serveur, ils seront administrs avec JMX [5].
2.3.2.2
JMX dans larchitecture technique de Websphere
Larchitecture des serveurs dapplications WebSphere est organise sur les concepts de cellule, nud, agent du nud, gestionnaire de dploiement, et serveurs (voir gure 2.10)[14]. Les cellules (Cells) Une cellule est une unit virtuelle qui est constitu dun gestionnaire de dploiement et un ou plusieurs nuds (Node) . Le gestionnaire de dploiement (Deployment Manager) Le gestionnaire de dploiement est un processus charg de grer linstallation et la maintenance des applications , pools de connexions et dautres ressources lies lenvironnement JEE. Le gestionnaire de dploiement communique avec les nuds travers un autre processus WebSphere qui est lagent de nud (Node Agent). Le nud (Node) Le nud est une autre unit virtuelle qui est constitu dun agent de nud et un ou plusieurs instances du serveur. Dans la pratique un nud est associ avec une installation physique du serveur dapplication WebSphere. Lagent de nud (Node agent) Lagent de nud est le processus responsable de dmarrer ou arrter les processus serveur et galement responsable pour la synchronisation de conguration entre le gestionnaire de dploiement et le nud. Les serveurs (servers) On trouve gnralement deux types de serveurs, Les serveurs JMS qui grent le messaging et les serveurs dapplication qui grent et excutent les applications dployes. La gure 2.10 illustre bien cette architecture.
Vermeg Services
28
Amal Allagui
F IGURE 2.10 Architecture de WebSphere Les Mbeans JMX contrlent tout les ressources au niveau de cette architecture. En effet, les MBeans disponibles sous les serveurs dun noeud sont visibles via lagent du nud, et ceux disponibles sur tous les noeuds sont visibles via le gestionnaire de dploiement. En se connectant au gestionnaire de dploiement, nous pouvons donc appeler des oprations, extraire et dnir des attributs et recevoir des notications pour nimporte quel MBean de la cellule. Le serveur dapplications fournit une classe AdminService qui rete linterface JMX MBeanServer standard [15].
Conclusion
Nous avons essay dans ce chapitre de mettre en jeu les diffrents outils utiliss qui seront utiles pour la prochaine phase pour rpondre nos besoins. Le chapitre suivant sera consacr lanalyse et la spcication de ces derniers.
Vermeg Services
29
CHAPITRE 3. ANALYSE ET SPCIFICATION DES BESOINS
Amal Allagui
Chapitre 3 Analyse et Spcication des besoins

Introduction
Au terme de ce projet, nous nous sommes x comme objectif dajouter laspect de monitoring dans le Framework Palmyra de lentreprise avec un outil de supervision et de gestion de ressources. En fait, il ya dabord une phase danalyse qui permet de dterminer clairement ce que doit faire ce dernier. Cette phase est dlicate car cest elle qui va conditionner la bonne suite du projet et touche dune faon trs critique le fonctionnement ultrieur du produit. En effet, dans ce chapitre nous allons analyser dune faon plus dtaille les diffrents besoins dicts par le cahier des charges et les fonctionnalits que la solution doit offrir lutilisateur.
3.1
Etude des besoins
La phase dtude de besoins est une phase primordiale dans la ralisation de tout projet. Elle consiste questionner lutilisateur de base an dexprimer ses besoins sous forme prcise.
3.1.1
Besoins fonctionnels
Lobjectif de notre outil est de permettre lutilisateur du Palmyra davoir un systme qui lui permet de faire la supervision et la gestion des ressources des applications dployes sous les serveurs dapplications JBoss et Websphre. Le produit doit tre dot de moyens pour appeler, accder ces ressources et vice versa, et ce par linstrumentation de ces derniers. Ces ressources sont, en effet, les applications que le Framework Palmayra renferme, les services dinformations quil exploite et ses modules intgrs. 30
Amal Allagui
Loutil doit en outre, exposer certaines proprits relatives ces ressources dj cites via des services JMX. Dans cette partie, nous allons mettre laccent sur un ensemble de fonctionnalits que doit supporter notre futur logiciel, en fait ces fonctionnalits seront divises en module dont chacun est associ une ressource bien dtermine. La gure 3.1 ci-aprs donne un aperu gnral sur lensemble de modules de notre application.
F IGURE 3.1 Les differents modules de loutil de monitoring Nous allons, maintenant, dtailler les besoins fonctionnels relatifs chaque module : Module JVM Ce module doit permettre lutilisateur de monitorer dans la machine virtuelle des fonctionnalits, telque : La quantit de mmoire libre (en octets). La quantit de mmoire utilise (en octets). La quantit maximale de mmoire (en octets). Module Server Informations Dans cette section, loutil doit exposer des informations concernant le serveur sous lequel lapplication superviser est dploye, tel que :
Vermeg Services
31
CHAPITRE 3. ANALYSE ET SPCIFICATION DES BESOINS Le nom de la version du serveur. Le numro de la version du serveur. La description du systme dexploitation. Module JDBC
Amal Allagui
La console de monitoring doit permettre au utulisateurs de monitorer les pools de connexion aux bases de donnes pour chaque Datasource , savoir : Le nombre de connexions en cours dutilisation. Le nombre total de connexions. Le nombre maximum de connexions. Le nombre de connexions cres depuis le dernier appel. Le nombre de connexions fermes depuis le dernier appel. Module JMS Lutilisateur doit pouvoir monitorer pour chaque le dattente JMS : Le nombre dmetteurs dans la le. Le nombre de messages dans la le dattente. Le dernier appel. La taille de la le dattente. Le nombre de destinataires dans la le dattente depuis le dernier appel . Module EJB Ce module doit donner la possibilit de monitorer les EJB, savoir : Le nombre dinvocations de chaque EJB Module Thread Cette section permet de monitorer les pools de threads pour chaque application, savoir : Le nombre de threads actifs dans le pool. Le nombre de threads dans le pool. Le nombre maximum de threads actifs dans le pool. Module Cache Loutil doit offrir lutuisateur la possibilit de monitorer le mcanisme de mise en cache, notamment la mise cache dynamique pour chaque application, savoir les proprits suivantes : Vermeg Services 32
CHAPITRE 3. ANALYSE ET SPCIFICATION DES BESOINS La taille courante du cache en Ko. Le nombre de hit du cache depuis le dernier appel. Le nombre daccs au cache depuis le dernier appel. Module ORB Loutil doit offrir lutilisateur la possibilit de monitorer lORB.
Amal Allagui
Donc, notre solution doit essentiellement monitorer ces ressources, en permettant lutilisateur de visualiser, modier les paramtres, effectuer des oprations tel que lajout, la suppression, et encore la mise jour de ses proprits. Ces changements doivent aussi tre modliss en temps rel par des graphes, exposs sur les interfaces de la console.
3.1.2
Besoins non fonctionnels
En plus des besoins fonctionnels, loutil de resource monitoring est appel satisfaire les besoins non fonctionnels suivants : Ergonomie :Loutil doit fournir des interfaces implmentes par GWT facilitant la supervision et la manipulation des donnes, an que lutilisateur puisse lexploiter sans se rfrer des connaissances particulires. En dautres termes, les informations doivent tre lisibles et faciles accder par nimporte quel dveloppeur et les donnes doivent tre rafrachies avec une frquence adquate. volutivit : Loutil doit tre capable de subir des ventuelles extensions comme par exemple, lajout dun autre serveur dapplications. Fiabilit : Loutil doit rsister aux pannes et surmonter la sollicitation excessive. Le monitoring doit prendre en charge toute ressource grable (pas de limitation en nombre de ressources), aussi il doit tre en phase avec tout changement qui se produit (temps de rponse immdiat). La portabilit des modules sur nimporte quelle plateforme. Rapidit de la mise en place des services dentreprise. Respecter les standards le plus populaires sur le march. La facilit de lutilisation.
Vermeg Services
33
Amal Allagui
3.2
Etude dtaille
En premier lieu, nous dterminons les acteurs du systme qui bncient de ses fonctionnalits, puis nous allons prsenter les diagrammes de cas dutilisation de notre outil de supervision et par la suite on enchaine par les diagrammes de squences systme.
3.2.1
Cas dutilisations
Nous commenons par dnir les acteurs du systme qui bncient de ses fonctionnalits, puis nous prsentons les diagrammes des cas dutilisation globals, ensuite rafns de notre outil de supervision.
3.2.1.1
Identication des acteurs
Un acteur reprsente un rle jou par une personne ou une chose qui interagit avec un systme. Les acteurs se dterminent en observant les utilisateurs directs du systme, ceux qui sont responsables de son exploitation ou de sa maintenance, ainsi que les autres systmes qui interagissent avec le systme en question. La mme personne physique peut jouer le rle de plusieurs acteurs. Les acteurs dans notre cas sont de type utilisateur simple, nous distinguons un seul type dacteur : acteur principal qui est le superviseur. Ce superviseur est principalement un utilisateur dune application Palmyra et qui veut la superviser.
3.2.1.2
Cas dutilisation globale
Le diagramme reprsent dans la gure 3.2 ci-dessous dcrit les diffrentes oprations relatives lutilisateur lors de lexploitation de notre systme. En effet un utilisateur est oblig, tout dabord, de passer par une tape dauthentication sauthentier lapplication travers linterface Login.jsp au niveau de lapplication Palmyra X quil souhaite superviser. Une fois, cette tape est passe avec succs, lutilisateur peut donc accder notre outil de monitoring, ce fait est exprim avec le cas dutulisation Superviser lApplication Palmyra X . Ce dernier cas est gnrale, rellement, pres avoir pass par lacte dauthentication, lacteur il est pass automatiquement vers lun des deux cas dutulisation suivants : Superviser lApplication Palmyra X sous JBoss : si lapplication est dploye sous le serveur dapplication JBoss. Superviser lApplication Palmyra X sous Websphere : si lapplication est dploye sous le serveur dapplication Websphere.
Vermeg Services
34
Amal Allagui
Par la suite, il aura la possibilit daccder aux diffrentes fonctionnalits offertes par notre systme.
F IGURE 3.2 Diagramme de cas dutilisation globale du systme Dans la section suivante, nous allons rafner ce diagramme global, en mettant le point sur chaque cas dutilisation quil comprend.
3.2.1.3
Cas dutilisation rafns
Dans cette partie nous allons aborder une tude dtaille des cas dutilisations. Nous allons dcomposer chacun des deux cas dutilisation Superviser lApplication Palmyra X sous JBoss et Superviser lApplication Palmyra X sous Websphere, qui englobent des diffrentes tches de monitoring, en plusieurs cas dutilisations fonctionnels tudier pour comprendre le fonctionnement de notre projet. Ce pendant, pour le cas dutilisation sauthentier lapplication , nous allons le prsent textuellement. Le cas dutilisation sauthentier lapplication Vermeg Services 35
Amal Allagui
Nous allons expliciter lacte de lauthentication par une description textuelle reprsent dans le tableau suivant, an de bien comprendre la faon dont lacteur peut accder la console de supervision. Titre du cas dutilisation : sauthentier lapplication But : Accder une application Palmyra pour la superviser. Acteur : Superviseur. Pr condition : Entrer le login et le password. Enchanement : 1. Lacteur remplit les champs propres au login et password 2. La page Login.jsp, qui gre lauthentication propre lapplication Palmyra X, vrie ses donnes partir de la base de donnes. 3. La page Login.jsp valide les donnes. Flux de donnes dans le systme : Les champs propres aux login et password. Enchanement alternatif : 1. Les paramtres nont pas t correctement introduits par lutilisateur, 2. Le systme afche un message derreur. Post condition : Lacteur accde avec succs lapplication. Le cas dutilisation Superviser lApplication Palmyra X sous JBoss Le diagramme suivant dcrit le cas dutilisation Superviser lApplication Palmyra X sous JBoss, il rsume les diffrentes oprations relatives la supervision, ladministration et la gestion des diffrentes ressources (Queue, EJB, thread, etc) consommes par lapplication Palmyra cible dploye sous JBoss AS.
Vermeg Services
36
Amal Allagui
F IGURE 3.3 Diagramme de cas dutilisation Superviser lApplication Palmyra X sous JBoss Pour viter les redondances que les similitudes de traitements engendrent, nous nous limiterons expliciter un scnario de supervision type : Le cas dutilisation Superviser les Queues Palmyra Daprs le diagramme prcdent, plusieurs oprations de monitoring de ressources sont possibles. An de les expliquer, nous allons en prendre un cas Superviser les Queues Palmyra et lexpliciter dans le diagramme suivant, et pour les autres ressources, ils se traitent de la mme manire.
Vermeg Services
37
Amal Allagui
F IGURE 3.4 Diagramme de cas dutilisation Superviser les Queues Palmyra La supervision se droule comme suit, lutilisateur choisit les queues superviser, soit celles de Palmyra, soit celles propres son application. Dans ce scnario on traite le premier cas, il peut visualiser les paramtres puis les modier selon son choix. Ce scnario sera plus dtaill dans le tableau de la description textuelle ci-dessous.
Vermeg Services
38
Amal Allagui
Titre du cas dutilisation : Superviser les Queues Palmyra. But : Visualiser et modier les informations des queues Palmyra. Acteur : Superviseur. Pr condition : Lutilisateur sest authenti au niveau de lapplication quil veut la superviser. Enchanement : 1. Lacteur choisit le module de supervision des queues. 2. Il spcie la queue superviser. 3. Lacteur consulte les informations de la queue et choisit de modier quelques informations. 4. Le systme afche un message de conrmation. 5. Lacteur valide les changements. 6. Le systme enregistre les modications et informe lutilisateur. Flux de donnes dans le systme : Les paramtres modis. Enchanement alternatif : 1. Les nouvelles valeurs nont pas t correctement introduites par lutilisateur, 2. Le systme afche un message derreur. Post condition : Lacteur supervise les queues Palmyra avec succs. Le cas dutilisation Superviser lApplication Palmyra X sous Websphere Dans le cas ou lapplication Palmyra superviser est dploye sur le serveur dapplication Websphere, tous les scnarios possibles de resource monitoring seront dcrits dans le diagramme suivant :
Vermeg Services
39
Amal Allagui
F IGURE 3.5 Diagramme de cas dutilisation Superviser lApplication Palmyra X sous Websphere Nous allons entamer la mme dmarche que celle suivie dans le cas dutilisation prcdent, cest--dire on va dtailler encore ce diagramme et ce en rafnant le cas dutilisation Superviser les pools des connexions JDBC Palmyra . Pour le reste des cas, ils senchainent pareillement. Le cas dutilisation Superviser les pools des connexions JDBC Palmyra La gure 3.6 illustre ce rafnement.
Vermeg Services
40
Amal Allagui
F IGURE 3.6 Diagramme de cas dutilisation Superviser les pools des connexions JDBC Palmyra Le diagramme rsume les oprations, que nous pouvons leffectuer pour superviser les pools de connexions JDBC, qui sont la visualisation et la modication des paramtres. Le diagramme textuel suivant explique ce scnario.
Vermeg Services
41
Amal Allagui
Titre du cas dutilisation : Superviser les pools des connexions JDBC Palmyra But : Visualiser et modier les pools des connexions JDBC Palmyra. Acteur : Superviseur. Pr condition : Lutilisateur sest authenti au niveau de lapplication quil veut la superviser. Enchanement : 1. Lacteur choisit le module de supervision les pools des connexions JDBC Palmyra. 2. Il spcie le pool superviser. 3. Lacteur visualise les informations du pool et choisit de modier quelques informations. 4. Le systme afche un message de conrmation. 5. Lacteur valide les changements. 6. Le systme enregistre les modications et informe lutilisateur. Flux de donnes dans le systme : Les paramtres modis. Enchanement alternatif : 1. Les paramtres nont pas t correctement introduits par lutilisateur, 2. Le systme afche un message derreur. Post condition : Lacteur supervise les pools des connexions JDBC Palmyra avec succs.
3.2.2
Enchainement de scnarios systme
Cette partie est consacre la prsentation des diffrents scnarios modlisant laspect dynamique du systme et ses interactions avec les acteurs . Cette modlisation sera tablit travers les diagrammes de squences qui illustrent des scnarios de cas dutilisation.
3.2.2.1
Supervision de ltat de serveur
Dans le diagramme de squence de la gure 3.7 , nous allons dcrire le scnario qui permet un utilisateur de superviser ltat de serveur .
Vermeg Services
42
Amal Allagui
F IGURE 3.7 Diagramme de squence systmeSuperviser ltat de serveur Pour consulter ltat du serveur, lutilisateur doit tout dabord accder son application Palmyra pour quil puisse la superviser. En cas de succs dauthentication, lutilisateur clique sur un bouton pour superviser lapplication et en ce moment notre outil (Console JMX) se lance et afche ltat du serveur et les ressources surveiller.
3.2.2.2
Visualisation des informations des Queues
Le scnario qui permet un utilisateur de Visualiser les inforlations des queues sera labor dans le diagramme de squence de la gure ci-dessous.
Vermeg Services
43
Amal Allagui
F IGURE 3.8 Diagramme de squence systmeVisualiser les informations des queues Pour ce scnario et les autres, lutilisateur va toujours passer par le prcdent scnario Superviser ltat du serveur . Aprs avoir consult les ressources superviser, lutilisateur choisit de visualiser des informations dune queue, ce moment l notre console se connecte au serveur JMX du serveur dapplications o lapplication est dploye et elle rcupre ses informations puis elle les afche.
3.2.2.3
Modication des informations des Queues
Le droulement de lactivit Modier les informations des queues , sera voqu dans la gure suivante.
Vermeg Services
44
Amal Allagui
F IGURE 3.9 Diagramme de squence systmeModier les informations des Queue Palmyra Ce scnario seffectue aprs la consultation des informations dune queue par lutilisateur du systme. Cest ainsi que lutilisateur dcide de modier quelques informations. Avant lenregistrement des nouvelles valeurs, il rpond un message de conrmation afch par le systme en validant lopration. Enn, le systme se connecte au serveur JMX, enregistre les nouvelles informations et afche un message de succs.
3.2.2.4
Visualisation des pools de connexion JDBC
La gure 3.10 montre les diffrentes communications entre lacteur et le systme an de Visualiser les pools de connexion JDBC .
Vermeg Services
45
Amal Allagui
F IGURE 3.10 Diagramme de squence systmeVisualiser les pools de connexion JDBCL Pour ce scnario lutilisateur choisit de visualiser des informations dun pool de connexion, ce moment l notre console se connecte au serveur JMX du serveur dapplications o lapplication est dploye pour Pour rcuprer les informations puis elle les afche.
3.2.2.5
Modication des pools de connexion JDBC
Le droulement de lopration Modie les pools de connexion JDBC , sera illustr dans la gure 3.11 ci-aprs.
Vermeg Services
46
Amal Allagui
F IGURE 3.11 Diagramme de squence systmeModier les pools de connexion JDBCL Aprs avoir consult les informations dun pool de connexion, lutilisateur dcide de modier quelques informations. Avant lenregistrement des nouvelles valeurs, le systme demande lutilisateur de conrmer ces modications. Une fois il conrme, le systme se connecte au serveur JMX, enregistre les nouvelles informations et afche un message de succs. Comme nous lavons dcrit dans le chapitre introductif (chapitre1), nous avons adopt la mthodologie Scrum pour la ralisation de notre projet, puisquil est bas sur la notion ditration. En fait dans chaque itration, nous allons laborer un module, dont chacun traite un besoin fonctionnel bien dtermin (voir la gure 7.1). Par consquent, nous nous sommes inspirs de la mthode Scrum, car il est le mieux adapt notre systme et il aide concevoir chaque itration sparment. Pour notre projet, nous pouvons classer les rles de Scrum comme suit : Vermeg Services 47
CHAPITRE 3. ANALYSE ET SPCIFICATION DES BESOINS Product Owner (Directeur de Produit) : Mr Imed Ben MIMOUN. Scrum Master : Melle Amira ALOUI.
Amal Allagui
Developer team (lquipe) : Nous avons t intgrs dans lquipe Palmyra, qui nous a con llaboration de ces modules.
Conclusion
Tout au long de ce chapitre nous avons parcouru les diffrents besoins fonctionnels et non fonctionnels de notre outil. Nous avons spci les fonctionnalits offertes et expliqu le principe avec lequel tourne notre systme pour rpondre aux demandes du superviseur. Dans le chapitre suivant nous allons laborer une conception qui prparera la ralisation de notre solution de supervision.
Vermeg Services
48
CHAPITRE 4. CONCEPTION
Amal Allagui
Chapitre 4 Conception
Introduction
Aprs avoir ralis la spcication des besoins de notre systme et dgag toutes ses fonctionnalits, nous laborons dans le prsent chapitre notre schma conceptuel. Dans ce chapitre, deux vues conceptuelles seront dcrites, la premire donne une vue globale du systme et la deuxime une vue dtaille.
4.1
Conception gnrale
La conception globale permet de faire le choix darchitecture et de spcier les composants logiques ncessaires pour le fonctionnement de loutil, pour cette raison nous allons entamer ce chapitre par larchitecture gnrale de loutil.
4.1.1
Architecture du systme de monitoring
Notre application est la mise en uvre du Design Pattern MVC 2 reprsent dans la gure 4.1, cest un schma de programmation qui prend en compte toute larchitecture dun programme et classe les diffrents types dobjets qui composent lapplication dans 3 catgories : Les objets "View" Ils sont la vue de lapplication, linterface avec laquelle lutilisateur communique. Ils ne soccupent pas de la gestion ou du stockage des donnes puisque aucun traitement ne doit tre effectu dans cette partie mais afchent les rsultats provenant des objets " model " et sassurent que ces donnes sont correctement afches. 49
CHAPITRE 4. CONCEPTION Les objets "Model"
Amal Allagui
Ils reprsentent les donnes de lapplication et dnissent la logique de manipulation de ces donnes. Cest dans cette partie que vont seffectuer les traitements. Les objets "Controller" Cest ici que va se raliser linteraction entre les objets "View" et les objets "model". Ils reoivent les requtes utilisateur puis dtermine quelles parties des objets " view " et " model " sont requises. Ils constituent donc lintermdiaire entre les deux autres types dobjets.
F IGURE 4.1 Architecture MVC La seule diffrence entre le Design Pattern MVC et MVC2, cest que dans un modle MVC 2, il nexiste quun seul et unique contrleur rceptionnant toutes les requtes clientes[16]. Aprs avoir prsent ce Design Pattern, nous allons justier pourquoi nous lavons adopt dans notre application. En effet, les interfaces home machine avec lesquelles interagit lutilisateur dsignent les objets view, dautre part la partie responsable de traitement et du rcupration des donnes depuis et vers le serveur JMX situ dans le serveur dapplication sous lequel est dploye lapplication, constitue la partie Model et concernant le contrleur, nous avons une servlet qui soccupe de la synchronisation et linteraction entre ces deux dernires partie .
4.2
Conception dtaille
Dans ce qui suit nous allons dcrire plus en dtails la conception de notre application.
Vermeg Services
50
Amal Allagui
4.2.1
Diagramme de classes
Le diagramme de classes regroupe les diffrentes classes ncessaires limplmentation de notre systme et fera ainsi notre point de dpart pour le dveloppement. Dans cette partie, nous dcrivons dans un tableau lensemble des classes de notre application qui ont permis la mise en uvre des besoins. Ensuite nous prsentons notre diagramme de classes.
Vermeg Services
51
Amal Allagui
Classe ApplicationServer
Description de la classe
Classe mre des serveurs dapplications (JBossAS, WebspherAS) et reprsente leurs proprits communes.
JBossAS
Classe qui reprsente le serveur dapplication JBoss, ainsi que ses attributs et contient deux mthodes :
getJBossASAttribute:permet de rcuprer les

informations du serveur.
getJBossMBeanServerConnection : permet de
rcuprer une connexion du serveur JMX de JBoss.
WebsphereAS
Classe qui reprsente le serveur dapplication WebSphere ainsi que ses attributs et contient deux mthodes :
getWSMBeanServerConnection: permet de
rcuprer une connexion au serveur JMX de WebSphere.
getWebSphereASAttribute : permet de rcuprer

les informations du serveur.
Resources
Classe qui reprsente de quoi dispose lapplication Palmyra cible de supervision comme ressources. Elle contient une mthode getPalmyraResources qui permet de parcourirles chiers XML dune application Palmyra et rcuprer le nom du serveur dapplications dans lequel lapplication est dploye et aussi les noms des ressources tel que Queues, Sources des donnes, EJBs Stateless.
WebsphereResources
Classe qui reprsente les ressources du serveur WebSphere (DataSource, QueuePoint, DynamicCache. . . ).
JBossResources
Classe qui reprsente les ressources du serveur Jboss (JDBCConnectionPool, Queue, JMSConnectionPool. . . ).
Autre classes
Classes qui contiennent des attributs qui reprsentent les informations de chaque ressource et possdent chacune deux mthodes qui permettent soit de rcuprer les informations dune ressource, soit de les modier .
Vermeg Services
52
Amal Allagui
F IGURE 4.2 Diagramme de Classe
Vermeg Services
53
Amal Allagui
Les activits de ce systme et linteraction entre ses composants seront illustres travers des diagrammes de squences dans la partie suivante.
4.2.2
Enchainement des scnarios objet
Ltude des cas dutilisation nous a permis didentier les diffrents acteurs ainsi que leur manire dexploiter loutil de monitoring. Dans ce qui suit, nous allons reprsenter dune faon dtaille leur interaction avec les diffrents objets constituant le systme en utilisant les diagrammes de squence objet. Pour ce fait, nous allons reprsenter les scnarios les plus importants.
4.2.2.1
Visualisation des informations des pools des connexions JDBC
Le schma suivant reprsente le diagramme de squence dcrivant le scnario nominal du cas dutilisation Visualiser les informations des pools des connexions JDBC
Vermeg Services
54
Amal Allagui
F IGURE 4.3 Diagramme de squence du cas dutilisation Visualiser les informations des pools des connexions JDBC Dans ce scnario lutilisateur a choisit de superviser les pools des connections JDBC, dans un premier temps un appel de la mthode getPalmyraResources de la classe WebSphereResources est ncessaire pour afcher les sources des donnes surveiller. Ensuite, lutilisateur rcupre une connexion au serveur JMX du serveur WebSphere en appelant la mthode getWSMBeanServerConnection de la classe IBMWebSphereAS et enn, lutilisateur appelle la mthode getDataSourceAttribute de la classe DataSource pour rcuprer les informations de la source de donnes dj choisi.
4.2.2.2
Modication des informations des pools des connexions JDBC
Pour ce scnario, lutilisateur va modier des informations dune source de donnes aprs avoir visualiser ces informations en appelant la mthode setDataSourceAttribute de la classe DataSource. Vermeg Services 55
Amal Allagui
F IGURE 4.4 Diagramme de squence du cas dutilisation Modier les informations des pools des connexions JDBC
4.2.2.3
Visualisation des informations des Queues
La gure suivant reprsente le diagramme de squence dcrivant le scnario nominal du cas dutilisation Visualiser les informations des queues .
Vermeg Services
56
Amal Allagui
F IGURE 4.5 Diagramme de squence du cas dutilisation Visualiser les informations des queues Ce scnario suit la mme dmarche que celle du scnario Visualiser les informations des pools des connections JDBC prsent prcdemment, mais en rcuprant cette fois une connexion au serveur JMX du serveur JBoss et on appelant la mthode getQueueAttribute de la classe Queue.
4.2.2.4
Modication des informations des Queues
Ce scnario aussi suit les mmes dmarches que celles au scnario Modier les informations des pools des connexions JDBC , mais dans ce cas en se connectant au serveur JMX de JBoss avant que lutilisateur appelle la mthode setQueueAttribute de la classe Queue pour modier les informations dsirs.
Vermeg Services
57
Amal Allagui
F IGURE 4.6 Diagramme de squence du cas dutilisation Modier les informations des queues
4.2.3
Diagramme de dploiement
Nous allons dcrire limplantation physique ainsi que la rpartition des composantes logicielles de notre outil, grce au diagramme de dploiement reprsent dans la gure 4.7 ci-aprs.
Vermeg Services
58
Amal Allagui
F IGURE 4.7 Diagramme de dploiement Nous avons besoin dun diagramme de dploiement parce quil sert essentiellement dmontrer la disposition physique des ressources matrielles qui composent le systme et la rpartition des composants sur ces matriels. En fait, nous avons un serveur dapplication (WebsphereAS ou bien JBossAS) dans lequel lapplication Palmyra est dploye, ce fait est traduit dans la gure par le placement dun composant intitul Application Palmyra dans un nuds reprsentant le serveur dapplication. Dautre part, notre module de supervision qui est reprsent par le composant Console JMX, sera intgr dans les applications Palmyra, ce qui explique pourquoi nous avons plac ce composant dans celui de lapplication Palmyra. La console JMX est en relation avec un autre lment principal du serveur dapplications qui est le Serveur JMX pour lui fournir les donnes ncessaires auprs des Mbeans.
Vermeg Services
59
Amal Allagui
4.2.4
Diagramme de composants
F IGURE 4.8 Diagramme de composants La plateforme Palmyra est la base de dveloppement des produits Vermeg. Larchitecture de cette Framework prsente un systme orient service pour le dveloppement dapplications nancires. Loutil que nous allons le dvelopper va tre intgr dans ce Framework. Il va le donner un aspect de contrle et de supervision. Le diagramme ci-dessus montre que notre futur logiciel (composant en vert) va tre ajout aux autres composants Palmyra . En effet, ces derniers se sont les services fourni par cette Framework aux applications quelle gnre. Notre outil va permettre de superviser les ressources ( cache, queues, workow, etc) consommes par des composants Palmyra tels que Quartz, Lifecycle, IODevices dans les serveurs dapplications JEE
Conclusion
Tout au long de ce chapitre, nous avons tudi la conception de notre outil de supervision. Nous avons fourni, dans un premier temps, une conception globale travers des schmas gnrales Vermeg Services 60
Amal Allagui
dcrivant larchitecture de notre application qui bnce de la puissance du motif de conception MVC 2. Par la suite, nous avons dtaill la conception travers le diagramme de classes, quelques diagrammes de squence, un diagramme de dploiement et enn un diagramme de composants. Dans le chapitre suivant, nous dcrivons de faon dtaille la ralisation de loutil et nous exposons le travail ralis.
Vermeg Services
61
CHAPITRE 5. RALISATION, TEST ET INTGRATION
Amal Allagui
Chapitre 5 Ralisation, test et intgration

Introduction
Ce chapitre a pour objectif la mise en uvre de tout ce que nous avons conu. Cest la phase de ralisation, dintgration et de test qui nous met en contact rel avec lenvironnement de dveloppement tout en ayant recours aux ressources de Palmyra. Nous consacrerons la premire partie la prsentation de lenvironnement de dveloppement de lapplication demande. Puis, nous exposerons quelques interfaces qui concordent avec les fonctionnalits du systme ainsi que lintgration loutil de resource monitoring dans le Framework Palmyra. Enn, nous dcrirons les problmes rencontrs le long de ce projet ainsi que le chronogramme.
5.1
5.1.1
Environnement de travail
Choix technologiques
Dans cette partie nous allons argumenter les choix technologiques que nous avons fait. Langage JAVA Java est un langage de programmation informatique orient objet, riche en lments graphiques et il rpond nos besoins. Ce choix savre appropri vu que cette plate-forme garantit la portabilit des applications . GWT GWT (Google Web Toolkit) est un Framework open source dveloppe par Google utilisant la technologie AJAX pour dvelopper des sites Web dynamiques proches de la 62
Amal Allagui
philosophie Web 2.0. Ainsi, GWT nest pas un langage part entire mais une utilisation astucieuse du langage Java pour crer une interface graphique pour Internet ( loppos du Framework Swing qui permet de crer des interfaces graphiques en Java pour des applications bureautiques en local). Une partie du code Java tant ensuite compil et transform en code JavaScript pour tre embarqu sur un serveur web et excut par le client[17]. Ext GWT Ext GWT est une bibliothque Java pour crer des applications Internet riches avec GWT. Il adapte Extjs (Ext JavaScript) destination de GWT et fournit un grand nombre de composants[18].
5.1.2
Outils logiciels
Les outils logiciels qui ont permis la mise en place de notre systme de supervision sont les suivants : Magic Draw Dans la phase de conception, nous avons eu recours au Magic Draw. Cest un outil de modlisation UML. Eclipse Eclipse 3.6 a t choisie car cest une plate-forme libre, ouverte pour le dveloppement dapplications et extensible grce un mcanisme de plug-in. Palmyra 12 Cest le Framework de Vermeg Services dans sa version la plus rcente. Les outils de Palmyra qui ont servi dans la ralisation de notre application sont Prsentation et Palmyra Gnration Tool. Palmyra Code Generation Tool Loutil de gnration de code Palmyra est une application qui gnre un chier EAR partir du modle UML. Le chier ear est prt tre dploye dans un serveur dapplication. Loutil propose un assistant qui aide le programmeur dans le processus de gnration et afche tous les avertissements ou des erreurs qui se produisent pendant le processus.
Vermeg Services
63
Amal Allagui
5.2
Implmentation et intgration des modules
Lobjectif de notre projet est doffrir lutilisateur un service qui lui permet de faire la supervision et la gestion des ressources dune application Palmyra. Cette dernire est rellement dploye et distribue sous un serveur certi JEE sous la forme dun chier EAR qui est un chier Jar avec lextension .ear . Une application Palmyra est livre au client sous cette extension. Avant de dcrire la phase dintgration de notre outil dans le Framework, nous allons dcrire brivement la structure dun ear. Un chier ear contient dune part des modules JEE (voir gure suivante) et Dautre part Les descripteurs de dploiement (META-INF) qui permettent au serveur au moment de lexcution dutiliser les composants de manire adquate.
F IGURE 5.1 Architecture dun EAR Donc en pratique, notre produit (console de monitoring JMX) doit instrumenter, exposer, et grer les diffrentes ressources qui composent un EAR. Nous allons par la suite visualiser quelques imprimes cran pour donner une ide plus proche sur limplmentation des modules.
5.2.1
Prsentation des modules implments
La gure reprsente linterface daccueil de la console, la partie encadr en rouge numro 1 indique le type et disponibilit du serveur sur le quel lapplications et a t dploye Vermeg Services 64
Amal Allagui
Et la partie encadre en rouge numro 2 reprsente les diffrentes ressources consommes par cette application, en effet lutilisateur peut accder au module de chaque ressource en choisissant le lien appropri du menu se trouvant gauche de la page.
F IGURE 5.2 Interface daccueil JBoss Dans la gure 5.3 ci-dessus, nous avons choisit de donner un aperu sur linterface qui safche lutilisateur dans le cas de monitoring dune application dploye sur Websphere. La partie encadr numro 1 montre que le serveur nest pas dmarrer. Cest pour cette raison que les liens qui reprsentent les ressources gauche de la page sont dsactivs.
Vermeg Services
65
Amal Allagui
F IGURE 5.3 Interface daccueil WebSphere Dans les deux interfaces prcdentes, chaque module de supervision dune ressource (JVM, EJB, etc) est reprsent par un lien dans le menu gauche. Dans lannexe A, nous allons prsenter les interfaces qui illustrent le fonctionnement de chaque module.
5.2.2
Intgration des Modules
Loutil dvelopp, sujet de notre projet, doit tre intgr dans le Framework Palmyra ainsi faire appel au module prsentation de ce dernier. Le paragraphe suivant rsume les diffrentes tapes de lintgration de cet outil dans Palmyra. Le projet dvelopp est une application GWT qui sera intgre comme un Module GWT dans le Framework Palmyra. Pour que cette dernire puisse prendre en considration cette application, il faut tout dabord dnir un point daccs dans le Menu du Framework et cest en faisant appel dans notre code la classe Initializer de Palmyra et utiliser ses services pour quelle puisse charger le console de monitoring ds le dmarrage de lapplication superviser. Ensuite, dans le point dentre de lapplication GWT, nous avons instanci une classe qui hrite de la classe abstraite de palmyra PalmyraExternalScreen qui est une interface dvelopp par Vermeg Services 66
Amal Allagui
lquipe palmyra an de permettre lajout des modules externe et de dvelopper toutes ses mthodes. A partir de cette implmentation, lintgration est automatis par le code source Palmyra vue quelle est dj faite en GWT(couche prsentation). Enn nous avons fait des modications dans le code an dadapter le point dentre de notre projet GWT aux exigences de dveloppement impos par la couche prsentation de Palmyra. Ltape de lintgration est ralise avec succs. Dornavant, lors de la cration dune application Palmyra et grce notre module, lutilisateur aura le choix dy intgrer la console de monitoring.
5.3
Test et validation de loutil
Aprs avoir termin limplmentation et lintgration des diffrents modules de loutil, dans le Framework Palmyra, tout en respectant les fonctionnalits dgages, dans ce qui suit nous allons les tester. En effet, nous allons entamer cette partie par des tests de fonctionnalits, cest--dire Est ce que le logiciel fait ce quil est cens faire ? Pour ce faire, nous allons crer comme entre de test une application Palmyra ayant des ressources, telque : Les quatre sources de donns Palmyra. La queue par dfaut de Palmyra. Un EJB Stateless. Lors de la cration de cette application de test, nous avons choisit le service de monitoring qui est dsormais offert par le Framework grce notre outil. Une fois cette application est genere, nous allons dmarrer notre console de monitoring pour tester la supervision de ces ressources (voir gure 5.4).
Vermeg Services
67
Amal Allagui
F IGURE 5.4 le monitoring console integr dans les applications Palmyra Pour ce faire, nous allons prsenter ci-dessous quelques scnarios de supervision. La gure 5.5 ci-aprs montre la fentre qui safche sur lcran au dmarrage de la console. Lors du chargement, linterface de ce dernier afche ltat et le type du serveur dans lequel lapplication superviser est dploye et la liste des ressources quon peut monitorer.
Vermeg Services
68
Amal Allagui
Figure 5.5: Interface daccueil Une fois la console est charge, la slection dune ressource dans le menu gauche entraine le chargement de ses informations. Et cest ainsi que le superviseur pourra contrler, surveiller et grer les ressources et par la suite suivre le fonctionnement de son application. Dans ce qui suit, nous nous contentons de montrer un aperu sur 4 scnarios diffrents, au cours des trois premiers nous avons dploy notre entre de test sous JBoss AS et au cours de uatrime sur Websphere AS. Scnario 1 : Monitoring dun pool JDBC. Pour superviser des informations dun pool JDBC, lutilisateur doit, en premier lieu slectionner le lien appropri JDBC Resources du menu se trouvant gauche de la page, cet instant la console charge les diffrentes sources de donns (datasource) de lapplication et qui sont quatre (Voir Figure 5.6) :
Vermeg Services
69
Amal Allagui
Figure 5.6: Interface Liste des sources de donnes Ds quil slectionne dans le tableau une source de donnes, les informations du pool correspondant safchent (Voir Figure 5.7) .
Vermeg Services
70
Amal Allagui
Figure 5.7: Interface Monitoring dun pool JDBC Dans cette interface, lutilisateur peut visualiser les diffrentes informations concernant ce pool, et en modier quelques paramtres. Ensuite, pour enregistrer les nouvelles valeurs, lutilisateur doit cliquer sur le bouton Save et pour rinitialiser les valeurs il doit cliquer sur le bouton Reset . Un message de conrmation safche pour lutilisateur avant lenregistrement des valeurs pour valider ou annuler lopration (Voir la gure 5.8).
Vermeg Services
71
Amal Allagui
F IGURE 5.8 Interface Message de conrmation Scnario 2 : Monitoring des queues. Pour superviser les ressources JMS de son application, lutilisateur doit choisir le lien JMS , ensuite il slectionne le lien Queue pour que la liste des queues safche sur linterface de la console (voir gure 5.9).
Vermeg Services
72
Amal Allagui
F IGURE 5.9 Interface Listes des Queues Une fois, la liste est afche, lutilisateur peut slectionner la queue, quil veut la superviser. Et pour chaque Queue, lutilisateur peut visualiser ou effectuer des modications son choix.
La gure 5.10 ci-dessus montre linterface qui correspond lafchage des informations de queue slectionn.
Vermeg Services
73
Amal Allagui
F IGURE 5.10 Interface Monitoring dune queue Lutilisateur peut grer la queue en modiant des valeurs. Pour y faire il doit conrmer le message qui safche au moment de lenregistrement. Scnario 3 :Monitoring des Threads. La console permet lutilisateur de visualiser aussi les threads grce cette charte graphique o les informations sont actualises en temps rels (voir gure 5.11).
Vermeg Services
74
Amal Allagui
Figure 5.11: Informations sur les threads Scnario 3 :Visualiser la mmoire de la machine virtuel Java (JVM). Pour afcher des informations sur la mmoire JVM, lutilisateur slectionne llment JVM Information dans le menu (Voir la gure 5.12) .
Vermeg Services
75
Amal Allagui
Figure 5.12: Interface Informations sur la mmoire JVM Pour enregistrer les nouvelles valeurs, lutilisateur doit cliquer sur le bouton Save et pour les rinitialiser il doit cliquer sur le bouton Reset . Un message de conrmation safche avant lenregistrement des valeurs pour valider ou annuler lopration (Voir la gure) .
An de garantir plus de robustesse pour notre code, de sassurer de son comportement, ainsi du bon fonctionnement des mthodes que nous avons implment, nous avons effectus des tests unitaires avec JUNIT 4. En effet, le test unitaire est un procd permettant de sassurer du fonctionnement correct dune partie dtermine dun logiciel ou dune portion dun programme . Nous avons crit des tests unitaires pour confronter ce que nous avons implment ce que nous avons spci. Et pour ce faire, nous avons utilis JUNIT comme bibliothque de test unitaire pour le langage de programmation Java. Elle nous permet de dvelopper des stratgies de tests pour nos applications. Dautre part , dans le but damlioration gnrale de la qualit du notre logiciel , nous avons effectu des test avec Sonar, qui est un logiciel open source permettant de mesurer la qualit du code source sur les projets de dveloppement java.
Vermeg Services
76
Amal Allagui
5.4
Problmes rencontrs
Vue sa richesse, nous avons mis beaucoup de temps pour se familiariser avec Palmyra. Nous avons eu quelques difcults lors de lintgration de notre outil de monitoring dans ce Framework, mais nous avons pu les surmonter.
5.5
Chronogramme
La gure 5.13 illustre la rpartition des diffrentes tches menes au cours du stage Ce projet a dmarr le 16 fvrier 2011. Nous avons commenc tout dabord par une tude de lexistant pour comprendre le travail demand et les besoins pour dbuter, accompagne par une phase de documentation sur les technologies utiliser. Suite la comprhension du sujet trait, nous avons dgag les spcications fonctionnelles et non fonctionnelles. Ensuite, nous avons pass la phase de conception et de limplmentation et le test des modules. Le chronogramme ci-dessous permet de dtailler les dfrentes tches effectues au cours du stage.
F IGURE 5.13 Chronogramme
Conclusion
Dans ce chapitre, nous avons donn un aperu de lenvironnement de travail. Puis, nous avons expos les choix technologiques et des outils pour lesquels nous avons opt an dimplmenter notre outil. Nous avons prsent les tapes de ralisation de notre outil de supervision. Nous avons expliqu chacune des phases dimplmentation, dintgration et de test de la solution mise en place. Vermeg Services 77
CONCLUSION GENERALE
Amal Allagui
Conclusion gnrale
e monitoring applicatif est un outil trs puissant reprsentant lagglomration et la corrlation des composantes ncessaires la livraison et lopration dune application dans un milieu dentreprise. Une organisation oprant dans ce domaine doit pouvoir quantier la disponibilit et la performance des applications quelle offre ses clients. Ces donnes serviront entre autre ltablissement et la maintenance dententes de niveaux de service, la planication de capacit et la gestion de performance ainsi que des attentes des usagers, sans mentionner les bnces potentiels au niveau de lalignement plus intime entre les applications utilises et les objectifs daffaires.
Lobjectif de ce projet de n dtudes dingnierie en informatique est la ralisation dune telle solution de supervision applicative pour lentreprise Vermeg Services . Pour aboutir ce rsultat, nous avons, tout dabord, commenc par une tude thorique au cours de laquelle nous avons prsent les serveurs dapplication, puis le concept de ressource monitoring. Ensuite, nous avons donn un aperu sur lAPI JMX jouant le rle de support technologique de notre solution. Cette tape est suivie dune analyse des besoins de lentreprise, leurs conception globale et dtaille. Finalement, nous avons dcrit ltape de ralisation qui traduit notre modlisation conceptuelle en une implmentation physique et qui sachevait avec des tests pour conrmer la rponse aux besoins fonctionnels de lentreprise. Ce stage effectu au sein de lentreprise Vermeg Services a t trs enrichissant du point de vue technique et relationnel. En effet, le dveloppement de ce projet nous a permis de nous familiariser davantage avec les serveurs dapplications JEE (JBoss et Websphere) ainsi que dapprofondir nos connaissances en termes de programmation Java, Framework GWT et de maitriser la nouvelle technologie JMX. Ce travail a accompli ses objectifs spcis, notre outil reprsente un atout dans le systme dinformation de lentreprise puisque il permet la supervision et la gestion des ressources des applications mtiers ainsi que leur disponibilit.
78
CONCLUSION GENERALE
Amal Allagui
Toutefois, il est signaler que la ralisation et lintgration de notre outil de monitoring ne signie pas quil nest pas susceptible tre amlior. En effet, Palmyra utilise aussi Weblogic comme serveur dapplications, et vue que notre projet se caractrise par lextensibilit, nous pouvons ltendre par un module de supervision des applications Palmyra dployes sur ce serveur. Dautre part cette plateforme possde de nombreux et de diffrents composants, de ce fait nous pouvons ajouter dautres modules qui supervisent les ressources consommes par ces derniers.
Vermeg Services
79
REFERENCES
Amal Allagui
Rfrences
[1] [2] Vermeg Services, Rapport technique Vermeg. Nada Almasri, Modle dadministration des systmes distribus base de composants, Institut national des sciences appliqus de Lyon, Thse de doctorat, 25/03/ 2005. Henrik Kniberg, Scrum et XP depuis les tranches, Enterprise Software Development, 2007. Jrme Molire, Cahiers du Programmeur J2EE, EYROLLES, 2005. Franck Simon, JBoss Dveloppement, dploiement et scurisation dapplications JEE, Editions ENI, Dcembre 2008. URL: http://community.jboss.org/wiki/JMXConsole, 27/03/2011. Dernire visite: le
[3]
[4] [5]
[6]
[7]
Websphere Aplication Server V7 : Administration consoles and commands, IBM Corp, 2009. SUN, URL: http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html, Dernire visite : le 24/03/2011. URL: http://www.jboss.org/jopr, Dernire visite : le 02/05/2011. Blair Hester, HQ Documentation, 10/11/ 2010. Calude Delanoy, Programmer en Java, EYROLLES, 2008 . Selim Kebir, Administration des ressources avec JMX, 10/10/ 2008. BEN G. SULLINS et MARK B. WHIPPLE, JMX in Action, Manning Publications Co, 2003. http://publib.boulder.ibm.com, Dernire visite : le 20/04/2011. URL:http://www.sencha.com, Dernire visite : le 11/05/2011. 80
[8]
[9] [10] [11] [12] [13]
[14] [15]
REFERENCES [16] [17] [18] Baptiste Wicht, Implmentation du pattern MVC, 24/04/2007.
Amal Allagui
Daniel Vaughan, Ex GWT 2.0, Packt Publishing Ltd, Novembre 2010. URL:http://www.sencha.com, Dernire visite : le 11/05/2011.
Vermeg Services
81
Annexe A
Amal Allagui
Annexe A
Nous allons prsenter dans cet annexe les imprimes crans relatifs aux scnarios de supervision des diffrents ressources. Module Thread Pour afcher les informations des threads, lutilisateur slectionne llment Thread dans le menu. La gure ci-dessous intitule Informations sur les threads1 reprsente linterface qui donne des informations sur les threads dune application dploye sous JBoss AS.
Figure A.1 : Interface Informations sur les threads1
82
Annexe A
Amal Allagui
Par contre, les 3 gure ci-aprs reprsentent les interfaces qui permettent au superviseur de contrler, superviser et grer respectivement 3 types de threads ORB Thread Pool, HAManager Thread Pool et TCPChannel DCS Thread Pool dune application dploye sous Websphere .
Figure A.2 : Interface Monitoring des ORB Thread Pools
Vermeg Services
83
Annexe A
Amal Allagui
Figure A.3 : Interface Monitoring des HAManager Thread Pools
Figure A.4 : Interface Monitoring desTCPChannel DCS Thread Pools Vermeg Services 84
Annexe A Module EJB
Amal Allagui
Pour afcher les informations des EJB, lutilisateur slectionne llment EJB dans le menu. Ensuite , il aura le choix de monitorer soit les pool EJB (voir gure A.5) Stateless, soit les pools MDB (voir gure A.5).
Figure A.5 : Interface Monitoring des EJB Stateless Pools
Vermeg Services
85
Annexe A
Amal Allagui
Figure A.6 : Interface Monitoring des Message Driven Bean Pools Module Server Informations A travers cet interface, lutilisateur peut superviser et consulter des informations sur le serveur sous lequel lapplication est dploye.
Vermeg Services
86
Annexe A
Amal Allagui
Figure A.7 : Interface Information sur le serveur Module Cache La console offre aussi lutilisateur de controler le fonctionnement du cache pour les applications dployes sur JBoss et la mise en cache dynamique pour celles dployes sur Websphere.
Vermeg Services
87
Annexe A
Amal Allagui
Figure A.8 : Interface Information sur le Cache Dynamique
Vermeg Services
88

RapporT Allagui AMAL

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

RapporT Allagui AMAL

Загружено:

Авторское право:

Доступные форматы

Remerciements

Liste des abrviations

TABLE DES MATIRES

Table des matires

Le Framework PALMYRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 1.2.2 1.2.3 1.2.4 Dnition dun Framework . . . . . . . . . . . . . . . . . . . . . . .

Le Framework PALMYRA . . . . . . . . . . . . . . . . . . . . . . Architecture de PALMYRA . . . . . . . . . . . . . . . . . . . . . . . Environnement de dveloppement . . . . . . . . . . . . . . . . . . . .

TABLE DES MATIRES 1.3.1 1.3.2 1.3.3 1.4

Problmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Etude et critiques de lexistant . . . . . . . . . . . . . . . . . . . . . . Solutions et objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . .

Etat de lart 2.1

Synthse des ressources superviser

Java Management Extension( JMX ) . . . . . . . . . . . . . . . . . . . . . . . 24 2.3.1 2.3.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

TABLE DES MATIRES 3 Analyse et Spcication des besoins 3.1

Conception gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.1.1 Architecture du systme de monitoring . . . . . . . . . . . . . . . . . 49

4.2.2.3 4.2.2.4 4.2.3 4.2.4

Diagramme de dploiement . . . . . . . . . . . . . . . . . . . . . . . 58 Diagramme de composants . . . . . . . . . . . . . . . . . . . . . . . . 60

TABLE DES MATIRES 5 Ralisation, test et intgration 5.1

Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.1.1 5.1.2 Choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Implmentation et intgration des modules 5.2.1 5.2.2

Prsentation des modules implments . . . . . . . . . . . . . . . . . 64 Intgration des Modules . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.3 5.4 5.5

Test et validation de loutil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Problmes rencontrs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 78 80 82

Conclusion gnrale References Annexe A

TABLE DES FIGURES

Table des gures

JMX dans larchitecture de JBoss . . . . . . . . . . . . . . . . . . . . . . . . . 27

TABLE DES FIGURES 3.8 3.9

Diagramme de squence systmeVisualiser les informations des queues

Diagramme de squence systmeModier les informations des Queue Palmyra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 46

3.10 Diagramme de squence systmeVisualiser les pools de connexion JDBCL

5.12 Interface Informations sur la mmoire JVM . . . . . . . . . . . . . . . . . 76 5.13 Chronogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

LISTE DES TABLEAUX

Liste des tableaux

Tableau comparatif entre les outils de monitoring existants sur le march

Les composants de larchitecture JBossAS . . . . . . . . . . . . . . . . . . . . 27

Liste des Abrviations

CHAPITRE 1. CADRE GNRAL DU PROJET

Chapitre 1 Cadre gnral du projet

Prsentation de lentreprise daccueil

Lorganisation de Vermeg Services

CHAPITRE 1. CADRE GNRAL DU PROJET Dpartement Commercial.

F IGURE 1.1 Organigramme de lentreprise

Les activits de Vermeg Services

Les produits de Vermeg

CHAPITRE 1. CADRE GNRAL DU PROJET

Les clients de Vermeg

CHAPITRE 1. CADRE GNRAL DU PROJET

CHAPITRE 1. CADRE GNRAL DU PROJET

CHAPITRE 1. CADRE GNRAL DU PROJET

Etude et critiques de lexistant

CHAPITRE 1. CADRE GNRAL DU PROJET

F IGURE 1.3 La solution propose Vermeg Services 9

CHAPITRE 1. CADRE GNRAL DU PROJET

Introduction la mthodologie Scrum

Le choix de la mthodologie Scrum

CHAPITRE 1. CADRE GNRAL DU PROJET

CHAPITRE 2. ETAT DE LART

Chapitre 2 Etat de lart

F IGURE 2.1 Elments de resource monitoring

Les serveurs dapplications

CHAPITRE 2. ETAT DE LART

CHAPITRE 2. ETAT DE LART

CHAPITRE 2. ETAT DE LART

TABLE 2.2 Les services de communication

Les serveurs dapplication tudis