Enterprise JavaBeans : composants Java d'entreprise.

Conception

Développement

Chaque composant EJB est mis en œuvre par un ensemble d'objets :

• une instance EJB, contenant l'implémentation des méthodes métier et l'état (ensemble de valeurs métier) du composant, s'il en a un. Cette instance est poolée et n'est donc en fait présente qu'au moment où l'on s'en sert (lorsqu'un appel arrive sur l'EJB).
• un (ou plusieurs) objet d'interposition (EJBObject) du conteneur, placé entre le client et l'instance. En filtrant l'ensemble des appels adressés à l'instant, cet objet rend de manière automatisée et transparente divers services du conteneur (démarrage/arrêt de transactions, contrôle des droits d'appel en fonction de l'identité de l'appelant, chargement de l'instance à la demande - lazy loading). Cet objet peut adopter divers types d'interfaces : distribuée (IIOP), Service Web, locale (intra-JVM) ou asynchrone (JMS).

Les composants trouvent les éléments externes (autres EJB, sources de données, files de messages, etc.) auxquels ils veulent accéder via un annuaire compatible JNDI.

Assemblage

Une fois définis, les composants EJB peuvent être assemblés en un module EJB. On résoud alors, entre composants de ce module, les dépendances :

• transactionnelles : tel composant, recevant un appel de tel autre composant, effectue-t-il son travail dans la même transaction ? Dans une autre ?

Déploiement

Une fois assemblé, un module EJB peut être déployé dans un conteneur EJB. On résoud alors, pour les composants de ce module, les dépendances avec l'environnement de déploiement, telles que les dépendances de :

• persistance : où (dans quelle base, sur quelle machine) et comment (mapping) l'état de tel ou tel composant est enregistré ou lu.
• sécurité : à quels véritables utilisateur ou groupe d'utilisateur correspond le rôle applicatif contrôlé dans tel composant ?

Implémentation

L'API des EJB est définie dans le package javax.ejb.

Un EJB est développé à partir de :

• la classe de l'instance, héritant d'une interface EJB dépendant du type d'EJB
  • EntityBean pour un EJB Entité
  • SessionBean pour un EJB Session
  • MessageDrivenBean pour un EJB asynchrone
