Dans Java tout est objet mais tout n’est pas EJB. Tel est le jeu de mots que nous avons choisi pour alimenter le débat sempiternel sur l’utilisation des Enterprise Java Beans dans les applications J2EE. L’engouement pour ces composants est tel que certains architectes n’hésitent pas à les implémenter dans leurs applications quelques soient les contraintes et le contexte d’utilisation. Un rapport du Gartner Group estime d’ailleurs que les entreprises ont mondialement dépensé un peu plus d’un billion de dollars US pour intégrer les EJB à leurs applications.

A dire vrai, les EJB sont des composants robustes qui facilitent le déploiement des applications dans les environnements fortement distribués. Ils sont également un bon choix technologique lorsqu’on souhaite construire des middletiers ou des passerelles vers les systèmes hérités [180] (vieilles applications écrites en Cobol et exécutées sur un gros système). Le revers de la médaille est que les EJB sont des composants très complexes qui nécessitent une main d’œuvre très qualifiée (et donc très chère).

La couche de complexité technique ajoutée par les EJB à l’architecture MVC n’est pas sans effet sur les performances de l’application. En effet les invocations multiples de leurs méthodes via le protocole RMI-IIOP sont extrêmement pénalisantes pour le temps de réponse. De plus des opérations comme l’instanciation, l’activation ou la passivation des beans sont gourmandes en processeur et en mémoire. Notons par ailleurs que les EJB ne peuvent pas être exécutés sur un conteneur de servlets comme Tomcat. Ils ont besoin d’un conteneur spécial comme celui d’IBM (Websphere) ou de BEA Systems (Weblogic). La politique de tarification de ces sociétés est très agressive parce qu’ils vendent leurs produits dans un seul bloc monolithique avec aucune possibilité de découplage entre la couche qui gère les JSP/Servlets et celle qui gère les EJB. A moins d’envisager l’utilisation d’un conteneur gratuit [181] comme JBOSS il faut donc évaluer les pour et les contre des EJB aussi bien en termes de complexité technique qu’en termes de coûts (rappelons le encore une fois la performance n’est pas seulement une affaire de débit et de temps de réponse mais également une affaire de coûts).

En pratique on peut développer avec les JSP, les servlets et les Java Beans tout ce qu’on peut développer avec les EJB. Soulignons à ce sujet que le framework Struts ne contient pas d’EJB et cela n’affecte ni sa popularité ni son applicabilité à plusieurs types de sites (y compris les sites de commerce électronique). Dans bien des cas les EJB peuvent s’avérer surdimensionnés par rapport aux besoins d’affaires. Ils sont certainement un bon choix technologique pour l’implémentation des middletiers dans des environnements fortement distribués mais ils peuvent devenir de véritables goulots d’étranglement dans les applications simples et centralisées (exemple un site de commerce électronique d’une PME dans lequel il n’y a aucune interaction avec un système d’héritage  [182]).

Notes de bas de page

[180] Traduction littérale de legacy systems

[181] Très souvent les licences sont gratuites mais il y a plusieurs coûts cachés liés à la formation, à la maintenance à l’ajout de modules supplémentaires…
[182] Legacy system