Instructions: Identification des beans session
Ces instructions portent sur l'identification et la modélisation de beans session pour une application J2EE.
Relations
Description principale

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.