Exporter en RTF

GLG203 - TP11 - Cluster (EJB 2)
Page
1
- dernière modification par Administrator le 2011/04/29 14:40
T
P1
1 -
Cl
us
te
r
(E
J
B
2)
Admi
nistra
tor
2011
/04/2
9
14:4
0
Table des matières
TP 11 - Cluster (version EJB2) ............................................................................................................................................................................................................................... 2
Hello PetStore ! ......................................................................................................................................................................................................................................................... 3

GLG203 - TP11 - Cluster (EJB 2)
Page
2
- dernière modification par Administrator le 2011/04/29 14:40
Outils ............................................................................................................................................................................................................................................................................. 6
Expression des besoins ............................................................................................................................................................................................................................................. 9
Vue utilisateur ......................................................................................................................................................................................................................................................... 10
Ecrans ........................................................................................................................................................................................................................................................................ 10
Analyse et conception ............................................................................................................................................................................................................................................. 11
Vue logique .............................................................................................................................................................................................................................................................. 11
Vue processus ........................................................................................................................................................................................................................................................ 16
Vue implémentation .............................................................................................................................................................................................................................................. 17
Architecture ........................................................................................................................................................................................................................................................... 19
Vue déploiement .................................................................................................................................................................................................................................................... 20
Implémentation .......................................................................................................................................................................................................................................................... 26
Recette utilisateur ..................................................................................................................................................................................................................................................... 26
Résumé ........................................................................................................................................................................................................................................................................ 26
Références .................................................................................................................................................................................................................................................................. 26
TP 11 - Cluster (version EJB2)
Les Entreprise Java Bean, ou EJB, sont des composants serveurs qui respectent les spécifications d’un modèle
édité par Sun. Ces spécifications définissent une architecture, un environnement d’exécution (un serveur
d’application) et un ensemble d’API. Ainsi, les EJB possèdent certaines caractéristiques comme la réutilisabilité,
la possibilité de s’assembler pour construire une application, etc ...
Le respect de ces spécifications permet d’utiliser les EJB de façon indépendante du serveur d’applications dans
lequel ils s’exécutent. Celui-ci fournit un ensemble de fonctionnalités telles que la gestion du cycle de vie du
bean, la sécurité, l’accès concurrent et les transactions. En réalité, c’est dans un conteneur que s’exécute un
EJB et il lui est impossible de s’exécuter en dehors.
Le but des EJB est de faciliter la création d’applications distribuées pour les entreprises. Ils sont en fait des
objets distants utilisant RMI/IIOP (un mélange de la syntaxe RMI et du protocole de communication utilisé par
Corba) : cela permet de garantir que les EJB pourront être utilisés via un quelconque code client.
Les composants EJB se classent dans trois catégories :
• Session Beans (Stateless/Stateful)
• Entity Beans
• Message Driven Beans
Nous n’aborderons ici que les composantes sessions sans états. Les Stateless Session Beans ne fonctionnent
que de façon éphémère. Une fois qu’un client a demandé et reçu une fonctionnalité du composant, la session
avec ce composant prend fin, ne laissant aucun enregistrement de ce qui s’est passé. Ils n’ont aucune
connaissance du client ou d’un semblant de contexte concernant la requête, ils sont donc parfaits pour une
utilisation unique. Ils n’ont pas d’état, c’est-à-dire qu’on ne peut pas manipuler leurs attributs en étant sûr de leur
valeur. Ces composants peuvent, par exemple être employés dans un système de suivi des bogues où
l’utilisateur recherche tous les bogues ouverts. L’application cliente contacte un Stateless Session Bean, lui
transmettant les paramètres de recherche. Le bean accède alors à une base de données, sélectionne les
entrées correspondant aux critères, et retransmet les enregistrements au client. Lorsque la communication
s’achève, le bean ne conserve aucun souvenir de l’interaction. Avec ce comportement, plusieurs clients distincts
peuvent accéder simultanément à un Stateless Session Bean sans impact négatif.
Le client d’un EJB peut être une entité de toute forme : une application avec ou sans interface graphique, un
bean, une servlet, une JSP ou un autre EJB. Il utilisera l’API JNDI pour localiser les objets distants EJB. Cette
API, accessible à partir du paquetage javax.naming.*, permet de manipuler toutes sources de données
hiérarchiques.

