COMPOSANTS LOURDS JAVA EE Enterprise - e-campus

IUT Vélizy
COMPOSANTS LOURDS JAVA EE
Enterprise Java Bean (EJB)
UVSQ JJLC
Introduction.
Les composants lourds Enterprise Java Bean (EJB) sont avant tout des composants logiciels
distribués. Après les générations d'architectures distribuées pour les langages procéduraux avec les
technologies DCE puis pour les langages orientés objet avec la technologie CORBA, la société
SUN MICROSYSTEMS a décidé à la fin des années 1990 de fournir une solution plus simple à
utiliser. En effet les technologies précédentes n'ont pas rencontrées le succès attendu du fait de leur
complexité.
La solution de la société SUN MICROSYSTEM repose sur des composants logiciels, les EJB et sur
une solution serveur d'applications pour gérer leur cycle de vie. Les EJB sont implémentés en JAVA
et configurés. La configuration est réalisée avant la version 1.5 de JAVA par un fichier XML (ejb-
jar.xml) et après par le système des annotations directement dans le code JAVA. Les composants
sont ainsi plus simples à implémenter pour les développeurs car c'est le serveur d'applications qui se
charge de la complexité. En effet le serveur transforme les EJB au niveau de leur byte-code au
moment de leur déploiement.
C'est pourquoi l'approche EJB a été perçue au moment de sa création comme une solution de type
RAD (Rapid Application Development). Aujourd'hui elle est plutôt vue comme une solution de type
cadriciel (framework). La technologie a évolué depuis ses débuts et elle fait maintenant partie de la
plateforme JAVA EE version 7. La version actuelle des composants est EJB 3.2 (jsr 345).
Les composants EJB ne peuvent s'exécuter qu'au sein de serveurs d'applications avec un profil
JAVA EE complet. Quelques éditeurs de logiciel proposent une solution de ce type. La compagnie
IBM avec sa solution WEBSPHERE, la société ORACLE avec les serveurs GLASSFISH et
WEBLOGIC, REDHAT avec sa solution JBOSS, la fondation APACHE avec le serveur
GERONIMO, la société TMAXSOFT avec son serveur TMAX JEUS 8, la société FUJITSU avec
sa solution INTERSTAGE APPLICATION SERVER et le consortium OW2 avec le serveur
JONAS.
Étape 1 : téléchargement et installation du serveur JBoss
Le serveur JBoss nécessaire à l'apprentissage de ce cours est le produit JBoss AS 7.1.1.Final. La
machine virtuelle JAVA est celle du kit de développement JDK1.7.0_51.
Après le téléchargement, il faut défaire l'archive du produit :
1/5 JJLC IUT-Vélizy

Ensuite pour faciliter le paramétrage du serveur JBoss et le déploiement des composants EJB, il est
nécessaire de créer un utilisateur avec les droits d'administration.
Puis de réaliser un script BASH de démarrage du serveur avec les variables d'environnement
habituelles à JAVA :
Il est nécessaire de démarrer le serveur et de tester son fonctionnement. Pour lancer le serveur, il
suffit d'exécuter le script BASH de lancement (après l'avoir rendu exécutable) puis d'attendre que le
processus de démarrage de JBoss soit accompli avec l'affichage du message suivant dans la console
texte :
10:20:15,990 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.1.1.Final
"Brontes" started in 8513ms - Started 172 of 249 services (76 services are passive or on-demand)
Puis il faut ouvrir un navigateur web et saisir l'URL localhost:8080. Sur la page d'accueil il y a un
lien vers la console d'administration. Après avoir saisi l'identifiant et le mot de passe créés avec
l'utilitaire add-user.sh (voir plus haut).
2/5 JJLC IUT-Vélizy

