Jeudi 21 juin avait lieu le lancement officiel de JBoss EAP (Enterprise Application Platform) 6 la dernière version “Enterprise” du serveur Java EE de Red Hat. La précédente version EAP, la 5.1 remontait à 2009 et rencontrait de plus en plus de critiques en terme de performance ou d’obsolescence de certains modules fournis. Si à ces plaintes on ajoute le fait que Java EE 6 soit sorti il y a 2 ans et demi, on comprendra la pression “amicale” que les clients de JBoss font peser sur l’éditeur depuis quelques mois pour la sortie de cette version commerciale supportant le “full profile” de Java EE 6. Autant dire que Red Hat était attendu au tournant pour cette sortie et sans dévoiler trop la suite de ce post on peut dire qu’ils semblent avoir en grande partie répondu à ces attentes.
Un historique compliqué
Avant de parler du très prometteur EAP 6 et des produits qui l’accompagnent, il est important de revenir sur les dernières version d’EAP et d’évoquer les difficultés rencontrées par Red Hat sur celles-ci.
La version EAP 4.2 (sortie mi 2007) était la première mouture à sortir à la mode Red Hat (qui avait acquis JBoss début 2006). Les versions antérieures étaient des versions communautaires pour lesquelles le client pouvait payer un support. Cette nouvelle approche introduisait d’importants changements dans la configuration et le fonctionnement du serveur pour marquer cette nouvelle ère de version “Enterprise”. L’EAP 4.2 a eu de très bons retours. Le serveur qui implémentait J2EE 1.4 (avec quelques previews de techno Java EE 5 comme les EJB 3 ou JSF 1.2) était réputé robuste et démarrait (à vide) en un peu plus de 10 secondes.
La version EAP 5 en revanche (sortie mi 2009) essuya beaucoup de critiques. Sortie près de 3 ans après le standard Java EE 5 qu’il implémentait, EAP 5 avait demandé des efforts de développement assez considérables (plus de 4 ans) et consistait en une refonte totale du socle du serveur avec un micro noyau et un système de fichiers virtuel qui furent à l’origine de bien des déboires. L’engin qui démarrait en 40 secondes à vide et proposait un mode de configuration assez complexe en complète rupture avec la version 4.2, contribua beaucoup à dégrader l’image de JBoss qui par ailleurs travaillait à des projets très prometteurs et innovants comme CDI, HornetQ ou Infinispan. Beaucoup de clients décidèrent de ne pas migrer vers EAP 5 et de rester en 4.3 plus stable, moins gourmande mais avec des technos vieillissantes.
Au moment de la sortie de Java EE 6 en décembre 2009, JBoss (partie prenante de la spec avec CDI et Bean Validation) se devait de proposer un serveur supportant cette norme rapidement. La version communautaire JBoss AS 6, basée sur le même micro noyau qu’EAP 5, fut livrée en 7 étapes (!) entre décembre 2009 et décembre 2010. Néanmoins JBoss AS 6 tentait de corriger des défauts de la version précédente et repensait encore la configuration du serveur pour la rendre plus centrale par rapport à AS 5 et donc EAP 5, ce qui était louable mais obligeait une nouvelle fois les utilisateurs à tout réapprendre ou presque.
Java EE 6 étant une avancée majeure dans l’histoire de Java EE, beaucoup de clients JBoss commencèrent à expérimenter sur JBoss AS 6 pensant qu’il finirait par servir de socle à JBoss EAP 6. Mais il n’en fut rien. Dans le courant de l’année 2010, Red Hat décida de limiter JBoss AS 6 à la certification Web profile de Java EE 6 et lança le projet JBoss AS 7 : une nouvelle refonte totale du socle Jboss.
Et nous y voilà : début 2012 JBoss AS 7.1.0 était certifié Web Profile et Full Profile et quelques mois plus tard, Red Hat délivrait enfin JBoss EAP 6 basé sur JBoss AS 7.1.2.
Ce rapide historique permet de mieux comprendre la pression qui pesait sur les épaules de Red Hat pour la sortie de ce nouveau serveur. En résumé et pour mieux comprendre les critiques des détracteurs de JBoss :
- Certains clients attendaient cette release depuis 5 ans (ceux qui n’étaient pas passés en EAP 5)
- EAP 6 constitue la troisième rupture du socle du serveur (4 si on compte AS 6) depuis le rachat de JBoss par Red Hat. Certaines mauvaises langues disent même que Red Hat ne livre que des version 1.0 de son serveur depuis 7 ans.
Quoi de neuf dans EAP 6 ?
Réponse facile : tout ! Les principaux points évoqués lors de la conférence furent les suivants
Un socle modulaire
Le socle tout d’abord repose désormais sur JBoss Module, un projet ambitieux de modularité qui, contrairement aux socles d’autres serveurs concurrents, n’utilise pas OSGi mais une approche beaucoup plus simple pour charger les différents services et les mettre à disposition des applications. On aurait pu craindre que Red Hat ait choisi une solution “propriétaire” face à OSGi, mais en fait leur démarche est d’accompagner Java Module, la fameuse JSR 277 qui devrait voir le jour avec Java 8 et permettra à Java de régler les soucis liés aux classpath et aux dépendances. JBoss Module suit la JSR en question et essaye de l’influencer. L’objectif à terme étant d’être compatible avec elle. Cela n’empêche pas JBoss EAP de supporter OSGi pour les applications déployées dans le conteneur.
Ce socle permet aujourd’hui à JBoss EAP de démarrer en 3 secondes (à vide) et d’adapter le fonctionnement du serveur beaucoup plus facilement que dans les versions antérieures. Si l’efficacité de JBoss Module ne fait pas débat, mes premières expériences sur sa mise en oeuvre dans EAP 6 montre que Red Hat a encore un peu de travail à faire sur la granularité des modules : impossible, par exemple, d’utiliser une implémentation de JSF intégrée dans sa Web App bien que sur le papier ce soit parfaitement possible.
Une configuration centralisée
La configuration est désormais entièrement centralisée dans un fichier (face à la dizaine de fichiers de configuration des versions précédentes c’est une révolution). Au dela de l’édition pure et simple du fichier, on peut intervenir sur con contenu via une interface d’administration flambant neuve, une ligne de commande (réclamée depuis longtemps) et des API Rest qui raviront les veinards qui font du Devops. Seule petite ombre au tableau la disparition de la console JMX que beaucoup de participants à la conf semblaient regretter.
L’architecture et le fonctionnement des clusters est désormais grandement facilitée grâce à l’introduction de la notion de domaine, déjà employée par d’autres éditeurs. Ce concept permet de fédérer l’administration de plusieurs serveurs en un seul endroit et de définir facilement des rôles pour chaque serveur dans un domaine. Par ailleurs la notion de groupe de serveurs ajoute un niveau de granularité supplémentaire.
La performance
Au dela du temps de démarrage très court, certains composants de JBoss EAP sont réputés pour être des booster de performance. Lors de la conférence deux de ces composants on été mis en avant :
- HornetQ : la solution de messaging mainte fois primée pour les records qu’elle a battus
- Infinispan : la solution de cache distribué (data grid) intégré à JBoss désormais et qui permet de répliquer efficacement les sessions au sein des clusters JBoss, fait office cache de second niveau hibernate et sert de socle à la nouvelle solution NoSQL de JBoss
Côté performance j’ajouterai les travaux importants d’optimisation de Weld : l’implémentation CDI de JBoss. Entre la version 1.0 de Weld et la 1.1.8 incluse dans EAP 6 le temps de démarrage a été divisé par 10.
Les nouveaux produits
Lors de cette conférence Red Hat a annoncé le lancement de nouveaux produits :
- JBoss Datagrid qui est la solution NoSQL de RedHat basée sur Infinispan. En y ajoutant Hibernate Search (basé sur Lucene) le support du multi-tenancy et un mécanisme de Map Reduce, Red Hat se lance sur le marché des bases NoSQL. Compte tenu des retours très positifs autour d’Infinispan, il y a fort à parier que ce serveur soit un des produits à suivre du secteur
- JBoss BRMS : une refonte complète de la suite BPM de JBoss. Cette mouture abandonne le langage jpdl au profit de la norme BPMN 2.0. Compte tenu de l’historique assez mouvementé autour de JBPM et de Jboss ESB l’avenir de ce produit est plus incertain. L’acquisition toute récente de Fuse Source par Red Hat risque de modifier la stratégie autour de BRMS. A suivre donc aussi (mais d’un peu plus loin 😉 ).
- JBoss Operation Network. JBoss ON n’est pas nouveau mais a été refondu pour supporter EAP 6. Il est désormais possible de l’utiliser pour piloter l’ensemble des serveurs et clusters de votre infrastructure.
Conclusion
Comme beaucoup d’utilisateurs des serveurs JBoss, j’ai pas mal pesté ces dernières années sur les problèmes techniques des versions AS et EAP. Ce n’était qu’une expérience de développeur, mais je crois savoir que les équipes de prod ont vécu des moments difficiles avec les versions passées.
Depuis six mois je travaille avec JBoss AS 7 et EAP 6 depuis quelques semaines et je sens clairement la différence. Même si tout n’est pas encore totalement en place, on a le sentiment que le socle est enfin robuste et permettra à Red Hat d’aller de l’avant pour dépasser la version 1.0 de son serveur. Le 21 juin 2012 marque à mon sens le premier jour du reste de la vie de JBoss EAP.
