Encadr - MultiMania

UNIVERSITE MOHAMMED PREMIER
ECOLE NATIONALE DES SCIENCES APPLIQUES
OUJDA
Département Génie Informatique
Réalisé par : Encadré par :
YAZIDI ALAOUI Youssef M. BOUCHENTOUF Toumi
EBOURKI Abderrahman
Année universitaire : 2004-2005

Etude de serveur d’application JBoss
Sommaire
1 Introduction :---------------------------------------------------------------------------------------- 3
2 Architecture J2EE : -------------------------------------------------------------------------------- 4
2.1 Introduction :---------------------------------------------------------------------------------- 4
2.2 Définition : ------------------------------------------------------------------------------------ 4
2.2.1 Environnent d’exécution J2EE :------------------------------------------------------ 4
2.2.2 Les API J2EE : ------------------------------------------------------------------------- 4
2.3 Composants J2EE :--------------------------------------------------------------------------- 5
2.3.1 Servlets :--------------------------------------------------------------------------------- 5
2.3.2 Les JSP :--------------------------------------------------------------------------------- 7
2.3.3 Les EJB : -------------------------------------------------------------------------------- 9
3 Les outils de développement : -------------------------------------------------------------------14
3.1 Eclipse :---------------------------------------------------------------------------------------14
3.1.1 L’installation ---------------------------------------------------------------------------15
3.1.2 le Workbench --------------------------------------------------------------------------16
3.1.3 Les fonctions pratiques du Workbench---------------------------------------------16
3.1.4 Le workspace --------------------------------------------------------------------------17
3.1.5 Le Java Development Tooling (JDT)-----------------------------------------------17
3.1.6 Génération de la documentation javadoc-------------------------------------------18
3.1.7 La perspective "debug" ---------------------------------------------------------------19
3.1.8 Le refactoring --------------------------------------------------------------------------19
3.1.9 L'aide dans Eclipse--------------------------------------------------------------------21
3.2 Le serveur d’application JBOSS :---------------------------------------------------------21
3.2.1 Les serveurs d’applications :---------------------------------------------------------21
3.2.2 JBOSS un serveur d’applications compatible J2EE :-----------------------------23
3.2.3 Architecture technique de JBOSS : -------------------------------------------------23
3.2.4 Installation du serveur JBOSS : -----------------------------------------------------25
3.2.5 Quelques caractéristiques de JBOSS :----------------------------------------------26
3.3 L’outil Ant :----------------------------------------------------------------------------------27
3.3.1 Installation de Ant---------------------------------------------------------------------27
3.3.2 Exécution de Ant ----------------------------------------------------------------------28
3.3.3 Le fichier build.xml -------------------------------------------------------------------28
3.4 L’outil XDoclet : ----------------------------------------------------------------------------35
4 Etude de cas réalisé :------------------------------------------------------------------------------36
4.1 Description : ---------------------------------------------------------------------------------36
4.2 Architecture de l’application : -------------------------------------------------------------36
4.3 Préparatifs : JBOSS IDE -------------------------------------------------------------------37
4.4 Création du projet :--------------------------------------------------------------------------41
4.4.1 Création de L’EJB Session : ---------------------------------------------------------42
4.4.2 Création de l’EJB Entity : ------------------------------------------------------------47
4.4.3 Création de la Servlet : ---------------------------------------------------------------52
4.4.4 Création de l’application Web: ------------------------------------------------------57
4.4.5 Déploiement et exécution :-----------------------------------------------------------59
5 Conclusion :----------------------------------------------------------------------------------------62
6 Bibliographie : -------------------------------------------------------------------------------------62
ENSA d’Oujda 2

Etude de serveur d’application JBoss
1 Introduction :
Aujourd’hui, les applications web complexes utilisent les serveurs d’applications J2EE
qui sont une extension des serveurs web grâce aux différents services offerts comme la
gestion de la sécurité, des transactions et leur grande disponibilité. Et face aux différentes
solutions propriétaires du marché, le monde Open Source propose lui aussi des solutions
fiables et stable dont la plus connue est le serveur d’application certifié J2EE Jboss.
C’est dans ce contexte, que se situe notre projet J2EE, d’une durée de 2 mois et sous le
thème : Etude du serveur d’application Jboss, Tomcat et Eclipse. Il s’agit en effet d’un projet
dont l’objectif consiste à installer, manipuler et mettre en œuvre le serveur d’application Jboss
avec le moteur de Servlet intégré Tomcat d’Apache et réaliser une étude de cas détaillé tout
en profitant des possibilités offertes par un environnement de développement intégré comme
Eclipse.
Ce rapport de projet décrit une étude de cas détaillé et qui met en œuvre deux types de
composants EJB : un EJB session et un autre EJB Entity type CMP pour la gestion de la
persistance ainsi qu’une Servlet pour communiquer avec le client en utilisant le serveur
d’application open source Jboss.
La première partie de ce rapport décrit en détail l’architecture J2EE ainsi que les
composants utilisés comme les EJB ou les servlets. La deuxième partie traite les outils de
développement utilisés qui sont le serveur d’application Jboss, l’IDE Eclipse, Ant, Tomcat et
XDoclet. La dernière partie décrit l’étude de cas réalisé qui récapitule l’ensemble des
connaissances acquises à propos des composants J2EE ainsi que le serveur d’application
Jboss.
Ce rapport se termine par une conclusion et éventuellement des perspectives.
ENSA d’Oujda 3

Etude de serveur d’application JBoss
2 Architecture J2EE :
2.1 Introduction :
J2EE signifie Java 2 Entreprise Edition et repose donc sur Java, le fameux langage objet
conçu pour être "portable" ("Write Once, Run Anywhere").
Dès son origine, java a révolutionné plusieurs domaines de l'informatique, que ça soit la
téléphonie, l'Internet ou les applications d'entreprise. Aujourd'hui, SUN a réorganisé son offre
autour de 3 briques :
� Java 2 Standard Edition (J2SE) qui vise les postes clients.
� Java 2 Micro Edition (J2ME) qui cible les terminaux portables.
� Java 2 Entreprise Edition (J2EE) qui définit le cadre d'un serveur d'applications et
d'intégration.
2.2 Définition :
J2EE est une plateforme orientée serveur pour le développement et l’exécution
d’application distribuées. Elle se compose de deux parties :
� Un ensemble de spécifications pour un environnement exécutant les composants Java
qui se nomme serveur d’applications.
� Un ensemble d’API qui peuvent être obtenus et utilisées séparément.
2.2.1 Environnent d’exécution J2EE :
Un des avantages majeurs de J2EE est de faire abstraction de l'infrastructure d'exécution.
En effet, J2EE spécifie les rôles et les interfaces pour les applications, ainsi que
l'environnement d'exécution dans lequel les applications sont déployées. Ceci permet aux
développeurs d'application de ne pas avoir a reprogrammé les services d'infrastructure.
2.2.2 Les API J2EE :
Le serveur J2EE va fournir à votre application un ensemble de services comme les
connexions aux bases de données, la messagerie, les transactions... L'architecture J2EE unifie
l'accès à ces services au sein des API de ses services d'entreprise mais plutôt que d'avoir accès
à ces services au travers d'interfaces propriétaires ou non standard, les applications J2EE
peuvent accéder à ces API via le serveur.
La spécification de la plateforme J2EE prévoit un ensemble d'extensions Java standard
que chaque plate-forme J2EE doit prendre en charge : JNDI, JDBC, SERVLET, JSP, JMS,
JTA, et les EJB.
ENSA d’Oujda 4

Etude de serveur d’application JBoss
2.3 Composants J2EE :
2.3.1 Servlets :
Une servlet est un programme qui s'exécute côté serveur en tant qu'extension du serveur.
Elle reçoit une requête du client, elle effectue des traitements et renvoie le résultat. La liaison
entre la servlet et le client peut être directe ou passer par un intermédiaire comme par exemple
un serveur http.
Même si pour le moment la principale utilisation des servlets est la génération de pages
html dynamiques utilisant le protocole http et donc un serveur web, n'importe quel protocole
reposant sur le principe de requête/réponse peut faire usage d'une servlet.
Ecrite en java, une servlet en retire ses avantages : la portabilité, l'accès à toutes les API
de java dont JDBC pour l'accès aux bases de données, ... Une servlet peut être invoquée
plusieurs fois en même temps pour répondre à plusieurs requêtes simultanées.
La servlet se positionne dans une architecture Client/Serveur trois tiers dans le tiers du
milieu entre le client léger chargé de l'affichage et la source de données.
Fonctionnement :
Un serveur d'application permet de charger et d'exécuter les servlets dans une JVM. C'est
une extension du serveur web. Ce serveur d'application contient entre autre un moteur de
servlets qui se charge de manager les servlets qu'il contient. Pour exécuter une servlet, il suffit
de saisir une URL qui désigne la servlet dans un navigateur.
1. Le serveur reçoit la requête http qui nécessite une servlet de la part du navigateur.
2. Si c'est la première sollicitation de la servlet, le serveur l'instancie. Les servlets sont
stockées (sous forme de fichier .class) dans un répertoire particulier du serveur. Ce
répertoire dépend du serveur d'application utilisé. La servlet reste en mémoire jusqu'à
l'arrêt du serveur. Certains serveurs d'application permettent aussi d'instancier des
servlets dès le lancement du serveur. La servlet en mémoire, peut être appelée par
plusieurs threads lancés par le serveur pour chaque requête. Ce principe de
fonctionnement évite d'instancier un objet de type servlet à chaque requête et permet
de maintenir un ensemble de ressources actives tel qu'une connexion à une base de
données.
3. le serveur créé un objet qui représente la requête http et objet qui contiendra la réponse
et les envoie à la servlet.
4. la servlet créé dynamiquement la réponse sous forme de page html transmise via un
flux dans l'objet contenant la réponse. La création de cette réponse utilise bien sûre la
requête du client mais aussi un ensemble de ressources incluses sur le serveur tels de
que des fichiers ou des bases de données.
5. le serveur récupère l'objet réponse et envoie la page html au client.
ENSA d’Oujda 5