Si le serveur doit répondre à des clients sur le réseau local alors il faut aménager le script de
démarrage avec l'option suivante sur la commande standalone.sh :
/home/etude/Téléchargements/jboss-as-7.1.1.Final/bin/standalone.sh -b=adresseIP du serveur &
Dans ce type de fonctionnement de JBoss en réseau, il est plus pratique en phase de développement
de désactiver l'authentification automatique des clients. Pour cela il faut modifier le fichier de
configuration du mode standalone(jboss-as-7.1.1.Final/standalone/configuration/standalone.xml ).
Il faut supprimer l'attribut xml security-realm :
<subsystem xmlns="urn:jboss:domain:remoting:1.1">
<connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
</subsystem>
Étape 2 : création d'un projet avec Eclipse pour JAVA Developers
Il faut crée un simple projet JAVA. Il faut ajouter au CLASSPATH du projet la librairie jboss-ejb-
api_3.1_spec-1.0.1.Final.jar qui est dans le répertoire :
modules//home/etude/Téléchargements/jboss-as-7.1.1.Final/modules/javax/ejb/api/main
pour pouvoir coder des composants EJB.
Pour implémenter un client il est nécessaire d'ajouter au CLASSPATH du projet la librairie :
/home/etude/Téléchargements/jboss-as-7.1.1.Final/bin/client/jboss-client.jar
Étape 3 : développement d'un composant EJB Stateless
Depuis la version JAVA EE 6, il n'est pas en principe obligatoire de concevoir une interface au
service distribué. Mais JBoss semble l'exiger. Il est donc nécessaire de développer une interface
JAVA du service distribué et de l'implémenter par une classe JAVA qui une fois annotée représente
le futur composant lourd EJB.
3/5 JJLC IUT-Vélizy

Il faut savoir qu'une fois déployé, le byte-code du composant est modifié par le serveur. C'est à dire
que le composant exécuté par le serveur n'est pas le même que celui implémenté par le
programmeur. Cette technique est relativement courante en JAVA.
Par exemple les pages JSP dans les serveurs d'applications JAVA EE WEB sont transformées en
classes SERVLET lors du déploiement. De même les objets restaurés dans la JVM à partir de la
base de données relationnelle par la couche ORM JPA sont transformés en objets mandataires pour
des raisons de performance (proxy object) en mode lazy.
Le code source de l'interface Salutation.java :
Le code source du composant SalutationEJB.java avec les annotations de l'API EJB :
4/5 JJLC IUT-Vélizy

Le développement d'un simple client JAVA du service offert par le composant EJB SalutationEJB
éxige l'ajout des librairies de type souche (stub) au CLASSPATH du projet Eclipse. Avec la solution
Jboss, une seule librairie est nécessaire, il s'agit de la librairie $JBOSS_HOME/bin/client/jboss-
client.jar.
Le client a également besoin de compléter sa partie souche avec l'interface du service distribué,
représentée dans le projet par l'interface JAVA Salutation.java.
La consommation du service « salutation » n'est possible qu' après avoir réalisé une connexion au
serveur et avoir exécuter une requête de type JNDI sur l'annuaire des services du serveur JBoss. La
connexion au serveur peut-être entièrement réalisée dans le code JAVA du client via un objet de
type dictionnaire (Hashtable) passé en argument du constructeur de l'objet InitialContext. Elle peut
l'être de façon partielle grâce à un fichier de propriété qui a pour nom par défaut jboss-ejb-
client.properties.
Exemple de contenu du fichier jboss-ejb-client.properties :
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port = 4447
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
Si le client doit consommer un service distant sur le réseau local, alors il faut adapter ce fichier en
remplaçant la valeur localhost par l'adresse TCP-IP du serveur.
Attention pour que le serveur distant soit en mesure de répondre à des requêtes issues du réseau il
doit être démarré avec l'option -b=adresse.
L'adresse peut-être celle du serveur (exemple: -b=192.168.0.100) et alors le serveur ne peut
répondre qu'aux requêtes émanant des clients du même réseau. L'expression peut être -b=0.0.0.0 et
alors le serveur peut répondre à toutes les requêtes quelque soit l'adresse réseau des clients.
5/5 JJLC IUT-Vélizy