TELECOM SUDPARIS
VAP : ARCHITECTE DE SERVICES EN RESEAU
Rapport de projet de fin d’études
Comparaison et évaluation de serveurs d'applications Java
Sarafou BALDE Muqiu ZHENG
Encadrante: Mme Sophie CHABRIDON
Le 26 Janvier 2011
2
Sommaire
I. Introduction ... 3
II. Etude et mise en œuvre de la spécification des EJB 3.0 ... 4
1. Quelques éléments sur les EJB ... 4
2. Quelles sont les évolutions apportées par les EJB 3.0 ... 5
3. La mise en œuvre des EJB : les serveurs d’applications ... 5
III. L’application Mailbox ... 6
1. Description de l'architecture de l'application Mailbox ... 6
2. Mise en œuvre de la solution ... 7
IV. Déploiement sous Glassfish ... 9
V. Déploiement sous JonAS ... 11
1. Le serveur Jonas ... 11
3. Installation et configuration de JonAS ... 12
4. Développement du Mailbox sous JonAS ... 15
VI. Déploiement sous SPRING ... 21
1. Introduction au Spring Framework ... 21
5. Solutions proposées de déploiement ... 22
VII. Comparaison de performances ... 27
6. Glassfish VS Jonas ... 27
7. Spring VS EJB ... 33
VIII. Management de Projet ... 36
IX. Bilan ... 38
X. Références ... 39
3
I. Introduction
Les serveurs d’applications Java EE ont eu un grand succès ces dernières années notamment dans le monde professionnel. Ils occupent une place de choix dans les systèmes d’information des entreprises.
Ce succès est dû à plusieurs raisons :
Le langage JAVA s’est peu à peu imposé comme un langage robuste et facile à maintenir
Les systèmes d’informations devenant de plus en plus complexes, les communications inter-applications s’accroissent, d’où un fort besoin d’intégration
La centralisation de la « logique » métier facilite les mises à jour et garantit la même version applicative à tous les utilisateurs (pas de risque de vieilles versions de données ou de codes sources pouvant amener une incompatibilité entre les applications)
Le découpage des applications en plusieurs « couches » permet d’augmenter la sécurité. Ainsi les accès sont gérés de manière centrale et les clients n’accèdent pas directement à la couche de données.
Les serveurs d’applications proposent également une bonne gestion de charge.
En effet ils offrent une souplesse dans la répartition et la gestion des traitements avec notamment la possibilité de déployer les traitements dans un environnement distribué.
Surfant sur cette vague plusieurs acteurs se sont lancés dans le développement de serveurs d’applications Java EE. Les éditeurs absents sur ce créneau tentent aujourd’hui de combler leur retard en orientant une partie de leur stratégie vers la proposition de solutions de cloud computing et de virtualisation. C’est ainsi que nous avons assisté récemment à la transformation du marché des serveurs d'applications Java EE qui mettent en œuvre la spécification des EJB 3.0. Avec le rachat de SUN par Oracle, le serveur d’applications Glassfish a ainsi changé de mains. Du coté de l’Open source, il y a également des avancées avec la solution JonAS du consortium OW2 qui enrichit son offre en intégration et architecture orientée services.
Les « concurrents » de la spécification des EJB3 ne sont pas en reste avec le rachat de SpringSource, fournisseur de la plate-forme Spring, par VMWare à l'été 2009.
Notre projet de fin d’études s’inscrit dans ce cadre et a plusieurs objectifs, qui sont :
Etudier la spécification des EJB 3.0
Prendre la main sur les serveurs d’application Java EE Glassfish et Jonas ainsi que le Framework Spring
4
Spécifier une application de taille significative et la développer sur chacune des ces trois plates formes
Faire une comparaison qualitative et quantitative entre les trois plates formes (Glassfish, Jonas et Spring)
II. Etude et mise en œuvre de la spécification des EJB 3.0
Dans cette partie nous présentons les plus importantes évolutions de la spécification des EJB (2.0 vers 3.0). Avant d’aborder ces évolutions, nous allons répondre à la question : C’est quoi un EJB ?
1. Quelques éléments sur les EJB
La technique Enterprise JavaBeans (EJB) est une architecture de composants logiciels côté serveur pour la plateforme de développement Java EE. Cette architecture propose un cadre pour créer des composants distribués (c’est-à-dire déployés sur des serveurs distants) écrit en langage de programmation Java et hébergés au sein d'un serveur applicatif permettant de représenter des données (EJB dit entité), de proposer des services avec ou sans conservation d'état entre les appels (EJB dit session), ou encore d'accomplir des tâches de manière asynchrone (EJB dit message). Tous les EJB peuvent évoluer dans un contexte transactionnel1. Les EJB permettent aux développeurs d’éviter à se préoccuper de tout ce qui a trait au système (transactions, sécurité, persistance, …). Pour être déployés, les EJB ont besoin d’un conteneur qui est souvent intégré dans les serveurs d’applications. Les EJB représentent une brique maîtresse de la plate-forme Java EE.
Figure 1 - Architecture 3 tiers
1 http://fr.wikipedia.org
5
2. Quelles sont les évolutions apportées par les EJB 3.0
La version 3.0 de la spécification des EJB ont apporté une révolution dans la manière de développer des applications Java EE par rapport aux versions précédentes. Nous allons citer quelques unes parmi les plus importantes.
a) La gestion des EJB de type Session
Les EJB de type Session, conçus pour encapsuler le logique métier, constituent l’un des deux types d’EJB. La gestion des EJB de type Session (Stateless et Stateful) se faisait au travers de fichiers XML, grâce à l’apparition des annotations dans Java EE 5, cette gestion se fait de manière très simple (utilisation des annotations @Stateless et @Stateful).
b) La persistance
L’une des critiques les plus virulentes sur les EJB 1 et EJB 2 est la complexité de la gestion de la persistance. La persistance consiste à associer un objet à un modèle relationnel dans une base de données2. Les EJB 3 ont apporté une solution à ce problème avec la spécification JPA (Java Persistance API) qui remplace avantageusement CMP (Container Managed Persistence) qui était la solution sous EJB 2.0. Cette API a plusieurs implémentations dont la plus connue est Hibernate. L’annotation @Entity permet de spécifier qu’une classe doit être persistée par JPA.
3. La mise en œuvre des EJB : les serveurs d’applications
Nous avons vu que pour fonctionner, les EJB ont besoin d'un conteneur qui est généralement intégré dans un serveur d'applications. La figure 2 montre l'architecture d'un serveur d'application.
Le serveur d'applications est un logiciel d'infrastructure offrant un contexte d'exécution pour des composants applicatifs3. Ils implémentent:
la logique métier de l'application grâce aux EJB
Une couche de persistance (JPA,...)
Un moteur de servlets
des composants de connexions et de communication (JNDI, JDBC, JMS, Java RMI, Java IDL...)
2 www.developpez.com
3 http://fr.wikipedia.org/wiki/Serveur_d'applications
6 Figure 2 Serveur d'applications
III. L’application Mailbox
L'un des objectifs du projet est de développer une application de taille significative sur trois plateformes. L'application que nous avons développé un gestionnaire de mail (Mailbox manager). Cette application doit pouvoir gérer des boites mails et proposer une interface de gestion des différents utilisateurs. Les utilisateurs doivent pouvoir envoyer des messages, lire des messages, effacer des messages, etc. L'administrateur du Mailbox doit pouvoir ajouter un utilisateur, modifier les droits d'un utilisateur (lecture, écriture de messages ou de news). L'application Mailbox manager doit en outre être multi-tiers.
1. Description de l'architecture de l'application Mailbox
Pour réaliser l'architecture proposée dans le sujet (voir figure 3), nous avons développé l'application en utilisant la technologie Java EE.
7 Figure 3 - Architecture proposée
L'application est constituée de 3 "couches" (3-tiers):
- Une couche client ou couche présentation constituée par une interface client et une interface administrateur. Cette couche permet d'interagir avec l'application et met à disposition des utilisateurs un certain nombre d'opérations.
- Une couche "traitement des données" qui correspond à la mise en œuvre de l'ensemble des règles métiers de l'application.
- Une couche "données" qui permet le stockage persistant des données.
Pour stocker les données, nous avons utilisé une base de données MySQL fournie par l’école.
2. Mise en œuvre de la solution
Dans cette partie, nous allons décrire la solution nous avons mis en œuvre dans le projet.
c) Les clients
Pour accéder aux différentes fonctions du Mailbox manager, l'application propose deux interfaces: une interface utilisateur et une interface administrateur.
L'interface utilisateur:
Cette interface est obtenue en lançant le client utilisateur (MailBoxClient). Elle est accessible après une authentification de l'utilisateur (login et mot de passe) et permet la gestion des messages à travers les opérations telles que:
- Envoyer un message - Lire un message
8
- Envoyer une news
- Afficher les messages non lus - Supprimer un message - etc..
L'interface administrateur
On y accède en lançant le client administrateur (AdministratorClient). Pour simplifier la gestion, ce client ne nécessite pas d'authentification. Cette interface permet de gérer les utilisateurs du MailBox. L'administrateur peut notamment:
- Ajouter un utilisateur
- Modifier les droits d'un utilisateur (lecture, écriture message ou lecture, écriture news...) - Supprimer un utilisateur
- etc.
d) Les composants coté serveur
Coté serveur, nous avons deux classes (MailBoxManagerBean et DirectoryManagerBean) implémentant les interfaces (MailBoxManager et DirectoryManager). Ces deux classes implémentent l'ensemble des fonctionnalités offertes par l'application, elles mettent donc en œuvre les opérations mises en visibilité aux utilisateurs et aux administrateurs.
e) Le stockage des données
Pour la persistance des données, nous avons mis en place deux classes pour décrire les tables dans la base de données à distance.
User: qui contient les informations de l'utilisateur (login, mot de passe, droits....) et les fonctions de traitement de ces données. L’annotation @OneToMany indique que un utilisateur sera relié aux plusieurs messages.
Message: qui est la classe qui traite deux type de message : mail et news. Il contient notamment les données des messages : sujet, corps du message, type du message, date du message, envoyeur, receveur, variable pour savoir si le message a été lu, etc.
Ci-dessous (Figure 4) un aperçu de la base de données créée lors du déploiement, les clés primaires des tables sont générées automatiquement.
Figure 4 - Aperçu de la table
9
IV. Déploiement sous Glassfish
Nous avons commencé notre développement sous Glassfish. GlassFish est le nom du serveur d'applications Open Source Java EE 5 et désormais Java EE 6 avec la version.
Dans cette partie, nous allons décrire comment déployer ce programme sous Glassfish.
f) Installation et configuration du Glassfish 1 Télécharger GlassFish 3.0.1 en utilisant le lien:
https://download.java.net/glassfish/3.0.1/release/glassfish-3.0.1.zip 2 Extraire le fichier zip.
3 Configurer les variables d’environnement comme $GLASSFISH_HOME et $CLASSPATH pour faciliter le travail sous Glassfish.
4 Lancer le Glassfish avec la commande : asadmin start-domain domain1, puis rendez- vous sur le lien http://localhost:8080. S’il fonctionne bien, la page suivante doit être affichée.
Figure 5 - Serveur Galassfish sur localhost
5 Configurer la source de base de données du Glassfish sur le lien : http://localhost:4848.
Créer un « JDBC connection pool » en donnant le nom de base de donnée, le URL, le nom du serveur, l’utilisateur et le mot de passe. Et puis créer une nouvelle JDBC ressource en utilisant ce pool.
10 Figure 6 - page de configuration de la base
g) Déploiement de l’application
Cette version de Glassfish nous permet de beaucoup simplifier la procédure de déploiement des applications. On n’a plus besoin d’autre descripteur comme ejb-jar.xml, qui est nécessaire pour la version précédente.
L’arborescence du projet est comme suivant :
src : qui contient tous les source Java donc il y a trois paquets.
META-INF : qui contient un descripteur persistence.xml. Ce fichier contient la configuration de base pour le mapping notamment en fournissant les informations sur la connexion à la base de données à utiliser.
11
client / ejb / entity : qui ont été créés par le compilateur ou on met les classes.
build.xml : qui le descripteur de l’outil de construction Ant. Il nous permet de compiler, deployer et exécuter l’application.
V. Déploiement sous JonAS
Dans cette partie, nous traitons du développement de l’application Mailbox sou Jonas.
1. Le serveur Jonas
JonAs (Java Open Application Server) est un projet Open Source développé au sein du consortium OW2 (INRIA, BULL, France Telecom). JOnAS est certifié Java EE 5 depuis 2009. La version que nous avons utilisée dans notre projet est la 5.1.5
a) Basé sur OSGi
La nouvelle architecture JOnAS 5 s'appuie sur un modèle de composants OSGi.
Figure 7 - Architecture JonAS basé sur OSGi4
4 http://wiki.jonas.ow2.org
12
JOnAS est un ensemble de bundles OSGi, les services techniques sont des services OSGi.
Dans cette nouvelle architecture, il est facile de remplacer ou d’implémenter un service.
Les services peuvent être démarrés, arrêtés ou reconfiguré alors que le serveur est en exécution.
b) JonAS 5 intègre un conteneur pour les EJB 3.0
JOnAS fournit toutes les ressources nécessaires pour mettre en œuvre les EJB 3.0 (et pour Java EE 5 en général). Il inclut:
Un conteneur EJB 3 (Easybeans, développé au sein du consortium OW2 )
Un conteneur Web (Tomcat ou Jetty)
Plusieurs protocoles RMI (IIOP, JRMP, Irmi) sont également supportés
Une implémentation Open source de JMS (JORAM 5) c) Gestion du serveur
JonAS embarque une console Web pour la configuration du serveur, le déploiement d’applications, etc.
Figure 8 - Console d'administration de JonAS
3. Installation et configuration de JonAS
Une fois que le serveur d’application JonAS est téléchargé5, un certain nombre de variables doivent être configurés (JONAS_ROOT et JONAS_ROOT /bin doivent être mises dans le PATH).
Structure du projet JonAS :
5 http://wiki.jonas.ow2.org/xwiki/bin/view/Main/Downloads
13
Tous les fichiers de configuration de JonAS sont dans le répertoire conf. Ils peuvent être modifiés mais cela va impacter toutes les applications déployés sur JonAS, ce qui peut être un inconvénient car toutes les applications n’utilisent pas forcément la même base de données, ni le même protocole d’appels d’objets. C’est pour cette raison que les concepteurs du projet JonAS ont pensé à permettre la création d’un environnement spécifique pour la configuration et le déploiement des applications tournant sur JonAS : ce environnement est créé à travers des scripts présents dans JONAS_ROOT/bin et configuré via la variable JONAS_BASE.
JONAS_ROOT
deploy bin conf
libs templates
examples logs Repositories
JONAS_BASE
deploy lib conf work
logs Repositories
14
En plus de la création de la JONAS_BASE, on a également dans le cadre de ce projet, fait un certain nombre de choix au niveau de certains paramètres de JonAS.
- le protocole jrmp pour les échanges via RMI, ce protocole est plus efficace qu’IIOP pour les échanges Java-Java (c’est-à-dire à la fois le client et le serveur doivent être codés en Java). Jonas permet la modification de ce protocole à l’intérieur même du code de l’application. Pour cela il suffit d’intégrer le fichier carol.properties à la base du projet et de modifier la ligne
# jonas rmi activation (iiop, irmi, jrmp) carol.protocols=jrmp
- Compte tenu des choix techniques que nous avons fait pour l’implémentation de l’application Mailbox, nous avons du paramétrer JonAS afin qu’il fonctionne avec une base de données MySQL. Pour cela, il faut :
Mettre le connecteur MySQL dans les librairies de JONAS_BASE
Configurer le fichier jonas.properties en modifiant les lignes
Activation du service de base de données:
jonas.services jtm,dbm,security,resource,ejb3,jaxws,web,ear,depmonitor Le datasource :
jonas.service.dbm.datasources Mysql1
Ensuite il faut créer le fichier Mysql1.properties avec toutes les données permettant la connexion à la base de donnée (login, mot de passe, adresse, ….)
datasource.name CSC5002_9
datasource.url jdbc:mysql://www-inf.it-sudparis.eu:3306/CSC5002_9 datasource.classname com.mysql.jdbc.Driver
datasource.username adm_csc5002_9 datasource.password Monday11October datasource.mapper rdb.mysql
15
Une fois configuré, JonAS se lance simplement par la commande jonas start ; pour l’arrêter il faut taper jonas stop. La commande jonas admin permet d’administrer le serveur en ligne de commande, ce mode permet notamment de voir les Beans déployés sur le serveur, ce qui est très utile.
4. Développement du Mailbox sous JonAS
Dans cette partie, nous abordons le développement et le déploiement de l’application Mailbox sous JonAS.
Pour faire ce travail, nous sommes partis de l’application que nous avions déjà développée sous Glassfish, notre idée était de l’adapter afin qu’elle puisse tourner sous JonAS.
d) Ce qui a été conservé
L’architecture de l’application n’a pas été changé, ainsi que sa conception.
e)
Ce qui a été modifié La persistance
Nous avons du modifier le modèle de persistance pour l’adapter à JonAS. Tout de même, JPA a été conservé, c’est son implémentation qui a été changé. On a ainsi du mettre Hibernate à la place de EclipseLink qui n’est pas supporté pas JonAS 5.1. Cela vient du fait que l’implémentation JPA 2.0 est apparue après le serveur JonAS 5.1.
Modifications dans jonas.properties : Le provider
# Set the JPA provider: hibernate or eclipselink jonas.service.ejb3.jpa.provider hibernate
Quelques lignes du fichier de persistance (persistence.xml)
<?xml version="1.0" encoding="UTF-8" ?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
<persistence-unit name="pu1">
<provider></provider>
<jta-data-source>CSC5002_9</jta-data-source>
<properties>
<property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect"/>
<property name="hibernate.hbm2ddl.auto" value="update"/>
<property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
<property name="eclipselink.ddl-generation.output-mode" value="database"/>
16
<property name="eclipselink.target-database" value="MySQL"/>
<property name="toplink.target-database" value="MySQL"/>
<property name="toplink.ddl-generation" value="drop-and-create-tables"/>
<property name="toplink.ddl-generation.output-mode" value="database"/>
<property name="openjpa.jdbc.DBDictionary" value="mysql"/>
<property name="openjpa.jdbc.SynchronizeMappings"
value="buildSchema(ForeignKeys=true)"/>
</properties>
</persistence-unit>
</persistence>
Le déploiement
Nous avons été surpris par l’écart existant entre le déploiement que nous avions fait sur Glassfish et ce que nous devions faire pour que l’application fonctionne sous jonAS. C’est la partie qui nous a le plus pris du temps.
Sous Glassfish on avait un plan de déploiement relativement simple, un fichier build.xml qui généré un jar à travers l’outil ANT et qui est directement déployable sur le serveur.
Notre premier réflexe a été d’essayer la même technique sous JonAS. Nous avons ainsi généré un jar que nous avons essayé de déployé sur JonAS, sans succès. On a notamment pas pu résoudre le cette erreur The given filename Mailbox.jar is not an absolute file.
La deuxième solution a été de packager le projet dans un fichier EAR.
Que contient le fichier EAR ?
Tout d’abord un fichier EAR est un fichier jar pour lequel on a changé l’extension. Il est utilisé par Java EE pour empaqueter un ou plusieurs 'modules' dans une seule archive, de façon à pouvoir déployer ces modules sur un serveur d'applications en une seule opération, et de façon cohérente. Ces archives contiennent aussi des fichiers XML appelés descripteurs de déploiement, qui indiquent comment les modules doivent être déployés sur le serveur.6
Ainsi dans notre cas le fichier EAR est structuré comme suit :
6 http://fr.wikipedia.org
17
Figure 9 - Structure d'un EAR
o Les clients
Chaque client (Admin et Mailbox) est un fichier jar qui contient la classe compilée du client et son propre descripteur de déploiement.
Figure 10 - Struture du client
o Le module EJB
Le module EJB (fichier jar) contient les classes métiers compilées de l’application (les bean et les entity). De plus il embarque un répertoire META-INF contenant le fichier de persistance.
Client Administrateur
•AdministratorClient.jar
Client Utilisateur
•MailBoxclient.jar
Module EJB
•Ejb3.jar
META-INF
•descripteurs de deploiement
EAR
Administrator.jar
Client
AdministratorClient.class
META-INF
application- client.xml
EJB3.jar Ejb
DirectoryManager DirectoryManagerBean MailBoxManager MailBoxManagerBean
Entity
User Message
META-INF
persistence.xml
18
o Comment est généré le fichier EAR ?
Pour voir comment ce fichier est généré, nous allons introduire la structure du projet Mailbox sous Jonas
etc : dans ce répertoire, on retrouve le fichier de persistance et les descripteurs de déploiement des modules de l’application
include : contenant un fichier
XML (jonas-common.xml)
rassemblant quelques éléments utiles au fichier build.xml . Ce fichier sera inclus dans build.xml, il est là pour éviter de trop surcharger ce dernier.
src : qui contient le code source des classes JAVA de l’application
bin-client/clientConfig : contenant les paramètres JNDI et le protocole de communication
le fichier build.xml
Le fichier build.xml contient les instructions nécessaires pour la compilation et le packaging des modules de l’application Mailbox au travers de l’outil ANT. Cela permet entre autre ce générer le fichier EAR
- Prise en charge du fichier EAR par jonas
A la fin de la compilation à travers ANT, le fichier EAR (maibox.ear) est déposé dans le répertoire deploy de JONAS_BASE. Jonas prend directement en compte le fichier et déploie l’application. On n’a pas besoin de redémarrer le serveur.
Pour lancer les client de l’application, on disposent de deux méthodes:
19
1. La commande Jclient
Avec la commande ci-dessous, on lance le client Administrator,
jclient -nowsgen $JONAS_BASE/deploy/mailbox.ear -jarClient administratorClient.jar
L'option -jarClient permet de spécifier le client à utiliser cr l'application Mailbox en a deux.
Sachant que cette méthode n'est pas conforme à la spécification Java EE, la commande jclient devrait être supprimée dans les prochaines versions de JonAS
2. Le conteneur client
Pour se conformer à la spécification Java, Jonas propose un "conteneur" client qui dispose de toutes les classes pour lancer le client de l'application. Ce conteneur est un fichier jar (client.jar) qui se trouve dans $JONAS_ROOT/lib7.
Ainsi pour lancer le client Administrator il faut taper:
java -jar client.jar $JONAS_ROOT/lib/client.jar -jarClient AdministratorClient.jar mailbox.ear
En plus du client à lancer (option -jarClient), il fut également donner le nom du package EAR qui contient ce client.
Pour permettre l'exécution du client sur une machine distance, on doit spécifier les paramètre JNDI et le protocole de connexion. Ces informations doivent être mises dans le fichier carol.properties de JONAS. Exemple l'adresse du serveur se traduit par la ligne:
carol.irmi.url=rmi://157.159.110.56:1099
Ce fichier peut être utilisé à différents niveaux. Le fichier carol.properties est recherché en respectant les priorités suivantes, par ordre décroissant:
- Le fichier carol.properties spécifié par l'argument -carolFile du conteneur client - le fichier carol.properties packagé dans l'application client (le jar client)
- si il n'a pas été trouvé selon les deux méthodes précédentes, le
fichier carol.properties contenu dans le fichier JONAS_ROOT/lib/client.jar sera utilisé.
Dans notre projet nous avons choisi la deuxième méthode, c'est à dire intégrer le fichier carol.properties dans le projet.
7 http://cvs.forge.objectweb.org/cgi-bin/viewcvs.cgi/jonas-doc/jonas-doc-fr/doc/PG_Client.html?rev=1.2
20
Code
Dans la partie précédente nous avons expliqué le travail qui a été fait pour déployer l’application Mailbox sous JonAS avec notamment le développement des descripteurs de déploiement des modules applicatifs. D’autres changements sont à noter également au niveau du code source
- La recherche d’un bean
Jonas a sa propre nomenclature des beans que le serveur déploie, pour accéder à un bean il faut donc se conformer aux noms des beans générés à travers le JNDI (Java Naming and Directory Interface).
Code de recherche d’un bean (ci-dessous celui du bean d’administration DirectoryManager)
private static final String JNDI_NAME = "ejb.DirectoryManagerBean" + "_"
+ DirectoryManager.class.getName() + "@Remote";
Context InitialContex = new InitialContext();
directoryManager = (DirectoryManager) InitialContex.lookup(JNDI_NAME);
Un autre moyen pour résoudre ce problème est de remplacer le paramètre name de l'annotation @Stateless sur Glassfish par le paramètre mappedName de la même annotation sur JonAS. En effet name ne fonctionne pas sur JonAS.
- Le type de retour d'une requête
Une autre différence est le type de retour d’une requête au travers de l’entity manager.
Lorsque par exemple on envoie une requête qui retourne tous les utilisateurs présents en base, sous Glassfish on l’obtenait dans un vecteur alors que sous Jonas on a une ArrayList.
Cela peut être du également à une différence entre Hibernate et EclipseLink
La requête:
query = entityManager.createQuery("SELECT user FROM User user");
Resultant sous Glassfish:
Vector<User> userList = (Vector<User>) query.getResultList();
Resultat sous JonAS:
ArrayList<User> userList = (ArrayList<User>) query.getResultList();
21
VI. Déploiement sous SPRING
Nous avons dernièrement essayé de déployer le programme sous Spring. Cette partie décrit les différents solution nous avons testées.
1. Introduction au Spring Framework
Spring est un conteneur dit «léger», c'est-à-dire une infrastructure similaire à un serveur d'application Java EE. Il prend donc en charge la création d'objets et la mise en relation d'objets par l'intermédiaire d'un fichier de configuration qui décrit les objets à fabriquer et les relations de dépendances entre ces objets.
Le gros avantage par rapport aux serveurs d'application est qu'avec Spring, les classes n'ont pas besoin d'implémenter une quelconque interface pour être prises en charge par le framework (au contraire des serveurs d'applications Java EE et des EJBs). C'est en ce sens que Spring est qualifié de conteneur «léger».
La mise en place de Spring n’a pas besoin d’un procédure d’installation. Il faut simplement télécharger le fichier compressé en forme de ZIP du Spring 3.0 sur le lien http://www.springsource.com/download/community. Ce framework s'intègre parfaitement dans Eclipse.
Nous avions cru au début que la mise en place de programme sous Spring est une procédure simple ne nécessitant pas beaucoup de modification de code. Mais on s'est aperçu que c'est un framework totalement différent des EJB.
Figure 11 - Besoin de développeur de Spring et de EJB8
8 http://www.indeed.com/jobtrends?q=spring%2C+ejb
22
5. Solutions proposées de déploiement
Dans cette partie, nous allons décrire les différents méthodes effectuées pour déployer le programme Mailbox sous Spring Framework.
f) L’intégration d’EJBs
Comme un conteneur léger, Spring est souvent considéré comme un remplacement d’EJB. Mais avec la version de Spring 2.5.0, on peut accéder à des EJB et mettre en œuvre des EJBs. Nous avons commencé notre déploiement avec cette solution.
Comme la documentation mentionne, Il faut simplement créer un class qui hérite AbstractStatelessSessionBean9 pour les EJBs 2.x:
Mais nous avons utilisé EJB3. EJB est beaucoup simplifié avec cette nouvelle version. Il n’y plus de EJB Remote et EJB Home et on n’a plus besoin de descripteur ejb-jar.xml pour déployer.
Spring nous propose alors la solution suivante pour EJB3:
9 http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/
public class MyFacadeEJB extends AbstractStatelessSessionBean implements MyFacadeLocal {
private MyComponent myComp;
//Obtain our POJO service object from the BeanFactory/ApplicationContext
protected void onEjbCreate() throws CreateException {
myComp = (MyComponent) getBeanFactory().getBean(
ServicesConstants.CONTEXT_MYCOMP_ID);
}
public String myFacadeMethod(...) { return myComp.myMethod(...);
} ...
}
23
Nous avons donc testé cette solution mais sans réussite. L’annotation @Interceptors donne toujours une erreur.
g) Redévelopper la couche intermédiaire avec JdbcTemplate
Après l’échec d’intégrer EJB au Spring, nous avons ensuite essayé à redévelopper la couche intermédiaire du programme. Spring a nous offert JdbcTemplate comme une approche simple pour les échanges avec les base de donnée.
Nous avons tout à bord créé une nouvelle classe pour configurer l’accès à base de données.
@Stateless
@Interceptors(SpringBeanAutowiringInterceptor.class) public class MyFacadeEJB implements MyFacadeLocal {
@Autowired
private MyComponent myComp;
// for business method, delegate to POJO service impl.
public String myFacadeMethod(...) { return myComp.myMethod(...);
} ...
}
24
Avec cette classe, on peut insérer un enregistrement comme la méthode suivante :
Et on peut également faire des requête comme la façon :
La manipulation des requêtes marchent très bien avec cette solution. Mais la difficulté reste la persistance de donnée. Spring ne connait rien sur la relation entre les deux tables car on n’a pas une entity manager (type JPA) qui gère la persistance de donnée. Ceci rend le développement beaucoup plus complexe. Nous avons réalisé les fonctionnalités d’AdministratorClient. Mais nous avons aperçu que ce n’est pas une bonne méthode sans utiliser un gestionnaire de persistance. Il nous donc trouver une autre meilleure solution qui encapsule les manipulations en relation avec la base de donnée.
h) Solution Spring + Hibernate
Notre encadrante nous a donc proposé d’utiliser Hibernate. Hibernate est un framework open source gérant la persistance des objets en base de données relationnelle et l'avions déjà mis en œuvre sur JonAS. Il permet de « mapper » une base de données relationnelle en
jdbcTemplate.queryForObject ("select ……");
jdbcTemplate.update("insert into User values (?, true, true, true, true, ?)", login, password);
@Configuration
public class JdbcConfig {
@Bean
public JdbcTemplate jdbcTemplate() { DriverManagerDataSource dataSource = new DriverManagerDataSource();
dataSource.setDriverClassName("com.mysql.jdbc.Driver");
dataSource.setUrl("xxxxx");
dataSource.setUsername("xxxx");
dataSource.setPassword("xxxx");
return new JdbcTemplate(dataSource);
} }
25
objets. Il permet donc d’abstraire totalement l’accès à la base de données et propose donc un accès totalement orienté objet aux données.
Nous avons créé une interface qui abstrait les actions sur la table User10 :
Nous avons ensuite crée une nouvelle classe qui implémente cette interface :
10 http://www.springbyexample.org/
public interface UserDao {
public Collection<User> findUsers() throws DataAccessException;
public Collection<User> findUsersByID(String id) throws DataAccessException;
public void save(User person);
} }
26
Cette solution doit normalement fonctionner mais en raison de l’échéance du projet, nous n’avons pas eu assez du temps pour la terminer.
@Repository
@Transactional(readOnly = true)
public class UserDaoImpl implements UserDao { protected HibernateTemplate template = null;
public void setSessionFactory(SessionFactory sessionFactory) { template = new HibernateTemplate(sessionFactory);
}
@Override
public Collection<User> findUsers() throws DataAccessException { return template.find("from User");
}
@Override
public Collection<User> findUsersByID(String id) throws DataAccessException {
return template.find("from User u where u.User_login = ?", id);
}
@Override
public void save(User person) {
template.saveOrUpdate(person);
} }
27
VII. Comparaison de performances
Dans cette partie, nous allons d’une part comparer l’implémentation du Mailbox avec la spécification EJB 3.0 sous JonAS et Glassfish, d’autre part nous allons voir les différences entre les EJB et l’implémentation proposée par Spring.
6. Glassfish VS Jonas i) Comparaison qualitative
Certification Java EE, communauté et documentation
Pour commencer cette comparaison, nous allons aborder les certifications Java EE qui sont un gage de performance des serveurs d’applications. Sur ce point là il ne fait aucun doute que Glassfish est en avance. Ceci peut s’expliquer par le fait que Glassfish est développé au sein de SUN (maintenant Oracle), la même entreprise qui développe les spécifications Java EE et EJB. Concrètement, la dernière version de Glassfish (v3) est déjà certifiée Java EE 6 tandis que Jonas 5.1 est certifiée Java EE 5 même si la version en cours de développement intègre déjà quelques éléments de Java EE 611.
Pour ce qui concerne la communauté et la documentation, là aussi Glassfish garde la main grâce au soutien de la forte communauté, par contre avec JonAS on a plus d'exemples fournis avec le serveur, ce qui est très utile pour comprendre le fonctionnement du serveur.
Persistance
Les deux serveurs intègre JPA 1.0 et proposent plusieurs supports pour JPA 1.0 notamment Hibernate, EclipseLink, Open JPA. Dans ce projet nous ne sommes tout de même pas arrivés à faire fonctionner JonAS et EclipseLink. A noter également que Glassfish V3 intègre JPA 2.0, ce qui n’est pas le cas pour l’instant des versions Stable de JonAS.
Code source
Pour la partie codage, nous pouvons mentionner tout d’abord que les deux projets proposent des plugins Eclipse pour leur administration (JOPE12 pour JonAS, Tools Bundle pour Glassfish 13 ). Nous avons testé ces outils, ils permettent de démarrer/stopper/configurer les serveurs. Quand à la possibilité de créer des projets préconfigurés pour fonctionner sur les serveurs, là c’est plus mitigé. Tools Bundle est plus orienté projets Web tandis que JOPE ne fonctionne malheureusement qu’avec des versions anciennes d’Eclipse (il ne fonctionne pas sous Galileo et Helios par exemple).
En ce qui concerne les différences dans les développements des applications, à part les quelques modifications mentionnées dans la partie VI.4, il n'y a pas énormément d'efforts de
11 http://wiki.jonas.ow2.org/xwiki/bin/view/Main/Downloads
12 http://forge.ow2.org/projects/jope
13http://dlc.sun.com.edgesuite.net/glassfish/eclipse/
28
modification de code à faire pour passer d'une application Java EE tournant JonAS vers Glassfish et vice versa. En effet les deux serveurs intègre très bien la spécification des
EJB 3.0, le seul soin à apporter lors du développement est de se conformer à cette spécification.
Déploiement
Nous avons déployé l'application Mailbox écrite en Java EE sous deux formes, une fichier jar classique pour Glassfish et un fichier EAR pour JonAS.
La méthode utilisant les EAR est probablement la plus propre surtout lorsque l'on a plusieurs modules EJBs dans l'application. Ce modèle permet d'avoir l'ensemble des modules dans un seul package. A contrario, elle demande un effort de développement supplémentaire, notamment pour l'écriture des descripteurs de déploiement car chaque module de l'application doit être packagé dans un jar.
La deuxième méthode est le paquetage des classes dans un jar qui va ensuite être déployé dans le serveur d'applications. Cette méthode convient pour des applications de petite taille et qui n'ont pas beaucoup de modules et qui ne demande pas énormément d'interactions entre les modules, ce qui le cas du Mailbox.
Administration
Les deux serveurs offrent deux modes d'administration: à travers console web ou en ligne de commandes. Les consoles web offrent à peu près les mêmes possibilités avec notamment la possibilité de :
- Configurer le serveur
- Configurer des services (bases de données, réseau, sécurité,...) - Gérer les applications (déploiement,...).
Glassfish donne la possibilité d'activer le monitoring de certains services
(JVM, JPA, conteneur EJB,...). Il faut toutefois noter que l'outil de monitoring qui permet d'avoir la représentation graphique des valeurs générées n'est pas inclus dans la version libre mais uniquement dans la version Entreprise de Glassfish. On peut tout de même récupérer ces valeurs à l'aide de dtrace (système de trace conçu par Sun Microsystems).
En ce qui concerne le monitoring du coté de JonAS, il existe un outil (JASMINe) qui permet entre autres de superviser des services JonAS ou encore. JASMINe est open source comme Jonas, ce qui représente un bon point pour le serveur.
Figure 12 - Console JASMINe
29
j) Comparaison quantitative
Dans cette partie nous allons donner quelques éléments de comparaison quantitatif entre les implémentations sur les deux serveurs.
Démarrage et arrêt des serveurs
Temps de démarrage Temps d'arrêt
Jonas 11 s 2 s
Glassfish 5s 4 s
On voit donc que le serveur JonAS met plus de temps à démarrer.
Pour la suite des calculs, la configuration retenue pour les performances à suivre est la suivante:
Les serveurs JonAS et Glassfish tournent sur une machine X et les clients sont lancés sur une machine distante Y.
Administration des utilisateurs
Temps JonAS Temps Glassfish
Ajouter un user 6ms 5ms
Supprimer un user 11ms 15ms
Supprimer droit lecture 10 ms 9ms
Ajouter droit lecture 11 ms 6ms
Voir liste User 6ms 5ms
Données sur l'utilisation du Mailbox
JonAS Temps Glassfish
Envoyer msg 14ms 11ms
Lire msg 19ms 30ms
Afficher liste msg (10 msg) 13 ms 21ms
Supprimer msg 13ms 7ms
Envoyer news 23ms 14ms
30
k) Montée en charge
Dans cette partie, nous avons effectué une montée en charge en augmentant le nombre d'utilisateurs et de messages.
Montée en charge sur les utilisateurs
Le tableau suivant et son graphique correspondant montrent une comparaison d'insertion d'utilisateurs dans la base. On remarque une différence entre 10% et 30% en faveur de Glassfish au niveau du temps mis pour insérer les utilisateurs.
Temps d'exécution en millisecondes
Nombre User Jonas Glassfish
1000 4443 3152
3000 10765 9337
5000 19468 15409
7000 24383 20918
10000 35240 29643
0 5000 10000 15000 20000 25000 30000 35000 40000
Jonas Glassfish
31
Montée en charge sur les messages
Dans cette partie nous avons comparé les performances des deux serveurs sur les temps d'envoi de messages.
Temps d'exécution en millisecondes
Nombre de messages envoyés Jonas Glassfish
500 438 310
1000 1060 646
5000 5070 3075
10000 9119 6914
Les deux serveurs sont à peu près équivalents lorsque l'on est sur des nombre de messages pas très grands. Mais plus le nombre le nombre de messages envoyés d'un seul coup augmente, plus Glassfish prend l'avantage en termes de rapidité. On remarque également qu'à partir de 10000 messages envoyés, que si l'on multiplie le nombre de messages par deux alors le temps d'envoi est quasiment multiplié par deux également.
0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000
JonAS Glassfish
32
l) Synthèse
JonAS Glassfish
Généralités,
communauté et
support
Projet Open Source Français
Petite communauté mais réactive aux mailings listes
Basé sur une architecture OSGi
Grosse communauté
Très bonne qualité de la documentation malgré son jeune âge
Support d'Oracle
Plusieurs fonctionnalités utiles peuvent être payantes
Full OSGi
Installation et prise en main
Installation facile, prise en main rapide, une base séparée pour les configurations et déploiements
De nombreux exemples fournis avec le serveur
Pas de difficultés d'installation
Peu d'exemples fournis pas défaut
Support EJB & Java EE Serveur certifié Java EE 5
Implémente EJB 3.0
Serveur certifié Java EE 6
Implémente EJB 3.0
Déploiement
Fournit un conteneur client
EAR souvent indispensables
Rapide si le projet n'est pas très gros à travers un jar
Persistance de
données
Intègre JPA 1.0 avec Hibernate et EclipseLink
Intègre JPA 2.0 avec EclipseLink comme implémentation de référence
Développement Pas de difficultés si on maitrise les technique EJB
Performances
Temps de démarrage lent
Performances satisfaisantes
Temps d'arrêt plutôt lent
Plus performants sur des quantités de données importantes
33
7. Spring VS EJB
Même si nous n’avons pas pu finaliser le déploiement du programme sous Spring, nous avons fait quelques tests de performance sur la partie que nous avons réussi à finaliser (l'administration des utilisateurs).
Ensuite nous avons mesuré les différentes opérations sur la base de données. Voici les tableaux :
a) Comparaison des performances
La performance d’ajout d’un utilisateur
EJB (avec Glassfish) Spring
1er test 9 ms 27 ms
2ère test 6 ms 26 ms
3ère test 6 ms 28 ms
Moyen 7 ms 27 ms
La performance sur la suppression d’un utilisateur EJB (avec Glassfish) Spring
1er test 10 ms 11 ms
2ère test 8 ms 23 ms
3ère test 9 ms 22 ms
Moyen 9 ms 18 ms
Les performances sur la modification d’un droit d'utilisateur EJB (avec Glassfish) Spring
1er test 9 ms 36 ms
2ère test 7 ms 33 ms
3ère test 8 ms 40 ms
Moyen 8 ms 33 ms
La performance de lister tous les utilisateurs EJB(avec Glassfish) Spring
1er test 6 ms 13 ms
2ère test 6 ms 16 ms
3ère test 6 ms 16 ms
Moyen 6 ms 15 ms
34
On peut bien voir qu’EJB est plus efficace que Spring dans ce cas. C’est parce qu'on n’a pas utilisé JPA pour encapsuler les méthodes de ces opérations. On a besoin des fois de deux requêtes pour s’assurer qu'il n'y ait pas de conflit de base. La performance de Spring peut surement être améliorée avec Hibernate Framework.
b)
Montée en chargeNous avons testé l'insertion en base des données (utilisateur) en quantité importante. Les résultats obtenus sont rassemblés dans le tableau suivant.
EJB (avec Glassfish) Spring
1000 3152 32844
3000 9337 46851
5000 15409 72253
7000 20918 93219
10000 29643 131463
Ces mesures montrent clairement un avantage des EJB par rapport à Spring mais comme mentionné plus haut, ils ne sont pas très significatifs car on n’a pas une version optimale sous Spring.
0 20000 40000 60000 80000 100000 120000 140000
1000 3000 5000 7000 10000
EJB(avec Glassfish) Spring
35
c) Synthèse
EJB Spring Framework
Définition
« une architecture de composants logiciels côté serveur pour la plateforme de développement Java EE »
« un framework libre pour construire et définir l'infrastructure d'une application java »
Généralités, communauté et support
Open source
Sun Microsystems
Très nombreux tutoriels et documentations
Open source
Communauté SpringSource
Grande quantité de documentations sur
http://www.springsource.org
Implémentation Conteneur d’EJB
Spring IoC (Inversion of Control) conteneur
Configuration
Via XML
Utilisation d’annotations JAVA standards
Via XML
Propre système d’annotation
Persistence de
données Java Persistence API (JPA)
De nombreux frameworks de persistance (JDBC,Hibernate, JDO, iBatis, JPA)
Développement
Pas de difficultés si on maitrise les technique EJB
Pas de difficultés si on
maitrise le Spring Framework
Performances
Besoin du temps de démarrage du serveur
Performances satisfaisantes
Pas besoin de démarrage
Performants moins
intéressant que EJB (dans le cadre de ce projet)
36
VIII. Management de Projet
a) Planning
Nous avons bien respecter notre planning avant de commencer à déployer l’application sous différents plateformes. Mais en raison de modification et amélioration de programme, nous étions en retard pour le portage de l’application. D’ailleurs nous n’avions pas prévu la complexité et les difficultés rencontrées au cours du projet. Ceci entraine qu’on n’ait pas eu assez de temps pour finaliser le déploiement sous Spring.
Activité prévue Semaine Activité faite
04/10/2010 -
13/10/2010 Lancer du projet
S40 (2010) Lancer du projet
S41 Créer le dépôt du projet sur SVN. Faire le planning.
14/10/2010 -
29/10/2010
Etudier des serveurs
S42 Découvrir la technologie Java EE et EJB S43 Etudier des différents serveurs d’application
02/11/2010 -
26/11/2010
Développer l’application
S44 – S47 Développer l’application Mailbox sous Glassfish
29/11/2010 -
17/12/2010
Porter l’application sur les différentes
plateformes
S48 Modifier les modèles du base de données S49 Compléter les annotations
S50 Début du déploiement l’application sous JonAs
15/12/2010 -
03/01/2011 Vacances Noel
S51 – S52 Continuer le travail de déploiement sur JonAs
04/01/2011 -
21/01/2011 Comparer des performances
S1 (2011) Finaliser le déploiement sous JonAs
S2 Déployer sous Spring
S3 Comparer la performance
24/01/2011 -
26/01/2011
Préparer la soutenance
S4 Finaliser du rapport et préparer la soutenance
37
b) Temps passé sur le projet
Nous avons dépensé globalement autant de temps de travail comme prévu.
Nous n’avons pas dépensé autant de temps à développer l’application comme prévu mais nous avons ajouté 16 heures de travail pour modifier et améliorer l’application sur les conseils de notre encadrante. On a notamment du refaire le modèle de données de l'application
Dernièrement, comme mentionné plus haut, nous avons dépensé beaucoup plus de temps à déployer l’application sous différentes plateformes.
Activité Charge prévue Charge réel
Présentation générale d'ASR 3 3
Réunion avec l'encadrant 16.5 5.5
Réunion d’évaluation 1.5 1.5
Participer aux soutenances 12 12
Formation Logiciels 6 6
Faire du planning 1 1
Etudier Java EE et des serveurs d’application 20 14
Développer l’application Mailbox 60 50
Modifier et améliorer l’application 0 16
Déployer l’application sous JonAs 28 30
Déployer l’application sous Spring 28 38
Comparer la performance 20 16
Finaliser du rapport et préparer la soutenance 26 24
Total 222 h 217 h
38
IX. Bilan
Ce projet nous a permis d'assouvir en partie notre passion naissante pour les technologies employées pour produire des applications en entreprise. Nous avons ainsi pu aller un peu plus loin dans nos connaissances sur les EJB et les serveurs d'applications qui sont un monde riche et en perpétuelle évolution.
Au moment où l'on parle de plus en plus de Cloud Computing, les architectures utilisant les serveurs d'applications prennent encore plus de place. En effet, elles constituent des briques importantes dans les offres des éditeurs.
Ce projet nous a en outre permis de comprendre comment les serveurs d'applications mettaient en œuvre la spécification des EJB et comment ils intégraient Java EE. On a aussi compris à travers les différentes évolutions des EJB, comment les équipes d'un projet s'adaptent aux critiques en mettant en place une stratégie pour faire évoluer leur produit dans le bon sens afin de ne pas se faire dépasser par les concurrents.
Ce projet était donc orienté EJB mais pas que, en effet le framework Spring est une bonne alternative qui a beaucoup de succès auprès des développeurs car il offre plus de
"souplesse" dans le développement et le déploiement des applications d'entreprise, même si avec les EJB 3.0, cela est de moins en moins évident.
Au delà de cette montée en compétences sur les serveurs d'applications, nous avons également approfondi nos connaissances des technologies JAVA ainsi que l'utilisation des outils comme Ant (pour construire les logiciels sous des formats différents, jar, EAR, etc...) et Subversion (pour la gestion de versions du projet).
Vu la charge de travail qu'on avait, il fallait en outre bien repartir les rôles dans le binôme, ce qui est toujours une expérience enrichissante, bien que nous avions déjà l'habitude de travailler en équipe.
On a rencontré certains problèmes sur ce projet. Les problèmes étaient plus ou moins complexes, cela nous a appris à nous adapter, par exemple à plusieurs solutions dans certains cas afin de prendre la meilleure, ou savoir tout simplement se contenter du minimum et passer à autre chose quand le problème nous prend trop de temps par rapport à notre planning.
Malgré les réussites sur les déploiements sur JonAS, Glassfish et une partie sur Spring, on aurait pu avec un peu plus de temps:
Enrichir les fonctionnalités de l'application (par exemple mettre en place un système de gestion des listes de diffusion)
Finaliser la version sur Spring
Déployer une version EAR du Mailbox sur Glassfish
Construire le projet avec Maven sur les deux serveurs d'application
Améliorer les interfaces des clients
Faire plus de tests de performances
39
X. Références
1. fr.wikipedia.org
2. www.springsource.com 3. www.springbyexample.org 4. jonas.ow2.org/
5. www.01net.com 6. www.developpez.com 7. blog.ippon.fr
8. "Les serveurs d'application: une introduction", Claude Duvallet, Université du Havre, Octobre 2006
9. "Glassfish and Jboss", Sun microsystems, 2009
10. "EJB 3", Cedric Bottero, Michael Mathieu, Clio S.A.,Juin 2009
11. "Introduction à EJB 3", Cedric Dumoulin, Laboratoire d'Informatique Fondamentale de Lille, 2006
12. "Spirng vs EJB 3.0", Ahmed Alami, SOA-Architect.net
13. "Serveurs d'applications JEE: quel avenir pour les éditeurs", Jean Goffinet, Clever Age, Mai 2008
14. "EJB 3, Spring and Hibernate", Reza Rahman, Tripod Technologies, Septembre 2007 15. "A Response to: EJB 3 and Spring Comparative Analysis", Mark Fisher, SpringSource,
Novembre 2007