Etude de serveur d’application JBoss
Les servlets http :
L'usage principal des servlets est la création de pages HTML dynamiques. Sun fourni une
classe qui encapsule une servlet utilisant le protocole http. Cette classe est la classe
HttpServlet. Cette classe hérite de GenericServlet, donc elle implémente l'interface Servlet, et
redéfinie toutes les méthodes nécessaires pour fournir un niveau d'abstraction permettant de
développer facilement des servlets avec le protocole http.
Ce type de servlet n'est pas utile que pour générer des pages HTML bien que cela soit son
principal usage, elle peut aussi réaliser un ensemble de traitements tel que mettre à jour une
base de données. En réponse, elle peut générer une page html qui indique le succès ou non de
la mise à jour.
La requête du client est encapsulée dans un objet qui implémente l'interface
HttpServletRequest : cet objet contient les données de la requête et des informations sur le
client. La réponse de la servlet est encapsulée dans un objet qui implémente l'interface
HttpServletResponse.
Typiquement pour définir une servlet, il faut définir une classe qui hérite de la classe
HttpServlet et redéfinir la classe doGet et/ou doPost selon les besoins. La méthode service
héritée de HttpServlet appelle l'une ou l'autre de ces méthodes en fonction du type de la
requête http :
� une requête GET : c'est une requête qui permet au client de demander une ressource.
� une requête POST : c'est une requête qui permet au client d'envoyer des informations
issues par exemple d'un formulaire.
La classe HttpServlet hérite aussi de plusieurs méthodes définies dans l'interface Servlet:
init(), destroy() et getServletInfo().
La méthode init() : Les paramètres d’initialisation de la servlet.
La méthode DoGet() : Le traitement typique de la méthode doGet() est d'analyser les
paramètres de la requête, alimenter les données de l'en-tête de la réponse et d'écrire la
réponse.
La méthode DoPost() : Une requête POST n'est utilisable qu'avec un formulaire
HTML. La méthode doPost() doit généralement recueillir les paramètres pour les traiter et
générer la réponse. Pour obtenir la valeur associée à chaque paramètre il faut utiliser la
méthode getParameter() de l'objet HttpServletRequest. Cette méthode attend en paramètre le
nom du paramètre dont on veut la valeur. Ce paramètre est sensible à la casse.
ENSA d’Oujda 6

Etude de serveur d’application JBoss
2.3.2 Les JSP :
Les JSP permettent d'introduire du code Java dans des tags prédéfinis à l'intérieur d'une
page HTML. La technologie JSP mélange la puissance de Java côté serveur et la facilité de
mise en page d'HTML côté client. En fait dans une servlet, les traitements et la présentation
sont regroupés. L'aspect présentation est dans ce cas pénible à développer et à maintenir à
cause de l'utilisation répétitive de méthodes pour insérer le code HTML dans le flux de sortie.
De plus, une simple petite modification dans le code HTML nécessite la recompilation de
la servlet. Avec un JSP, la séparation des traitements et de la présentation rend ceci très facile
et automatique.
Une JSP est habituellement constituée de données HTML, de tags JSP et de scriplets :
2.3.2.1 Les tags de directives :
Les directives permettent de préciser des informations globales sur la page JSP. Leur
syntaxe est la suivante :
Les spécifications des JSP définissent trois directives :
page : permet de définir des options de configuration
Exemples :
:défini un import.
: définit le type mime.
include : le fichier inclus peut être un fragment de code JSP, HTML ou Java. Le fichier est
inclus dans la JSP avant que celle ci ne soit interprétée par le moteur de JSP. La syntaxe est la
suivante :
ENSA d’Oujda 7

Etude de serveur d’application JBoss
taglib : permet de définir des tags personnalisés.
2.3.2.2 Les tags de scripting
Ces tags permettent d'insérer du code Java qui sera inclus dans la servlet générée à partir
de la JSP. Il existe trois tags pour insérer du code Java :
Le tag de déclarations :
Ce tag permet de déclarer des variables ou des méthodes qui pourront être utilisées dans
la JSP. Il ne génère aucun caractère dans le fichier HTML de sortie.
Exemple :
Il est possible de déclarer plusieurs variables dans le même tag en les séparant avec des
caractères ' ;'.
Le tag d'expressions :
Le moteur de JSP remplace ce tag par le résultat de l'évaluation de l'expression présente
dans le tag. Ce résultat est toujours converti en une chaîne.
Exemple :
Date du jour :
Le tag des scriplets :
Ce tag contient du code Java nommé un scriptlet. Par défaut, le code inclus dans le tag est
inséré dans la méthode service() de la servlet générée à partir de la JSP.
Exemple :
Essai de page JSP

Etude de serveur d’application JBoss
2.3.2.3 Les tags de commentaires
Il existe deux types de commentaires avec les JSP :
Les commentaires visibles dans le code HTML :
Ces commentaires sont ceux définis par format HTML. Ils sont intégralement reconduit
dans le fichier HTML généré. Il est possible d'insérer, dans ce tag, un tag JSP de type
expression qui sera exécuté.
Exemple :
Dans la JSP :
−−>
Dans la page HTML générée :
Les commentaires cachés :
Les commentaires cachés sont utilisés pour documenter la page JSP. Leur contenu est
ignoré par le moteur de JSP et ne sont donc pas reconduit dans la page HTML générée.
2.3.2.4 Les tags d'actions
Les tags d'actions permettent de réaliser des traitements couramment utilisés.
2.3.3 Les EJB :
• Le tag : Ce tag permet de localiser une instance ou d'instancier
un bean pour l'utiliser dans la JSP.
• Le tag : Ce tag permet de mettre à jour la valeur d'un ou
plusieurs attributs d'un Bean.
• Le tag : Ce tag permet d'obtenir la valeur d'un attribut d'un
Bean.
• Le tag : Ce tag permet de rediriger la requête vers une autre
URL pointant vers un fichier HTML, JSP ou un servlet.
• Le tag : Ce tag permet d'inclure le contenu généré par une JSP ou
une servlet dynamiquement au moment ou la JSP est exécutée. C'est la
différence avec la directive include avec laquelle le fichier est inséré dans la
JSP avant la génération de la servlet.
Les Entreprise Java Bean ou EJB sont des composants serveurs donc non visuel qui
respectent les spécifications d'un modèle édité par Sun. Ces spécifications définissent une
architecture, un environnement d'exécution et un ensemble d'API.
ENSA d’Oujda 9

Etude de serveur d’application JBoss
Le respect de ces spécifications permet d'utiliser les EJB de façon indépendante du
serveur d'applications J2EE dans lequel ils s'exécutent, du moment ou le code de mise en
oeuvre des EJB n'utilisent pas d'extensions proposées par un serveur d'applications particulier.
En fait Le but des EJB est de faciliter la création d'applications distribuées pour les
entreprises.
Une des principales caractéristiques des EJB est de permettre aux développeurs de se
concentrer sur les traitements orientés métiers car les EJB et l'environnement dans lequel ils
s'exécutent prennent en charge un certain nombre de traitements tel que la gestion des
transactions, la persistance des données, la sécurité, ...
Physiquement, un EJB est un ensemble d'au moins deux interfaces et une classe
regroupée dans un module contenant un descripteur de déploiement particulier.
2.3.3.1 Présentation des EJB
Les EJB sont des composants et en tant que tel, ils possèdent certaines caractéristiques
comme la réutilisabilité, la possibilité de s'assembler pour construire une application, etc. Les
EJB et les beans n'ont en commun que d'être des composants. Les java beans sont des
composants qui peuvent être utilisés dans toutes les circonstances. Les EJB doivent
obligatoirement s'exécuter dans un environnement serveur dédié.
Il sont parfaitement adaptés pour être intégrés dans une architecture trois tiers ou plus. Et
ils s'exécutent dans un environnement particulier : le serveur d'EJB. Celui ci fournit un
ensemble de fonctionnalités utilisées par un ou plusieurs conteneurs d'EJB qui constituent le
serveur d'EJB. 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 conteneur d'EJB propose un certain nombre de services qui assurent la gestion :
� du cycle de vie du bean
� de l'accès au bean
ENSA d’Oujda 10

Etude de serveur d’application JBoss
� de la sécurité d'accès
� des accès concurrents
� des transactions
Les entités externes au serveur qui appellent un EJB ne communiquent pas directement
avec celui ci. Les accès au EJB par un client se fait obligatoirement via le conteneur.
L'avantage de passer par le conteneur est que celui ci peut utiliser les services qu'il propose et
libérer ainsi le développeur de cette charge de travail. Ceci permet au développeur de se
concentrer sur les traitements métiers proposés par le bean.
Il existe deux types d'EJB : les EJB de session (session beans) et les EJB entité (les entity
beans). Depuis la version 2.0 des EJB, il existe un troisième type d’EJB : les EJB orienté
message (message driven beans).
2.3.3.2 Le développement d'un EJB
Le cycle de développement d'un EJB comprend :
� la création des interfaces et des classes du bean
� le packaging du bean sous forme de fichier archive jar
� le déploiement du bean dans un serveur d'EJB
� le test du bean
La création d'un bean nécessite la création d'au minimum deux interfaces et une classe
pour respecter les spécifications de Sun : la classe du bean, l'interface remote et l'interface
home.
L'interface remote permet de définir l'ensemble des services fournis par le bean. Cette
interface étend l'interface EJBObject. Dans la version 2.0 des EJB, l'API propose une
interface supplémentaire, EJBLocalObject, pour définir les services fournis par le bean qui
peuvent être appelés en local par d'autres beans. Ceci permet d'éviter de mettre en oeuvre
toute une mécanique longue et coûteuses en ressources pour appeler des beans s'exécutant
dans le même conteneur.
L'interface home permet de définir l'ensemble des services qui vont permettre la gestion
du cycle de vie du bean. Cette interface étend l'interface EJBHome.
La classe du bean contient l'implémentation des traitements du bean. Cette classe
implémente les méthodes déclarées dans les interfaces home et remote. Les méthodes
définissant celle de l'interface home sont obligatoirement préfixées par "ejb".
L'accès aux fonctionnalités du bean se fait obligatoirement par les méthodes définies dans
les interfaces home et remote et il existe un certain nombre d'API qu'il n'est pas possible
d'utiliser dans un EJB :
• les threads
• flux pour des entrées/sorties
• du code natif
• AWT et Swing
ENSA d’Oujda 11

Etude de serveur d’application JBoss
L'interface remote
L'interface remote permet de définir les méthodes qui contiendront les traitements
proposés par le bean. Cette interface doit étendre l'interface javax.ejb.EJBObject. Toutes les
méthodes définies dans cette interface doivent obligatoirement respecter les spécifications de
RMI et déclarer qu'elles peuvent lever une exception de type RemoteException. L'interface
javax.ejb.EJBObject définit plusieurs méthodes qui seront donc présentes dans tous les EJB :
L'interface home
• EJBHome getEJBHome() : renvoie une référence sur l'objet Home
• Handle getHandle() : renvoie un objet permettant de sérialiser le bean
• Object getPrimaryKey() : renvoie une référence sur l'objet qui encapsule la clé
primaire d'un bean entité
• booléen isIdentical(EJBObject) : renvoie un booléen qui précise si le bean est
identique à l'instance du bean fourni en paramètre. Pour un bean session sans
état, cette méthode renvoie toujours true. Pour un bean entité, la méthode
renvoie true si la clé primaire des deux beans est identique.
• void remove() : cette méthode demande la destruction du bean. Pour un bean
entité, elle provoque la suppression des données correspondants dans la base de
données.
L'interface home permet de définir des méthodes qui vont gérer le cycle de vie du bean.
Cette interface doit étendre l'interface EJBHome. La création d'une instance d'un bean se fait
grâce à une ou plusieurs surcharges de la méthode create(). Chacune de ces méthodes renvoie
une instance d'un objet type de l'interface remote L'interface javax.ejb.EJBHome définit
plusieurs méthodes :
• EJBMetaData getEJBMetaData() throws java.rmi.RemoteException
• HomeHandle getHomeHandle() throws java.rmi.RemoteException : renvoie
un objet qui permet de sérialiser l'objet implémentant l'interface EJBHome
• void remove(Handle) throws java.rmi.RemoteException,
javax.ejb.RemoveException : supprime le bean
• void remove(Object) throws java.rmi.RemoteException,
javax.ejb.RemoveException : supprime le bean entité dont l'objet encapsulant la
clé primaire est fourni en paramètre
La ou les méthodes à définir dans l'interface home dépendent du type d'EJB:
ENSA d’Oujda 12

