Socle technique des applications Java EE : dans le WAR ou dans le serveur ?

Le sujet du packaging des applications Java EE a suscité récemment des échanges riches sur notre mailing-list interne. C'est pourquoi nous avons trouvé intéressant d'en publier une synthèse. Nous remercions Dominique Jocal pour avoir réalisé cette synthèse, ainsi que les participants à ce débat : Benoît Lafontaine, Mikael Robert, Bertrand Paquet, Marc Bojoly - et nous vous souhaitons une bonne lecture !

Un projet de montée en version ou de changement de serveur d’application Java et de JVM est l’occasion pour une direction technique de se pencher à nouveau sur la stratégie d’empaquetage des applications : doivent-elles embarquer leur socle technique, ou s’appuyer sur celui présent dans le serveur d’application ?

La quasi-totalité des frameworks techniques utilisés par les applications sont présents dans les serveurs récents. 2 stratégies sont alors possibles pour empaqueter les “webapps” (application web Java) :

• “full webapp” : l’application embarque ses versions de frameworks techniques comme SLF4J et LOG4J, Hibernate, CXF, iText.... Elle n’utilise du serveur d’application - par ex. JBoss - que quelques services de connexions HTTP, SQL, MOM, annuaire d’objet...
• “full server” : la webapp n’embarque que les frameworks absents du serveur, par exemple iText. Elle utilise tous les autres frameworks techniques déjà présents dans le serveur dans leurs versions présentes.

Mettons-nous dans un cas de portefeuille applicatif, au demeurant très courant: un SI Java de plusieurs dizaines d’applications construites sur une décennie, bâties sur 2 ou 3 générations de socles techniques - les frameworks techniques d’injection, de logging, de persistance, d’IHM, de génération PDF, etc - exécutées sur une seule machine virtuelle Java et une seule version de serveur d’application sous licence/support éditeur, sauf rares exceptions. Dans ce contexte également, citons les besoins et contraintes exprimés par les équipes techniques:

• Rester en phase avec l’évolution des serveurs d’applications qui embarquent toujours plus de services techniques.
• Diminuer globalement l’effort d’intégration et de dépannage sur les frameworks techniques.
• Continuer à bénéficier au maximum des outils d’administration et de supervision des ressources techniques, sans avoir à compenser en écrivant soi-même ces outils.

On peut être alors tenté pour ce cas d’adopter la stratégie “full server”:

• on pourra toujours suivre l’évolution du serveur, pas de conflit avec les frameworks techniques embarqués en webapp;
• la diminution voire la disparition de la diversité de frameworks rationalise de facto l’effort d’intégration et de dépannage;
• la possibilité d’utiliser les outils fournis avec le serveur est par définition garantie.

En revanche une contrainte apparaît: monter en version sur un framework technique pour résoudre un problème ou gagner une fonctionnalité sur la moindre application implique de mettre à niveau le serveur, la webapp n'est pas seule impactée.

Or les retours d’expérience montrent que cette contrainte a non seulement de grandes chances d’arriver, mais peut s’avérer bloquante. Benoit, architecte Octo explique que “migrer ensemble toutes les applications sur une version donnée est une mission quasi-imposssible”. “L’application X subit le bug spécial de la version x.y.z qui n’est pas compatible avec telle version de telle librairie, et à côté l’application Y qui ne doit plus évoluer ne sera jamais compatible avec cette fameuse version de librairie”. Fondamentalement, explique Marc, “les cycles de vie des applis sont trop différents entre eux et encore différents de celui d'une production”.

Enfin, il est possible de “rester en phase avec les évolutions des serveurs” en stratégie “full webapp” grâce à la notion de profil. “Un profil très léger, avec uniquement un conteneur web et quelques services d'administration” permet en même temps de disposer d’outillage prêt à l’emploi pour l’Exploitation en laissant les webapps embarquer des socles techniques plus importants. Un profil léger peut être obtenu par exemple en utilisant un JBoss allégé, ou en se contentant d’un simple conteneur de servlet comme Tomcat.

En conclusion, pour ce cas de SI, on préconise plutôt la stratégie “full webapp” sur serveur à profil léger. La webapp ne délègue alors au serveur un service technique que lorsque :

• il vient avec un outillage prêt à l’emploi, différenciateur et accélérateur pour la Production comme une configuration centralisée, une reconfiguration à chaud...

• l’API est mature et stable.

L’accès aux SGBDR, aux messageries applicatives, ou encore aux logs, sont des exemples de tels services, si votre serveur d’applications dispose des outils précités. Le cas ou la strategie full-serveur pourrait être préconisée serait alors sur un ensemble d'applications ayant le même cycle de vie et maintenues par la même équipe.