|
EJB 2 - Les Entreprise Java Bean (JavaBeans)
4.3.Spécifications d’un
Session Bean
Les spécifications au niveau du code sont les mêmes
entre un stateless et un stateful. Seul le descripteur de déploiement
différe quelque peu.
4.3.1.Classe du Bean
La classe du session bean dans cet exemple se nomme CartBean. Comme
chaque session bean, la classe CartBean doit répondre à
ces conditions :
-
Elle implémente l’interface SessionBean
-
La classe est déclarée public
-
Elle ne peut être abstract ou final
-
Elle implémente une ou plusieurs méthodes ejbCreate()
-
Elle implémente les méthodes métiers
-
Elle contient un constructeur public sans paramètre
-
Elle ne doit pas définir de méthode finalize()
4.3.2.L’interface SessionBean
L'interface SessionBean hérite de l'interface
EnterpriseBean, qui hérite également de
l'interface Serializable. L'interface SessionBean
déclare les méthodes ejbRemove(),
ejbActivate(), ejbPassivate(), et
setSessionContext(). La classe CartBean n’utilise
pas ces méthodes, mais elle doit les implémenter parce
qu’elles sont déclarées dans l'interface
SessionBean. En conséquence, ces méthodes sont
vides dans la classe CartBean.
4.3.3.Les méthodes ejbCreate
Puisqu’un enterprise bean s’exécute dans un
conteneur d’EJB, un client ne peut instancier directement le
bean. Seul le conteneur peut instancier un enterprise bean. Durant
l’instantiation, le programme en exemple effectue les étapes
suivantes :
-
Le client appelle la méthode create() sur
l’objet home :Cart
shoppingCart = home.create("Duke DeEarl", "123");
-
Le conteneur d’EJB instancie l’enterprise bean
-
Le conteneur appelle la méthode ejbCreate()
adéquate de CartBean
Typiquement, une méthode ejbCreate() initialise
l’état de l’enterprise bean. La méthode
ejbCreate() précédente, par exemple,
initialise les variables customerName et customerId via
les arguments passés en paramètre à la méthode
create().
Un enterprise bean doit avoir une ou plusieurs méthodes
ejbCreate(). Les signatures de ces méthodes doit
répondre aux conditions suivantes :
-
Le modificateur d’accès doit être public.
-
Le type retourné doit être void.
-
Si le bean permet un accès distant, les arguments doivent
avoir un type adéquat à l’API Java Remote Method
Invocation (« Java RMI »).
-
Le modificateur ne peut être static ou final.
La clause throws peut inclure javax.ejb.CreateException
et d’autres exceptions spécifiques à votre
application. La méthode ejbCreate() génère
habituellement une CreateException si un paramètre
entré est invalide.
4.3.4.Méthodes métiers
Le but premier d’un session bean est d’exécuter
les tâches métiers pour le client. Le client appelle les
méthodes métiers sur la référence de
l’objet distant qui est retourné par la méthode
create(). Du point de vue du client, les méthodes
métiers semblent êtres exécutés
localement, mais elles sont réellement exécutées
à distance sur le session bean. L’extrait de code
suivant montre comment le programme CartClient appelle les méthodes
métiers :
Cart
shoppingCart = home.create("Duke
DeEarl", "123");
shoppingCart.addBook("The
Martian Chronicles");
shoppingCart.addBook("2001
A Space Odyssey");
shoppingCart.addBook("The
Left Hand of Darkness");
Vector
bookList = new Vector();
bookList
= shoppingCart.getContents();
La classe CartBean implémente les méthodes métiers
dans le code suivant :
public
void
addBook(String title) {
contents.addElement(title);
}
public
void
removeBook(String title) throws
BookException {
boolean
result
=
contents.removeElement(title);
if
(result == false)
{
throw
new
BookException(title
+
"
not in cart.");
}
}
public
Vector getContents() {
return
contents;
}
La signature des méthodes métiers doit ête
conforme aux règles suivantes :
-
Le nom de la méthode ne doit pas entrer en conflit avec un
nom de méthode défini par l’architecture EJB.
Par exemple, vous ne pouvez appeler une méthode métier
ejbCreate() ou ejbActivate().
-
Le modificateur d’accès doit être public.
-
Si le bean permet un accès distant, les arguments doivent
avoir un type adéquat à l’API Java Remote Method
Invocation (« Java RMI »).
-
Le modificateur ne peut être static ou final.
La clause throws peut inclure les exceptions que vous
définissez pour votre application. La méthode
removeBook(), par exemple, génère une
BookException si le livre n’est pas dans le
caddie.
Pour indiquer un problème au niveau du système, tel que
l’impossibilité de se connecter à une base de
données, une méthode métier dévrait
générer un javax.ejb.EJBException. Quand une
méthode métier lève une EJBException, le
conteneur l'enveloppe dans une RemoteException, qui est
attrapée par le client. Le conteneur n’enveloppera pas
les exceptions spécifiques à l’application telles
que BookException. Puisqu'EJBException est une sous-classe de
RuntimeException, vous n'avez pas besoin de l'inclure dans la
clause throws de la méthode métier.
4.3.5.Interfaces
Home interface
Une home interface hérite de l'interface
javax.ejb.EJBHome. Pour un session bean, le but de la home
interface est de définir les méthodes create()
qu'un client distant peut appeler. Le programme CartClient,
par exemple, appelle cette méthode create() :
Cart
shoppingCart = home.create("Duke DeEarl", "123");
Chaque méthode create() dans la home interface
correspond à une méthode ejbCreate() dans
la classe du bean. Voici les signatures des méthodes
ejbCreate() dans la classe CartBean :
public
void
ejbCreate(String person) throws
CreateException
public
void
ejbCreate(String person, String id) throws
CreateException
Comparez les signatures des méthodes ejbCreate()
à celles des méthodes create() dans
l'interface CartHome :
Cart
create(String person) throws
RemoteException, CreateException;
Cart
create(String person, String id) throws
RemoteException, CreateException;
Les signatures des méthodes ejbCreate() et
create() sont similaires mais comportent des diffèrences.
Voici les règles pour définir les signatures des
méthodes create() de la home interface :
-
Le nombre et les types d'arguments dans une méthode
create() doivent correspondre à ceux de sa méthode
ejbCreate() correspondante.
-
Les arguments et le type de retour de la méthode create()
doivent être les types RMI valides.
-
Une méthode create() retourne le type
d'interface distante de l'enterprise bean (mais une méthode
ejbCreate() renvoie void).
-
La clause throws de la méthode create()
doit inclure java.rmi.RemoteException et
javax.ejb.CreateException.
Remote interface
L'interface distante, qui hérite javax.ejb.EJBObject,
définit les méthodes métiers qu'un client
distant peut appeler.
Les définitions de méthodes dans la remote interface
doivent suivre ces règles :
-
Chaque méthode de la remote interface doit correspondre à
une méthode implémentée dans la classe de
l’enterprise bean.
-
Les signatures des méthodes dans la remote interface doivent
être identiques aux signatures des méthodes
correspondantes dans la classe du bean.
-
Les arguments et les valeurs de retour doivent être d’un
type valide pour RMI.
-
La clause throws doit inclure java.rmi.RemoteException.
4.3.6.Les classes Helper
Le session bean CartEJB possède deux classes helper :
BookException et IdVerifier. La BookException est générée
par la méthode removeBook() et IdVerifier valide le customerId
dans l’une des méthodes ejbCreate(). Les
classes helper doivent résider dans le fichier EJB JAR
qui contient les classes de l’enterprise bean.
4.3.7.Descripteur de déploiement
Voici un exemple de descripteur de déploiement pour un EJB
Session Bean :
<?xml
version="1.0"?>
<!DOCTYPE
ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise
JavaBeans
1.1//EN" "http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd">
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>TravelAgentEJB</ejb-name>
<home>com.titan.travelagent.TravelAgentHomeRemote</home>
<remote>com.titan.travelagent.TravelAgentRemote</remote>
<ejb-class>com.titan.travelagent.TravelAgentBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<ejb-ref>
<ejb-ref-name>ejb/CabinHome</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<home>com.titan.cabin.CabinHomeRemote</home>
<remote>com.titan.cabin.CabinRemote</remote>
</ejb-ref>
</session>
</enterprise-beans>
<assembly-descriptor>
...
</assembly-descriptor>
</ejb-jar>
La différence entre un stateless et un stateful SessionBean
n’est lié qu’à la balise :
« session-type ». Cette balise prend comme
valeur : Stateless ou Stateful en fonction du type de l’EJB.
Les session bean étant très souvent utilisés en
tant que façade pour le management des données, il nous
faut établire des références entre les Beans.
Cette référence se fait par la balise : ejb-ref
qui regroupe l’ensemble des informations d’une référence.
-
ejb-ref : section pour une référence
-
ejb-ref-name : nom JNDI de la référence
-
ejb-ref-type : type du bean référencé
-
home : classe Home du bean référencé
-
remote : classe Remote du bean référencé
4.3.8.Cycle de vie
Le cycle de vie différe suivant que l’on se trouve avec
un stateful ou un stateless Session Bean. En effet, le stateful
gardant un état de semi-persistance.
Stateless
Puisqu’un stateless session bean n’est jamais
« passivé », son cycle de vie n’a
que deux états : « n’existe pas »
et « prêt » pour l’appel de
méthodes métiers.
Cycle de vie d’un Stateless Session Bean
Stateful
Le schéma ci-dessous illustre les étapes par lesquelles
passe un session bean durant sa vie. Le client initialise le cycle de
vie en faisant appel à la méthode create().
Le conteneur d’EJB instancie le bean et appelle ensuite les
méthodes setSessionContext() et ejbCreate()
du session bean. Le bean est alors « prêt »
pour l’appel de ses méthodes métiers.
Cycle de vie d’un Stateful Session Bean
A l'étape ready, le conteneur d'EJB peut décider
de désactiver, ou passivate, le bean en le déplaçant
de la mémoire vers un stockage secondaire. Typiquement, le
conteneur d'EJB utilise un algorithme pour choisir le bean le moins
récemment utilisé pour la passivation. Le conteneur
d'EJB appelle la méthode ejbPassivate() du bean
juste avant la passivation. Si un client appelle une méthode
métier sur le bean alors qu'il est à l'étape
passive, le conteneur d'EJB active le bean, appelant sa
méthode ejbActivate() et le déplace à
l'étape ready.
À la fin du cycle de vie, le client appelle la méthode
remove() et le conteneur d’EJB appelle la méthode
ejbRemove() du bean. L'instance du bean est prête
à être supprimée par le Garbage Collector.
Au niveau de l’application cliente, votre code contrôle
seulement l'invocation de deux méthodes du cycle de vie :
les méthodes create() et remove().
Toutes les autres méthodes du schéma 1-4 sont appelées
par le conteneur d’EJB. La méthode ejbCreate(),
par exemple, à l'intérieur de la classe du bean, vous
permet d'effectuer certaines opérations juste après que
le bean ait été initialisé. Éventuellement,
vous pourriez (par exemple) avoir envie de vous connecter à
une base de données dans la méthode ejbCreate().
|
|
 |