Etude de serveur d’application JBoss
2.3.3.3 Les EJB session
Un EJB session est un EJB de service dont la durée de vie correspond à un échange avec
un client. Ils contiennent les règles métiers de l'application. Il existe deux types d'EJB session
: sans état (stateless) et avec état (statefull).
Les EJB session statefull sont capables de conserver l'état du bean dans des variables
d'instance durant toute la conversation avec un client. Mais ces données ne sont pas
persistantes : à la fin de l'échange avec le client, l'instance de l'EJB est détruite et les données
sont perdues. Par contre les stateless ne peuvent pas conserver de telles données entre chaque
appel du client.
Il ne faut pas faire appel directement aux méthodes create() et remove() de l'EJB. C'est le
conteneur d'EJB qui se charge de la gestion du cycle de vie de l'EJB et qui appelle ces
méthodes. Le client décide simplement du moment de la création et de la suppression du bean
en passant par le conteneur.
Une classe qui encapsule un EJB session doit implémenter l'interface
javax.ejb.SessionBean. Elle ne doit pas implémenter les interfaces home et remote mais elle
doit définir les méthodes déclarées dans ces deux interfaces.
2.3.3.4 Les EJB entité
Ces EJB permettent de représenter et de gérer des données enregistrées dans une base de
données. Ils implémentent l'interface EntityBean.
L'avantage d'utiliser un tel type d'EJB plutôt que d'utiliser JDBC ou de développer sa
propre solution pour mapper les données est que certains services sont pris en charge par le
conteneur.
Les beans entité assurent la persistance des données en représentant tout au partie d'une
table ou d'une vue. Il existe deux types de bean entité :
• persistance gérée par le conteneur (CMP : Container Managed Persistence)
• persistance gérée par le bean (BMP : Bean Managed Persistence).
Avec un bean entité CMP, c'est le conteneur d'EJB qui assure la persistance des données
grâce aux paramètres fournis dans le descripteur de déploiement du bean. Il se charge de toute
la logique des traitements de synchronisation entre les données du bean et les données dans la
base de données. Tandis qu’un bean entité BMP, assure lui même la persistance des données
grâce à du code inclus dans les méthodes du bean.
2.3.3.5 Le déploiement des EJB
Pour permettre le déploiement d'un EJB, il faut définir un fichier DD (deployement
descriptor) qui contient des informations sur le bean. Ce fichier au format XML permet de
donner au conteneur d'EJB des caractéristiques du bean.
ENSA d’Oujda 13

Etude de serveur d’application JBoss
Un EJB doit être déployé sous forme d'une archive jar qui doit contenir un fichier qui est
le descripteur de déploiement et toutes les classes qui composent chaque EJB (interfaces
home et remote, les classes qui implémentent ces interfaces et toutes les autres classes
nécessaires aux EJB).
Une archive ne doit contenir qu'un seul descripteur de déploiement pour tous les EJB de
l'archive. Ce fichier au format XML doit obligatoirement être nommé ejb−jar.xml. et met dans
un répertoire META−INF qui contiendra lui même le descripteur de déploiement. Le reste de
l'archive doit contenir les fichiers .class avec toute l'arborescence des répertoires des
packages.
L'appel d'un EJB par un client
Un client peut être une entité de toute forme : application avec ou sans interface
graphique, un bean, une servlet ou une JSP ou un autre EJB.
Le mode d'appel d'un EJB suit toujours la même logique :
• obtenir une référence qui implémente l'interface home de l'EJB grâce à JNDI
• créer une instance qui implémente l'interface remote en utilisant la référence
précédemment acquise
• appelle de la ou des méthodes de l'EJB
2.3.3.6 Les EJB orientés messages
Ces EJB sont différents des deux types d'EJB car ils répondent à des invocations de façon
asynchrone. Ils permettent de réagir à l'arrivée de messages fournis par un M.O.M.
(middleware oriented messages).
3 Les outils de développement :
3.1 Eclipse :
Eclipse est un environnement de développement intégré (Integrated Development
Environment) développé en Java dont le but est de fournir une plate−forme modulaire pour
permettre de réaliser des développements informatiques.
I.B.M. est à l'origine du développement d'Eclipse qui est d'ailleurs toujours le cœur de
son outil Websphere Studio Workbench (WSW). Tout le code d'Eclipse a été donné à la
communauté par I.B.M afin de poursuivre son développement.
Les principaux modules fournis en standard avec Eclipse concernent le développement
avec Java mais d’autres modules peuvent être ajoutés pour d'autres langages notamment C++,
Cobol, et d'autres aspects de développement (base de données, conception avec UML, … ).
Les performances à l'exécution d'Eclipse sont très bonnes car il n'utilise pas Swing pour
l'interface homme−machine mais un toolkit particulier nommé SWT associé à la bibliothèque
ENSA d’Oujda 14

Etude de serveur d’application JBoss
JFace. SWT (Standard Widget Toolkit) est développé en Java par IBM en utilisant au
maximum les composants natifs fournis par le système d'exploitation sous jacent.
Eclipse est formé d’un noyau (le Runtime) qui est le cœur de la plate-forme et d’un
ensemble de modules nommés plug-ins, cela permet l’extension de la plate-forme et ainsi
fournir la possibilité à des tiers de développer des fonctionnalités qui ne sont pas fournies en
standard par Eclipse.
3.1.1 L’installation
Avant de commencer l’installation, il faut obligatoirement qu'un JDK 1.3 minimum y soit
installé. La version 1.4 est fortement recommandée pour améliorer les performances et
pouvoir utiliser le remplacement de code lors du débogage (technologie JPDA).
les plate−formes supportant Eclipse sont Windows ( 98ME et SE / NT / 2000 / XP),
Linux , Solaris 8, QNX, AIX 5.1, HP−UX 11, MAC OS X.
� Sous Windows
Sur le site http://www.eclipse.org/downloads/index.php télécharger le fichier
eclipse−SDK−3.0.1−win32.zip. Ensuite, extraire l'archive dans un répertoire et exécuter le
programme eclipse.exe. le programme termine automatiquement l’installation puis s’exécute.
� Sous Linux
Il faut ajouter le répertoire bin du JDK à la variable système PATH pour permettre au
système de trouver les exécutables nécessaires.
PATH=$PATH: /opt/IBMJava2−13/bin
Pour exécuter Eclipse, il suffit de le lancer dans un shell.
$ eclipse −data workspace
� Lancer Eclipse
Eclipse accepte plusieurs paramètres sur la ligne de commande qui lance l'application.
Les plus importants sont :
–vm : préciser la machine virtuelle qui va exécuter Eclipse.
–data : préciser l'emplacement du workspace.
–ws : préciser sous les environnements de type Unix la bibliothèque graphique utilisée,
"motif" ou "gtk".
Exemple : Eclipse.exe −vm C:\java\jre1.4.2\bin\javaw.exe
ENSA d’Oujda 15

Etude de serveur d’application JBoss
3.1.2 le Workbench
Au lancement d’Eclipse, une seul fenêtre s’ouvre contenant le Workbench. Il est composé
de huit perspectives. Chaque perspective est adaptée a un usage particulier :
Une perspective contient des sous fenêtres qui peuvent contenir des vues et des éditeurs.
Les vues sont pour sélectionner des éléments et les éditeurs pour visualiser et modifier leur
contenu.
3.1.3 Les fonctions pratiques du Workbench
� La fonction de recherche :
Cette fonction de recherche permet d'obtenir une liste d'éléments qui contiennent une
chaîne désignée par un motif. Elle peut se faire dans tous les fichiers, dans les fichiers source
Java ou dans l'aide en ligne.
Exemple : recherche des chaines qui se termine par « Bean » dans les fichier java
Pour la chaîne : *Bean
Pour les fichiers :*.java
� La liste des tâches :
La vue "Tâches" affiche et permet de gérer une liste de tâches à faire. Ces tâches peuvent
être de plusieurs types :
• des actions à réaliser �
• des erreurs de compilation �
• des points d'arrêt pour le debugage �
� La liste des signets
ENSA d’Oujda 16

Etude de serveur d’application JBoss
Les signets permettent de maintenir une liste d'éléments particuliers dans le but d'y
accéder rapidement.
� La comparaison d'éléments
Le workbench dispose d'un outil pratique pour comparer le contenu de deux éléments.
Pour réaliser cette comparaison, il faut sélectionner ces deux éléments en maintenant la
touche Ctrl enfoncée dans la vue "Navigateur" et sélectionner l'option "Comparer /
Réciproquement" du menu contextuel.
La vue de comparaison de fichier contient une barre d'outils qui permet de naviguer dans
les différences et de les reporter pour effectuer une synchronisation sélective.
3.1.4 Le workspace
Le workspace est l'entité qui permet de conserver les projets et leur contenu.
Physiquement c'est un répertoire du système d'exploitation qui contient une hiérarchie de
fichiers et de répertoires. Il y a d'ailleurs un répertoire pour chaque projet à la racine du
workspace. Le workspace contient tous les éléments développés pour le projet. Les opérations
de gestion permises sont tous réalisées dans la vue Navigateur :
� La création de nouvelles entités : un projet, un répertoire, un fichier,…
� La duplication d'un élément
� Le déplacement d'un élément
� Renommer un élément
� Importation
� Exportation
3.1.5 Le Java Development Tooling (JDT)
Le JDT est inclus dans Eclipse pour fournir des outils de développement en Java. Dans le
workspace, il définit un projet de type particulier pour les projets Java. L'arborescence de ces
projets contient un fichier particulier nommé .classpath qui contient la localisation des
bibliothèques utiles à la compilation et à l'exécution du code. Pour pouvoir développer des
entités en Java, il faut les regrouper dans un projet de type Java.
� Création d'un nouveau projet Java
L’assistant de création demande le type de projet à créer, puis le nom de projet. Et on
peut modifier certains paramètres concernant le chemin de la compilation :
ENSA d’Oujda 17

