EJB3 - Bean session - programmer en java, programme java, cours

EJB3 - Bean session
Chapitres traités Architecture multi-tiers
Après avoir longuement travailler sur les applications Web, nous allons passer, à partir de maintenant, sur l'autre grande ossature
concernant Java EE, c'est-à-dire les EJB. Je rappelle que EJB veut dire Entreprise Java Bean. C'est ce type de composants qui
s'intéressent plus particulièrement à la logique métier au travers d'objets distants. Ces EJB servent d'intermédiaire entre les applications
de type fenêtrées, ou application Web, et la base de données.
Après avoir vu les différents concepts généraux sur les systèmes client-serveur et les architectures multi-tiers, nous passerons ensuite
sur l'installation et l'utilisation de serveur d'applications qui intègrent ces EJB. Nous montrerons l'utilisation de ces EJB au travers
d'applications classiques, en mode console et en mode graphique, mais aussi au travers des applications Web. Par contre, nous nous limiterons dans cette étude qu'à
une partie des EJB, je veux dire les Beans de type session.
Architecture multi-tiers
Avant de rentrer dans le vif du sujet concernant les Beans de type session, nous allons revoir les principes fondamentaux constituant les applications distribuées.
Toute l'application est sur une même machine - fonctionnement en standalone
Une application monolitique est un programme constitué d'un seul bloc et s'exécute sur une seule machine. Ces applications sont généralement utilisées dans le domaine
du temps réel ou bien au sein d'applications demandant de grandes performances. Ces applications sont utilisées en standalone (de manière autonome)sur des machines
personnelles.
L'avantage de cette structure c'est que l'application possède un grand niveau de performance en terme de temps de réponse. Le problème, c'est de pouvoir déployer
cette application sur l'ensemble du parc machines de l'entreprise, avec également le souci de la gestion des versions.
Comme nous l'avons découvert dans une étude antérieure, pour gérer le déploiement, il est possible de passer par Java Web Start au travers d'un serveur Web.
Grâce à cette technique, la gestion des versions est totalement assurée.

Apllication client-serveur
Dès l'apparition des réseaux, ces applications ont cherché à évoluer et ont abouti à des architectures dites client-serveur, permettant de séparer la partie cliente qui
s'intéresse plus particulièrement à l'IHM, et de regrouper la partie applicative sur un serveur.
Cependant, le développement de ce genre d'application nécessite la création d'un protocole de communication entre le client et le serveur. Ce protocole étant
souvent propriétaire, l'évolution de ces applications doivent se faire par les mêmes développeurs. Par ailleurs, le serveur doit gérer la connexion de plusieurs clients
en même temps.
Pour les systèmes d'information d'entreprise, ces solutions restent trop limitées. En effet, leur problème majeur est leur manque de séparation entre les différents
éléments qui les constituent. C'est également le manque de standard qui a poussé la communauté au concept de séparation par tiers afin d'optimiser leurs
développements.
Application multi-tiers
Dans le milieu professionnel, les applications doivent être plus robustes et travaillent généralement sur des gros volumes de données. Elles doivent, de plus, connecter
différents départements au sein même d'une entreprise.
La maintenance et la stabilité de ces applications sont donc des priorités pour les architectes et les développeurs. Différents modèles existent. Le plus connu est
sans doute le modèle trois-tiers, largement utilisé par les grandes entreprises ayant besoin de systèmes complexes basés sur la même organisation des
informations : la logique métier.
Ce modèle permet donc d'avoir plusieurs applications différentes avec une même logique métier, elles peuvent alors mettre en place facilement des applications
distribuées dans un environnement hétérogène.
De manière théorique, une application distribuée est une application découpée en plusieurs unités. Chaque unité peut être placée sur une machine différente,
s'exécuter sur un système différent et être écrite dans un langage différent.
Le modèle trois-tiers : Ce modèle est une évolution du modèle d'application client-serveur. L'architecture trois-tiers est donc divisées en trois niveaux :
>Tiers client qui correspond à la machine sur laquelle l'application cliente est exécutée.
>Tiers métier qui correspond à la machine sur laquelle l'application centrale est excutée.
>Tiers accès aux données qui correspond à la machine gérant le stockage des données.

