Bean session

Présentation

Un bean Session est un objet java situé côté serveur qui joue le rôle d'intermédiaire entre une application cliente et le serveur (en général un serveur d'application Java EE);   les beans session implémentent la logique métier d'une application Java EE. Il en existe trois sortes: les beans Session stateless, les bean Session stateful et les bean session singleton.
Dans une application Java la complexité des échanges d'informations et des données entre le client et le serveur sont masquées par l'utilisation d'annotations.

Cycle de vie d'un java bean session

Le cycle de vie d'un java  bean session est défini par les états traversés par le java bean session au sein de l'application qui l'utilise. C'est le client  (l'application cliente du java bean) qui initie le cycle de vie du java bean;  ensuite  le conteneur d'EJB instancie le java bean en appelant les méthodes setSessionContext et ejbCreate au sein du java bean session. A partir de ce moment les méthodes du java bean accessibles par  l'application peuvent être utilisées.

	Cycle de vie bean stateless

Les beans session stateless

Un bean session stateless (bean sans état) fournit un ensemble de services (un service par méthode) aux applications clientes sans attendre, lors de son exécution, de résultat venant d'une quelconque de ses exécutions précédentes. Les beans session stateless sont utilisés en général pour traiter les requêtes de plusieurs clients.
Une bean session stateless peut implémenter un service web, ce qui n'est pas le cas d'un bean stateful.

Cycle de vie d'un java bean session stateless

Un java bean stateless a deux états possibles; soit il n'existe pas ("état inexistant") soit il est dans un "état prêt"; il ne peut pas être dans un "état passif" (voir le schémas " Cycle de vie bean stateless" à côté).
Normalement, si le besoin de se servir d'un java bean session stateless se fait sentir, le conteneur d'EJB crée et maintient un pool de java beans session stateless,    exécute toutes les injections de dépendance et invoque la méthode annotée avec  @PostConstruct  si elle existe.  Le java bean est, à partir de ce moment,  dans l' "état prêt" à l'emploi i.e qu'un client peut faire appel à ce java bean. 
A la fin du cycle de vie, le conteneur d'EJB appelle la méthode annotée avec @PreDestroy (s' il en existe une)  et ainsi l'instance du java bean est mise à la disposition du ramasse miette (garbage collection).

	Cycle de vie de bean stateful

Les bean session stateful

Un bean session Stateful  permet de maintenir l'état conversationnel entre un client et l'application cliente. Il introduit le concept de session entre le client et le serveur. On se sert de bean session Stateful lors d'un ou plusieurs échanges d'informations avec le même client. Ce type de bean peut conserver des données entre les échanges avec le client.
L'état d'un bean session stateful est l'ensemble des valeurs des méthodes et des variables de son instance lors de  son  exécution.

Cycle de vie d'un java bean session stateful

le client initie le cycle de vie d'un bean session stateful en obtenant sa référence (i.e ?? ...). Ainsi le conteneur (container) exécute toutes les Injections de Dépendance, invoque la méthode ayant  l'annotation @PostConstruct s' il en existe une; à partir de là le bean session stateful passe à l' "état prêt"  i.e qu'il  peut-être utilisé  par un client.
Pendant le temps où le java bean est dans l'"état prêt", le conteneur d'EJB peut le faire passer dans un état passif (deactivate, or passivate) en le mettant dans une partie de la mémoire appelée "secondary storage" (moving it from memory to secondary storage); précisément, le conteneur d'EJB utilise l'algorithme "least-recently-used algorithm" pour selectionner le java bean qui doit être passé dans l'"état  passivate" . Le conteneur d'EJB invoque dans ce cas la méthode  ayant l'annotation @PrePassivate s'il en existe une, avant de faire passer le bean dans l'"état passivate". Si un client invoque une méthode faisant partie de l'interface associée à la définition du java bean (ces méthodes ce sont celles qu'on appelle généralement des "business method") pendant que ce dernier est dans l'"état passif", le conteneur d'EJB active le java bean (fait passer le java bean dans l'"état prêt"), appelle la méthode annotée avec @PostActivate, s'il en existe une.       
A la fin du cycle de vie du java  bean, le client invoque la méthode avec l'annotation  @Remove, et le conteneur d'EJB quant à lui fait appel à celle ayant l'annotation @PreDestroy; ainsi le bean  est prêt pour le "garbage collection". Le code client contrôle uniquement  l'invocation le cycle de vie de la méthode annotée avec @Remove. Les autres méthodes sont contrôlées par le conteneur d'EJB (voir le schémas  "Cycle de vie de bean session stateful" ci-dessus)