Etude de serveur d’application JBoss
� La création d'entité
Dans un projet Java, il est possible de créer différentes entités qui entrent dans sa
composition
� les packages
� les classes
� les interfaces
� et Autres
� L'éditeur de code
Le JDT propose un éditeur dédié au fichier contenant du code java. Il propose des
fonctionnalités particulièrement pratiques pour le développement de code Java notamment :
� la coloration syntaxique �
� la complétion de code �
� le formatage du code source
� l'importation et l'exportation de code via un assistant
� Affichage des paramètres sous la forme d'une bulle d'aide
� Utilisation des modèles
� La gestion des importations
� La génération de getter et setter
� Formater le code
� Mise en commentaire d'une portion de code
� Protéger une portion de code avec un bloc try/catch
� Signalisation des erreurs grâce a des indicateurs
� une forte synergie avec le débogueur
3.1.6 Génération de la documentation javadoc
Pour demander la génération de la documentation javadoc, il faut utiliser le menu
"Projet/Générer/Le javadoc" après avoir renseigner les préférences.
� Définition du JRE à utiliser
Eclipse est capable de travailler avec plusieurs JRE. Dans l'arborescence " Java/JRE
installé " des préférences, il est possible de définir plusieurs JRE installés sur la machine.
ENSA d’Oujda 18

Etude de serveur d’application JBoss
� Utilisation du scrapbook
Le scrapbook, traduit par " page de testeur de code ", est une fonctionnalité qui permet de
tester des morceaux de code dans une machine virtuelle.
3.1.7 La perspective "debug"
Pour déboguer du code Java, Eclipse propose une perspective dédiée : la perspective
"débogage". Celle ci est automatiquement affichée lorsqu'une application est lancée sous le
contrôle du débogueur en utilisant le bouton de la barre d'outils. Par défaut, la perspective
débogage affiche quelques vues aussi présentes dans la perspective Java (les vues "Structure"
et "Console") ainsi que l'éditeur de code Java. Et elle affiche aussi plusieurs vues
particulièrement dédiées au débogage. Les vues spécifiques au débogage sont :
� la vue "Débogage" : affiche sous la forme d'une arborescence, les différents processus
en cours d'exécution ou terminés.
� la vue "Variables" : affiche les variables utilisées dans les traitements en cours de
débogage.
� la vue "Points d'arrêts" : affiche la liste des points d'arrêts définis dans l'espace de
travail.
� la vue "Expressions" : permet d'inspecter une expression en fonction du contexte des
données en cours d'exécution.
� la vue "Affichage" : permet d'afficher le résultat de l'évaluation d'une expression.
� Mise en oeuvre du débogueur
La mise en oeuvre du débogueur reste comparable à celle proposé par d'autres IDE : mise
en place d'un point arrêts, exécution plus ou moins rapide dans le débogueur pour arriver à
cibler le problème.
� Mettre en place un point d'arrêt
Pour placer un point d'arrêt, il suffit dans l'éditeur de double cliquer dans la barre de
gauche pour faire apparaître une icône ronde bleue.
� Exécution dans le débogueur
Le plus simple pour lancer le débogage d'une application est de sélectionner l'option
«Déboguer en tant que /Application Java ». L'option "Déboguer ... " permet de fournir des
paramètres précis en vue de l'exécution d'une application sous le débogueur. Un assistant
permet de sélectionner la classe et de préciser les paramètres. Il ne reste plus qu'à mettre en
oeuvre les différentes fonctionnalités proposées par les vues de la perpective pour déboguer le
code.
3.1.8 Le refactoring
ENSA d’Oujda 19

Etude de serveur d’application JBoss
Eclipse intègre de puissantes fonctionnalités pour faciliter le refactoring. Le refactoring
consiste à modifier la structure d'un fichier source et si nécessaire à propager ces
modifications dans les autres fichiers sources pour maintenir autant que possible l'intégrité du
code.
Un menu nommé « Propager les modifications » permet d'utiliser certaines de ces
fonctionnalités : il est présent dans le menu principal et dans de nombreux menus contextuels.
Chacune de ces fonctionnalités est applicable sur un ou plusieurs types d'entité selon le cas :
projets, classes et membres d'une classe. Certaines de ces fonctionnalités possède un raccourci
clavier.
ENSA d’Oujda 20

Etude de serveur d’application JBoss
3.1.9 L'aide dans Eclipse
� L’aide en ligne
L'aide en ligne est disponible dans toute l'interface de l'IDE au moyen de la touche F1.
Cette aide est contextuelle en fonction de l'élément sélectionné dans l'interface au moment de
l'appui sur la touche. Le choix des sujets se rapportant à l'élément courant est affiché dans une
info bulle. Il suffit de cliquer sur l'élément sélectionné pour que l'aide en ligne correspondante
s'affiche.
� L'aide Javadoc
Si la configuration de l'IDE est correcte, il est possible d'accéder directement à la page
javadoc d'un élément java en plaçant le curseur sur cet élément et en appuyant sur F2. Si
l'accès à la documentation javadoc pour l'élément n'est pas configuré un message d'erreur
s'affiche.
� Le plug in Java docs de Crionics
La société Crionics propose un plug in qui s'intègre dans l'aide en ligne de Eclipse et qui
contient la documentation du JDK 1.3 et de quelques API open source. Ce plug in créée une
entrée nommée "Essentials Java Docs" dans la table des matière de l'aide en ligne. Cette
documentation regroupe les API essentielles.
3.2 Le serveur d’application JBOSS :
3.2.1 Les serveurs d’applications :
Le serveur d'application est l'environnement d'exécution des applications côté serveur. Il
prend en charge l'ensemble des fonctionnalités qui permettent à N clients d'utiliser une même
application :
� Le support des plateformes : le serveur d'applications doit implémenter un ensemble
d'API propre à chacun des nombreux systèmes d'exploitation pour d’avantage de
liberté et productivité. A titre d'exemple, lorsqu'une application fait appel à des
fonctions dites système telles que l'ouverture, l'écriture, la lecture ou la suppression de
fichiers, le serveur d'applications doit être en mesure de les exécuter indépendamment
de la plate-forme utilisée.
� Répartition de charges : Un des devoirs du serveur d'applications est d'assurer la
fiabilité et les performances de l'application. Dans ce contexte, la fonctionnalité de
répartition de charges joue un rôle essentiel. D'un point de vue technique, cette
approche se traduit généralement par l'exécution de plusieurs instances qu'il est
possible de répartir sur différentes machines serveur. Cette architecture permet
ENSA d’Oujda 21

Etude de serveur d’application JBoss
également de scinder l'application en modules différents, sans avoir l'obligation de
reproduire sur chacun des serveurs la totalité d'une application. Ainsi, un module
fréquemment sollicité peut être isolé sur un seul serveur afin d'absorber plus
facilement la charge.
� La disponibilité : Dans une configuration où l'application est répliquée sur plusieurs
serveurs physiques, il est plus facile de mettre en place la fonctionnalité de reprise sur
incident. En cas de " plantage " au niveau applicatif ou serveur, la requête utilisateur
est redirigée vers un serveur disponible de manière transparente. La tolérance aux
pannes à ce niveau permet d'offrir la disponibilité au niveau application puisqu'il
existe toujours un module actif pouvant être invoqué par les utilisateurs.
Toutefois, le serveur d'applications doit être également capable de maintenir
l'ensemble des opérations effectuées par l'utilisateur. Pour éviter des désagréments
néfastes, il doit donc prévoir la sauvegarde du contexte utilisateur. Cela implique la
réplication des sessions utilisateur sur une autre machine. A ce niveau, cette
réplication se fait soit en base de données, soit sur disque, soit en mémoire. Les
serveurs d'applications les plus avancés automatisent la gestion de reprise sur incident
au niveau session.
� Le pooling de connexions : En architecture web, l'ensemble des utilisateurs accède à
la base de données depuis le serveur d'applications. Cette connexion peut être
ponctuelle, mais les temps de réponse deviennent alors catastrophiques. La solution la
plus couramment retenue consiste à passer par un pool de connexions. Ceci consiste à
démarrer un nombre prédéfini de connexions vers un SGBDR. Le serveur
d'applications dirige ensuite les demandes utilisateur en répartissant les différentes
requêtes sur les connexions disponibles. Ceci permet d'avoir la maîtrise du nombre de
connexions maximales ouvertes et d'éviter le goulet d'étranglement à ce niveau.
� L’ouverture vers l’existant, le respect des standards : un serveur d’application doit
reconnaître les serveurs http ainsi que la plupart des bases de données relationnelles du
marché. Aussi le serveur d’applications doit respecter les standards tels que Java,
XML et permettre d’intégrer les nouvelles technologies.
� La gestion de contexte : Le principe de gestion de contexte consiste à conserver le
temps d'une session les données propres à l'utilisateur contrairement aux variables
d'application qui ne sont rien d'autre que des variables globales. Toutefois, les
variables de session spécifiques à un utilisateur ne sont envisageables que si
l'utilisateur peut être identifié. Une des fonctionnalités de base du serveur
d'applications est de gérer automatiquement cette identification, suivant une des trois
méthodes : le cookie, l'URL long et la variable cachée. Ceci permet au serveur
d'applications de créer un espace mémoire dédié à chaque utilisateur. C'est à ce
niveau, généralement dans un objet session, que vont être stockées les informations
spécifiques à chacun des utilisateurs. Aussi le serveur doit permettre plus de fonctions
comme le time-out, lancement d’un événement en fin de session, etc.
� La sécurité : un serveur d’application doit permettre de déployer une application
utilisant des services sécurisés avec des ports différents.
ENSA d’Oujda 22

