Java EE

Java Entreprise Edition

Chapitre 1 :
Introduction au Java EE

- Qu'est-ce que Java EE ?

- Internet n'est pas le web !
- Comment ça marche
- Les langages du web
Java EE n'est pas Java

• Le terme « Java » fait bien évidemment référence à

un langage, mais également à une plate-forme : son
nom complet est « Java SE » pour Java Standard
Edition, et était anciennement raccourci « J2SE ».
Celle-ci est constituée de nombreuses bibliothèques,
ou API : citons par exemple [Link], [Link],
[Link], [Link], etc. Bref, toutes ces bibliothèques
que vous devez déjà connaître et qui contiennent un
nombre conséquent de classes et de méthodes prêtes
à l'emploi pour effectuer toutes sortes de tâches.
Java EE n'est pas JavaScript

• S'il est vrai que Java EE permet la création

d'applications web, il ne faut pas pour autant le
confondre avec le langage JavaScript, souvent
raccourci en « JS », qui est lui aussi massivement
utilisé dans les applications web. Ce sont là deux
langages totalement différents, qui n'ont comme
ressemblance que leur nom !
Qu'est-ce que Java EE ?
• Le terme « Java EE » signifie Java Enterprise Edition, et était
anciennement raccourci en « J2EE ».
• Il fait quant à lui référence à une extension de la plate-forme
standard. Autrement dit, la plate-forme Java EE est construite
sur le langage Java et la plate-forme Java SE, et elle y ajoute
un grand nombre de bibliothèques remplissant tout un tas de
fonctionnalités que la plate-forme standard ne remplit pas
d'origine.
• L'objectif majeur de Java EE est de faciliter le développement
d'applications web robustes et distribuées, déployées et
exécutées sur un serveur d'applications.
Internet n'est pas le web !

• l'internet est le réseau, le support physique de

l'information. Pour faire simple, c'est un
ensemble de machines, de câbles et
d'éléments réseau en tout genre éparpillés sur
la surface du globe ;
• le web constitue une partie seulement du
contenu accessible sur l'internet. Vous
connaissez et utilisez d'autres contenus,
comme le courrier électronique ou encore la
messagerie instantanée.
Qu'est-ce qu’un site web?
• Un site web est un ensemble constitué de pages web (elles-mêmes
faites de fichiers HTML, CSS, JavaScript, etc.). Lorsqu'on développe
puis publie un site web, on met en réalité en ligne du contenu sur
internet. On distingue deux types de sites :
– les sites internet statiques : ce sont des sites dont le contenu
est « fixe », il n'est modifiable que par le propriétaire du site. Ils
sont réalisés à l'aide des technologies HTML, CSS et JavaScript
uniquement.
– les sites internet dynamiques : ce sont des sites dont le contenu
est « dynamique », parce que le propriétaire n'est plus le seul à
pouvoir le faire changer ! En plus des langages précédemment
cités, ils font intervenir d'autres technologies : Java EE est l'une
d'entre elles !
Comment ça marche 1/6

Lorsqu'un utilisateur consulte un site, ce qui se

passe derrière les rideaux est un simple échange
entre un client et un serveur.
• le client : dans la plupart des cas, c'est le
navigateur installé sur votre ordinateur. Retenez
que ce n'est pas le seul moyen d'accéder au web.
• le serveur : c'est la machine sur laquelle le site
est hébergé, où les fichiers sont stockés et les
pages web générées.
Comment ça marche 2/6
• La communication qui s'effectue entre le client et le
serveur est régie par des règles bien définies : le
protocole HTTP.
1. l'utilisateur saisit une URL (pour Uniform Resource
Identifier, soit identifiant uniforme de ressource) dans la
barre d'adresses de son navigateur ;
2. le navigateur envoie alors une requête HTTP au
serveur pour lui demander la page correspondante ;
3. le serveur reçoit cette requête, l'interprète et génère
alors une page web qu'il va renvoyer au client par le
biais d'une réponse HTTP ;
4. le navigateur reçoit, via cette réponse, la page web
finale, qu'il affiche alors à l'utilisateur.
Comment ça marche 3/6

Echange dynamique client <-> serveur

Comment ça marche 4/6

Ce qu'il faut comprendre et retenir de tout ça :

– les données sont échangées entre le client et le
serveur via le protocole HTTP ;
– le client ne comprend que les langages de
présentation de l'information, en d'autres termes
les technologies HTML, CSS et JavaScript ;
– les pages sont générées sur le serveur de manière
dynamique, à partir du code source du site.
Comment ça marche 5/6

Echange dynamique HTTP client <-> serveur