Ce système utilise un navigateur pour représenter l'application sur la machine cliente, un serveur Web pour la gestion de la logique de l'application et un serveur
de bases de données pour le stockage des données. La communication entre le serveur Web peut s'effectuer via le protocole HTTP, la communication avec la base
de données via l'API JDBC.
La séparation entre le client, l'application et le stockage, est le principal atout de ce modèle. Toutefois, dans des architectures qui demandent de nombreuses
ressources, il sera assez limité. En effet, aucune séparation n'est faite au sein même de l'application, qui gère aussi bien la logique métier que la logique
fonctionnelle ainsi que l'accès aux données.
Le modèle multi-tiers : Dans le cadre d'applications beaucoup plus importantes, l'architecture trois-tiers montre ses limites. L'architecture multi-tiers est
simplement une généralisation du modèle précédent qui prend en compte l'évolutivité du système et évite les inconvénients de l'architecture trois-tiers vus
précédemment.
Dans la pratique, on travaille généralement avec un tiers permettant de regrouper la logique métier de l'entreprise. L'avantage de ce système, c'est que ce tiers
peut être appelé par différentes applications clientes, et même par des applications classiques, de type fenêtrées, qui ne passent donc pas par le serveur Web.
Entre parenthèses, dans ce dernier cas de figure, nous nous retrouvons de nouveau avec une architecture trois-tiers.
Si l'architecture est bien étudiée dès le début et s'exécute sur une plate-forme stable et évolutive, le développeur n'aura alors plus qu'à connecter les différents
systèmes entre eux. De même, les types de clients peuvent être plus variés et évoluer sans avoir d'impact sur le coeur du système.
La logique métier est la principale de toute l'application. Elle doit s'occuper aussi bien de l'accès aux différentes données qu'à leurs traitements, suivant les
processus définis par l'entreprise. On parle généralement de traitement métier qui regroupe :
- la vérification de la cohésion entre les données,
- l'implémentation de la logique métier de l'entreprise au niveau de l'application.
Il est cependant plus propre de séparer toute la partie accès aux données de la partie traitement de la logique métier. Cela offre plusieurs avantages. Tout d'abord, les
développeurs ne se perdent pas entre le code métier (représenté par les EJBs de type session), qui peut parfois être complexe, et le code d'accès aux données
(représenté par les EJBs de type entité), plutôt élémentaire mais conséquent. Cela permet aussi d'ajouter un niveau d'abstraction sur l'accès aux données et donc
d'être plus modulable en cas de changement de type de stockage. Il est alors plus facile de se répartir les différentes parties au sein d'une équipe de développement.
Les Entreprises JavaBeans

