Rapport de projet de fin d`études

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
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
2
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
3


II.
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)
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
4
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:




2
3
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...)
www.developpez.com
http://fr.wikipedia.org/wiki/Serveur_d'applications
5
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.
6
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
7
-
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
8
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
2
3
4
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
Extraire le fichier zip.
Configurer les variables d’environnement comme $GLASSFISH_HOME et $CLASSPATH
pour faciliter le travail sous Glassfish.
Lancer le Glassfish avec la commande : asadmin start-domain domain1, puis rendezvous 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.
9
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.
10
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 OSGi
4
4
http://wiki.jonas.ow2.org
11
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
12
JONAS_ROOT
deploy
bin
conf
libs
templates
examples
logs
Repositories
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_BASE
deploy
lib
conf
work
logs
Repositories
13
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
datasource.url
CSC5002_9
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
14
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"/>
15
<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
16
Client
Administrateur
Client Utilisateur
• MailBoxclient.jar
• AdministratorClient.jar
EAR
Module EJB
META-INF
• Ejb3.jar
• descripteurs de
deploiement
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.
Administrator.jar
META-INF
Client
AdministratorClient.class
applicationclient.xml
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.
EJB3.jar
Ejb
Entity
DirectoryManager
User
DirectoryManagerBean
Message
META-INF
persistence.xml
MailBoxManager
MailBoxManagerBean
17
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:
18
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
19
 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();
20
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 EJB
8
8
http://www.indeed.com/jobtrends?q=spring%2C+ejb
21
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:
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(...);
}
...
}
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/
22
@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(...);
}
...
}
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.
23
@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);
}
}
Avec cette classe, on peut insérer un enregistrement comme la méthode suivante :
jdbcTemplate.update("insert into User values (?, true, true, true, true, ?)", login,
password);
Et on peut également faire des requête comme la façon :
jdbcTemplate.queryForObject ("select ……");
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
24
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 :
public interface UserDao {
public Collection<User> findUsers() throws DataAccessException;
public Collection<User> findUsersByID(String id) throws
DataAccessException;
public void save(User person);
}
}
Nous avons ensuite crée une nouvelle classe qui implémente cette interface :
10
http://www.springbyexample.org/
25
@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>
DataAccessException {
findUsersByID(String
id)
throws
return template.find("from User u where u.User_login = ?", id);
}
@Override
public void save(User person) {
template.saveOrUpdate(person);
}
}
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.
26
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
http://forge.ow2.org/projects/jope
13
http://dlc.sun.com.edgesuite.net/glassfish/eclipse/
12
27
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
28
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
Jonas
Temps d'arrêt
11 s
2s
5s
4s
Glassfish
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
29
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
40000
35000
30000
25000
20000
15000
10000
Jonas
Glassfish
5000
0
30

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
10000
9000
8000
7000
6000
5000
4000
JonAS
3000
Glassfish
2000
1000
0
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.
31
l) Synthèse
JonAS

Généralités,
communauté
support

et

Projet
Open
Source
Français
Petite communauté mais
réactive aux mailings listes
Basé sur une architecture
OSGi
Glassfish






Installation facile, prise en
main rapide, une base
séparée
pour
les
configurations
et
déploiements
De nombreux exemples
fournis avec le serveur



Serveur certifié Java EE 5
Implémente EJB 3.0


Serveur certifié Java EE 6
Implémente EJB 3.0

Fournit un conteneur
client
EAR souvent
indispensables

Rapide si le projet n'est
pas très gros à travers un
jar
Intègre JPA 1.0 avec
Hibernate et EclipseLink

Intègre JPA 2.0 avec
EclipseLink
comme
implémentation
de
référence
Installation et prise en
main

Support EJB & Java EE

Déploiement

Persistance
données
de
Développement
Performances
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

Pas
de
difficultés
d'installation
Peu d'exemples fournis
pas défaut
Pas de difficultés si on maitrise les technique EJB


Temps de démarrage lent
Performances
satisfaisantes


Temps d'arrêt plutôt lent
Plus performants sur des
quantités de données
importantes
32
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
1er test
2ère test
3ère test
Moyen

EJB (avec Glassfish)
10 ms
8 ms
9 ms
9 ms
Spring
11 ms
23 ms
22 ms
18 ms
Les performances sur la modification d’un droit d'utilisateur
1er test
2ère test
3ère test
Moyen

Spring
27 ms
26 ms
28 ms
27 ms
La performance sur la suppression d’un utilisateur
1er test
2ère test
3ère test
Moyen

EJB (avec Glassfish)
9 ms
6 ms
6 ms
7 ms
EJB (avec Glassfish)
9 ms
7 ms
8 ms
8 ms
Spring
36 ms
33 ms
40 ms
33 ms
La performance de lister tous les utilisateurs
1er test
2ère test
3ère test
Moyen
EJB(avec Glassfish)
6 ms
6 ms
6 ms
6 ms
Spring
13 ms
16 ms
16 ms
15 ms
33
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 charge
Nous avons testé l'insertion en base des données (utilisateur) en quantité
importante. Les résultats obtenus sont rassemblés dans le tableau suivant.
Spring
1000
EJB (avec Glassfish)
3152
3000
9337
46851
5000
15409
72253
7000
20918
93219
10000
29643
131463
32844
140000
120000
100000
80000
EJB(avec Glassfish)
60000
Spring
40000
20000
0
1000
3000
5000
7000
10000
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.
34
c) Synthèse
Définition
Généralités,
communauté et
support
Implémentation
EJB
Spring Framework
« 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 »




Open source
Sun Microsystems
Très nombreux tutoriels
et documentations



Open source
Communauté SpringSource
Grande quantité de
documentations sur
http://www.springsource.org

Spring IoC (Inversion of
Control) conteneur
Conteneur d’EJB

Configuration
Persistence de
données




Via XML
Propre système d’annotation

De nombreux frameworks de
persistance (JDBC,Hibernate,
JDO, iBatis, JPA)

Java Persistence API (JPA)

Pas de difficultés si on
maitrise les technique
EJB

Pas de difficultés si on
maitrise le Spring Framework

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)
Développement
Performances
Via XML
Utilisation d’annotations
JAVA standards

35
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
04/10/2010
13/10/2010
Semaine
- S40 (2010)
S41
Lancer du projet
14/10/2010
29/10/2010
- S42
S43
Activité faite
Lancer du projet
Créer le dépôt du projet sur SVN. Faire le
planning.
Découvrir la technologie Java EE et EJB
Etudier des différents serveurs d’application
Etudier des serveurs
02/11/2010
26/11/2010
- S44 – S47
Développer
Glassfish
l’application
Mailbox
sous
- S48
Modifier les modèles du base de données
Développer l’application
29/11/2010
17/12/2010
Porter l’application sur
les différentes
plateformes
15/12/2010
03/01/2011
S49
Compléter les annotations
S50
Début du déploiement l’application sous
JonAs
- S51 – S52
Continuer le travail de déploiement
JonAs
- S1 (2011)
Finaliser le déploiement sous JonAs
sur
Vacances Noel
04/01/2011
21/01/2011
Comparer des
performances
24/01/2011
26/01/2011
S2
Déployer sous Spring
S3
Comparer la performance
- S4
Finaliser du
soutenance
rapport
et
préparer
la
Préparer la soutenance
36
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
37
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
38
X.
Références
1.
2.
3.
4.
5.
6.
7.
8.
fr.wikipedia.org
www.springsource.com
www.springbyexample.org
jonas.ow2.org/
www.01net.com
www.developpez.com
blog.ippon.fr
"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
39