Conférence: Apache TomEE

En Java EE, il est commun d’utiliser des serveurs d’applications qui vont réaliser le déploiement de nos applications War et servir de conteneurs à tous les traitements réalisés. Le problèmes posé par ces serveurs est qu’ils sont généralement assez volumineux et qu’ils consomment beaucoup de ressources serveurs. Au Java User Group de Lyon, Jean-Louis Monteiro est venu nous présenter le serveur d’applications Apache TomEE qui allie les capacités du Java EE et la légéreté de Tomcat, le conteneur de servlets de la fondation Apache.apachetomee

Le speaker

Jean-Louis Monteiro est un architecte logiciel Java EE senior qui a un CV assez bien rempli. Actuellement, il fait partie de l’Apache Software Foundation dispense également des cours dans certaines universités françaises. Il a également été membre du groupe JCP (Java Community Process) en charge de la spécification EJB3.2. Il travaille sur le projet TomEE au sein de l’entreprise TomiTribe et vient nous en parler.

Serveurs d’applications

Les serveurs d’applications Java EE sont définis par le respect ou non de spécifications précisées par Oracle et Sun avant eux. Les serveurs d’applications certifiés possèdent toutes les spécifications nécessaires. Les spécifications Java EE sont très nombreuses. Elles contiennent toutes les fonctionalités qui ont été ajoutées au Java EE depuis sa création. Ainsi certaines spécifications, qui ne sont plus beaucoup utilisées par les développeurs, sont conservées afin de garantir un fonctionnement normal en cas de passage d’anciennes applications sur de nouveaux serveurs d’applications. Afin de limiter la taille des spécifications, un second groupe de spécifications a été créé: le Web Profile. Ce groupe contient un nombre plus restreint de spécifications ce qui permet aux serveurs d’applications certifiés Web Profile d’être plus léger.

C’est sur cette base de Web Profile que TomEE a été pensé en 2011. Il a été conçu à partir d’une base de code mature ce qui le rend aujourd’hui stable malgré le fait qu’il soit récent sur le marché des serveurs d’applications. TomEE est la combinaison du conteneur de servlets Apache Tomcat et de plugins Java EE comme les spécifications de Transaction (JTA) ou REST (JAX-RS). L’objectif du projet était de réaliser un serveur d’applications qui soit léger et certifié Java EE afin que les applications puissent être transférées de TomEE ou vers TomEE sans difficulté.

Packaging de TomEE

Aujourd’hui plusieurs packaging de TomEE sont disponibles. Le package de base respecte les attentes de la certification Web Profile. Le second package contient en plus la spécification JAX-RS permettant de réaliser des Web Services REST. TomEE Plus contient un ensemble de spécifications supplémentaires dont JAX-WS pour les Web Services SOAP et JMS pour la gestion de queues JMS. Enfin le dernier package disponible est TomEEPluMe qui inclut également Mojarra (implémentation de JSF par Oracle en open sources) et EclipseLink (ensemble d’API offrant une solution de persistance assez complète et implémentant notamment la spécification JPA).

Particularités

Tous ces packages fonctionnent de la même manière, c’est à dire qu’il est facile d’ajouter une nouvelle librairie au serveur TomEE car à son démarrage il va lancer un scan du dossier lib afin d’identifier les nouvelles librairies. L’architecture de TomEE reste la même que Tomcat, les dossiers sont identiques malgré l’import de nombreuses fonctionnalités supplémentaires. Cela fait d’ailleurs parti des trois règles de développement de TomEE:

  • be light
  • be certified : afin d’assurer la portabilité des applications
  • be Tomcat : toutes les applications qui fonctionnent sur Tomcat doivent pouvoir fonctionner sur le serveur TomEE

Lors du développement du serveur d’application, un accent a été mis sur le fait de faire une véritable intégration des différentes spécifications. Ainsi, sur un serveur d’applications lors du déploiement de l’application, plusieurs scans sont lancés à la recherche d’annotations qui vont définir le comportement de certaines classes. Par exemple, Hibernate va rechercher les Entity et CXF va rechercher les WebServices REST. Ces scans multiples sur toutes les classes de l’application ont un coût important aux niveaux de la mémoire et du CPU. Dans TomEE, un seul scan est réalisé, et les données récupérées vont ensuite être données à qui en a besoin.

Tous ces changements au niveaux du serveur d’application lui permettent d’être très rapide au démarrage et d’être de manière générale plus léger. Très simplement, le Zip contenant TomEE Plus respectant les spécifications Java EE a une taille de 41,5Mo, nettement en dessous des 128Mo de JBoss. De plus, le serveur d’application TomEE à un temps moyen de démarrage inférieur à 1 seconde et sa consommation générale de mémoire est réduite.

Les tests sur TomEE sont réalisés en permanence avec l’outil Arquillian. L’intégration des développements est réalisée très rapidement sur de petites machines dont la JVM utilise le minimum de mémoire. Parmi ces tests, sont présents les tests de certification d’Oracle qui sont d’après les dires du présentateur très rigoureux et assez longs à passer en temps normal. Cependant, toujours d’après lui, TomEE permet la validation de ces tests en un temps record inférieur à tous les autres serveurs d’applications.

Avenir

En 2013, Tomcat représentait 54% des serveurs d’applications Java. L’objectif de TomEE est de participer à l’amélioration de l’ensemble de ces serveurs d’applications en apportant une intégration fluide des spécifications Java EE. TomEE grandit et est maintenant facilement utilisable graĉe aux communautés d’autres projets qui l’intègrent de plus en plus comme IntelliJ, Jellastic (Infrastructure as a Service), Stackato

Petite citation du présentateur

« Ear are dead » – Jean Louis Monteiro.

J’ai souhaité mettre ici cette citation car elle complète ce que je pensais déjà depuis mon précédent stage et la découverte de Maven. Les Ear sont des Jar dont l’extension a été modifiée. Ils sont composés d’autres archives Jar (ou War) et sont déployables sur des serveurs d’applications. Leur fonctionnement se base sur un descripteur de déploiement XML présent dans le dossier META-INF. Aujourd’hui, le packaging Java étant majoritairement réalisé par Maven ou d’autres outils similaires, il est devenu inutile d’avoir une surcouche supplémentaire de type Ear. Ce sujet ne sera pas approfondi ici.

spacer

Laisser un commentaire