Singleton

Un java bean session singleton est un objet java situé côté serveur qui est instancié une fois pour le cycle de vie de l'application au sein de laquelle il est développé. un bean singleton offre les mêmes similitudes de fonctionnement qu'un bean session stateless à la seule différence qu'il ne peut y avoir qu'un seul bean session singleton par application.
Remarque :
une application contenant un bean session singleton doit préciser si le bean doit être instancié dès le lancement de l'application.

Cycle de vie d'un  bean session singleton

Comme un bean session stateless,  un bean session singleton n'est jamais dans un "état passif" (jamais "passivated"); il a, lui aussi, seulement deux états,  à savoir  l'"état inexistant" ou "état prêt"  (voir figure pour bean session stateless)....

Le conteneur d'EJB  initialise le cycle de vie d'un  java bean singleton en créant une instance de ce dernier et cela dès le début du déploiement de l'application si le singleton est annoté avec l'annotation @Startup. Le conteneur exécute alors toutes les Injections de Dépendance et invoque la méthode ayant l'annotation @PostConstruct si elle existe.  A partir de cet instant, le singleton est dans un "état prêt" et le client peut l'utiliser.
A la fin du cycle de vie, le conteneur d' EJB appelle la méthode ayant l'annotation @PreDestroy et le java bean session singleton est mis à la disposition du système de  nettoyage de l'application (Le bean Session singleton est maintenant prêt pour être récupérer par le système de garbage  -garbage collection-).

Utilisation des beans session

Quand on développe une application JEE avec des EJB 3.0, on doit définir les interfaces de type locale ( accès local) ou remote ( accès distant); ces interfaces sont implémentés par les EJBs sessions et cela permet de gérer l'exposition des EJBs aux applications clientes.
Avec la version 3.1 des EJB, il n'est plus nécessaire de définir une interface Local pour les EJB session; la classe de l'EJB session peut être directement annotée avec @Stateless ou @Stateful; l' EJB session est de ce fait un simple POJO. Le fait qu'on définisse pas d'interface local est appelé développment d'EJB session "no-interface view".

no-interface view

Dans le développement d'une application JEE utilisant les EJBs, le rôle d'une application cliente est d'échanger des informations avec les EJB session présents sur le serveur;  si l'EJB session est de type  "no-interface view" (i.e que l'EJB session n'implémente pas d'interface métier), il expose aux clients  ses méthodes publiques. Cette technique (no-interface view) est utilisée uniquement pour les EJB session à accès local (annoté avec @Local) à partir des EJB 3.1.

Business-interface

Un "business-interface" (interface métier) est un simple interface java qu'implémente l'EJB session lors de sa création;  toutefois un EJB session  peut avoir d'autres méthodes;   les méthodes définies dans le "business interface" s'appellent des "business-method" (méthodes métier); ce sont ces  "business méthod" qui sont  exposées par l' EJB session aux applications clientes. Un client peut donc accéder à un EJB session en se servant des  "business-method".
L'annotation javax.ejb.Local est facultative lorsque l'interface métier ("business-interface") est à accès local; si  l'EJB Session est à accès distant, l'annotation javax.ejb.Remote est obligatoire