Introduction
Ces instructions concernent l'identification de beans session. Des conseils supplémentaires sur les beans session
figurent dans Instructions : Beans session. Des conseils généraux sur les EJB sont disponibles dans
Instructions : Enterprise JavaBean (EJB).
Identification des beans session
Les classes de contrôle sont souvent des candidats appropriés pour les beans session, ces derniers étant adaptés pour
fournir une logique de contrôle, en particulier lorsque cette logique implique une conversation avec un client. Un bean
session est par ailleurs souvent identifié comme façade pour un ensemble d'objets au niveau métier (reportez-vous à Pattern de façade session ci-dessous). Depuis J2EE 1.4, des beans session sans état
peuvent également être utilisés pour implémenter des services Web.
Si vous utilisez J2EE 1.3, une pratique courante consiste à traiter l'accès de tous les clients distants via des EJB
session, qui utilisent des EJB entity sur la même machine JVM au moyen d'interfaces composant locales.
Modélisation des beans session
Reportez-vous à Instructions : Identification d'Enterprise JavaBeans (EJB).
Avec état ou sans état ?
Il existe de types de beans session : avec état et sans état. Identifier un bean session consiste en partie à définir
ses responsabilités (l'une d'elles peut signifier gérer l'état du client entre des appels.)
Les beans session avec état conservent des informations sur l'état quant à la conversation entre le client et le
conteneur d'EJB. Une instance de bean session avec état existe uniquement pour la durée de la conversation avec le
client. Les beans session avec état effectuent généralement des services à l'aide de ces données du client. Les
services fournis par le bean session avec état peuvent coordonner les interactions d'autres objets métier (beans
session et beans entity). Par exemple, une carte d'achat contenant des objets pour l'achat peut être implémentée
à l'aide d'un bean session avec état, car ce bean conserve des informations pendant les interactions du client avec
l'application. Etant donné que les beans session avec état sont affectés à un client spécifique, ils consomment plus de
ressources système qu'un bean session sans état, mais présentent l'avantage de conserver l'état du client. Le conteneur
gère ces ressources, généralement en "transférant" (en écrivant sur le disque) des beans session avec état et en les
réactivant lorsque besoin est.
Les beans session sans état ne conservent pas d'informations sur l'état quant à la conversation entre le client et le
conteneur d'EJB. "Sans état" signifie en réalité qu'il n'existe pas d'état de conversation avec le client. Un bean
session sans état peut donc contenir d'autres types d'état, tels qu'une connexion à une base de données que tout client
peut utilisé. Les beans session sans état effectuent des services génériques qui n'utilisent pas les données d'état du
client provenant des appels de méthode précédents, mais qui reçoivent toute l'entrée appropriée comme paramètres dans
l'appel de méthode en cours ou qui accèdent aux données provenant d'autres sources au cours de l'appel de méthode
(provenant de beans entity ou en accédant à une base de données via JDBC). Ces beans session proviennent généralement
d'un pool prêt et sont répartis comme nécessaire pour traiter les requêtes entrantes. Toutes les instances étant
équivalentes, les beans session sans état n'ont pas besoin d'être informés sur leur client. Vous gagnez ainsi en
performances et en évolutivité. Les beans session sans état sont plus efficaces, car une instance peut être répartie
sur plusieurs requêtes discontinues et non "liées" à une session particulière d'activité.
Vous devez en règle générale choisir le type de bean session le mieux adapté à la conversation avec le client.
Certaines stratégies permettent de forcer la conversion d'un bean session avec état en bean session sans état, par
exemple en stockant l'état du client sur le client et en le réémettant à chaque appel ou en stockant et en récupérant
dans une base de données l'état du client à chaque appel d'une méthode. En réalité, ces stratégies risquent toutefois
de diminuer l'évolutivité, en raison de l'apparition de surdébits quant au niveau du trafic réseau et à l'accès aux
données.
S'il est prévu qu'un bean session soit créé pour implémenter un service Web, vous devez utiliser un bean session sans
état comme défini dans la spécification JSR 1.3 API.
La rubrique Instructions : Conception d'un état pour les Applications J2EE décrit plusieurs
approches pour la conception un état de client.
Pattern de façade de session
Utiliser les beans session comme une façade qui encapsule des interactions entre des objets au niveau métier est un
usage courant des beans session. Le bean session permet de faire abstraction de cette complexité et fournit une
interface plus simple à des clients. Ce pattern est décrit en détail dans Patterns J2EE - Session Facade Pattern (J2EE
Patterns - Pattern de façade de session) ([ALU01]).
Par exemple, extraire la logique des beans inter-entity pour la déplacer vers des beans session est une bonne méthode
pour minimiser le couplage entre les beans entity. Les beans entity sont accessibles via des interfaces locales, car la
façade de bean session permet d'accéder aux clients distants. Cette approche est plus efficace lorsque plusieurs beans
entity sont fortement liés.
Noeud final de services Web
Comme expliqué précédemment, les beans session sans état peuvent servir à implémenter des services Web. Ces beans sont
également appelés bean d'implémentation de service et doivent satisfaire les exigences suivantes :
-
Ils doivent comporter un constructeur public par défaut.
-
Ils doivent implémenter toutes les méthodes déclarées par l'interface de noeud final de service et leurs méthodes métier doivent être
publiques, mais ni finales, ni statiques.
-
Ils doivent être sans état.
-
La classe doit être publique, mais ni finale, ni abstraite.
Pour plus d'informations sur l'utilisation de beans session en vue d'implémenter des services Web, reportez-vous à EJB 2.1 et aux
spécifications JSR 109.
|