Il est actuellement un peu déroutant car il existe maintenant plusieurs modèles de composants dans Java EE. Il s'agit de Beans gérés CDI , EJB3 et JSF .
CDI est le petit nouveau du quartier. CDI haricots disposent dependency injection
, scoping
et un event bus
. Les beans CDI sont les plus flexibles en termes d'injection et de cadrage. Le bus d'événements est très léger et parfaitement adapté aux applications Web les plus simples. En plus de cela, CDI expose également une fonctionnalité très avancée appelée portable extensions
, qui est une sorte de mécanisme de plug-in permettant aux fournisseurs de fournir des fonctionnalités supplémentaires à Java EE qui peuvent être rendues disponibles sur toutes les implémentations (Glassfish, JBoss AS, Websphere, etc.) .
Les beans EJB3 ont été modernisés à partir de l'ancien modèle de composant EJB2 hérité * et ont été les premiers beans de Java EE à être gérés via une annotation. Les haricots EJB3 disposent dependency injection
, declarative transactions
, declarative security
, pooling
, concurrency control
, asynchronous execution
et remoting
.
L'injection de dépendances dans les beans EJB3 n'est pas aussi flexible que dans les beans CDI et les beans EJB3 n'ont aucun concept de portée. Cependant, les beans EJB3 sont transactionnels et mutualisés par défaut ** , deux choses très utilisables que CDI a choisi de laisser dans le domaine d'EJB3. Les autres éléments mentionnés ne sont pas non plus disponibles dans CDI. EJB3 n'a cependant pas de bus d'événements propre, mais il a un type spécial de bean pour écouter les messages; le bean piloté par message. Cela peut être utilisé pour recevoir des messages du système de messagerie Java ou de tout autre système doté d'un adaptateur de ressources JCA. L'utilisation d'une messagerie complète pour des événements simples est beaucoup plus lourde que le bus d'événements CDI et EJB3 définit uniquement un écouteur, pas une API de producteur.
Les Beans gérés JSF existent dans Java EE depuis que JSF a été inclus. Eux aussi comportent dependency injection
et scoping
. JSF Managed Beans a introduit le concept de portée déclarative. A l'origine, les portées étaient plutôt limitées et dans la même version de Java EE où les beans EJB3 pouvaient déjà être déclarés via des annotations, les Beans gérés JSF devaient encore être déclarés en XML. La version actuelle de JSF Managed Beans est également finalement déclarée via une annotation et les étendues sont étendues avec une étendue de vue et la possibilité de créer des étendues personnalisées. L'étendue de la vue, qui mémorise les données entre les requêtes sur la même page, est une fonctionnalité unique de JSF Managed Beans.
En dehors de la portée de la vue, il reste très peu de choses pour JSF Managed Beans dans Java EE 6. La portée de vue manquante dans CDI est malheureuse, car sinon CDI aurait été un super ensemble parfait de ce que propose JSF Managed Beans. Mise à jour : Dans Java EE 7 / JSF 2.2, un @ViewScoped compatible CDI a été ajouté, faisant de CDI ce super ensemble parfait. Mise à jour 2 : Dans JSF2.3, les beans gérés JSF ont été déconseillés au profit des beans gérés par CDI.
Avec EJB3 et CDI, la situation n'est pas si claire. Le modèle de composant et l'API EJB3 offrent de nombreux services que CDI n'offre pas, de sorte que l'EJB3 ne peut généralement pas être remplacé par CDI. D'autre part, CDI peut être utilisé en combinaison avec EJB3 - par exemple en ajoutant la prise en charge de la portée aux EJB.
Reza Rahman, membre du groupe d'experts et réalisateur d'une implémentation CDI appelée CanDI, a souvent laissé entendre que les services associés au modèle de composant EJB3 peuvent être modernisés sous la forme d'un ensemble d'annotations CDI. Si cela se produisait, tous les beans gérés dans Java EE pourraient devenir des beans CDI. Cela ne signifie pas que EJB3 disparaît ou devient obsolète, mais simplement que sa fonctionnalité sera exposée via CDI au lieu de via les propres annotations d'EJB comme @Stateless et @EJB.
Mettre à jour
David Blevins de TomEE et la renommée d'OpenEJB explique très bien les différences et les similitudes entre CDI et EJB sur son blog: CDI, quand sortir les EJB
* Bien que ce ne soit qu'un incrément de numéro de version, les beans EJB3 étaient pour la plupart un type de bean complètement différent: un simple pojo qui devient un "bean géré" en appliquant une simple annotation unique, vs le modèle dans EJB2 où un poids lourd et Un descripteur de déploiement XML trop détaillé était requis pour chaque bean, en plus du bean étant nécessaire d'implémenter diverses interfaces de composants extrêmement lourdes et pour la plupart dénuées de sens.
** Les beans session sans état sont généralement regroupés, les beans session avec état ne le sont généralement pas (mais ils peuvent l'être). Pour les deux types, la mise en commun est donc facultative et la spécification EJB ne l'exige pas dans les deux cas.