Instructions: Conception des Enterprise JavaBeans (EJB)
Ces instructions portent sur la conception des Enterprise JavaBeans (EJB) d'une application J2EE.
Relations
Eléments connexes
Description principale

Introduction

Ces instructions portent sur la conception des EJB. Des conseils supplémentaires concernant entre autres l'identification et la modélisation des EJB figurent dans Instructions relatives au produit : EJB.

Les instructions relatives à la conception de types particuliers d'EJB figurent dans les instructions suivantes :

Interfaces en local et interfaces distantes

Ces deux types d'interfaces sont décrits dans Concept : Présentation de J2EE : Enterprise JavaBeans.

Les interfaces en local sont plus efficaces que les interfaces distantes. Les interfaces en local doivent être fournies si certains clients spécifiques utilisent toujours les EJB en mode local.

Vous trouverez des conseils plus spécifiques à ce sujet dans les instructions relatives aux types spécifiques d'EJB.

Transfert de paramètres

Le nombre d'appels distants et le nombre de données transférées à chaque appel peuvent avoir une incidence sur les performances. Il est possible d'y remédier en fournissant des appels spécifiques qui renvoient toutes les données requises par le client distant. Par exemple, un bean session, qui agissant comme façade pour un ensemble de beans entity liés, peut copier des données de plusieurs beans entity dans des objets de valeur sérialisables puis renvoyer ces données dans un seul appel distant. Vous trouverez une description détaillée dans Core J2EE Patterns - Value Object Pattern ([ALU01].

Cela doit être contrebalancé par le souci de conserver des interfaces aussi générales que possible et d'éviter l'envoi de données indésirables.

Transactions

La démarcation des transactions consiste à initialiser, valider et abandonner les transactions. Un concepteur d'EJB doit choisir entre implémenter la démarcation d'une transaction gérée par le bean et la démarcation d'une transaction gérée par conteneur. Vous devez aussi choisir l'emplacement des frontières des transactions dans les séquences de logique métier que votre application réalise. Pour plus d'informations, reportez-vous à Tâche : Conception de cas d'utilisation, Modéliser des transactions et la section intitulée Gestion des transactions dans Concept : Présentation de J2EE.

Utilisez les transactions gérées par conteneur lorsque cela est possible. Ainsi votre code restera simple et cela permettra aussi aux développeurs de se concentrer sur la logique métier de l'application.

En général, les transactions de granularité plus larges donnent de meilleures performances globales. Supposez que vous établissiez une séquence d'appels de méthode à un EJB (par exemple, getX, getY et setZ). Chaque méthode va s'exécuter par défaut dans une nouvelle transaction, ce qui donne des performances réduites. Afin d'appeler ces performances dans la même transaction, vous devez créer une autre méthode, par exemple la méthode processXYZ d'une EJB session, et définir les attributs de transaction des méthodes appelées sur Required, pour qu'elles utilisent la transaction existante (c'est-à-dire la transaction de la méthode d'appel dans la bean session). 

Sécurité

Les concepts de base concernant la sécurité des EJB sont traités dans Concept : Présentation de la plateforme J2EE - Sécurité.

Pour définir les exigences de sécurité des EJB, vous devez définir les rôles de sécurité et les autorisations de méthode. Les rôles de sécurité et les autorisations de méthode sont définis dans le descripteur de déploiement des EJB. C'est le serveur qui mappe (à l'aide d'outils d'administration) les rôles de sécurité aux utilisateurs ou groupes d'utilisateurs. 

Un rôle de sécurité définit un ensemble de types d'activités semblables regroupés sous un seul nom. Une autorisation de méthode donne à un rôle de sécurité particulier le droit d'appeler la méthode. Considérez par exemple une EJB entity Employee et les méthodes setAddress, setSalary etc. Un rôle de sécurité pour manager se verra attribué une autorisation de méthode pour les méthodes setAddress et setSalary alors qu'un rôle pour employee se verra seulement attribué une autorisation de méthode pour la méthode setAddress.  

