E. J. B. (1998)

Enterprise JavaBeans : composants Java d'entreprise.

Besoin

Fournir un modèle de composants Java pouvant être :

• distribuables
• transactionnels
• persistants
• sécurisés

Analyse

Les composants EJB peuvent représenter des :

• processus
  • synchrones : sessions (session beans)
    • sans état (stateless session beans) et donc partageables par plusieurs clients
    • avec état (stateful session beans)
  • asynchrones et sans état (message-driven beans)
• données : entités (entity beans) persistantes et affectées par les transactions.

Conception

Développement

Chaque composant EJB est mis en oeuvre 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 :

• java:comp/env/ejb/AutreEJB
• java:comp/env/jdbc/UneDataSource
• java:comp/env/jms/UneFileDeMessages
• java:comp/env/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 javax.ejb.*;

public abstract class SkillTree implements EntityBean {
  /**
   * Constructeur par défaut, toujours vide
   */
  public SkillTree() {}

  public SkillKey ejbCreate (Skill someRootSkill) throws CreateException {
    setRoot (someRootSkill);
    return null;  // En CMP la clé est déduite
  }

  /**
   * Accesseurs CMP
   */
  public abstract Object getRoot();
  public abstract void setRoot (Object);

  public void ejbStore() {
    // Rien à faire ici
  }

  public void ejbLoad() {
    // Rien à faire ici
  }

  public void ejbRemove() {
    // Rien à faire ici
  }

  public void ejbActivate() {
    // Rien à faire ici
  }

  public void ejbPassivate() {
    // Rien à faire ici
  }

  public void setEntityContext (EntityContext someContext) {
    ejbContext = someContext;
  }

  public void unsetEntityContext() {
  }

  private EntityContext ejbContext;
}

Notes

• EJB	Version		1		2		Commentaire
  Technologie	Release		0	1	0	1
  Sessions	Stateless		Oui				Sans état conversationnel (donc optimisables en étant partagés par plusieurs clients)
  	Stateful		Oui				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.
  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			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 :

• 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ération, accéder à un état protégé, etc.)

Voir

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