Editions ENI Livres | Vidéos | e-Formations
Les EJB Session
Objectif des chapitres sur les EJB (Enterprise Java Beans)
Développer des applications écrites en Java, en utilisant les EJB.
-
L’application cliente peut être un client lourd, qui accède à des objets distants du conteneur d’EJB du serveur JEE.
-
L’application cliente peut être un client léger, qui accède à des objets distants du conteneur d’EJB du serveur JEE, via le conteneur web du serveur JEE.
Types d’EJB Session
1. EJB Session avec état (stateful)
Chaque client qui appelle une méthode d’un EJB stateful dispose d’une instance qui lui est dédiée. Ainsi, la classe EJB peut comporter des propriétés, qui sont distinctes pour chaque instance, et donc pour chaque client. Ces propriétés sont conservées entre deux appels de méthode.
Une instance de l’EJB est instanciée par le conteneur d’EJB au premier appel de méthode par le client.
L’inconvénient des EJB stateful est l’encombrement mémoire qui peut résulter de la connexion de nombreux clients. On préférera en général utiliser des EBJ stateless.
2. EJB Session sans état (stateless)
Le fonctionnement des EJB Session stateless ressemble à celui des Servlets. Au premier appel d’un client, le conteneur d’EJB instancie l’objet. Cet objet est unique et commun à tous les clients. Il reste en mémoire jusqu’à ce qu’il soit explicitement détruit (arrêt du serveur ou redéploiement).
Il n’est pas interdit de déclarer des propriétés dans un tel objet. Mais attention au mélange des données, car elles sont communes à tous les clients.
En général, un EJB Session stateless se présente comme une collection de services...
Outils et conventions utilisés dans ce chapitre
1. Outils
L’EDI utilisé est NetBeans.
Le serveur JEE est GlassFish.
2. Conventions de nommage utilisées
Les noms de l’interface et de la classe EJB qui implémente l’interface sont conventionnels. Le nom JNDI est une convention propre à l’ouvrage.
L’interface, la classe EJB et le programme client sont placés dans des projets développés dans l’EDI (ici NetBeans). Ces projets (disponibles depuis la page Informations générales) ont aussi des noms qui obéissent à des conventions propres à l’ouvrage :
-
L’interface XxxRemote est placée dans un projet nommé LibrairieXxx.
-
La classe de l’EJB Xxx est placée dans un projet nommé EJBXxx.
L’interface contenue dans le projet LibrairieXxx est utilisée par le projet EJBXxx et par le projet client.
Exemple : un objet distant de tri
1. Création de l’EJB Session
a. L’interface TrieurRemote
L’écriture de l’interface est plus simple qu’en RMI :
-
L’interface n’hérite plus de l’interface Remote.
-
La méthode n’émet plus de RemoteException.
L’annotation @Remote de l’interface indique au conteneur d’EJB que l’objet distant peut être accédé à partir d’une autre machine virtuelle Java.
package objetDistant;
import javax.ejb.Remote;
@Remote
public interface TrieurRemote {
public Comparable[] trier(Comparable tableau[]);
}
b. Classe de l’objet distant : Trieur
L’annotation @Stateless de la classe indique au conteneur d’EJB que l’objet distant est sans état. Il n’y en a qu’une occurrence pour tous les clients.
package objetDistant;
import javax.ejb.Stateless;
@Stateless
public class Trieur implements TrieurRemote
{
@Override
public Comparable[] trier(Comparable tableau[])
{
. . .
}
}
2. Déploiement
Pour que le serveur puisse exécuter les méthodes d’un objet distant, il faut qu’il le connaisse. Ce renseignement lui est donné...
Cycle de vie de l’EJB Session : @PostConstruct, @PreDestroy
-
Le cycle de vie d’un EJB Session ressemble à celui d’une Servlet. Le conteneur d’EJB instancie l’EJB la première fois qu’une de ses méthodes est appelée par un client.
-
Pour effectuer un traitement au moment de l’instanciation, il faut utiliser l’annotation @PostConstruct. Cette annotation précède la déclaration de la méthode qui est exécutée juste après l’instanciation. Le nom de cette méthode est quelconque.
-
Pour effectuer un traitement au moment où l’EJB est détruit (arrêt du serveur par exemple), il faut utiliser l’annotation @PreDestroy. Cette annotation précède la déclaration de la méthode qui sera exécutée juste avant la destruction. Le nom de cette méthode est quelconque.
Exemples
La méthode apresInstanciation() s’exécute au premier appel de l’EJB :
@PostConstruct
public void apresInstanciation()
{
System.out.print("Ouverture.............................");
}
L’instruction :
System.out.print("Ouverture..............................");
ne sert qu’à visualiser ce premier appel.
La méthode avantDestruction()...
Travail pratique : Contact distant
1. Objectifs
-
Utiliser les EJB pour accéder à une base de données.
-
Architecture de l’application :
2. Sujet
a. À réaliser
-
Créer un EJB Session qui accède à la table CONTACT de la base de données. Il propose une méthode de lecture d’un contact dont on connaît le numéro.
-
Écrire le programme client qui utilise cet EJB.
b. Briques logicielles à utiliser sans modification
Les briques logicielles ci-dessous sont déjà développées, on peut les utiliser sans modification.
c. Copie d’écran de l’application cliente
Lorsque l’utilisateur saisit un numéro de contact et appuie sur la touche [Entrée] les propriétés du contact s’affichent.
d. Diagramme de séquence de l’application
3. Contact distant : proposition de correction
a. EJB Session ContactDistant
Interface ContactDistantRemote
La méthode lireContact retourne l’objet Contact correspondant au numéro passé en paramètre ou une SQLException :
package objetDistant;
import java.sql.SQLException;
import javax.ejb.Remote;
import metierMapping.Contact;
@Remote
public interface ContactDistantRemote
{
public Contact lireContact(Integer numeroContact) throws SQLException;
}
Classe ContactDistant
package objetDistant;
. . .
@Stateless
public class ContactDistant implements ContactDistantRemote
{
private BaseDeDonnees base;
La méthode ouvreBase(), précédée de l’annotation @PostConstruct, s’exécute au premier appel de l’EJB....
Pools de connexions
1. Le problème des connexions à un serveur de base de données
La gestion des connexions à une base de données est d’une grande importance pour optimiser les performances d’une application.
Quand un client se connecte à un serveur, un espace est réservé en mémoire du serveur, ne serait-ce que pour contenir les informations nécessaires pour lui répondre.
Chaque nouvelle connexion encombre un peu plus le serveur, ce qui peut devenir gênant, surtout s’il s’agit d’un serveur de bases de données.
Une solution consiste, pour chaque client, à ouvrir une connexion, effectuer une requête, et fermer la connexion, ce qui libère l’espace réservé sur le serveur. Cette solution (que nous avons appliquée dans la méthode lireContact() de l’EJB ContactDistant du travail pratique précédent) présente malgré tout un inconvénient : l’allocation et la désallocation de l’espace réservé sur le serveur prennent du temps, ce qui peut ralentir le programme client et le serveur.
Les pools de connexions proposent une solution efficace à ce problème.
2. Les pools de connexions
a. Définition
Un pool de connexion est un serveur de connexions !
Quand on démarre un tel serveur, il ouvre un certain nombre de connexions avec le serveur de bases de données. Les clients s’adressent au pool, qui leur attribue une connexion.
Un serveur à la norme JEE doit permettre la création de pools de connexions....
Travail pratique : Projet GestionContactEJB
1. Objectifs
-
Utiliser les EJB Session pour développer une application 4 tiers web qui accède à une base de données.
-
Architecture de l’application :
2. Sujet
a. À réaliser
-
Créer l’EJB Mapping et son interface MappingRemote. Cet objet distant possède toutes les méthodes d’accès aux données nécessaires à l’application GestionContactEJB.
-
Créer l’application GestionContactEJB qui reprend l’application GestionContactMVC2. C’est l’application cliente de l’EJB.
-
Les écrans de l’application sont inchangés.
-
L’enchaînement des programmes et des écrans est inchangé.
-
Il faut adapter les classes ServletControleur, TraitementAccueil et TraitementModif, car l’application accède aux données par l’intermédiaire d’un objet distant : l’EJB Mapping.
b. Briques logicielles à utiliser sans modification
Les JSP de l’application GestionContactMVC2 sont utilisables sans modification.
c. Documents fournis
-
L’interface MappingRemote.java
-
Un diagramme de séquence de l’application (liste des contacts)
d. Interface MappingRemote
@Remote
public interface MappingRemote
{
Lire un contact dont on connaît le numero. Une SQLException peut se produire :
public Contact lireContact(Integer numero) throws SQLException;
Liste des contacts
La méthode lireListeContact() retourne un Vector<Vector> qui contient deux postes :
-
Le poste 0 contient le Vector<Contact>.
-
Le poste 1 contient le Vector<Colonne>.
public Vector<Vector> lireListeContacts() throws SQLException;
Modifier un contact
La méthode modifierContact() retourne :
-
1 si la modification est réussie.
-
0 si un incident est survenu (le contact n’existe pas).
-
Une SQLException par ailleurs.
public int modifierContact(Contact contact) throws SQLException;
Liste des secteurs : même principe que lireListeContacts() :
public Vector<Vector> lireListeSecteurs() throws SQLException;
}
e. Diagramme de séquence
Ce diagramme ne représente que la séquence d’appels des méthodes correspondant au choix de la liste des contacts...
