B- Un exemple simple d`application en JSF - vs

Introduction
J’ai débuté mon stage chez Alloa le 15 mars 2004. Celui-ci allai constituer ma
première expérience dans la réalisation d’un site Internet commercial. Au cours de ce stage
j’ai dû appréhender le développement J2EE et découvert de nombreux outils et spécifications.
Une grande partie du temps à donc était consacré à de la recherche de documentation sur tout
ce qui concerne le développement J2EE et JSF (JavaServer Faces) dernière spécification en
date de Sun pour la réalisation de pages Web. Ce rapport a donc pour but, en plus de présenter
le travail réalisé, de donner une vision globale des outils et concepts intervenants dans la
création d’une application J2EE.
Dans ce rapport je présenterai dans un premier temps l’agence Alloa et le projet auquel
j’ai participé en exposant le rôle des intervenants et les choix technologiques qui ont été fait.
Je consacrerai ensuite une partie à la présentation de JSF et utiliserai un exemple simple
d’application faite en JSF pour illustrer mes propos. Dans la troisième partie je présenterai le
travail réalisé en soulignant les principes et les points importants de notre développement.
Enfin j’établirai un bilan de ce projet en faisant le point sur les éléments réalisés et sur le
travail restant.

I- Présentation de l’entreprise et du projet
A- Alloa et la structure informatique en place
-L’agence Alloa :
Alloa est une agence de Voyages située 72 rue Léon Gambetta à Lille. Elle est dirigée
par Michel Dewintre, créateur de l'entreprise en 1982 et qui y travaille avec son épouse. C’est
une agence polyvalente, proposant des séjours, des circuits, des vols, son point fort étant
d’être à l’écoute du client afin de proposer des solutions « à la carte ». Alloa est encore peu
présente sur Internet mais elle s’est forgée une solide réputation en tant qu’agence de voyage
classique. D’un point de vue technique Alloa se distingue par sa volonté d'être présente sur
chaque nouvelle technologie. Cela s'est traduit par un développement sur minitel et
aujourd'hui par sa présence sur internet. Le souhait d’utiliser les dernières technologies et
d’exploiter au maximum les outils issus du monde libre est également très prononcé.
-Les outils informatiques au cœur d’Alloa :
Pour gérer l'ensemble de ses informations, Alloa dispose principalement de deux outils:
- Une application créée par Michel Dewintre sur OMNIS 7 permettant de gérer la
quasi-totalité des données de l'entreprise y compris les séjours et les circuits. OMNIS 7 est un
environnement intégré de développement qui intègre les outils nécessaires au stockage des
données et à leur manipulation. Il est ainsi possible de créer des formulaires de gestion des
données mais également ses propres règles de gestion via un langage de programmation L4G.
-Du moteur de réservation GALILEO et de son application FOCALPOINT. Grâce
au logiciel Focalpoint, l'agent de voyages peut consulter le Système de Réservation Central
(CRS) de Galileo. Il dispose ainsi d'un accès en ligne aux tarifs actualisés et connaît
immédiatement la disponibilité des 503 compagnies aériennes, des 51.000 hôtels et des 34
sociétés de location de voitures. Il peut aussi faire des réservations de manière totalement
automatisée.
Les postes réservés au développement informatique sont des PC sous linux et plus
précisément une distribution Gentoo. Alloa possède deux DNS, un serveur Internet et un
serveur de base de données.
B- Le projet
-L’existant
Le précédent site Internet était développé sous PHP et était associé à une base de
données MySql. C'était un site WEB assez abouti mais relativement peu fiable aux dires de
Michel. Des problèmes de plantage avec la base de données étaient notamment observés. Sous
l’impulsion de Mikaël, étudiant en maîtrise informatique à Nantes et travaillant en parallèle
pour Alloa depuis 3 ans, Michel a décidé de miser sur le langage JAVA.

Le projet de refonte en Java et plus précisément en JSP a été initié durant l’été 2003
par Benjamin, qui effectuait alors son stage comptant pour sa 3ème année de formation à
l’école des Mines de Douai. Le site n’était plus aussi fonctionnel que celui en PHP mais
Michel à tout de même décidé de basculer vers cette architecture. Il ne s’agissait pas d’une
structure distribuée, il n’y avait pas d’EJB etc. (voir les explications présente dans ce rapport)
-Les objectifs et le rôle des intervenants
Au cours de l’entretien que j’ai eu avec Michel en vue d’effectuer mon stage au sein
de l’agence Alloa, l’objectif premier qui avait été énoncé était de compléter l’application
existante et d’étudier par la suite les améliorations possibles. Mais en début de stage il a été
convenu de remettre en cause les technologies utilisées et la structure de l’application web
comprenant la partie publique (site Internet) mais aussi la partie englobant les modules
destinés à un usage interne (Intranet).Il a ainsi été décidé de refondre l’application en utilisant
J2EE.
J2EE (pour Java 2 Enterprise Edition) est un ensemble d'APIs dédiées au
développement d'applications d'entreprise. Java 2 Standard Edition (la version "standard" de
Java) contient par exemple l’API JDBC (pour Java DataBase Connectivity) ou encore RMI
(pour Remote Methods Invocation). Le SDK J2EE fournit en plus l’API des EJBs (pour
Enterprise Java Beans). Je définirai le terme EJB dans ce rapport.
On entend généralement par "applications d'entreprise" des applications distribuées,
qui interagissent par l'intermédiaire d'un réseau. Avec la croissance exponentielle de l'usage
des réseaux en entreprise, ces applications sont amenées à se développer et J2EE est la
réponse de Sun à ce besoin. L'étendue des APIs J2EE de Sun permet de couvrir l'ensemble
des besoins en la matière.
Avec l’arrivée fin mars de Jérôme, étudiant en DESS informatique à Calais et ayant
déjà des connaissances en programmation J2EE, nous avons pu avec Michel faire un point sur
les éléments à prendre en compte, sur les outils à utiliser ainsi que le type de structure à
adopter. Il fallait que l’architecture englobe les aspects Intranet et Internet. Le schéma de la
figure I-1 montre le type de structure standard utilisée dans le développement d’applications
J2EE dites 3 tiers.
Figure I-1 : Structure classique 3 tiers d’une application distribuée

Je n’avais jamais programmé en utilisant la technologie J2EE et j’ai dû m’initier aux
notions de JavaBean, d’EJB ou bien encore RMI et JNDI, notions que je présenterai dans les
grands traits par la suite où dont une définition est présente dans le glossaire.
Michel souhaitait aussi utiliser JBoss un serveur d’application et conteneur d’EJB et
surtout il voulait tester JSF (JavaServer Faces) la dernière spécification de Sun pour la
conception de pages Web. Il insista donc pour utiliser les derniers standards et outils existants
pour la réalisation d’applications web même si ceci, on le verra, a engendré un niveau de
productivité moindre.
Nous étions donc début avril quatre personnes à travailler sur le projet dirigé par
Michel Dewintre. Mikaël avait en quelque sorte le rôle de chef de projet tout en suivant ses
études à Nantes, Sonia étudiante en licence informatique et statistique en alternance travaillait
sur les données (établissement des tables), quant à Jérôme et moi nous étions chargés du
développement. Baptiste n’est arrivé sur le projet que début juin afin de travailler sur l’aspect
graphique et du JavaScript.
C -Les choix technologiques
Les choix suivants ont été faits :
-Outil de développement et de déploiement : Eclipse et MyEclipse
-Le serveur web et moteur de servlets: Apache/Tomcat
-Le serveur d’application : Jboss 4
-Le langage des pages Web : JSF
-Base de données : postgreSQL (gestion avec le logiciel pgadmin III)
-Pour la manipulation des données : Hibernate.
Je décrirai le plus brièvement possible les principales notions qu’il m’a fallu
appréhender comme les EJB et les principaux outils adoptés pour ce projet. Ce dernier
s’annonçait donc comme un pari audacieux du fait, d’un point de vue personnel, de la
découverte des outils et du développement J2EE et, d’un point de vue technologique, par le
choix de JSF dont La spécification 1.0 finale date du 3 mars 2004.
Le travail est enregistré via un système CVS dont Eclipse fait fortement usage. CVS
pour Concurrent Versions Systems est un outil permettant de garder une trace des versions
précédentes des fichiers sources d'un projet de développement. L'intérêt est de faciliter la
recherche de bogues issus d'une modification malencontreuse du code, en identifiant
précisément quel changement en est la cause.
CVS est particulièrement adapté pour les projets collectifs, où chaque développeur
peut travailler indépendamment dans son propre répertoire. L'ensemble des changements
effectués fait l'objet d'une prise en compte collective par "fusion". On évite ainsi que les
modifications d'un des développeurs n'entrent en concurrence avec celles, simultanées, d'un
autre. CVS est utilisé par de nombreux projets opensource comme par exemple Mozilla, The
GIMP, KDE ou Gnome.
Je vais maintenant aborder dans la partie qui vient les notions de JavaBean et
d’Entreprise JavaBean (EJB) puis je présenterai le logiciel Eclipse mais également le serveur
JBoss Enfin je présenterai Hibernate.

-Les notions de JavaBean et d’Entreprise JavaBean
Pour expliquer ce qu'est un EJB, je vais me baser sur ce que je connaissais avant ce
stage, à savoir une classe Java. Une classe contient des attributs ou encore propriétés. Lorsque
l’on décide d'empêcher l'accès direct à ses propriétés, mais de réguler cet accès en imposant
aux autres objets l'usage de méthodes appelées “accesseurs ”, la classe est dite “encapsulée”
et répond alors à peu prés à la définition d'un Java Bean.
Un Enterprise JavaBean est un JavaBean qui peut s'exécuter sur une autre machine, ou
tout au moins dans une autre machine virtuelle Java. Il est installé dans un environnement
d'exécution particulier appelé conteneur d'EJB qui, en échange du respect de certaines règles
de coopération, lui fournira de nombreux services : accès à des bases de données, gestion des
transactions et des ressources, services de messagerie et bien d'autres encore.
L'exécution à distance est presque transparente pour l'utilisateur de l'EJB mais pour
développer un EJB, il faut écrire la classe proprement dite, qui s'exécutera dans le conteneur,
et l'interface distante ou remote interface, qui spécifie les méthodes que l'on va appeler à
distance.
Le problème qui se pose est celui de la création d’une instance d'EJB ? On ne peut pas
utiliser new(), qui ne fonctionne pas à distance. C'est donc le conteneur qui va se charger de
créer et détruire sur demande les instances d'EJB. Pour le diriger dans cette tâche, il faut donc
aussi spécifier une interface de gestion du cycle de vie, dite interface home, qui contient au
moins une méthode create() chargée de créer une instance et une méthode remove() pour la
supprimer.
-Les différentes sortes d'EJB
On distingue plusieurs sortes d'EJB. Ceux qui constituent des services, par exemple
d'information ou de communication, et ne sont jamais associés à un utilisateur en particulier.
Ils sont dits EJB sans état de session, en anglais: session stateless.
D'autres EJB sont directement liés à un utilisateur pour le temps de sa connexion au
système; l'exemple le plus courant est celui du panier dans une application de commerce
électronique. Ceux-là sont appelés EJB avec état de session (session stateful).
Il existe également une dernière sorte d’EJB qui eux représentent les objets persistants
de l'application, par exemple les clients et les produits; ces objets doivent persister dans le
système d'une session à une autre, et en raison de leurs caractéristiques on les appelle les EJB
entités ou entity beans.
Je ne rentrerai pas plus en détail car je viens d’exposer les principales caractéristiques
des EJB et ce que j’ai le mieux assimilé. De plus je pense que cela suffira à la compréhension
du travail réalisé que je présenterai dans la partie III de ce rapport.
Je vais maintenant présenter les outils qu’ils m’a été donné d’étudier et d’utiliser au
cours de ce stage comme Eclipse, JBoss ou bien encore Hibernate.