Comment ça marche 6/6
Seulement, à la différence du couple HTML &
CSS qui est un standard incontournable pour
la mise en forme des pages web, il existe
plusieurs technologies capables de traiter les
informations sur le serveur. Java EE est l'une
d'entre elles, mais il en existe d'autres :
PHP, .NET, Django…
Les langages du web
• Les langages utilisés pour mettre en forme les données et les
afficher à l'utilisateur sont le HTML, le CSS et éventuellement le
JavaScript. Ceux-ci ont une caractéristique commune importante :
ils sont tous interprétés par le navigateur, directement sur la
machine client. D'ailleurs, le client est uniquement capable de
comprendre ces quelques langages, rien de plus !
• Le serveur dispose de technologies bien à lui, que lui seul est
capable de comprendre : une batterie complète ayant pour objectif
final de générer les pages web à envoyer au client, avec tous les
traitements que cela peut impliquer au passage :
 analyse des données reçues via HTTP,
 transformation des données,
 enregistrement des données dans une base de données ou des
fichiers,
 intégration des données dans le design…
Comment choisir la technologie la mieux
adaptée à notre projet ?
 rapidité de développement;
 faible utilisation des ressources sur le serveur;
 réactivité de la communauté soutenant la
technologie;
 ampleur de la documentation disponible en
ligne;
 Coût,… etc.
Résumé de chapitre
• Java EE est une extension de la plate-forme standard Java SE,
principalement destinée au développement d'applications web.
• Internet désigne le réseau physique ; le web désigne le contenu
accessible à travers ce réseau.
• Pour interagir avec un site web (le serveur), l'utilisateur (le client)
passe par son navigateur.
• À travers le protocole HTTP, le navigateur envoie des requêtes au
serveur et le serveur lui renvoie des réponses :
– le travail du serveur est de recevoir des requêtes, de générer les
pages web et de les envoyer au client.
– le travail du navigateur est de transmettre les actions de
l'utilisateur au serveur, et d'afficher les informations qu'il
renvoie.
Chapitre 2 :
Le Java EE mis à nu !

-Principes de fonctionnement
- Le modèle MVC : en théorie
- Le modèle MVC : en pratique
Le Java EE mis à nu !
• Le Java Enterprise Edition, comme son nom
l'indique, a été créé pour le développement
d'applications d'entreprises.
• JEE peut faciliter le travail en équipe sur un même
projet : l'application est découpée en couches, et le
serveur sur lequel tourne l'application est lui-même
découpé en plusieurs niveaux. Pour faire simple,
Java EE fournit un ensemble d’extensions au Java
standard afin de faciliter la création d’applications
centralisées.
Principes de fonctionnement
• Nous venons de découvrir qu'afin de pouvoir communiquer
entre eux, le client et le serveur doivent se parler via HTTP.
côté client, le navigateur s'en occupe.
Côté serveur, qui s'en charge ?
C'est un composant que l'on nomme logiquement serveur
HTTP. Son travail est simple : il doit écouter tout ce qui arrive
sur le port utilisé par le protocole HTTP, le port 80, et scruter
chaque requête entrante. C'est tout ce qu'il fait, c'est en
somme une interface de communication avec le protocole.
• À titre informatif, voici les deux plus connus : Apache HTTP
Server et IIS (Microsoft).
Principes de fonctionnement
• Cependant, nous n'allons directement utiliser ni l'un ni l'autre.
Pourquoi ?
• Être capable de discuter via HTTP c'est bien, mais notre serveur doit
permettre d'effectuer d'autres tâches. En effet, une fois la requête
HTTP lue et analysée, il faut encore traiter son contenu et
éventuellement renvoyer une réponse au client en conséquence.
Vous devez probablement déjà savoir que cette responsabilité vous
incombe en grande partie : c'est le code que vous allez écrire qui va
décider ce qu'il faut faire lorsque telle requête arrive !
• un serveur HTTP de base ne peut pas gérer votre application, ce
n'est pas son travail
• Remarque : cette affirmation est en partie fausse, dans le sens où la
plupart des serveurs HTTP sont devenus des serveurs web à part
entière, incluant des plugins qui les rendent capables de supporter
des langages de script comme le PHP, l'ASP, etc.
le serveur d'applications

• le serveur d'applications : c'est qu'un tel

serveur inclut un serveur HTTP, et y ajoute la
gestion d'objets de diverses natures au travers
d'un composant que nous allons pour le
moment nommer le conteneur.
Principes de fonctionnement

Architecture de serveur
le serveur d'applications va :
1. récupérer les requêtes HTTP issues des clients ;
2. les mettre dans des boîtes, des objets, que votre code sera capable de
manipuler ;
3. faire passer ces objets dans la moulinette qu'est votre application, via le
conteneur ;
4. renvoyer des réponses HTTP aux clients, en se basant sur les objets retournés
par votre code.

il en existe plusieurs sur le marché, que l'on peut découper en deux