Etude de serveur d’application JBoss
� L’administration : un serveur d’application doit être livré avec un outil
d’administration qui se présente sous la forme d’une interface web ou console. Il doit
favoriser le réglage du serveur d’applications.
3.2.2 JBOSS un serveur d’applications compatible J2EE :
JBOSS est un serveur d'application compatible J2EE. Il a été créé par un ancien ingénieur
français de chez Sun, Marc Fleury. Il est distribué sous licence GPL et s'est spécialisé dans les
technologies EJB (Enterprise Java Beans), une des évolutions de la technologie Java
favorisant la réutilisation des composants.
� JBOSS fournit un certains nombres de modules :
� JBossServer qui comporte une infrastructure constituée des conteneurs EJB, ainsi que
du Java Management Extension (JMX).
� JBossMQ pour la gestion des messages JMS (Java Messaging service)
� JBossTX pour la gestion des transactions avec les API JTA (Java Transaction API ) et
JTS (Java Transaction Service).
� JBossCMP pour la persistance CMP.
� JBossSX pour la sécurité basée sur JAAS (Java Authentication and Authorization
Service).
� JBossCX pour la gestion des connecteurs avec JCA (J2EE Connector Architecture).
Tomcat ou Jetty pour le support des servlets et des pages JSP.
JBOSS permet grâce au JMX de chargé les différents modules, conteneurs ou plugin en
fonction des besoins. Bien entendu, JBOSS permet d'implémenter ses propres services.
3.2.3 Architecture technique de JBOSS :
Cette partie décrit de manière plus détaillée l'architecture du serveur d'application Jboss.
La figure ci-dessous est une vue d'ensemble de l'architecture. Le JMX Implementation, EJB
Container et Remote Management correspondent au composant JbossServer, le JMS au
composant JbossMQ. Le JTS/JTA correspond à JbossTX et les Databases représentent le
stockage des objects avec le composant JbossCMP. La security correspond à la gestion de la
sécurité par JbossSX, les Data sources représentent le composant JbossCX réalisant la gestion
des connecteurs, et enfin les Java Server Pages correspond aux serveurs Tomcat ou Jetty.
ENSA d’Oujda 23

Etude de serveur d’application JBoss
� Le composant JbossServer : Ce composant constitue le coeur du serveur
d'application Jboss. Son rôle est de gérer le noyau grâce au JMX, mais également de
fournir les conteneurs EJB.
Contrairement à la plupart des serveurs d'applications J2EE, JbossServer permet de
déployer et redéployer automatiquement les nouvelles applications sans avoir à
stopper ou arrêter le serveur. Comme vous pourez le voir dans l'installation du serveur
Jboss, un répertoire nommé deploy permet de déployer les nouvelles applications de
manière automatique.
� Le composant JbossMQ : Ce composant est apparu en avril 2000. Il implémente
l'API Java Messaging Service (JMS). Le JMS permet un échange entre des
applications ou des composants via des brokers de messages ou MOM (Middleware
Oriented Messages). Ces échanges peuvent se faire dans un contexte interne (pour
l'EAI) ou un contexte externe (pour le B2B). Le module JBOssMQ supporte plusieurs
sortes de message : RMI (Remote Méthode Invocation)
OIL (Optimized Invocation Layer)
UIL pour les applications clientes qui n'acceptent pas les connexions venant du
Serveur.
� Le composant JbossTX : Ce composant permet le support des moniteurs de
transaction avec les API JTA/JTS. Le JTS définit l'implémentation du manager de
transaction qui supporte l'API de transaction JTA. Malgré que Jboss implémente la
manager de transaction JTS, vous ne pouvez pas accéder directement aux méthodes.
Vous devez utiliser l'API JTA pour invoquer les routines de bas niveau du JTS.
Les services offerts par JbossTX sont:
Fournir aux applications la capacité de contrôler le périmètre et la durée d'une
Transaction, supporter les transactions synchronisées, etc...
� Le composant JBossCMP : Ce module permet de gérer les connexions aux bases de
données grâce au connecteur JDBC. La version actuelle de JBOssCMP permet de se
connecter à 17 bases de données (Oracle, SQLServer, DB2, Sybase, PointBase,
Cloupscape, HypersonicsSQL, PostgreSQL, mySQL, etc ...)
ENSA d’Oujda 24

Etude de serveur d’application JBoss
� Le composant JbossSX : Ce composant a pour rôle de gérer la sécurité grâce à l'API
JAAS. JbossSX fournit une implémentation de la sécurité standard à J2EE. Il permet
notamment l'authentification des utilisateurs grâce au module JAAS Login.
� Le composant JbossCX : JbossCX permet de gérer les connecteurs aux systèmes
d'informations de l'entreprise comme CICS, TUXEDO, SAP, Siebel, etc...
� Le composant Web Servers : Le serveur web est géré à l'aide de deux produits
existants Tomcat et Jetty.
3.2.4 Installation du serveur JBOSS :
Pour installer JBOSS, il faut d’abord télécharger JBOSS depuis le site officiel
www.jboss.org . Comme il existe deux versions du serveur, une avec le serveur web Jetty et
l’autre avec Tomcat, on a choisit d’utiliser la dernière.
Pour installer JBOSS, il suffit de décompresser le fichier zippé à l’endroit voulu. Une fois
décompressé, on a l’arborescence suivante :
La structure des répertoires :
ENSA d’Oujda 25

Etude de serveur d’application JBoss
Répertoire Description
Bin Comporte tous les scripts permettant le démarrage, l'arrêt de Jboss,
notamment le script run.bat pour Windows et run.sh pour linux
Client Comporte tous les fichiers JAR pour le client.
Lib Ce répertoire contient toutes les librairies utilisées pour le
fonctionnement du serveur JBOSS.
Server Ce répertoire comporte tous les fichiers de configuration de Jboss.
Les sous répertoire default, all, minimal représentent les différents
types de configuration.
Server/default/deploy Ce répertoire comporte tous les jars devant être déployé. Si vous
ajoutez un jar dans ce répertoire, celui-ci sera automatiquement
chargé par Jboss.
3.2.5 Quelques caractéristiques de JBOSS :
� Permet le déploiement et le redéploiement des applications sans redémarrer le serveur.
� Intègre une base de données par défaut Hypersonic pour gérer la persistance niveau
conteneur.
� Spécialisé sur la technologies des EJB, mais il implémente les autres fonctions J2EE
comme les servlets ou les JSP via le moteurs de servlets libre Tomcat d’Apache ou
Jetty.
� Gratuit et sous licence GPL.
� Son développement est très actif. Il est soutenu par une communauté de 500
développeurs dans le monde, dont un noyau dur de 50 personnes et il est financé par la
vente de documentations et de services autour de ce produit.
� Offre des caractéristiques avancées telles que l’administration via une console JMX.
� Environnement d’exécution complet et 3 configurations de serveurs prédéfinies.
� JBOSS AS 4.0 est la première application Open Source à obtenir la certification J2EE
de Sun microsystems (23000 tests).
� JBOSS AS 4.0 permet l’approche de l’AOP ou programmation Java orientée aspect.
Cette approche de la programmation associe la complexité de J2EE à la simplicité du
langage Java en apportant des éléments contraints J2EE, mais standardisés.
� JBOSS AS 4.0 implémente les EJB 3.0.
� Une excellente diffusion : c’est le quatrième projet le plus actif sur Sourceforge sur
plus de 70000. Il a déjà été téléchargé plus de 3.500.000 de fois depuis début 2002,
dont 1.500.000 les 6 derniers mois.
� Accès à un très nombre de sources de données (Oracle, SQL Server, MySQL,…).
ENSA d’Oujda 26

Etude de serveur d’application JBoss
3.3 L’outil Ant :
Ant est un projet du groupe Apache−Jakarta. Son but est de fournir un outil écrit en Java
pour permettre la construction d'applications (compilation, exécution de tâches post et pré
compilation ...). Ces processus de construction d'applications sont très importants car ils
permettent d'automatiser des opérations répétitives tout au long du cycle de développement de
l’application (développement, tests, recettes, mises en production ... ). Le site officiel de l'outil
est http://jakarta.apache.org/ant/index.html.
Ant repose sur un fichier de configuration XML qui décrit les différentes tâches qui
devront être exécutées par l'outil. Il fournit un certains nombre de tâches courantes qui sont
codées sous forme d'objets développés en Java. Ces tâches sont donc indépendantes du
système sur lequel elles seront exécutées. De plus, il est possible d'ajouter ces propres tâches
en écrivant de nouveaux objets Java respectant certaines spécifications.
Le fichier de configuration contient un ensemble de cibles (Target). Chaque cible
contient une ou plusieurs tâches et peut avoir une dépendance envers une ou plusieurs autres
cibles pour pouvoir être exécutée.
Ant possède donc plusieurs atouts : multi plate−forme, configurable grâce à un fichier
XML, open source et extensible. Ainsi des plug−ins ont été développés pour la majorité des
IDE (JBuilder, Forte, Visual Age ...) pour leur permettre d'utiliser Ant, devenu un standard de
fait.
3.3.1 Installation de Ant
Avant de commencer l’installation, un jdk1.1 ou supérieur est requis. Ensuite, il faut
suivre les étapes suivantes :
ENSA d’Oujda 27

Etude de serveur d’application JBoss
� dézipper le fichier.
� ajouter le chemin complet au répertoire bin de Ant à la variable système PATH
� s'assurer que la variable JAVA_HOME pointe sur le répertoire contenant le
JDK.
� créer une variable d’environnement ANT_HOME qui pointe sur le répertoire
crée lors de la décompression.
� Il peut être nécessaire d’ajouter les fichiers .jar contenu dans le répertoire lib
de Ant a la variable d’environnement CLASSPATH.
3.3.2 Exécution de Ant
Ant s'utilise en ligne de commande avec la syntaxe suivante : ant [options] [cible], par
défaut, Ant recherche un fichier nommé build.xml dans le répertoire courant. Ant va alors
exécuter la cible par défaut définie dans le projet de ce fichier build.xml.
Pour exécuter un autre fichier de configuration, il faut spécifier le nom dans la commande
après l’option –buildfile :
ant –buildfile file.xml
Et pour exécuter une cible particulière, il suffit de spécifier le nom. Par exemple pour
exécuter la cible clean : ant clean
3.3.3 Le fichier build.xml
Le fichier build est un fichier XML qui contient la description du processus de
construction de l'application.
L'élément principal de l'arborescence du document est le projet représenté par le tag
qui est donc le tag racine du document.
� Le projet
A l’intérieur du tag sont définis les autres éléments du fichier, à savoir les
cibles, les propriétés et les tâches. Il possède les attributs :
� name : cet attribut précise le nom du projet
� default : cet attribut précise la cible par défaut à exécuter si aucune cible n'est précisée
lors de l'exécution
� basedir : cet attribut précise le répertoire qui servira de référence pour la localisation
relative des autres répertoires.
� Les propriétés :
Le tag permet de définir une propriété qui pourra être utilisée dans le projet :
c'est souvent la définition d'un répertoire ou d'une variable qui sera utilisée par certaines
tâches. Leur définition en tant que propriété permet de facilement changer leur valeur une
seule fois même si la valeur de la propriété est utilisée plusieurs fois dans le projet.
ENSA d’Oujda 28

