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 :
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.
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).
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.
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].
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.
|