secteurs :
– les solutions propriétaires et payantes : WebLogic et WebSphere,
respectivement issues de chez Oracle et IBM, sont les références dans le
domaine. Massivement utilisées dans les banques et la finance notamment,
elles sont à la fois robustes, finement paramétrables et très coûteuses.
– les solutions libres et gratuites : Apache Tomcat, JBoss, GlassFish et Jonas
en sont les principaux représentants.
Comment faire un choix parmi toutes ces solutions ?

• Hormis les problématiques de coûts qui sont

évidentes, d'autres paramètres peuvent influencer
notre décision ; citons par exemple la rapidité de
chargement et d’exécution, ainsi que la quantité de
technologies supportées.
• Remarque : nous partons de zéro : ainsi, un serveur d'applications
basique, léger et gratuit fera très bien l'affaire. Ça tombe bien, il
en existe justement un qui répond parfaitement à tous nos besoins
: Apache Tomcat.
Qu'est-ce qu'un modèle de conception ?
En anglais design pattern, un modèle de conception
(ou encore patron de conception) est une simple
bonne pratique, qui répond à un problème de
conception d'une application. C'est en quelque sorte
une ligne de conduite qui permet de décrire les
grandes lignes d'une solution. De tels modèles sont
issus de l'expérience des concepteurs et développeurs
d'applications : c'est en effet uniquement après une
certaine période d'utilisation que peuvent être mises
en évidence des pratiques plus efficaces que d'autres,
pratiques qui sont alors structurées en modèles et
considérées comme standard.
Que recommandent les développeurs Java EE
expérimentés ?
Le développement en entreprise implique entre autres :
1. que l'on puisse être amené à travailler à plusieurs contributeurs
sur un même projet ou une même application (travail en équipe) ;
2. que l'on puisse être amené à maintenir et corriger une application
que l'on n'a pas créée soi-même ;
3. que l'on puisse être amené à faire évoluer une application que l'on
n'a pas créée soi-même.
Pour toutes ces raisons, il est nécessaire d'adopter une
architecture plus ou moins standard, que tout développeur
peut reconnaître, c'est-à-dire dans laquelle tout développeur
sait se repérer.
Le modèle MVC
le modèle MVC (Modèle-Vue-Contrôleur) : découpe
littéralement l'application en couches distinctes, et de ce fait
impacte très fortement l'organisation du code ! Voici dans les
grandes lignes ce qu'impose MVC :
1. tout ce qui concerne le traitement, le stockage et la mise à
jour des données de l'application doit être contenu dans la
couche nommée "Modèle" (le M de MVC) ;
2. tout ce qui concerne l'interaction avec l'utilisateur et la
présentation des données (mise en forme, affichage) doit
être contenu dans la couche nommée "Vue" (le V de MVC) ;
3. tout ce qui concerne le contrôle des actions de l'utilisateur
et des données doit être contenu dans la couche nommée
"Contrôle" (le C de MVC).
Le modèle MVC

MVC
Qu'est-ce qu'un Framework ?

• Framework est un ensemble de composants qui servent à

créer l'architecture et les grandes lignes d'une application,
donc c’est une boîte à outils géante, conçue par un ou
plusieurs développeurs et mise à disposition d'autres
développeurs, afin de faciliter leur travail. Il existe des
Framework dans beaucoup de langages et plate-forme, ce
n'est pas un concept propre à Java EE ni au développement
web en particulier.
• En ce qui concerne Java EE, nous pouvons par exemple citer
JSF, Spring, Struts ou encore Hibernate. Toutes ces solutions
sont des Framework que les développeurs sont libres d'utiliser
ou non dans leurs projets.
La couche Modèle du modèle MVC avec
Java EE
Modèle : des traitements et des données
• Dans le modèle, on trouve à la fois les données et les
traitements à appliquer à ces données. Ce bloc
contient donc des objets Java d'une part, qui
peuvent contenir des attributs (données) et des
méthodes (traitements) qui leur sont propres, et un
système capable de stocker des données d'autre
part. Rien de bien transcendant ici, la complexité du
code dépendra bien évidemment de la complexité
des traitements à effectuer par votre application.
La couche Vue du modèle MVC avec Java EE

Vue : des pages JSP

• Une page JSP est destinée à la vue. Elle est
exécutée côté serveur et permet l'écriture de
gabarits (pages en langage "client" comme
HTML, CSS, JavaScript, XML, etc.). Elle permet
au concepteur de la page d'appeler de manière
transparente des portions de code Java, via des
balises et expressions ressemblant fortement
aux balises de présentation HTML.
La couche contrôleur du modèle MVC
avec Java EE
Contrôleur : des servlets
• Une servlet est un objet qui permet d'intercepter les
requêtes faites par un client, et qui peut personnaliser
une réponse en conséquence. Il fournit pour cela des
méthodes permettant de scruter les requêtes HTTP.
Cet objet n'agit jamais directement sur les données, il
faut le voir comme un simple aiguilleur : il intercepte
une requête issue d'un client, appelle éventuellement
des traitements effectués par le modèle, et ordonne
en retour à la vue d'afficher le résultat au client.
Le modèle MVC avec Java EE