Etude de serveur d’application JBoss
Les propriétés peuvent être définies sur la ligne de commande avec l’option –D suivie du
nom de la propriété, suivi du =, suivi de sa valeur.
Le tag possède plusieurs attributs :
� name : cet attribut défini le nom de la propriété.
� value : cet attribut défini la valeur de la propriété.
� location : cet attribut permet de définir un fichier avec son chemin absolu. Il
peut être utilisé à la place de l'attribut value.
� file : cet attribut permet de préciser le nom d'un fichier qui contient la définition
d'un ensemble de propriétés. Ce fichier sera lu et les propriétés qu'il contient
seront définies.
L'ordre de définition d'une propriété est très important : Ant gère une priorité sur l'ordre
de définition d'une propriété. La règle est la suivante : la première définition d'une propriété
est prise en compte, les suivantes sont ignorées.
Pour utiliser une propriété définie dans le fichier, il faut utiliser la syntaxe suivante :
${nom_propriete}
� les ensembles de fichiers :
Le tag permet de définir un ensemble de fichiers. Cet ensemble de fichier sera
utilisé dans une autre tâche. La définition d'un tel ensemble est réalisé grâce à des attributs du
tag :
L'expression **/ permet de désigner tous les sous répertoires du répertoire défini dans
l'attribut dir.
Exemple :
On peut utilisé le tag pour définir un ensemble de motifs pour sélectionner
des fichiers. L’ensemble est identifié par un attribut id, les fichiers a inclure sont définies dans
, et ceux a exclure dans . Le refid peut être utilisé pour référencer un
ensemble déjà défini.
Exemple :
ENSA d’Oujda 29

Etude de serveur d’application JBoss
Pour définir un ensemble de fichier fini, on utilise le tag . Les attributs sont
l’identifiant id, le dir pour indiquer le répertoire de départ, le files pour indiquer les fichiers
séparés par un virgule, et éventuellement le refid pour référencer un ensemble déjà défini.
Exemple :
� Les éléments de chemins :
Le tag permet de définir un élément qui sera ajouter à la variable
classpath. La définition d'un tel élément est réaliser grâce à des attributs du tag
: location et path.
Exemple :
� Les cibles :
Le tag définit une cible. Une cible est un ensemble de tâches à réaliser dans un
ordre précis. Cet ordre correspond à celui des tâches décrites dans la cible.
Les attributs :
name contient le nom de la cible. Cet attribut est obligatoire
description
if
unless
depends
contient une brève description de la cible
permet de conditionner l'exécution par l'existence d'une propriété
permet de conditionner l'exécution par l'inexistence de la définition d'une propriété
permet de définir la liste des cibles dont dépend la cible
L’attribut depends défini un ensemble de cible a exécuté avant l’exécution de la cible
courante.
� Les tâches :
Une tâche est une unité de traitements contenue dans une classe Java qui implémente
l'interface org.apache.ant.Task. Dans le fichier de configuration, une tâche est un tag qui peut
avoir des paramètres pour configurer le traitement à réaliser. Une tâche est obligatoirement
incluse dans une cible.
ENSA d’Oujda 30

Etude de serveur d’application JBoss
Ant fournit en standard un certain nombre de tâches pour des traitements courants lors du
développement en Java dont les plus importantes sont :
� Echo :
La tâche permet d'écrire dans un fichier ou d'afficher un message ou des
informations durant l'exécution des traitements.
Les données à utiliser peuvent être fournies dans un attribut dédié ou dans le corps du tag
.
Exemple :
Fin des traitements du projet ${ant.project.name}
Fin des traitements
� Mkdir :
La tâche permet de créer un répertoire avec éventuellement ces répertoires pères
ci ceux ci n'existent pas. Elle possède un seul attribut dir pour donner le chemin et le nom du
répertoire.
Exemple :
� Delete :
La tâche permet de supprimer des fichiers ou des répertoires. Il a pour attributs :
ENSA d’Oujda 31

Etude de serveur d’application JBoss
� Copy
La tâche permet de copier un ou plusieurs fichiers dans le cas ou ils n'existent pas
dans la cible ou si ils sont plus récents dans la cible. Ses attributs sont :
� Tstamp :
La tâche n’a pas d’attribut et permet de définir trois propriétés :
Exemple :
DSTAMP : cette propriété est initialisée avec la date du jour au format AAAMMJJ
TSTAMP : cette propriété est initialisée avec l'heure actuelle sous la forme HHMM
TODAY : cette propriété est initialisée avec la date du jour au format long
� Java :
La tâche permet de lancer une machine virtuelle pour exécuter une application
compilée.
ENSA d’Oujda 32

Etude de serveur d’application JBoss
Le tag fils permet de fournir des paramètres à l'exécution. Et permet
de définir le classpath à utiliser lors de l'exécution.
Exemple :
� Javac :
La tâche permet la compilation de fichiers source contenus dans une
arborescence de répertoires.
ENSA d’Oujda 33

Etude de serveur d’application JBoss
� Javadoc :
La tâche permet de demander la génération de la documentation au format
javadoc des classes incluses dans une arborescence de répertoires.
Cette tâche possède plusieurs attributs dont les principaux sont :
Exemple :
ENSA d’Oujda 34

Etude de serveur d’application JBoss
� Jar :
La tâche permet la création d'une archive de type jar.
Exemple :
� Autres :
Ant utilises d’autres tâches pour divers traitements : exécution d’une requête sql, envois
d’un courrier électronique, zipper ou de zipper un fichier, etc. un guide complet du différentes
tâches est fourni dans la documentation de Ant.
3.4 L’outil XDoclet :
XDoclet est un moteur de génération de code. C'est un projet open-source hébergé sur le
site sourceforge.net, sous licence BSD.
Le but de ce projet est d’améliorer la productivité des développeurs en leur évitant de
taper du code redondant et d’avoir à s’occuper des mises à jour des documents liés à un
projet. Ainsi, tout le travail fastidieux de création de fichiers xml de déploiement ou de
paramétrage et la génération de code source commun (interfaces pour les EJB par exemple…)
est supprimé.
Les développeurs n'auront alors plus qu'à se concentrer sur l'édition d'un seul fichier
source Java par composant. Cela s’appelle l’intégration continue. XDoclet permet de générer
du texte (et donc du code) en ajoutant aux fichiers sources codés des balises de type Javadoc
spécifiques. Les principaux bénéfices de l'intégration continue :
� Mise à jour automatique des fichiers de déploiement (meta-data) à chaque fois que le
code est modifié. Le déploiement de ces meta-data est continuellement intégré.
� Travailler avec un seul fichier par composant permet d'avoir une vue plus globale de
l’application en cours de développement. Si le composant est constitué de plusieurs
fichiers, comme les Entreprise Java Bean (EJB), il est facile de s'y perdre. En effet, un
ENSA d’Oujda 35

Etude de serveur d’application JBoss
seul EJB est traditionnellement constitué de 7 fichiers voire plus. Avec XDoclet, il
suffit de maintenir un seul d'entre-eux et le reste sera généré.
� Réduction du temps de développement, et le développeur pourra ainsi se concentrer
sur d'autres aspects puisque XDoclet va générer 85% du code.
Une balise spécifique XDoclet se présente sous la forme :
/**
* @namespace:tag_name name="value" name2="value2" ...
**/
Chaque balise XDoclet est identifiée par un nom (tag_name) qui appartient à un espace de
noms (namespace). Les propriétés sont passées par le format name="value". Il est possible
d'associer plusieurs propriétés à un élément en cumulant les couples name="value".
4 Etude de cas réalisé :
4.1 Description :
L’étude de cas réalisé récapitule l’ensemble des connaissances acquises sur les EJB et les
Servlets. Ainsi, l’application doit permettre de calculer la moyenne de 3 notes d’un étudiant et
de les enregistrer dans la base de données. La saisie du code, nom et les 3 notes de l’étudiant
se fait via un formulaire Html qui va rediriger la requête vers une servlet. Celle-ci va traiter la
requête Post et récupérer les valeurs du formulaire. Il va faire appel à un bean Session qui va
calculer la moyenne des 3 notes et créer un bean Entity CMP qui se chargera d’enregistrer le
code, le nom et la moyenne dans la base de données Hypersonic disponible par défaut avec le
serveur d’application Jboss.
4.2 Architecture de l’application :
Notre application suit cette architecture car elle se compose d’une servlet, deux EJB
(Session et Entity).
ENSA d’Oujda 36

Etude de serveur d’application JBoss
4.3 Préparatifs : JBOSS IDE
Jboss IDE est un plug-in pour Eclipse qui permet de contrôler Jboss directement depuis
Eclipse : démarrage, arrêt et fenêtre console de Jboss intégré à l'éditeur. Il permet également,
à l’aide d’assistant, de créer des composants EJB, Servlets et des pages JSP ainsi que des
projets J2EE de façon automatisé, ceci afin d’éviter au programmeur d’écrire le squelette de
ces composants. La dernière version (1.3.3) est disponible sur le site de SourceForge.
Pour l’installer, il faut fermer tout d’abord Eclipse si celui-ci est ouvert, ensuite
décompresser le contenu de l’archive téléchargée dans le répertoire de l’installation d’Eclipse.
Une fois ceci effectué il faut relancer Eclipse et aller vous dans le menu Help > Software
Update > Manage Configuration. Cliquer ensuite sur le bouton « Show disabled features ».
Il faut ensuite faire un clic droit sur JBoss-IDE 1.3.30 et choisir Enable dans le menu.
Confirmer le redémarrage d’Eclipse pour que le changement soit pris en compte. Une fois le
plug-in installé il faut maintenant afficher les nouvelles fonctionnalités offertes par celui-ci.
Pour cela, il faut aller dans le menu Windows > Custom perspective, la fenêtre suivante
s’affiche :
ENSA d’Oujda 37

Etude de serveur d’application JBoss
Dans le menu déroulant il faut choisir New et cocher ensuite la case JBoss-IDE. Cela a
pour effet d’afficher les nouveaux assistants quand vous utiliserez le menu File > New.
Toujours dans le même menu déroulant choisir maintenant Show View et cocher encore
JBoss-IDE. Cela a pour effet d’afficher les deux nouvelles vues disponibles dans le menu
Window > Show View. La nouvelle vue Server Navigator est particulièrement utile pour
démarrer ou arrêter le serveur JBoss à partir d’Eclipse.
ENSA d’Oujda 38

Etude de serveur d’application JBoss
Avant de pouvoir rajouter le serveur JBoss à la vue Server Navigator il faut effectuer une
modification dans le menu Window > Preferences:
ENSA d’Oujda 39

Etude de serveur d’application JBoss
Le serveur JBoss a besoin d'utiliser la machine virtuelle incluse avec le JDK. Pour cela
allez dans le menu Java puis Installed JREs, cliquez sur Add. Dans la fenêtre suivante,
cliquer sur Browse pour le champ JRE home directory puis indiquer le répertoire
d’installation de JDK. Pour rajouter le serveur JBoss ouvrer la vue Server Navigator (Window
> Show Wiew) et Choisir la version du serveur JBoss dans la liste (4.0 ici) et cliquer sur New
pour créer une nouvelle configuration de lancement. Renseignez ensuite le chemin d’accès au
répertoire Jboss, valider la nouvelle configuration en cliquant sur Apply et fermer la fenêtre.
Pour démarrer ou arrêter le serveur JBoss un simple clic droit sur la nouvelle
configuration donne accès au menu permettant ces actions.
ENSA d’Oujda 40

