Rubriques

Introduction Haut de la page

Ces principes et conseils concernent principalement la conception des EJB. Des conseils supplémentaires sur les EJB, concernant par exemple leur identification et leur modélisation, sont fournis par Principes et conseils : EJB.

Les Principes et conseils suivantes fournissent des conseils spécifiques sur la conception de types particuliers d'EJB :

Les interfaces locales contre les interfaces distantes To top of page

Les interfaces locales et distantes sont décrites dans Concepts: Vue d'ensemble de J2EE : Enterprise JavaBeans.

Les interfaces locales sont plus efficaces que les interfaces distantes. Elles devraient être fournies si certains clients sont toujours locaux à EJB.

Les principes et conseils sur les types particuliers d'EJB fournissent des conseils plus précis à ce sujet.

Passage de paramètresHaut de page

Les performances peuvent être sévèrement affectées par le nombre d'appels distants et par la quantité de données transmises sur chaque appel. Ce problème peut être résolu si les appels spécifiques renvoient toutes les données demandées par le client. Prenons un exemple : un bean de session qui joue le rôle de façade pour un ensemble de beans d'entité liés peut copier des données de plusieurs beans d'entité en objets sérialisables et renvoyer ces données en un seul appel distant. Vous trouverez une description détaillée àPatterns principaux J2EE - Modèleobjet valeur ([ALU01].

Il faut trouver un équilibre en tentant de garder les interfaces les plus générales que possible, et d'éviter d'envoyer trop de données inutiles.

TransactionsTo top of page

Délimiter des transactions signifie les émettre, les valider et les annuler. Un concepteur EJB doit choisir entre une délimitation des transactions gérées par bean ou par conteneur. Les limites des transactions doivent être déterminées dans les séquences de logique applicative réalisées par votre application. Pour plus d'informations, voir Activité: conception d'un cas d'utilisation, modélisation des transactions dans la partie intitulée Gestion des transactions dans Concepts: Vue d'ensemble de J2EE.

Utilisez les transactions gérées par conteneur lorsque vous le pouvez. Ainsi, votre code restera simple et les développeurs se concentreront sur la logique applicative.

En général, les transactions qui possèdent une plus grosse granularité s'avéreront, dans l'ensemble, plus performantes. Supposons que vous fassiez une séquence d'appels de méthode à un EJB (par exemple, getX, getY et setZ). Par défaut, chaque méthode exécutera une nouvelle transaction, ce qui diminuera la performance. Pour appeler durant la même transaction, créez une méthode supplémentaire (par exemple méthode processus XYZ d'un EJB de session) et installez les attributs de la transaction des méthodes appelées à Required pour qu'elles utilisent la transaction en cours (c'est-à-dire la transaction de la méthode appelante dans le bean de session). 

Sécurité

Les concepts basiques de la sécurité des EJB sont couverts dans Concepts: Vue d'ensemble de la plate-forme J2EE - Sécurité.

Les conditions de sécurité des EJB sont définies par les rôles de sécurité et les permissions méthodes.  Les rôles de sécurité et les permissions méthodes sont définis dans le descripteur de déploiement.   C'est au serveur, à l'aide d'outils d'administration, d'établir une correspondance entre les rôles de sécurité et les utilisateurs ou groupes d'utilisateurs.  

Un rôle de sécurité définit un ensemble de types d'activités similaires regroupées sous un seul nom. Une permission méthode permet à un rôle de sécurité d'appeler une méthode.   Prenons comme exemple un EJB entité Employé, avec des méthodes définirAdresse, définirSalaire etc. Un rôle de sécurité de manager pourrait être une permission méthode accordée pour les méthodes définirAdresse et définirSalaire, alors qu'un rôle de sécurité d'employé pourrait seulement être une permission méthode accordée pour la méthode définirAdresse.  

Il est parfois impossible de prendre en charge les conditions de sécurité d'une application qui utilise des permissions méthodes déclaratives dans le descripteur de déploiement. Dans ce cas, utilisez les méthodes getCallerPrincipal et isCallerInRole de l'interface javax.ejb.EJBContext interface. 

Timer Service

Depuis J2EE 1.4 (plus précisément EJB 2.1), les beans de session sans état et les beans pilotés par messages peuvent utiliser des temporisateurs pour programmer des séries de processus grâce au Timer Service EJB.

Le Timer Service EJB fournit des méthodes pour permettre la programmation de rappels pour des événements basés sur le temps. Le conteneur fournit un service de notification fiable et transactionnel des événements programmés. Les notifications du temporisateur peuvent être programmées pour se produire à une heure déterminée, après une certaine durée écoulée, ou à des intervalles périodiques spécifiques.

Le Timer Service est mis en oeuvre par le conteneur EJB et un bean enterprise peut accéder à ce service par l'interface du contexte EJB.

Le Timer Service EJB est un service Notification des événements à grosse granularité conçu pour la modélisation des processus de niveau d'application. Il n'est pas prévu pour la modélisation des événements en temps réel.

Accès direct contre beans d'entitéTo top of page

L'utilisation des beans d'entité pour des données rémanentes fournit un mécanisme riche et standard pour l'accès aux données rémanentes. Il est possible de cacher aux clients la décision d'utiliser la persistance gérée par bean ou la persistance gérée par conteneur; la conception est ainsi flexible. Les EJB peuvent profiter des transactions, de la gestion des ressources, de l'équilibrage de charge et d'autres caractéristiques fournies par l'environnement J2EE.

Cependant, vous serez peut-être amené à vouloir accéder directement à la base de données et éviter d'utiliser des beans d'entité. Par exemple, si un seul client accède toujours aux données en lecture seule, un accès direct à la base de données serait plus efficace.

Si vous avez accédez directement à la base de données ,par exemple d'un bean de session sans état, encapsulez tous les accès aux bases de données dans une classe d'Objets 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, et si, l'interface de la source de données est modifiée. Voir Patterns principaux J2EE -Modèle Objet Accès aux Données ([ALU01].

Connexions à une base de donnéesTo top of page

Tous les conteneurs EJB, ou presque, prennent en charge la connexion en mettant en commun un ensemble de connexions entre clients déjà créées. Ces connexions sont attribuées aux EJB comme nécessaires. L'EJB tire profit de l'obtention d'une connexion sans avoir à la créer et à l'initialiser. Lorsque la connexion est renvoyée au groupe, elle est recyclée. Le groupe devrait avoir suffisamment de connexions prêtes disponibles pour recycler celles utilisées.

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

Pour les beans d'entité avec persistance gérée par bean (ou pour les EJB de session ou pilotés par messages qui accèdent à une base de données), le développeur est chargé du codage du sous-programme de connexion. Suivez les instructions suivantes:

  • Isolez votre code d'accès à la base de données dans une classe DAO.
  • Ne codez pas l'URL elle-même de la base de données mais utilisez un nom logique qui peut être récupéré grâce à la recherche de Java Naming and Directory Interface (JNDI). Cela vous permet de réutiliser EJB dans plusieurs applications, peut être avec des noms différents de bases de données.
  • En général, utilisez des groupes de connexions et laissez seulement la connexion le temps nécessaire. Par exemple, un bean d'entité pourrait se connecter, mettre à jour une ligne d'un tableau puis se déconnecter. Cela permettra à de nombreux EJB de partager la même connexion. La spécification JDBC comprend le support pour le regroupement de connexions.

RUP (Rational Unified Process)   2003.06.15