MVC avec Java EE

 Résumé de chapitre 2
• Un serveur d'applications est constitué d'un serveur HTTP et d'un conteneur
web.
• Le modèle de conception MVC impose une répartition stricte des tâches au
sein d'une application :
1. la couche Modèle se charge des traitements à effectuer sur les données
et de leur stockage ;
2. la couche Vue se charge de la présentation des données pour l'utilisateur
et de l'interaction ;
3. la couche Contrôle se charge d'aiguiller les requêtes entrantes vers les
traitements et vues correspondants.
• Un Framework est une boîte à outils mise à disposition du développeur pour
lui alléger certaines tâches.
• Dans une application Java EE sans Framework :
1. la couche Modèle est constituée d'objets Java ;
2. la couche Vue est constituée de pages JSP ;
3. la couche Contrôle est constituée de servlets.
Chapitre 3 :
Outils et environnement de
développement

- L'IDE Eclipse
- Le serveur Tomcat
- Structure d'une application Java EE
L'IDE Eclipse
l'IDE Eclipse se caractérise par :
– Massivement utilisé en entreprise;
– c'est un outil puissant;
– gratuit, libre et multiplateforme…
Les avantages d'un IDE dans le développement d'applications web Java EE
sont multiples, et sans toutefois être exhaustif en voici une liste :
– intégration des outils nécessaires au développement et au
déploiement d'une application ;
– paramétrage aisé et centralisé des composants d'une application ;
– multiples moyens de visualisation de l'architecture d'une application ;
– génération automatique de portions de code ;
– assistance à la volée lors de l'écriture du code ;
– outils de débogage…
L'IDE Eclipse (Intégration d’Eclipse for Java
Developers )
• Pour ceux d'entre vous qui ont déjà sur leur poste une version "Eclipse for
Java developers" et qui ne souhaitent pas télécharger et installer la version
pour Java EE, sachez qu'il est possible - mais bien moins agréable - d'y
ajouter des plugins afin d'y reproduire l'intégration de l'environnement
Java EE. Si vous y tenez, voici les étapes à suivre depuis votre fenêtre
Eclipse :
– Allez dans Help > Install New Software.
– Choisissez le site "Indigo -
[Link]
– Déroulez "Web, XML, and Java EE Development".
– Cochez alors "JST Server Adapters" et "JST Server Adapters
Extentions".
L'IDE Eclipse (Configuration de
l’environnement)
• Modification de l'encodage par défaut
• Si vous ouvrez Eclipse pour la première fois, commencez par
fermer l'onglet de bienvenue qui s'affiche.
• Rendez-vous alors dans la barre de menus supérieure, et
cliquez sur Window, puis Preferences.
• Dans la fenêtre qui s'affiche alors, il y a un champ vous
permettant de taper du texte en haut à gauche. Saisissez-y le
mot "encoding", et dans chaque section qui apparaît alors
dans le volet de gauche, changez l'encodage par défaut (il est
généralement réglé à Cp1252 ou ISO-8859-1) par la valeur
UTF-8, comme indiqué à la figure suivante.
L'IDE Eclipse (Modification de l'encodage par défaut)
L'IDE Eclipse (Modification de l'encodage par défaut)
L'IDE Eclipse (Modification de l'encodage par défaut)
L'IDE Eclipse (Modification de l'encodage par défaut)
L'IDE Eclipse
• Désactivation de la vérification de l'orthographe
• Rendez-vous à nouveau dans le menu
(Window > Preferences), puis dans le volet de
gauche rendez-vous dans (General > Editors >
Text Editors), et dans le volet de droite cochez la
case "Show line numbers". Dans le volet de
gauche, cliquez alors sur le sous-menu Spelling,
et dans le nouveau volet de droite qui apparaît,
décochez la case "Enable spell checking ».
L'IDE Eclipse (Désactivation de la vérification de
l'orthographe)
L'IDE Eclipse (Désactivation de la vérification de
l'orthographe)
Le serveur Tomcat

• Nous l'avons découvert dans le second chapitre :

pour faire fonctionner une application web Java EE,
nous avons besoin de mettre en place un serveur
d'applications. Il en existe beaucoup sur le
marché : on va choisir d'utiliser Tomcat, car c'est
un serveur léger, gratuit, libre, multiplateforme et
assez complet pour ce que nous allons aborder. On
le rencontre d'ailleurs très souvent dans des
projets en entreprise, en phase de développement
comme en production.
Le serveur Tomcat

Répertoire d'installation de Tomcat