Le modèle d'architecture distribuée que nous venons de découvrir impose l'idée qu'une application est découpée en plusieurs unités. Des standards ont vu le jour. Le plus
général est sans doute CORBA qui correspond au modèle idéal des applications distribuées. Cependant la lourdeur et la complexité de mise en oeuvre de ce genre
d'application sont les inconvénients majeurs de cette technologie. C'est pourquoi, un modèle plus restrictif mais plus performant a vu le jour : le modèle EJB.
Objets distribués
La communication entre les applications, comme nous l'avons vu dans nos différentes études antérieures, a été introduite par la programmation client-serveur et le principe
des sockets. Ce modèle de bas niveau oblige les concepteurs et développeurs à inventer des protocoles pour faire communiquer leurs applications. Avec l'arrivée de le
programmation orientée objet, la communauté a souhaité développer des standards et surtout faciliter la communication inter-applications via des modèles de plus niveaux
par l'intermédiaire de la technique d'objets distants. Ainsi, des objets existent sur différentes machines et communiquent entre eux, c'est ce que nous définissons par
objets distribués.
Les objets distribués sont une solution à ce problème d'efficacité. Nous pouvons les considérer simplement comme des objets pouvant communiquer entre eux par
le réseau de façon autonome. Il est souhaitable, alors, d'avoir un mécanisme permettant, au développeur d'application cliente, d'effectuer un appel de méthode sur
l'objet de façon ordinaire, sans se préoccuper du format de la requête. De la même façon, le développeur de l'application serveur pourra répondre aux applications
clientes, sans avoir à s'inquiéter du protocole à mettre en place. Au travers de ce mécanisme, nous utilisons ainsi un objet à distance.
Nous avons déjà abordé cette approche au travers notamment de RMI. Les EJB, toutefois, représentent à un niveau beaucoup plus sophistiqué, les objets distants
que nous avons déjà mis en oeuvre lors de l'études des RMI. Faisons quand même un petit rappel sur cette technologie RMI.
RMI
RMI (Remote Method Invocation) correspond au modèle d'invocation à distance mis en oeuvre par Java. Grâce à RMI, Java permet l'accès via un réseau aux objets se
trouvant sur un ordinateur distant.
Pour créer un objet avec RMI :
1. Il faut d'abord concevoir une interface étendant l'interface java.rmi.Remote. Cette interface définit les opérations que doit exposer l'objet accessible à distance.
2. L'étape suivante consiste à concevoir l'objet comme une classe implémentant l'interface préalablement définie. Cette classe doit étendre la classe
java.rmi.UnicastRemoteObject qui fournit les moyens nécessaires à la communication entre l'objet et ses clients.
3. Enfin, il reste à définir l'application qui créera une instance de cet objet et l'enregistrera dans le registre RMI. Ce registre est un simple service de localisation
permettant aux ordinateurs distants de trouver l'objet à l'aide du nom qui lui est attribué.
4. Ce service est mis à contribution par l'application cliente, qui demande au registre l'objet nommé et effectue un casting vers l'interface créée lors de la première
étape.
Ce que fournit les bases de l'implémentation d'une architecture client - serveur :
1. Un registre pour la localisation des composants,
2. Les moyens de communication nécessaires pour l'invocation des opérations et le passage des paramètres et des valeurs de retour,
3. Ainsi qu'un mécanisme simple pour la gestion des accès aux ressources systèmes.
Toutefois, RMI est une technologie légère, insuffisante pour satisfaire les besoins des applications d'entreprises distribuées. Il lui manque les éléments essentiels
que sont une gestion avancée de la sécurité, le contrôle des transactions ou la faculté de répondre efficacement à une montée en charge. Bien qu'elle fournisse les
classes fondamentales, elles ne constitue pas une infracstructure pour un serveur d'applications devant recevoir les composants métier et s'adapter à l'évolution du
système et de sa charge.
Les Entreprises JavaBeans
C'est là qu'intervient les Entreprise JavaBeans. Les EJB sont des composants Java qui implémentent la logique métier de l'application, ce qui permet à cette logique d'être
décomposée en éléments indépendants de la partie de l'application qui les utilise.
L'architecture Java EE comporte un serveur qui sert de conteneur pour les EJB. Ce conteneur charge tous les composants à la demande et invoque les opérations
qu'ils exposent, en appliquant les règles de sécurité et en contrôlant les transactions. Cette architecture est très complexe mais heureusement totalement
transparente au développeur. Le conteneur d'EJB fournit automatiquement toute la plomberie et le câblage nécessaire pour la réalisation d'applications
d'entreprise.