Il est impossible dans certaines situations de prendre en charge les exigences de sécurité d'une application en ayant recours à des autorisations de méthode déclaratives dans le descripteur de déploiement. Vous devez dans ce cas utiliser les méthodes getCallerPrincipal et isCallerInRole de l'interface javax.ejb.EJBContext. 

Service de temporisation

Depuis J2EE 1.4 (et plus exactement EJB 2.1) les beans session sans état et les beans gérés par message peuvent utiliser des temporisateurs pour programmer des processus par lots grâce au service de temporisation d'EJB.

Le service de temporisation d'EJB fournit des méthodes permettant de programmer les rappels pour des événements temporels. Le conteneur fournit un service de notifications transactionnelles fiable pour les événements temporels. Les notifications temporelles peuvent être programmées pour se produire à un moment donné, après un certain délai ou à intervalles spécifiés.

Le service de temporisation est implémenté par le conteneur d'EJB et un enterprise bean peut y accéder par le biais de son interface EJBContext.

Ce service, qui fournit des notifications temporelles à granularité grossière, est conçu pour modéliser les processus au niveau de l'application et non pour modéliser des événements en temps réel.

Accès direct et bean entity

L'utilisation de beans entity pour des données persistantes fournit un mécanisme standard, riche en fonctions pour accéder à ces données. Il est possible de ne pas préciser au client quel type de persistance est utilisé, persistance gérée par le bean ou persistance gérée par conteneur, ce qui donne une certaine flexibilité au niveau de la conception. Les EJB peuvent exploiter les transactions, la gestion des ressources, l'équilibrage de charge et d'autres fonctions fournis par l'environnement de J2EE.

Cependant, il y a des moments où vous voudrez accéder directement à la base de données sans passer par les beans entity. Par exemple, si les données sont toujours accessibles en lecture seule par un seul client, il est plus efficace d'y accéder directement.

Si vous accédez directement à la base de données (à partir de beans session sans état, par exemple), vous devez encapsuler tous les accès à la base dans une classe objet accès aux données. Il s'agit simplement d'une classe Java qui masque et encapsule le mécanisme de stockage sous-jacent et isole les changements lorsque/si l'interface de la source de données change. Voir Core J2EE Patterns - Data Access Object Pattern ([ALU01].

Connexions à une base de données

Presque tous les conteneurs d'EJB fournissent une prise en charge des regroupements de connexions - partageant un ensemble de connexions entre clients existantes. Ces connexions sont affectées aux EJB selon les besoins. L'EJB a l'avantage d'obtenir ainsi une connexion sans avoir à la créer ou à l'initialiser. Lorsque la connexion est renvoyée vers le groupe, elle est recyclée. Le groupe doit contenir assez de connexions déjà prêtes, disponibles pour recycler celles qui ont été utilisées.

Pour les beans entity à persistance gérée par conteneur, le conteneur gère la connexion de la base de données et l'accès au groupe de connexions de la base de données.

Pour les beans entity à persistance gérée par le bean (ou pour les sessions ou EJB gérés par message qui accèdent à une base de données), le développeur est responsable de la codification d'une routine de connexion. Tenez compte des instructions suivantes :

  • Isoler le code d'accès de votre base de données dans une classe DAO (Data Access Objects).
  • Ne pas coder en dur l'URL actuelle de la base de données. Utiliser plutôt un nom logique que l'on peut retrouver par une recherche dans Java Naming and Directory Interface (JNDI). Cela vous permet de réutiliser l'EJB dans diverses applications, avec éventuellement des noms de base de données différents.
  • Utiliser en général des groupes de connexions et ne maintenir la connexion que le temps nécessaire. Par exemple, un bean entity peutse connecter, mettre à jour une ligne dans une table puis se déconnecter. Cela permet à beaucoup d'EJB de partager la même connexion. La spécification de la connectivité JDBC (Java DataBase Connectivity) comprend la prise en charge du regroupement de connexions.