Le serveur Tomcat
• Dans ce répertoire d'installation de Tomcat, vous trouverez un
dossier nommé webapps : c'est ici que seront stockées par défaut
vos applications. Pour ceux d'entre vous qui souhaiteraient jeter
un œil à ce qui se passe derrière les rideaux, vous trouverez dans
le dossier conf les fichiers suivants :
– [Link] : contient les éléments de configuration du serveur ;
– [Link] : contient les directives communes à toutes les applications
web déployées sur le serveur ;
– [Link] : contient entre autres l'identifiant et le mot de passe
permettant d'accéder à l'interface d'administration de votre serveur
Tomcat ;
– [Link] : contient les paramètres de configuration communs à toutes les
applications web déployées sur le serveur.
 Création du projet web avec Eclipse

• Depuis Eclipse, suivez le chemin

suivant :
File > New > Project...
Ceci peut d'ailleurs être raccourci en
tapant au clavier Ctrl + N.
Création du projet web avec Eclipse

Nouveau projet web sous Eclipse

 Création du projet web avec Eclipse

• Sélectionnez alors Dynamic Web Project

comme le montre l'image ci-dessus, puis
cliquez sur Next >. Donner un nom à ton
projet. Remarquez ensuite à la figure suivante
le passage concernant le serveur.
Création du projet web avec Eclipse

Mise en place de Tomcat - Étape 1

 Création du projet web avec Eclipse

• Cliquez sur le bouton New Runtime... et

sélectionnez alors Apache Tomcat 7.0 dans la
liste des possibilités, comme indiqué à la
figure suivante.
Création du projet web avec Eclipse

Mise en place de Tomcat - Étape 2

 Création du projet web avec Eclipse

• Cochez la case comme indiqué ci-dessus, ce

qui signifie que nous allons en plus du projet
créer localement une nouvelle instance d'un
serveur, instance que nous utiliserons par la
suite pour déployer notre application. Cliquez
ensuite sur Next > et remplissez correctement
les informations relatives à votre installation
de Tomcat en allant chercher le répertoire
d'installation de Tomcat sur votre poste
Création du projet web avec Eclipse

Mise en place de Tomcat - Étape 3

 Création du projet web avec Eclipse

• Validez alors en cliquant sur Finish, puis

cliquez deux fois sur Next >, jusqu'à obtenir
cette fenêtre
Création du projet web avec Eclipse
Création du projet web avec Eclipse
 Création du projet web avec Eclipse

• Vous noterez l'apparition d'une entrée Tomcat

v7.0 dans l'onglet Servers, et de
l'arborescence de votre projet test dans le
volet de gauche.
Faites maintenant un clic droit sur le titre de
votre projet dans l'arborescence Eclipse, et
suivez Run As > Run on Server, comme indiqué
à la figure suivante.
Création du projet web avec Eclipse
 Création du projet web avec Eclipse

• Dans la fenêtre qui s'ouvre alors, nous allons

sélectionner le serveur Tomcat que nous
venons de mettre en place lors de la création
de notre projet web, et préciser que l'on
souhaite associer par défaut notre projet à ce
serveur.
Création du projet web avec Eclipse
 Création du projet web avec Eclipse

• Cliquez alors sur Next >, puis vérifiez que votre

nouveau projet est bien pris en compte par
votre serveur.
Création du projet web avec Eclipse
 Création du projet web avec Eclipse

• Validez enfin en cliquant sur Finish, et voilà la

mise en place de votre projet et de son serveur
terminée !
• Pour la petite histoire, une section est ajoutée
dans le fichier [Link] de votre instance de
Tomcat, qui est maintenant accessible depuis
le dossier Servers de votre arborescence
Eclipse, comme vous pouvez le voir sur la
figure suivante.
Création du projet web avec Eclipse

Mise en place de Tomcat - Étape 9

 Création du projet web avec Eclipse
<Context docBase="test" path="/test" reloadable="true"
source="[Link]:test"/>

Dorénavant, pour piloter votre serveur Tomcat il vous suffira de

vous rendre dans l'onglet Servers en bas de votre fenêtre Eclipse,
et d'utiliser un des boutons selon le besoin (redémarrage, arrêt,
debug), comme indiqué à la figure suivante.

Mise en place de Tomcat - Étape 10

 Création du projet web avec Eclipse

• Sachez pour finir, que cette manipulation n'est pas

limitée à Tomcat. Vous pouvez utiliser d'autres
types de serveurs, cela ne pose pas de problèmes.
De même, une fois que vous avez correctement
paramétré un serveur Tomcat depuis Eclipse, vous
n'êtes pas forcés de recréer localement un nouveau
serveur pour chacun de vos projets, vous pouvez
très bien réutiliser la même instance de Tomcat en y
déployant plusieurs applications web différentes.
 Structure d'une application Java EE