La création des EJB ressemble beaucoup à celle des objets RMI. Cependant, le conteneur fournissant des fonctionnalités supplémentaires, vous pouvez passer plus
de temps à créer l'application au lieu d'avoir à gérer des problèmes d'intendance tels que la sécurité ou les transactions.
Il existe plusieurs types d'EJB :
1. Les beans sessions : Les beans sessions sont des composants conçus pour implémenter la logique de l'application. Une application comporte généralement
plusieurs beans sessions qui sont individuellement chargés d'une partie du traitement. Les beans sessions sont alors des briques de l'ossature globale. En
général, un bean session est responsable d'un groupe de fonctionnalités dans un domaine particulier. Par exemple, une application pour une école peut posséder
un bean session contenant la logique nécessaire pour gérer les étudiants. Un autre sera responsable de la liste des cours et des programmes. Les beans
sessions, comme leur nom l'indique, ont une durée de vie correspondant à celle de la "conversation" ou "session" entre l'application cliente et le composant.
Selon le choix de celui-ci, un bean session peut maintenir un état (stateful) pendant toute la durée de la session (c'est-à-dire conserver l'état des attributs internes
aux objets de façon à maintenir la conversation avec le client) ou au contraire sans état (stateless), ce qui signifie qu'il fournit un accès à des méthodes
implémentant la logique applicative (comme RMI), mais ne conserve aucun résultat auquel le client pourrait faire référence ultérieurement.
2. Les beans entités : Avant le développement de la programmation objet, les programmes étaient généralement développés à l'aide de langages procéduraux et
stockaient les données dans des bases de données relationnelles. Les bases de données relationnelles ont ainsi acquis une maturité telle qu'il est souvent
avantageux de les utiliser également dans des applications orientés objets. Le problème de cette approche est qu'il existe une différence fondamentale entre ces
deux technologies et que leur cohabitation au sein d'une même application est un peu contre nature. L'utilisation des beans entités permet de bénéficier du
meilleur des deux mondes. Ce sont des objets qui utilisent le mécanisme de persistance.Rappelons que la persistance correspond à l'utilisation d'une base de
données qui stocke la valeur des attributs de chacun de ces beans entités. Avec les beans entités, il n'est pas du tout nécessaire de maîtriser le langage SQL ainsi
que la connectivité JDBC.De fait, la base de données de type relationnelle devient une base de données de type objet. Ce type de bean est vraiment intéressant
puisque sans cette technologie, le développeur passe généralement beaucoup de temps à la gestion de la base de données. Avec un bean entité, le développeur
ne voit pas du tout la base de données et donc ne s'en occupe pas ; il peut alors passer tout son temps sur l'application elle-même. Dans un scénario EJB type,
lorsqu'un bean session doit accéder à des données, il appelle les méthodes d'un bean entité. Par exemple, une application pour la gestion d'une école peut
posséder un bean entité nommé Etudiant qui possèdera une instance pour chaque étudiant inscrit. Les beans entités lisent et écrivent les données dans des tables
fournissant ainsi une abstraction orienté objet d'une base de données relationnelle.
3. Les beans contrôlés par messages : Au sein d'une application d'entreprise de grande ampleur, il peut être intéressant de faire communiquer entre elles, les
différentes sous-applications clientes et serveur. Par communication, il faut comprendre un envoi de données directement interprétables et utilisables par les
autres applications. Ce sont les beans contrôlés par messages qui permettent de traiter les messages venant d'autres applications. Ces messages sont de type
asynchrone, ce qui sous-entends que le serveur d'application met en oeuvre un service de messagerie. Ainsi, l'application qui doit recevoir le message ne doit pas
nécessairement être active au moment de l'envoi du message. De toute façon, elle le recevra. Les messages asynchrones échangés par les systèmes sont
analogues aux événement déclenchés par les composants d'une interface utilisateur et envoyés au gestionnaire d'événements de la JVM. Par exemple, dans une
application de commerce, un module de vente en gros pourrait utiliser un tel composant pour recevoir les commandes envoyées sous forme électronique par les
détaillants.
Architecture du serveur d'applications, relation avec l'extérieur
Un serveur d'application met en oeuvre toute les spécifications prévues par Java EE. Nous avons déjà pris connaissance que Java EE permet de fabriquer des applications
Web à l'aide de servlet et de pages JSP, le tout orchestré par la technologie JSF. Par ailleurs, nous découvrons maintenant que Java EE intègre les EJB. En réalité, un
serveur d'application possède deux conteneurs, un pour la partie Web et un autre pour les objets distribués. C'est comme si nous avions deux services en un seul.
L'avantage ici, c'est que ces deux services font parties de la même machine virtuelle Java. Du coup, il est possible d'utiliser les EJB comme si c'étaient des objets normaux
et non comme des objets distants. Dans ce cas là, il faut passer par l'intermédiaire des composants issues de l'application Web. Si vous désirez atteindre les EJB sans
passer par l'application Web, c'est que vous utilisez une autre machine virtuelle qui est d'ailleurs issue d'un autre poste sur le réseau local. Dans ce dernier cas, vous faites
un accès distant par RMI qui est l'ossature interne des EJB.
Le conteneur d'EJB
les EJB sont des applications exécutées côté serveur mais également englobées dans un conteneur. Chaque partie a ses propres obligations et règles. Le rôle principal du
conteneur EJB est de gérer le cycle de vie des applications EJB qui lui sont associées. C'est lui qui les déploie, les stoppe et les redéploie, tout en gérant leur conformité
avec les spécifications du serveur.
Même si le conteneur a le rôle le plus important, c'est le serveur qui aiguille l'ensemble des requêtes et gère l'ensemble des conteneurs et services. Le serveur se
doit de gérer, de plus, un ensemble de services d'infrastructure communs à l'ensemble des conteneurs ou des services. Ainsi, la spécification Java EE oblige le