• l'interface composant (component interface, parfois générée à partir de la classe d'instance), pouvant hériter de :
  • EJBObject pour proposer une interface distribuable
  • EJBLocalObject pour proposer une interface locale
  • (générée au déploiement dans le cas d'un MDB)

La recherche des éléments externes doit s'effectuer en interrogeant le contexte de nommage de l'environnement du composant :

• <strong>java:comp/env/</strong>ejb/AutreEJB
• <strong>java:comp/env/</strong>jdbc/UneDataSource
• <strong>java:comp/env/</strong>jms/UneFileDeMessages
• <strong>java:comp/env/</strong>eis/UnConnecteurJCA
• etc.

Au moment du déploiement, les noms recherchés dans cet environnement local seront associés à des noms absolus d'objets déployés dans le serveur (tout ou partie de cette résolution de nom peut également s'effectuer lors de l'assemblage, s'il s'agit de désigner d'autres EJB locaux au module de l'EJB appelant).

Exemples

Un exemple de classe d'instance d'EJB Entité 2.0 est :

import <strong>javax.ejb</strong>.*;<br> <br> <strong>public abstract</strong> class SkillTree implements <strong>EntityBean</strong> {<br> <span class="codeComment"> /** <br> * Constructeur par défaut, toujours vide <br> */</span><br> public SkillTree() {}<br> <br> <strong>public </strong>SkillKey <strong>ejbCreate </strong>(Skill someRootSkill) throws <strong>CreateException </strong>{ <br> setRoot (someRootSkill);<br> return null; <span class="codeComment">// En CMP la clé est déduite</span><br>} <br> <br> <span class="codeComment"> /**<br> * Accesseurs CMP<br> */ </span><br> <strong>public abstract</strong> Object getRoot();<br><strong>public abstract</strong> void setRoot (Object);<br> <br> public void <strong>ejbStore</strong>() {<br> <span class="codeComment"> // Rien à faire ici<br> </span> }

public void <strong>ejbLoad</strong>() {<br> <span class="codeComment"> // Rien à faire ici<br> </span> }

public void <strong>ejbRemove</strong>() {<br> <span class="codeComment"> // Rien à faire ici<br> </span> }

public void <strong>ejbActivate</strong>() {<br> <span class="codeComment"> // Rien à faire ici<br> </span> }

public void <strong>ejbPassivate</strong>() {<br> <span class="codeComment"> // Rien à faire ici<br> </span> }

public void <strong>setEntityContext</strong> (EntityContext someContext) { <br> ejbContext = someContext; <br> } <br> <br> public void <strong>unsetEntityContext</strong>() { <br> } <br> <br> private <strong>EntityContext </strong>ejbContext;<br>}

Notes

• EJB	Version		1		2		3	Commentaire
  Technologie	Release		0	1	0	1
  Sessions	Stateless		OuiOui					Sans état conversationnel (donc optimisables en étant partagés par plusieurs clients)
  	Stateful							Avec état conversationnel (optimisés via pooling)
  	MDB		Non		Oui			Message-Driven Bean. Invoqué par des messages asynchrones (JMS)
  Entités	CMP	Champs simples	N/A	Attributs	Accesseurs abstraits
  		Langage de requête	N/A	Dépendant de l'implémentation	EJB QL
  		Relations	N/A	Manuel	Accesseurs abstraits, intégrité			Container-Managed Persistence : la persistance du composant est automatisée par le conteneur.
  	BMP	BMP	N/A	Oui				Bean-Managed Persistence : le composant gère lui-même sa persistance.
  	POJO	Champs simples	N/A				Oui
  		Langage de requête	N/A				EJB QL
  		Relations	N/A				Oui
  Invocation	Distribuée	Distribuée	Oui					Inter-processus.
  	Locale	Locale	Non		Oui			Intra-processus (JVM).
  	Service Web	Service Web	Non			Oui		Invoqué par des messages SOAP.
  	Timer	Timer	Non			Oui		Invoqué par le temps.
  	IIOP	IIOP	Non		Oui			Protocole de transport.
  Descripteur	Référence EJB	Référence EJB	Non	ejb-ref				Réference relative à un autre EJB
  	Réference ressource	Réference ressource	Non	resource-ref			Annotations resource	Réference relative à une ressource (DataSource, ConnectionFactory, etc.)
  	Référence rôle	Référence rôle	Non	role-ref				Référence relative à un rôle de sécurité
  	Environnement de ressource	Environnement de ressource	Non	resource-env-ref
  	Type d'identité d'exécution	Type d'identité d'exécution	RUN_AS_MODE	Non	run-as-mode			Propagation, spécifique ou système.
  	Identité d'exécution	Identité d'exécution	RUN_AS_IDENTITY	Non	run-as-identity			Identité si type d'identiié spécifique.
  Descripteur	Format		Objet sérialisé dans un fichier	XML
  Transaction	Requise	Requise	REQUIRED	Required				Utilise si existante, sinon démarre une nouvelle
  	Nouvelle requise	Nouvelle requise	REQUIRES_NEW	RequiresNew				Démarre toujours une nouvelle (suspend celle en cours si besoin)
  	Supporte	Supporte	SUPPORTS	Supports				Ne démarre rien, utilise le contexte courant.
  	Non supportée	Non supportée	NOT_SUPPORTED	NotSupported				Ne peut intégrer ses actions dans une transaction.
  	Obligatoire	Obligatoire	Non	Mandatory				Nécessite une transaction.
  	Jamais	Jamais	Non	Never				Refuse toute transaction.
  	Niveau d'isolation		ISOLATION_LEVEL	Non				Spécifique aux SGBD

  Leurs dépendances (références à d'autres EJB, sources de données, rôles, files de messages, web service) peuvent être déclarées (ejb-ref, etc.) dans leur descripteur.
• Pas de rapport avec les JavaBeans.

Limitations

On peut reprocher aux EJB :

• Les finders d'entités EJB ne sont pas adaptés à la récupération de listes : un EJBObject est chargé pour chaque élément de la liste récupérée, alors qu'une liste ne sert généralement qu'à sélectionner un élément parmi n pour un traitement particulier (édition du détail, etc.).
• Une partie des avantages des EJB réside dans des fonctionnalités propriétaires des serveurs, comme :
  • le mapping O/R (non standardisé)
  • les optimisations (accès exclusif à la base, méthodes en lecture seule)
• Les composants ne sont portables (déployables dans n'importe quel conteneur et donc serveur) que tant qu'ils ne sont pas déployés (donc jusqu'à l'étape d'assemblage).
• Langage de requêtes limité :
  • pas d'expression de contrainte possible sur les collections (pas d'expressions du type champ.collection.champ dans EJBQL contrairement au contains() de JDO)
  • les méthodes select (select methods) ne permettent que de récupérer soit un champ unique soit une Entité (pas un objet léger ou ensemble de champs).
• développer une application avec des EJB demande une bonne expérience de cette technologie qu'il de mal utiliser. Il faut par exemple :
  • éviter de modéliser tous les objets métier avec des EJB qui sont un modèle de composants et non un modèle objet. Tout objet (par exemple un objet à granularité fine) n'a pas vocation à être un composant réutilisable. Par contre des EJB peuvent encapsulant des graphes entiers d'objets (transitoires ou persistants).
  • éviter de n'utiliser des Entités EJB que pour leur persistance CMP : les EJB ne sont pas conçus pour la persistance d'un modèle objet (pas d'héritage par exemple) et imposent un coût global de modèle de composants (sécurité+transactions+persistance+composant) alors que des solutions de simple persistance d'un modèle objet n'imposent pas le coût ni les contraintes d'un modèle de composants tel que les EJB. On préfèrera typiquement JDO comme service de persistance des EJB, prenant en charge la persistance d'objets complexes encapsulés dans un EJB.

On ne peut pas reprocher aux EJB < 3 :

• l'absence d'héritage : un composant n'est pas naturellement adapté à la notion d'héritage, qui limite sa réutilisabilité en introduisant une dépendance forte (avec la classe héritée) et non spécifiée (héritage d'implémentation permettant de redéfinir des opérations, accéder à un état protégé, etc.)

Voir

• The Server Side
• EJB UML diagram par Jean-Michel Garnier