Etude de serveur d’application JBoss
4.4 Création du projet :
Après avoir lancé Eclipse, on crée un nouveau projet par « File/New/Project... ». On
choisit »JBoss-IDE/J2EE1.4 Project », puis on clique sur « Next ». Appelons donc le projet «
Projet», puis cliquons sur « Next ».
Dans la fenêtre suivante, il faut définir les répertoires des fichiers sources et binaires,
ainsi que les fichiers jar nécessaires à l'application j2ee.
Nous commençons par créer un répertoire source, que nous appellerons « src », en
cliquant sur « Add folder... », et en saisissant « src ».Il faut définir ensuite le répertoire des
binaires en saisissant « Tutorial/bin » dans « Default output folder ».
Ensuite, nous allons dans l'onglet « Libraries ». Plusieurs bibliothèques ont déjà été
importées automatiquement. Nous allons rajouter les jars spécifiques à Jboss. Pour ce faire,
nous cliquons sur « Add external jars », et nous ajoutons « javax.servlet.jar » (dans
jboss4.0.0/server/default/lib) et « jboss-j2ee.jar » (dans jboss4.0.0/client).
ENSA d’Oujda 41

Etude de serveur d’application JBoss
Nous pouvons maintenant cliquer sur « Finish ». Le projet est créé.
4.4.1 Création de L’EJB Session :
Nous allons tout d'abord créer notre EJB Session stateless, CalculBean, dont la méthode
Moyenne calcule la moyenne des 3 notes.
Création de l’EJB Session :
On clique sur « File/New/Other », puis on choisit « JBoss-IDE/EJB Components/Session
Bean », et on clique sur « Next ». On peut ensuite renseigner notre EJB : on indique le
package : « projet/ejb » ; puis on indique que l'EJB est « stateless », avec interfaces « remote
», et que l'on ajoute la méthode «ejbCreate », puis on clique sur « Finish ».
Il ne reste plus qu'à coder la méthode « Moyenne ». Afin de générer automatiquement les
tags Xdoclet, on passe par les menus : Dans la fenêtre « Outline », on fait un clic droit sur «
CalculBean », et dans « J2EE », on choisit « Add Business Method », que l'on complète
après.
ENSA d’Oujda 42

Etude de serveur d’application JBoss
ENSA d’Oujda 43

Etude de serveur d’application JBoss
On code ensuite notre méthode Moyenne et on rajoute les commentaires Xdoclet. Au
final notre EJB a l’allure suivante :
/*
* Created on 15 janv. 2005
*
* TODO To change the template for this generated file go to
* Window - Preferences - Java - Code Style - Code Templates
*/
package projet.ejb;
import java.rmi.RemoteException;
import javax.ejb.EJBException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
import javax.ejb.CreateException;
//import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
//import javax.rmi.PortableRemoteObject;
import projet.interfaces.EtudiantLocal;
import projet.interfaces.EtudiantLocalHome;
/**
ENSA d’Oujda 44

Etude de serveur d’application JBoss
* @ejb.bean name="Calcul"
* display-name="Name for Calcul"
* description="Description for Calcul"
* jndi-name="ejb/Calcul"
* type="Stateless"
* view-type="remote"
* @ejb.ejb-local-ref name="Save"
* type="Entity"
* local-home="projet.interfaces.EtudiantLocalHome"
* local="projet.interfaces.EtudiantLocal"
* @jboss.ejb-local-ref ref-name = "Save"
* jndi-name = "EtudiantLocalH"
*/
public class CalculBean implements SessionBean {
/**
*
*/
public CalculBean() {
super();
// TODO Auto-generated constructor stub
}
/* (non-Javadoc)
* @see javax.ejb.SessionBean#setSessionContext(javax.ejb.SessionContext)
*/
public void setSessionContext(SessionContext ctx)
throws EJBException,
RemoteException {
// TODO Auto-generated method stub
}
/* (non-Javadoc)
* @see javax.ejb.SessionBean#ejbRemove()
*/
public void ejbRemove() throws EJBException, RemoteException {
// TODO Auto-generated method stub
}
/* (non-Javadoc)
* @see javax.ejb.SessionBean#ejbActivate()
*/
public void ejbActivate() throws EJBException, RemoteException {
// TODO Auto-generated method stub
}
/* (non-Javadoc)
* @see javax.ejb.SessionBean#ejbPassivate()
*/
public void ejbPassivate() throws EJBException, RemoteException {
// TODO Auto-generated method stub
}
/**
* Default create method
ENSA d’Oujda 45

Etude de serveur d’application JBoss
*
* @throws CreateException
* @ejb.create-method
*/
public void ejbCreate() throws CreateException {
// TODO Auto-generated method stub
}
/**
* Business method
* @ejb.interface-method view-type = "remote"
*/
public double Moyenne(double note1, double note2, double note3) {
// TODO Auto-generated method stub
return (note1 + note2 + note3) / 3;
}
public void enregistrer(String code, String nom, double moyen) {
try {
javax.naming.Context jndiContext = new InitialContext();
EtudiantLocalHome home = (EtudiantLocalHome) jndiContext
.lookup("java:comp/env/EtudiantLocalH");
EtudiantLocal instance = home.create(code);
instance.setName(nom);
instance.setMoyenne(moyen);
} catch (NamingException ne) {
// throw new EJBException(ne);
} catch (CreateException ne) {
}
}
}
Génération de fichiers complémentaires pour l’EJB ( Home et l’interface Remote) :
Pour générer ces fichiers complémentaires (les interfaces de l’EJB ainsi que les
descripteurs de déploiement), il faut configurer XDoclet.
Pour cela, il faut ouvrir la configuration en faisant un clic droit sur le projet « Projet », et
en choisissant « Properties ». Ensuite, on se rend dans la rubrique « Xdoclets Configurations
». On fait un clic droit dans la fenêtre en haut à droite, on choisit « Add Standard », et on
choisit « Standard EJB ».
Cela met à jour la plupart des champs nécessaires. On peut cliquer sur le « Standard EJB
» créé, et se promener dans les fenêtres du bas pour s'en rendre compte. La seule modification
consiste à se rendre dans « fileset » et à modifier « includes » (remplacer « **/*.java » par
« **/*Bean.java »).
ENSA d’Oujda 46

Etude de serveur d’application JBoss
On clique ensuite sur « OK ». On peut ensuite lancé la construction de l'EJB en faisant un
clic droit sur le projet Projet, et en cliquant sur « Run Xdoclet ». Après le refresh, Le fichier «
xdoclet-build.xml » est généré. Cette action génère aussi les méta-informations de l'EJB, ainsi
que les classes d'interface (home/remote).
4.4.2 Création de l’EJB Entity :
Enfin, il faut implémenter le dernier élément composant ce projet : l’EJB Entity. Le rôle
de ce dernier est la gestion de la persistance des données. Il existe deux types, mais ici le
CMP qui sera utilisé. L’avantage de ce composant est qu’il permet de gérer rapidement
l’accès à une base de données sans avoir à écrire la moindre ligne de code utilisant JDBC.
Cet exemple s’appuie sur la base de données par défaut fournis avec JBOSS qui est
Hypersonic.
Pour créer cet EJB sous Eclipse, il faut utiliser l’assistant, on clique sur « File/New/Other
», puis on choisi « JBoss-IDE/EJB Components/Entity Bean », et on clique sur « Next ».
On peut ensuite renseigner notre EJB : on indique le package : « projet/ejb » ; puis on
indique Un nom : EtudiantBean, puis on clique sur « Finish ».
ENSA d’Oujda 47

Etude de serveur d’application JBoss
Le bean crée sera donc à la norme CMP 2.x et accessible uniquement en local ce qui
suffit amplement puisque celui-ci sera utilisé par le bean Session.
Il faut ensuite spécifier la méthode ejbCreate.
ENSA d’Oujda 48

Etude de serveur d’application JBoss
Ajout de tags spécifiques à la classe :
Nous devons maintenant rajouter un certain nombre de tags XDoclet qui vont permettre
de définir la base de données et la table sur laquelle le bean devra opérer. Cela évite donc
d’avoir à ajouter manuellement ces informations aux descripteurs de déploiement. Voici la
liste de tous les tags rajoutés avant la déclaration de la classe accompagnés d’une description :
* primkey-field = "Id"
* @ejb.persistence
* table-name = "etudiant"
Son rôle est de définir le nom de la table sur laquelle le bean devra effectuer les
différentes opérations d’ajout, modifications, etc. … ainsi que la clé primaire utilisée.
ENSA d’Oujda 49

Etude de serveur d’application JBoss
Ajout des tags spécifiques aux méthodes :
Maintenant que nous avons rajouté les différents tags au niveau de la classe, nous
pouvons rajouter les différentes variables et méthodes nécessaires au fonctionnement de notre
bean entité.
Le bean entité représentant un enregistrement d’une table de notre base de données, il
doit donc contenir autant de champ que la table en question. Elle se compose des champs
suivants :
� Id : type varchar, clé primaire
� Nom : type varchar,
� Moyenne : type float
Pour chacun des champs, il faut créer deux méthodes : une pour faire le get et l’autre pour
faire le set et de spécifier le nom de la colonne et son type grâce aux tags XDoclet.
/**
If faut rajouter quelques éléments accompagnés de quelques tags.
* Getter for CMP Field Id
*
* @ejb.pk-field
* @ejb.persistent-field
* @ejb.interface-method view-type="local"
* @ejb.persistence column-name = "Id"
* sql-type = "VARCHAR"
*/
public abstract String getId();
/**
* Setter for CMP Field Id
*
* @ejb.interface-method view-type="local"
*/
public abstract void setId(String value);
ENSA d’Oujda 50