GLG203 - TP11 - Cluster (EJB 2)
Page
3
- dernière modification par Administrator le 2011/04/29 14:40
Figure 1 - Cycle de vie d’un Stateless Session Bean
Hello PetStore !
L’exemple ci-dessous permet à une classe cliente d’interroger un EJB et d’obtenir la chaîne de caractère “Hello
Petstore!” ainsi que la date du jour.
Tout Stateless Session Bean est au moins constitué de trois fichiers :
• Une première interface, qualifiée « d’interface de fabrique », permet la construction (factory) d’un
composant EJB. Il s’agit bien d’une interface distante : en effet, l’interface EJBHome (1), qu’étend
HelloHome, dérive elle-même de l’interface Remote. Le nom d’une méthode de création est
obligatoirement create (2). Notez que l’invocation de cette méthode peut échouer : soit pour des raisons
liées au réseau (RemoteException) soit pour des problèmes de sécurité (CreateException).
public
interface HelloHome
extends EJBHome { // 1
Hello create()
throws RemoteException, CreateException; // 2
}
• Une interface qualifiée « d’interface métier », permet de définir les services que propose le composant
EJB. Elle définit les méthodes métiers qu’expose le composant. Dans notre cas les deux méthodes
sayHello() et today(). Notez que l’invocation de ces méthodes peut échouer pour des raisons liées au
réseau (RemoteException)
public
interface Hello
extends EJBObject {
String sayHello()
throws RemoteException;
Date today()
throws RemoteException;
}
• La classe d’implémentation du bean, c’est-à-dire le code métier à proprement parlé (1)(2). Il est
intéressant de noter que les deux méthodes métier (sayHello et today) ne lancent pas de RemoteException
alors qu’elles sont déclarées comme telle dans l’interface métier. La méthode create de l’interface locale
(home) se doit d’être renommée ejbCreate (3) dans la classe du bean.

GLG203 - TP11 - Cluster (EJB 2)
Page
4
- dernière modification par Administrator le 2011/04/29 14:40
public class HelloBean
implements SessionBean {
public HelloBean() { }
public
String sayHello() {
return
”Hello Petstore !”; // 1
}
public Date today() {
return
new Date(); // 2
}
public void ejbCreate()
throws CreateException { } // 3
public void setSessionContext(SessionContext sessionContext)
throws EJBException { }
public void ejbRemove()
throws EJBException { }
public void ejbActivate()
throws EJBException { }
public void ejbPassivate()
throws EJBException { }
}
N’oubliez pas que J2EE vous permet de spécifier des choses en rapport aux transactions et à la sécurité. Ces
informations ne seront pas codées, mais spécifiées dans le descripteur de déploiement (le fichier XML
ejb-jar.xml). Lors du déploiement du bean sur un serveur d’applications, ce dernier se chargera de générer le
code manquant en tenant compte de la sécurité et de la police transactionnelle (1). Ce fichier informe le
container du nom des interfaces ainsi que de la classe métier (2) et aussi le type du composant (3), dans notre
cas un composant session dans état (stateless).
<ejb-jar>
<enterprise-beans>
<session>
<display-name>HelloSB</display-name>
<ejb-name>HelloBean</ejb-name>
<home>HelloHome</home> // 2
<remote>Hello</remote>
<ejb-class>HelloBean</ejb-class>
<session-type>Stateless</session-type> // 3
<transaction-type>Container</transaction-type> // 1
</session>
</enterprise-beans>
</ejb-jar>
Un autre fichier de description propre au serveur d’application (dans notre cas jboss.xml), permet de donner un
nom JNDI à l’EJB afin qu’il puisse être appelable par un client. Le composant HelloBean s’appelle donc ejb/Hello
(1).
<jboss>
<enterprise-beans>
<session>
<ejb-name>HelloBean</ejb-name> // 1
<jndi-name>ejb/Hello</jndi-name>
</session>
</enterprise-beans>
</jboss>

GLG203 - TP11 - Cluster (EJB 2)
Page
5
- dernière modification par Administrator le 2011/04/29 14:40
Il ne reste plus qu’à développer la classe cliente. Celle-ci a tout d’abord besoin d’obtenir le contexte initial de
JNDI (1) propre au serveur d’application (2). Dans ce type de système hiérarchique, un contexte peut être vu
comme un noeud au sein d’un arbre. À partir de ce contexte initial (la racine), la classe recherche l’EJB qui porte
le nom ejb/Hello (défini dans le fichier de description) (3). Elle obtient ainsi l’interface home sur laquelle elle
appelle la méthode create (4) et qui retourne l’interface remote. Ce n’est qu’à partir de cette interface remote que
la classe cliente pourra appeler les méthodes métiers du composant (5).
public class Main {
public
static void main(
String[] args) {
InitialContext ic =
null;
Hashtable properties =
new Hashtable();
properties.put(Context.INITIAL_CONTEXT_FACTORY,
”org.jnp.interfaces.NamingContextFactory”);
properties.put(Context.PROVIDER_URL,
”jnp://localhost:1099”);
properties.put(Context.URL_PKG_PREFIXES,
”org.jboss.naming”); // 2
try {
ic =
new InitialContext(properties); // 1
Object objRef = (HelloHome) ic.lookup(
”ejb/Hello”); // 3
HelloHome home = (HelloHome) PortableRemoteObject.narrow(objRef, HelloHome.class);
Hello hello = home.create(); // 4
System.out.println(hello.sayHello());
System.out.println(hello.today()); // 5
}
catch (Exception e) {
e.printStackTrace();
}
}
}
Pour compiler et packager cet EJB, utilisez la cible Ant deploy du fichier build.xml qui va construire et déployer
l’archive hello-ejb.jar.
Figure 2 - Structure du fichier hello-ejb.jar
Une fois ce fichier déployé dans le serveur d’application, on peut exécuter la classe Main à l’aide de la cible
run-client.
[...]\ GLG203\ TP11.cor\ Hello> ant run-client
Buildfile: build.xml
check:
compile:
[echo] Compiles java classes
run-client: