RapporT Allagui AMAL

Remerciements

C

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

ResumPour faire face la complexit croissante des systmes informatiques, de nombreux travaux etrecherches 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 .

AbstractInorder 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 abrviationsUMLJEE 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

2

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

4

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 gures1.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

x

LISTE DES TABLEAUX

Amal Allagui

Liste des tableaux2.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 gnralee 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.

D

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

2

CHAPITRE 1. CADRE GNRAL DU PROJET

Amal Allagui

Chapitre 1 Cadre gnral du projetIntroductionAu 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.21.2.1

Le Framework PALMYRADnition 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

6


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.31.3.1

Prsentation du travailProblmatique

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.

ConclusionCe 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 lartIntroductionNotre 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.12.1.1

Les serveurs dapplicationsJEE 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].

ConclusionNous 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 besoinsIntroductionAu 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.

ConclusionTout 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 ConceptionIntroductionAprs 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 classeClasse 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 lesinformations du serveur.

getJBossMBeanServerConnection : permet dercuprer 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 dercuprer une connexion au serveur JMX de WebSphere.

getWebSphereASAttribute : permet de rcuprerles 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, wor

Documents

RapporT Allagui AMAL