• Structure standard
• Toute application web Java EE doit respecter
une structure de dossiers standard, qui est
définie dans les spécifications de la plate-
forme. Vous en trouverez le schéma à la figure
suivante.
Structure d'une application Java EE

Structure des fichiers d'une application web JSP/Servlet

Structure standard
• La racine de l'application, en violet sur le schéma, est le dossier qui porte le nom
de votre projet et qui contient l'intégralité des dossiers et fichiers de l'application.
• Le dossier nommé WEB-INF est un dossier spécial. Il doit obligatoirement exister et
être placé juste sous la racine de l'application. Il doit à son tour obligatoirement
contenir :
– le fichier de configuration de l'application ([Link]) ;
– un dossier nommé classes, qui contient à son tour les classes compilées
(fichiers .class) ;
– un dossier nommé lib, qui contient à son tour les bibliothèques nécessaires au
projet (archives .jar).
• Bref, tous les dossiers et fichiers marqués en rouge sur le schéma doivent
obligatoirement être nommés et placés comme indiqué sur le schéma.
• Les fichiers et dossiers persos placés directement sous la racine, en bleu sur le
schéma, sont publics et donc accessibles directement par le client via leurs URL.
• Les fichiers et dossiers persos placés sous le répertoire WEB-INF, en orange sur le
schéma, sont privés et ne sont donc pas accessibles directement par le client.
Structure standard
• Voilà tout concernant la structure officielle : si
votre application n'est pas organisée de cette
manière, le serveur d'applications ne sera pas
capable de la déployer ni de la faire
fonctionner correctement.
 Votre première page web

• Eclipse, ce fourbe !
• Ce que vous devez savoir avant de continuer,
c'est qu'Eclipse joue souvent au fourbe, en
adaptant certaines spécificités à son mode de
fonctionnement. En l'occurrence, Eclipse
modifie comme suit la structure d'une
application Java EE (voir la figure suivante).
Structure des fichiers d'une application web sous Eclipse

Structure des fichiers d'une application web sous Eclipse

Structure des fichiers d'une application web sous
Eclipse

• Eclipse déplace la structure standard de

l'application vers un dossier nommé WebContent,
et ajoute sous la racine un dossier src qui
contiendra le code source de vos classes (les
fichiers .java). En outre (ils ne s’ont pas représenté
ici), sachez qu'Eclipse ajoute également sous la
racine quelques fichiers de configuration qui lui
permettront, via une tambouille interne, de gérer
correctement l'application !
 Création d'une page web

• Pour placer la première page HTML dans ce

dossier public, c'est-à-dire sous le dossier
WebContent d'Eclipse:
– tapez une nouvelle fois Ctrl + N au clavier, puis
– cherchez HTML File dans le dossier Web de
l'arborescence qui apparaît alors.
– Sélectionnez ensuite le dossier parent, en l'occurrence
le dossier WebContent de votre projet, puis
– donnez un nom à votre page et enfin validez.
Création d'une page HTML dans votre projet
Saisie du dossier parent et du nom de la page HTML
 Création d'une page web
• Une page HTML est donc apparue dans votre projet, sous le répertoire
WebContent. Remplacez alors le code automatiquement généré par Eclipse
dans votre page par ce code HTML basique :
• <!DOCTYPE html>
• <html>
• <head>
• <meta charset="utf-8" />
• <title>Test</title>
• </head>
• <body>
• <p>Ceci est une page HTML.</p>
• </body>
• </html>
 Création d'une page web
• Vous pouvez maintenant tenter d'accéder à
votre page web fraîchement créée. Pour ce
faire, lancez le serveur Tomcat, via le bouton

si vous avez bien suivi les instructions que

je vous ai présentées précédemment.
Ouvrez ensuite votre navigateur préféré, et
entrez l'URL suivante afin d'accéder à votre
serveur :
[Link]
 Création d'une page web
• C'est quoi toute cette histoire ? Tout un flan pour afficher trois mots ?
• Patience, patience… Notre serveur étant maintenant fonctionnel, nous voici
prêts à entrer dans le vif du sujet.
• Un IDE permet de simplifier le développement d'un projet dans son
ensemble.
• Tomcat n'est pas un serveur d'applications Java EE au sens complet du terme.
• La configuration du serveur passe principalement par deux fichiers :
[Link] et [Link].
• Une application web Java EE doit respecter une architecture bien définie.
• Eclipse modifie l'architecture des applications pour les intégrer correctement
à son système.
• Nous sommes maintenant prêts pour développer notre première application
web. Allons-y !
Chapitre 4 :
Les servlets

- Méthodes HTTP
- Qu’est ce que servlet
- Création d’une servlet
 Méthodes HTTP
• Le langage HTTP ne comprend que quelques
mots, appelés méthodes HTTP. Ce sont les
mots qu'utilise le navigateur pour poser des
questions au serveur. Mieux encore, nous ne
nous intéresserons qu'à trois de ces mots :
GET, POST et HEAD.
 La méthode GET
