Rubriques

IntroductionTo top of page

Ces conseils sont axés sur l'identification des beans de session. Pour plus d'informations sur les beans de session, voir Principes et conseils : Beans de session. Des conseils généraux sur les EJB sont fournis dans Principes et conseils : Enterprise JavaBeans.

Identifier les beans de sessionTo top of page

Les classes de contrôle sont souvent de bons beans potentiels, car les beans de session sont équipés pour fournir une logique de commande, en particulier lorsque cette logique de commande implique une conversation avec un client. Un bean de session est également souvent identifié comme une façade pour un ensemble d'objets dans le niveau métier (voir Pattern de façade de session ci-dessous). Egalement, depuis J2EE 1.4, les beans de session sans état peuvent être utilisés pour implémenter les services Web.

Si vous travaillez avec J2EE 1.3, la pratique standard consiste à traiter tous les accès clients distants par des EJB de session, qui manipulent les EJB d'entité dans la même machine virtuelle Java par le biais d'interfaces locales de composants.

Modéliser les beans de sessionTo top of page

Voir Principes et conseils : Identifier les Enterprise JavaBeans (EJB).

Avec état ou sans étatHaut de la page

Il existe deux types de beans de session : avec état et sans état. L'identification d'un bean de session consiste notamment à définir ses responsabilités - l'une d'elle pouvant être de maintenir l'état du client entre deux appels.

Les beans de session avec état possèdent des informations d'état sur la conversation entre le client et le conteneur EJB. Une instance de bean de session avec état n'existe que pendant la durée de la conversation avec le client. Les beans de session avec état effectuent généralement des services en utilisant ces données pour le client. Les services fournis par le bean de session avec état peuvent coordonner les interactions d'autres objets métier (beans de session et beans d'entité). Par exemple, un panier contenant les objets à acheter peut être implémenté en utilisant un bean de session avec état, car il conserve des informations lorsque le client interagit avec l'application. Les beans de session avec état étant attribuées à un client spécifique, ils consomment plus de ressources système qu'un bean de session sans état, tout en ayant pour avantage de conserver l'état du client. Le conteneur gère ces ressources, généralement en "passivant" (en enregistrant sur le disque) les beans de session avec état et en les réactivant au moment adéquat, en cas de besoin.

Les beans de session sans état ne conservent pas les informations d'état sur la conversation entre le client et le conteneur EJB."Sans état" signifie en fait aucun état de conversation client. Ainsi, un bean de session sans état peut contenir d'autres types d'états, comme une connexion de base de données que tous les clients peuvent utiliser. Les beans de session sans état effectuent des services génériques qui n'utilisent pas de données d'état client des précédents appels de méthode, mais reçoivent toute entrée pertinente en tant que paramètres dans l'appel de méthode actuel, ou obtiennent les données d'autres sources pendant l'appel de méthode (comme de la part de beans d'entité ou en accédant à une base de données via JDBC). Les beans de sessions sans état sont généralement tirés d'un regroupement établi et répartis selon les besoins pour gérer les demandes entrantes. Les instances étant toutes équivalentes, les beans de session sans état n'ont pas besoin de connaître l'existence de leur client. Cela peut apporter une meilleure performance et une plus grande extensibilité. Les beans de session sans état sont plus efficaces, car une instance peut être partagée entre des demandes non contigües, plutôt que d'être "liée" à une session d'activité spécifique.

En général, choisissez le type de bean de session correspondant le mieux à la conversation avec le client. Il existe des stratégies pour faire correspondre de force un bean de session avec état à un bean de session sans état, comme le stockage de l'état client sur le client, et le renvoi de chaque appel, ou le stockage et la récupération de l'état client d'une base de données sur chaque appel méthode. Ces stratégies, cependant, peuvent réduire l'extensibilité du fait de temps système dans le trafic du réseau et l'accès aux données.

Si le bean de session est créé pour implémenter un service Web, vous devez utiliser un bean de session sans état comme défini dans la spécification JSR 1.3 API.

Les différentes approches de la conception de l'état client sont traitées dans Principes et conseils : Concevoir l'état pour les applications J2EE.

Pattern de façade de sessionHaut de la page

On utilise souvent les beans de session comme une façade qui encapsule les interactions entre les objets dans le niveau métier. Le bean de session sert à abstraire cette complexité en fournissant une interface plus simple pour les clients. Ce pattern est décrit en détails dans les pattern J2EE - Patterns de façade de session ([ALU01]).

Par exemple, il est recommandé de retirer la logique bean inter-entité et d'adopter les beans de session pour minimiser le couplage entre des beans d'entité. On peut accéder aux beans d'entité via des interfaces logiques, car la façade de bean de session donne accès aux clients distants. Cette approche est très efficace lorsque plusieurs beans d'entité sont étroitement liés.

Extrémité de services WebHaut de la page

Comme nous l'avons vu précédemment les beans de session sans état peuvent être utilisés pour implémenter les services Web. On appelle aussi ce type de bean un bean d'implémentation de service et il doit répondre aux exigences suivantes :

  • Il doit avoir un constructeur publique par défaut.
  • Il doit implémenter toutes les méthodes déclarées par l'Interface d'extrémité de service et ses méthodes métier doivent être publiques et ni finales ni statiques.
  • Il doit être sans état.
  • La classe doit être publique, mais ni finale ni abstraite.

Pour plus d'informations sur l'utilisation de beans de session pour implémenter les services Web, veuillez consulter les spécifications EJB 2.1 et JSR-109.

RUP (Rational Unified Process)   2003.06.15