Etude de serveur d’application JBoss
/**
* Getter for CMP Field Name
*
*
* @ejb.persistent-field
* @ejb.interface-method view-type="local"
* @ejb.persistence column-name = "Nom"
* sql-type = "VARCHAR"
*/
public abstract String getName();
/**
* Setter for CMP Field Name
*
* @ejb.interface-method view-type="local"
*/
public abstract void setName(String value);
/**
* Getter for CMP Field Moyenne
*
*
* @ejb.persistent-field
* @ejb.interface-method view-type="local"
* @ejb.persistence column-name = "Moyenne"
* sql-type = "FLOAT"
*/
public abstract double getMoyenne();
/**
* Setter for CMP Field Moyenne
ENSA d’Oujda 51

Etude de serveur d’application JBoss
*
* @ejb.interface-method view-type="local"
*/
public abstract void setMoyenne(double value);
Implémentation :
Enfin de pouvoir créer et utiliser ce bean nous devons implémenter une méthode
ejbCreate, elle doit comporter en argument le champ correspondant à la clé primaire de la
table. Pour notre cas elle doit donc avoir une chaîne de caractère.
/**
* Create method
* @ejb.create-method view-type = "local"
*/
public String ejbCreate(String code) throws javax.ejb.CreateException {
}
// TODO Auto-generated method stub
return null;
this.setId(code);
4.4.3 Création de la Servlet :
Pour la création du Servlet, il faut commencer par cliquer sur « File/New/Others », puis
choisir « Web Components/HTTP Servlet ». Dans la fenêtre de dialogue, placer la servlet
dans le package « projet.web », on appelle le servlet « CalculServlet », et on implémente les
méthodes init(), doGet() et doPost().
Nous allons ensuite coder deux méthodes : la méthode init, dans laquelle nous allons lier
le servlet à l'EJB, par le biais du contexte, et la méthode reponse, méthode privée qui crée la
page de réponse et appelée par doPost et doGet. On n'oubliera pas de créer les entrées
Xdoclets pour les références au titre de la page et à l'EJB ainsi que le mapping jboss de l'EJB
(on enlèvera également le paramétrage de l'init).
ENSA d’Oujda 52

Etude de serveur d’application JBoss
Le code de la Servlet est le suivant :
/*
* Created on 15 janv. 2005
*
* TODO To change the template for this generated file go to
* Window - Preferences - Java - Code Style - Code Templates
*/
package projet.web;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import javax.servlet.http.HttpServlet;
ENSA d’Oujda 53

Etude de serveur d’application JBoss
import javax.servlet.ServletException;
import javax.servlet.ServletConfig;
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import projet.interfaces.Calcul;
import projet.interfaces.CalculHome;
/**
* Servlet Class
*
* @web.servlet name="Calcul"
* display-name="Name for Calcul"
* description="Description for Calcul"
* @web.servlet-mapping url-pattern="/Calcul"
* @web.servlet-init-param name="A parameter"
* value="A value"
* @web.ejb-ref name = "Calcul"
* type = "Session"
* home = "projet.interfaces.CalculHome"
* remote = "projet.interfaces.Calcul"
* description = "ref de calcul"
* @jboss.ejb-ref-jndi ref-name = "Calcul"
* jndi-name = "ejb/Calcul"
*
*/
public class CalculServlet extends HttpServlet {
private CalculHome home;
/**
*
*/
public CalculServlet() {
super();
// TODO Auto-generated constructor stub
}
public void init(ServletConfig config) throws ServletException {
//super.init(config);
// TODO Auto-generated method stub
try {
Context ctx=new InitialContext();
Object ref=ctx.lookup("ejb/Calcul");
home=(CalculHome)PortableRemoteObject.narrow(ref,CalculHome.class);
}catch(Exception e) {
throw new ServletException("lookup of java:/comp/env/Calcul failed");
}
}
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException,
IOException {
// TODO Auto-generated method stub
super.doGet(req, resp);
}
ENSA d’Oujda 54

Etude de serveur d’application JBoss
protected void doPost(
HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
// TODO Auto-generated method stub
reponse(request,response);
}
private void reponse(HttpServletRequest req, HttpServletResponse resp)throws ServletException,
IOException{
resp.setContentType("text/html");
PrintWriter out=resp.getWriter();
out.println("");
out.println("la moyenne");
out.println("");
out.println("");
try{
Calcul bean=home.create();
double limit1=0;
double limit2=0;
double limit3=0;
String code=req.getParameter("code");
String nom=req.getParameter("name");
String note1=req.getParameter("note1");
String note2=req.getParameter("note2");
String note3=req.getParameter("note3");
try{
limit1=Double.parseDouble(note1);
limit2=Double.parseDouble(note2);
limit3=Double.parseDouble(note3);
}catch (Exception e) {
}
double result=bean.Moyenne(limit1,limit2,limit3);
bean.enregistrer(code,nom,result);
out.println("enregistrement");
// bean.remove();
out.println("");
out.println("l'etudiant "+nom+" est enregistré ");
out.println("La moyenne des notes est :");
out.println("" +result);
out.println("");
}catch(Exception e){
e.printStackTrace(out);
}finally{
out.println("");
out.println("");
}
}}
Il nous reste à générer les fichiers relatifs au servlet. On commence par rouvrir les
propriétés du projet, et on retourne dans la configuration de Xdoclet. On ajoute un « Standard
Web », et on modifie :
« webdoclet/destDir » (remplacer « src » par « src/WEB-INF »).
« fileset/includes » (remplacer « **/*.java » par « **/*Servlet.java »).
« jbosswebxml/Version » (4.0)
ENSA d’Oujda 55

Etude de serveur d’application JBoss
On ferme ensuite en cliquant sur « ok », et on relance le « Run XDoclet » dans le menu
contextuel du projet (puis on fait un refresh quand le run est terminé).
On crée ensuite un répertoire pour mettre la page html qui invoque le servlet. On crée
donc un répertoire « docroot » dans le projet (clic droit+ »New/Folder »). On crée à
L’intérieur un fichier « index.html » (par «New/Other » + « Web Components/HTML Page»).
Ce fichier ressemble au contenu suivant :
calcul
Formulaire etudiant
code:
name :
note1:
note2:
ENSA d’Oujda 56

Etude de serveur d’application JBoss
note3:
4.4.4 Création de l’application Web:
Nous allons assembler tous nos éléments dans une application j2ee. Pour ce faire nous
allons créer un fichier « application.xml » dans « src/META-INF » (à partir de « New/File »).
Ce fichier liste les modules (ejb et web) qui composent l'application, et indique le point
d'accès au module web.
Sum Application
CalculEJB.jar
CalculWeb.war
/calcul
On indique ensuite les paramètres de paquetage de l'application et de ses modules. Pour
se faire on ouvre la fenêtre des propriétés du projet, et on va dans « Packaging configurations
». On doit créer quatre rubriques : une pour l'application, une pour le module ejb , une pour le
module web, plus une pour les clients de l'ejb (en l'occurence, le servlet).
Pour l'ejb, on fait un clic droit dans la fenêtre en haut à droite, et on sélectionne « Add
Archive ». On appelle cette archive « CalculEJB.jar », et on clique sur OK. On ajoute ensuite
les rubriques suivantes:
ENSA d’Oujda 57

Etude de serveur d’application JBoss
� Liste des ejb : on précise que l'on utilise les classes des packages ejb et interfaces.
Pour ce faire, clic droit sur « CalculEJB.jar », « Add Folder ». On indique comme
folder « /Projet/bin », puis on indique dans « Includes » : «
projet/ejb/*.class,projet/interfaces/*.class ».
� Fichiers de configuration: Clic droit sur « CalculEJB.jar », « Add File ». On ajoute
deux rubriques, une pour « /Projet/src/META-INF/ejb-jar.xml », une pour «
/Projet/src/METAINF/jboss.xml », en précisant dans les deux cas le préfixe « META-
INF » (c à d qu'ils seront placés dans ce sous répertoire dans le .jar généré).
On crée ensuite l'entrée pour les clients : Clic droit dans la fenêtre + « Add Archive » : on
l'appelle calcul-client.jar. Il suffit de placer à l'intérieur les interfaces de l'EJB : Clic droit+ «
AddFolder ». On indique comme folder « /Projet/bin », puis on indique dans « Includes » : «
projet/interfaces/*.class ».
On crée le module web : Clic droit dans la fenêtre + « Add Archive » (on l'appelle
CalculWeb.war).
� On y place le servlet : clic droit + « Add Folder » + Folder = «Projet/bin » et Includes
=« projet/web/*.class ».
� On ajoute les fichiers de configuration (Projet/src/WEB-INF/jboss-web.xml et
Projet/src/WEB-INF/web.xml) avec « Add File ». Sans oublier de préciser le prefix :
ENSA d’Oujda 58

Etude de serveur d’application JBoss
« WEBINF».
On ajoute enfin le module client, afin que le servlet le voie. On fait donc clic droit+ «
Add File » et on choisit le fichier « Projet/calcul-client.jar » (qui n'existe pas encore car c'est
l’exécution du paquetage qui le créera...). Comme il n'existe pas, on clique sur « Project File »
et on saisit à la main le nom du fichier... Le préfix doit être « WEB-INF/lib »
� Pour avoir accès à index.html on ajoute le répertoire « docroot ».
Reste à créer la configuration de l'application. Dans la fenêtre, on fait un clic droit+ «
Add Archive ». On l'appelle « CalculApp.ear ». On y ajoute le fichier « /Projet/src/META-
INF/application.xml », avec le prefix « META-INF ». On ajoute ensuite les fichiers «
/Projet/CalculEJB.jar » et « /Projet/CalculWeb.war ». Comme ils n'existent pas encore, on
procède comme précédemment.
On peut ensuite cliquer sur ok, puis dans le menu contextuel du projet, lancer « Run
Packaging ». On fait un « refresh » pour voir tous les fichiers générés.
Ainsi l’architecture finale de l’application est la suivante :
4.4.5 Déploiement et exécution :
ENSA d’Oujda 59

Etude de serveur d’application JBoss
Pour tester l'application, on lance JBOSS, puis on déploie l'application en faisant un clic
droit sur « CalculApp.ear » + « Deployment/Deploy to », et choisir « default ».
Pour tester l'application, on lance un navigateur et on va à l'URL : «
http://localhost:8080/calcul »...
ENSA d’Oujda 60

Etude de serveur d’application JBoss
Les données comme l’id, le nom et la moyenne de l’étudiant sont bien enregistré dans la
table etudiant de la base de données.
ENSA d’Oujda 61

Etude de serveur d’application JBoss
5 Conclusion :
L’utilisation d’un serveur d’application open source comme Jboss permet d’avoir plus de
contrôle sur l’environnement utilisé car l’un des avantages majeurs des outils open source est
de pouvoir modifier le code source et l’adapter à des besoins spécifiques de l’entreprise. En
plus, et pour la plupart des outils open source dont Jboss, la correction des bogues est assurée
par une large communauté, ce qui permet d’accélérer le processus de mise à jour des outils
open source.
Ce projet nous a permet sur le plan formation, d’aborder un sujet de grande envergeure
qui est celui des serveurs d’applications et d’étudier la technologie J2EE. Ainsi, on a utilisé
les composants côte serveur, qui sont les EJB ainsi que les servlets et les JSP pour le
développement web. En parallèle, on a eu l’occasion de découvrir des outils Open Source
comme Ant et XDoclet permettant de simplifier la tâche des développeurs tout en profitant
des possibilités offertes par un environnement de développent intégré qui est Eclipse.
6 Bibliographie :
Le site officiel de Jboss : www.jboss.org
Le site officiel d’Eclipse : www.eclipse.org
Livre : Entreprise JavaBeans édition O’Reilly de Richard Monson-Haefel
ENSA d’Oujda 62