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
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 transactionnel 1. 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ées 2. 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 applicatifs 3. 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 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 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 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 datasource.classname datasource.username datasource.password datasource.mapper CSC5002_9 jdbc:mysql://www-inf.it-sudparis.eu:3306/csc5002_9 com.mysql.jdbc.driver adm_csc5002_9 Monday11October 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 AdministratorClient.jar Client Utilisateur MailBoxclient.jar EAR Module EJB Ejb3.jar META-INF 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. Client Administrator.jar AdministratorClient.class META-INF applicationclient.xml o Le module EJB Figure 10 - Struture du client 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 DirectoryManager DirectoryManagerBean MailBoxManager MailBoxManagerBean User Message Entity META-INF persistence.xml 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/lib 7. 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 AbstractStatelessSessionBean 9 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 User 10 : 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 { } @Override return template.find("from User"); public Collection<User> findusersbyid(string id) throws DataAccessException { } } @Override return template.find("from User u where u.user_login =?", id); 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 6 11. 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 (JOPE 12 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 13 http://dlc.sun.com.edgesuite.net/glassfish/eclipse/ 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