• C'est la méthode utilisée par le client pour récupérer une
ressource web du serveur via une URL. Par exemple,
• lorsque vous tapez  [Link] dans la barre d'adresses
de votre navigateur et que vous validez, votre navigateur
envoie une requête GET pour récupérer la page
correspondant à cette adresse et le serveur la lui renvoie. La
même chose se passe lorsque vous cliquez sur un lien.
• Lorsqu'il reçoit une telle demande, le serveur ne fait pas que
retourner la ressource demandée, il en profite pour
l'accompagner d'informations diverses à son sujet, dans ce qui
s'appelle les en-têtes ou headers HTTP : typiquement, on y
trouve des informations comme la longueur des données
renvoyées ou encore la date d'envoi.
•  on ne peut pas utiliser cette méthode pour envoyer des
données volumineuses au serveur, par exemple un fichier.
 La méthode POST
• La taille du corps du message d'une requête
POST n'est pas limitée, c'est donc cette
méthode qu'il faut utiliser pour soumettre au
serveur des données de tailles variables, ou
que l'on sait volumineuses. C'est parfait pour
envoyer des fichiers par exemple.
 La méthode HEAD
• Cette méthode est identique à la méthode GET, à ceci
près que le serveur n'y répondra pas en renvoyant la
ressource accompagnée des informations la
concernant, mais seulement ces informations. En
d'autres termes,
– il renvoie seulement les en-têtes HTTP !
– Il est ainsi possible par exemple de vérifier la validité d'une
URL ou de vérifier si le contenu d'une page a changé ou non
sans avoir à récupérer la ressource elle-même : il suffit de
regarder ce que contiennent les différents champs des en-
têtes.
Que fait-il lorsqu'une requête lui parvient ?

• Nous savons déjà qu'il la transmet à un autre élément,

que nous avons jusqu'à présent qualifié de conteneur :
il s'agit en réalité d'un conteneur de servlets,
également nommé conteneur web . Celui-ci va alors
créer deux nouveaux objets :
– HttpServletRequest : cet objet contient la requête HTTP, et
donne accès à toutes ses informations, telles que les en-
têtes (headers) et le corps de la requête.
– HttpServletResponse : cet objet initialise la réponse HTTP
qui sera renvoyée au client, et permet de la personnaliser,
en initialisant par exemple les en-têtes et le corps.
Architecture de servlet
qu'est-ce qu'une servlet ?
• Une servlet est en réalité une simple classe
Java, qui a la particularité de permettre le
traitement de requêtes et la personnalisation
de réponses. Pour faire simple, dans la très
grande majorité des cas une servlet n'est rien
d'autre qu'une classe capable de recevoir une
requête HTTP envoyée depuis le navigateur de
l'utilisateur, et de lui renvoyer une réponse
HTTP.
 Remarque
• En principe, une servlet dans son sens
générique est capable de gérer n'importe quel
type de requête, mais dans les faits il s'agit
principalement de requêtes HTTP. Ainsi,
l'usage veut qu'on ne s'embête pas à préciser
"servlet HTTP" lorsque l'on parle de ces
dernières, et il est donc extrêmement
commun d'entendre parler de servlets alors
qu'il s'agit bien en réalité de servlets HTTP.
Création de servlet (1)
• Nous souhaitons traiter des requêtes HTTP,
nous allons donc faire hériter notre servlet de
la classe HttpServlet ! 
De retour sur le projet Eclipse, faites un clic
droit sur le répertoire src, puis choisissez
New > Class. Renseignez alors la fenêtre qui
s'ouvre comme indiqué sur les figures
suivantes.
Création de servlet (2)
• Renseignez le champ package par un package
de votre choix : exemple [Link] !
Renseignez le nom de la servlet, puis cliquez
ensuite sur le bouton Browse... afin de définir
de quelle classe doit hériter notre servlet, puis
allez chercher la classe HttpServlet et validez.
Voici le code que vous obtenez alors
automatiquement :
 Code de servlet
• package [Link];

• import [Link];

• public class Test extends HttpServlet {

•
• }
• Rien d'extraordinaire pour le moment, notre servlet étant absolument
vide. D'ailleurs puisqu'elle ne fait encore rien, sautons sur l'occasion pour
prendre le temps de regarder ce que contient cette classe HttpServlet
 héritée, afin de voir un peu ce qui se passe derrière. La Javadoc nous
donne des informations utiles concernant le fonctionnement de cette
classe : pour commencer c'est une classe abstraite, ce qui signifie qu'on
ne pourra pas l'utiliser telle quelle et qu'il sera nécessaire de passer par
une servlet qui en hérite. On apprend ensuite que la classe propose les
méthodes Java nécessaires au traitement des requêtes et réponses
HTTP ! Ainsi, on y trouve les méthodes :
• doGet() pour gérer la méthode GET ;
• doPost() pour gérer la méthode POST ;
• doHead() pour gérer la méthode HEAD.
Comment la classe fait-elle pour associer chaque type de
requête HTTP à la méthode Java qui lui correspond ?

