Vous trouverez dans cette annexe les informations à connaître pour packager et déployer simplement votre projet sur un serveur d'applications.
Mise en boîte du projet
JAR, WAR ou EAR ?
Pour faciliter l'étape de déploiement d'un projet, il est coutume de mettre en boîte le code dans un fichier ressemblant en tout point à une archive, à l'exception de la compression. Une application web Java EE peut être empaquetée dans une archive Java (JAR), dans une archive Web (WAR) ou dans une archive dite "d'entreprise" (EAR). En réalité, sur le principe ces trois formats ne diffèrent que par leur extension : ce sont tous des fichiers JAR standard ! C'est uniquement par l'usage que les différences apparaissent.
Quand utiliser un format d'archive en particulier ?
L'utilisation de formats différents rend possible l'assemblage de différentes applications Java EE partageant des composants identiques. Aucune étape de codage supplémentaire n'est alors requise, seul l'assemblage (ou packaging) des différents éléments constituant une application dans des fichiers JAR, WAR ou EAR joue un rôle. Voilà comment se définit habituellement l'usage des trois formats :
- les modules EJB, qui contiennent les EJB (des classes Java) et leurs éventuels fichiers de description, sont packagés dans une archive JAR classique, qui contient un fichier de configuration nommé ejb-jar.xml dans son répertoire /META-INF ;
- les servlets, les pages JSP, les éléments de présentation et de design et les classes métier Java sont packagés dans une archive WAR, qui n'est rien d'autre qu'une archive JAR classique contenant un fichier web.xml dans son répertoire /WEB-INF ;
- les archives JAR et WAR sont à leur tour packagées dans une archive globale EAR, qui n'est rien d'autre qu'une archive JAR classique contenant un fichier application.xml dans son répertoire /META-INF, et qui sera finalement déployée sur le serveur.
L'intérêt majeur d'isoler les EJB dans une archive séparée est de pouvoir séparer convenablement les données et le code métier du reste de l'application. Et c'est exactement ce que l'archive EAR permet : les EJB vont dans un JAR, le contenu lié de près ou de loin au web va dans un WAR (qui au passage, n'est pas forcément un fichier, mais plutôt une structure représentant l'arborescence du projet). La conséquence de cette séparation, c'est que les deux modules JAR et WAR n'ont pas accès aux mêmes ressources : le module web peut accéder aux EJB (typiquement, des beans), le module EJB peut accéder aux éventuelles ressources définies globalement dans le module englobant EAR (typiquement, des bibliothèques), mais le module EJB ne peut pas accéder aux ressources définies dans le module web. Cette contrainte est voulue, et permet de rendre indépendant le module EJB qui doit être totalement découplé d'une quelconque information liée à la vue.
Cette isolation forcée permet ainsi de s'assurer qu'un développeur ne peut pas mélanger les concepts, que ce soit par mégarde ou par ignorance.
En outre, grâce à cette nette séparation il devient très simple de réutiliser le module EJB depuis d'autres applications web, Java SE ou autres. Si celui-ci contenait des références aux servlets ou Facelets JSF, par exemple, il serait alors compliqué de les utiliser dans d'autres contextes, en particulier dans un contexte Java SE.
Pour faire une analogie avec des concepts que vous maîtrisez déjà, vous pouvez comparer ce système avec le fait que je vous interdise d'écrire des scriptlets dans vos JSP, ou avec le principe de la programmation par contrat (interfaces et implémentations). En somme, placer vos EJB dans un module séparé est une bonne pratique.
Cependant, dans le cadre de projets de faible envergure, il est fréquent de ne pas se soucier de cette pratique. C'est encore plus courant avec des développeurs débutants, pour lesquels il est souvent difficile de comprendre et de se souvenir de la répartition des différents éléments. Ainsi, passer outre la contrainte de découpage et tout ranger dans un unique module WAR rend le déploiement plus aisé aux développeurs inexpérimentés, et leur facilite donc l'entrée dans le monde Java EE. Tôt ou tard, ils finiront quoi qu'il arrive par assimiler la notion de couches, et placeront leurs EJB dans un module séparé.
Par ailleurs, ce mode d'intégration simplifié fait partie d'un concept plus global intitulé EJB Lite, qui est destiné à rendre possible l'utilisation d'EJB dans une application sans devoir charger l'intégralité des services que peut fournir un conteneur EJB. Cela sort du cadre de cette annexe, mais pour information sachez que c'est une des principales différences entre la version complète de GlassFish, et la version "web profile" que je vous ai fait installer.
Et donc pour déployer une application, quand utiliser un WAR, et quand utiliser un EAR ?
En résumé, deux possibilités s'offrent à vous :
- si votre projet utilise des EJB et est déployé sur un serveur d'application Java EE, alors vous pouvez suivre la recommandation et utiliser une archive EAR, qui sera elle-même constituée d'une ou plusieurs archives WAR et JAR. Vous pouvez également ignorer la bonne pratique courante et utiliser un unique fichier WAR, mais sachez que derrière les rideaux, votre serveur va en réalité automatiquement englober votre archive… dans une archive EAR !
- si votre projet web ne fait pas intervenir d'EJB, alors seule une archive WAR est requise. En outre, si votre serveur n'est pas un serveur d'applications Java EE au sens strict du terme, comme Tomcat ou Jetty par exemple, alors vous ne pourrez pas utiliser le format EAR, vous devrez obligatoirement packager vos applications sous forme d'archives WAR.
Mise en pratique
Nos projets sont de très faible envergure, ne font que très peu intervenir les EJB et nous débutons le Java EE : nous allons donc apprendre à déployer un projet sous forme d'une unique archive WAR.
Prenons pour exemple le projet intitulé pro que nous avons développé dans le cadre du cours. Pour l'exporter sous forme d'archive WAR depuis Eclipse, rien de plus simple ! Faites un clic droit sur votre projet dans le volet de gauche de votre espace de travail Eclipse, puis choisissez Export > WAR File.
Une fenêtre s'ouvre alors, dans laquelle vous devez choisir un emplacement pour enregistrer l'archive qui va être créée.
Vous pouvez par ailleurs choisir d'optimiser votre WAR pour un type de serveur en particulier, et d'inclure les fichiers source de votre code dans l'archive générée. Cliquez alors sur le bouton Finish, et votre WAR apparaîtra alors dans le dossier que vous avez spécifié sur votre disque (voir la figure suivante).
Voilà tout ce qu'il est nécessaire de faire pour exporter votre projet dans une archive WAR !
Déploiement du projet
Contexte
Habituellement, le développement d'une application et la première phase de tests (les tests unitaires, et éventuellement d'autres tests plus spécifiques) sont réalisés depuis un serveur local, très souvent intégré à Eclipse (ou Netbeans, ou autre IDE similaire).
Ensuite, il est courant qu'un premier déploiement ait lieu sur une seconde plate-forme, dite "de qualification". Celle-ci correspond en général à une réplique plus ou moins fidèle de l'environnement de production final.
Enfin a lieu le déploiement sur la plate-forme de production, la plate-forme finale sur laquelle va tourner l'application ouverte aux utilisateurs.
Par ailleurs, il est important de noter que parfois le développement et la qualification sont effectués sur un type de serveur d'applications, par exemple Tomcat ou GlassFish installés sur une distribution Debian, puis l'application est finalement déployée sur un serveur dont la configuration est différente en production (bien souvent pour des raisons de coûts ou de simplicité), par exemple un serveur WebLogic installé sur une distribution OpenSuse.
Bref, vous avez compris où je veux en venir : une même application est amenée à être utilisée dans différents contextes et sur différentes configurations, et il est donc nécessaire de pouvoir simplement installer et mettre à jour une application sur les plate-formes de qualification et de production sans contraintes.
Voilà pourquoi le système d'archives a été mis en place : en exportant votre application dans une archive WAR ou EAR, vous vous assurez de pouvoir la transporter et manipuler de manière extrêmement simple !
Mise en pratique
Pour commencer, si ce n'est pas déjà, fait retirez le projet pro de votre serveur Tomcat intégré à Eclipse. Pour ce faire, il vous suffit de faire un clic droit sur le projet dans le volet Servers et de choisir Remove (voir la figure suivante).
Dans la fenêtre d'avertissement qui s'ouvre alors, confirmez en appuyant sur Ok. Ainsi, nous sommes maintenant certains que notre application n'existe plus dans Tomcat. Fermez ensuite Eclipse.
Nous allons maintenant lancer Tomcat manuellement. La manipulation est différente selon le système d'exploitation que vous utilisez :
- depuis Windows, rendez-vous dans le dossier /bin de votre installation de Tomcat, et lancez le fichier intitulé startup.bat ;
- depuis un système Unix (Linux ou Mac OS), ouvrez un Terminal, déplacez-vous dans le dossier de votre installation de Tomcat, et exécutez la commande
bin/startup.sh.
Votre serveur correctement lancé, vous pouvez dorénavant accéder à l'URL http://localhost:8080 depuis votre navigateur pour vérifier que votre serveur fonctionne, et vous pouvez également vérifier que vous ne pouvez pas accéder à l'URL http://localhost:8080/pro/inscription, autrement dit que l'application pro n'est pas encore disponible.
Il ne nous reste plus qu'à déployer notre application sur notre server Tomcat. Pour cela, rien de plus simple : nous devons déposer notre archive WAR dans le répertoire webapps de Tomcat. Copiez-collez donc votre archive pro.war dans ce dossier, puis rendez-vous à nouveau sur l'URL http://localhost:8080/pro/inscription depuis votre navigateur. Vous devez alors constater que votre application fonctionne : Tomcat a automatiquement analysé et déployé votre archive WAR !
Par ailleurs, vous pourrez également vérifier que dans le répertoire webapps existe dorénavant un dossier intitulé pro : c'est Tomcat qui l'a créé à partir du contenu de votre fichier WAR. Vous y trouverez toutes vos classes compilées dans le répertoire WEB-INF/classes, vos JSP et autres éléments de design. Si vous aviez choisi d'intégrer les fichiers source de l'application à l'archive lors de l'export depuis Eclipse, alors vous y trouverez également vos fichiers source Java.
Sous GlassFish, l'opération est sensiblement la même :
- lancez votre serveur en vous rendant dans le dossier /glassfish/bin, et en exécutant le fichier startserv ou startserv.bat selon que vous utilisiez Unix ou Windows ;
- déployez alors automatiquement votre archive en la déposant dans le répertoire autodeploy présent dans /glassfish/domains/nom-de-votre-domaine/.