• Ceci est géré automatiquement par sa méthode 

service() : c'est elle qui se charge de lire
l'objet HttpServletRequest et de distribuer la requête
HTTP à la méthode doXXX() correspondante.
• Ce qu'il faut retenir pour le moment :
• une servlet HTTP doit hériter de la classe
abstraite HttpServlet ;
• une servlet doit implémenter au moins une des
méthodes doXXX(), afin d'être capable de traiter une
requête entrante.
 Remarque
• Puisque ce sont elles qui prennent en charge
les requêtes entrantes, les servlets vont être
les points d'entrée de notre application web,
c'est par elles que tout va passer.
Contrairement au Java SE, il n'existe pas en
Java EE de point d'entrée unique prédéfini,
comme pourrait l'être la méthode main()…
 Mise en place
• Vous le savez, les servlets jouent un rôle très particulier dans une
application. Comme nous avons vu les servlets sont des aiguilleurs en
introduction, on peut encore les voir comme des gendarmes : si les requêtes
étaient des véhicules, les servlets seraient chargées de faire la circulation sur
le gigantesque carrefour qu'est votre application ! Eh bien pour obtenir cette
autorité et être reconnues en tant que telles, les servlets nécessitent un
traitement de faveur : il va falloir les enregistrer auprès de notre application.
• Revenons à notre exemple. Maintenant que nous avons codé notre première
servlet, il nous faut donc un moyen de faire comprendre à notre application
que notre servlet existe, à la fois pour lui donner l'autorité sur les requêtes
et pour la rendre accessible au public ! Lorsque nous avions mis en place
une page HTML statique dans le chapitre précédent, le problème ne se
posait pas : nous accédions directement à la page en question via une URL
directe pointant vers le fichier depuis notre navigateur.
Mais dans le cas d'une servlet qui, rappelons-le, est une
classe Java, comment faire ?
• Concrètement, il va falloir configurer quelque part le fait que notre servlet va être
associée à une URL. Ainsi lorsque le client la saisira, la requête HTTP sera
automatiquement aiguillée par notre conteneur de servlet vers la bonne servlet, celle qui
est en charge de répondre à cette requête. Ce "quelque part" se présente sous la forme
d'un simple fichier texte : le fichier [Link].
• C'est le cœur de votre application : ici vont se trouver tous les paramètres qui contrôlent
son cycle de vie. Nous n'allons pas apprendre d'une traite toutes les options intéressantes,
mais y aller par étapes. Commençons donc par apprendre à lier notre servlet à une URL :
après tous les efforts que nous avons fournis, c'est le minimum syndical que nous sommes
en droit de lui demander ! 
• Ce fichier de configuration doit impérativement se nommer [Link] et se situer juste
sous le répertoire/WEB-INF de votre application. Si vous avez suivi à la lettre la procédure
de création de notre projet web, alors ce fichier est déjà présent. Éditez-le, et supprimez
le contenu généré par défaut. Si jamais le fichier est absent de votre arborescence, créez
simplement un nouveau fichier XML en veillant bien à le placer sous le répertoire /WEB-
INF et à le nommer [Link]. Voici la structure à vide du fichier :
• <?xml version="1.0" encoding="UTF-8"?>
• <web-app
• xmlns="[Link]
• xmlns:xsi="[Link]
• xsi:schemaLocation="[Link]
[Link]
• version="3.0">

• </web-app>
L'intégralité de son contenu devra être placée entre les
balises <web-app> et </web-app>.
• La mise en place d'une servlet se déroule en
deux étapes : nous devons d'abord déclarer
la servlet, puis lui faire correspondre une
URL.
• Définition de la servlet
• La première chose à faire est de déclarer notre
servlet : en quelque sorte il s'agit de lui
donner une carte d'identité, un moyen pour le
serveur de la reconnaître. Pour ce faire, il faut
ajouter une section au fichier qui se présente
ainsi sous sa forme minimale :
• <servlet>
•     <servlet-name>Test</servlet-name>
•      <servlet-class>
[Link]
• </servlet-class>
• </servlet>
• La balise responsable de la définition d'une servlet se
nomme logiquement <servlet>, et les deux balises
obligatoires de cette section sont très explicites :
• <servlet-name> permet de donner un nom à une
servlet. C'est ensuite via ce nom qu'on fera référence à
la servlet en question. Ici, j'ai nommé notre servlet Test.
• <servlet-class> sert à préciser le chemin de la classe de
la servlet dans votre application. Ici, notre classe a bien
pour nom Test et se situe bien dans le
package [Link].