TP N°0 (Architecture n

Master 2 – Professionnel - SITW
Module : Web services
2015/2016
TP 0 : Architecture n-Tiers
Technologies côté serveur (servlets/JSP)
Objectifs pédagogiques du TP

Se familiariser avec la programmation côté serveur en Java : servlets et JSP

Concevoir une application Web complète et fonctionnelle comportant plusieurs couches distinctes

Gérer les sessions

Manipuler les headers HTTP
Outils

Navigateurs Web, EDI NetBeans / Eclipse , glassfish / serveur Tomcat, Mysql, …
Description de l'application
Il s'agit d'une application Web de « chat » simple qui fonctionnera derrière un serveur Web et un moteur de
servlets et de JSP.
Les tâches à réaliser sont les suivantes :

Permettre à chaque utilisateur de saisir un pseudonyme (pas de gestion des mots de passe).

Permettre à chaque utilisateur de saisir un message textuel.

Mémoriser les interventions de tous les utilisateurs, précédées de leurs pseudos.

Les afficher aux utilisateurs.
Description de l'interface et architecture des composants de
l'application
Accueil
La page d’accueil (« index.html », voir figure ci-dessous) contient un formulaire demandant un
pseudo à l’utilisateur. Le pseudo est saisi dans un champ texte, qui est envoyé par la méthode
POST à une servlet, appelée « Init ».
Page 1 sur 4
Master 2 – Professionnel - SITW
Module : Web services
2015/2016
Initialisation
La servlet « Init » effectue un traitement de la requête (voir plus loin), et redirige l’utilisateur sur une page
HTML appelée « interface.html ».
Chat
Cette interface est celle qui est affichée pendant le fonctionnement "normal" de l'application (voir figure cidessous). Elle est reponsable des fonctionnalités suivantes :

Affichage des messages : cette page statique délègue à une page JSP nommée « Messages.jsp » la
gestion et l'affichage des messages envoyés par les différents utilisateurs (voir plus loin) ; pour cela,
elle contient un élément iframe qui affiche Messages.jsp et est placé en haut de l'écran, sur toute la
largeur de la fenêtre
Attention, pour pouvoir adresser cette page JSP depuis un autre élément de la page interface.html, il
faut lui donner un nom (attribut name) ; vous l'appellerez "messages"

Saisie et envoi de nouveaux messages : interface.html contient un formulaire basique qui permet la
saisie d'un message et son envoi par POST à la JSP "messages" ; cela provoque la mémorisation du
nouveau message et l'actualisation de l'affichage de ceux-ci

Déconnexion : quand l'utilisateur veut quitter l'application, il est redirigé vers une page statique le
remerciant de s'être connecté
Remarques :

affichage des messages : la totalité des messages échangés sont affichés, avec leurs auteurs ; pour
permettre le chargement des nouveaux messages sans renvoi de données de la part de l'utilisateur, cet
affichage est actualisé toutes les 5 secondes,

On ne se préoccupe pas ici de la sauvegarde des messages ; leur durée de vie est la même que celle de
l'application déployée sur le serveur.
Page 2 sur 4
Master 2 – Professionnel - SITW
Module : Web services
2015/2016
Partie 1 : conception basique de l'application
Pages statiques
Dans votre projet, commencez par créer les deux pages statiques « index.html » et « interface.html. Pour
interface.html, faites en sorte de fixer la hauteur de l'iframe en fonction de la hauteur du formulaire, de façon à
laisser un maximum de place pour l'affichage des messages.
Initialisation
Créez ensuite une nouvelle servlet « Init ». Cette servlet répondra aux requêtes en GET ou en POST, et
effectuera les traitements suivants :

Pour les appels en GET : redirection sur index.html

Pour les appels en POST :
1. création / récupération de la session de l'utilisateur
2. récupération du paramètre de la requête contenant le pseudo saisi par l'utilisateur
3. création d'un attribut de la session ayant pour valeur ce pseudo
4. redirection vers interface.html
En cas d'erreur dans l'une des étapes de ce processus, l'utilisateur sera redirigé vers « index.html ».
Interface de gestion des messages
La page « Messages.jsp » permet de gérer les messages. Pour cela, elle possède une variable globale de type
List<Message> (à vous de créer la classe Message). « Messages.jsp » a deux fonctions distinctes :
1. Réception et mémorisation des messages envoyés par POST : à la réception d'une requête POST,
la page récupère le texte du message dans le paramètre de la requête ad hoc, ainsi que le nom de son
auteur dans l'attribut de session stocké par Init. Elle crée alors un nouveau message, qu'elle place en
queue de liste.
2. Affichage des messages : à la réception d'une requête (GET ou POST), la page parcourt la liste et
affiche tous les messages avec la mise en forme qui vous plaîra. En l'absence d'envoi de données de la
part du client, cet affichage s'actualisera toutes les 5 secondes.
Indications :

pour l'actualisation automatique de la page, vous utiliserez l'en-tête HTTP "Refresh"

l'envoi d'un formulaire vers un iframe se fait en utilisant l'attribut target,

bien entendu, faites en sorte que vos documents (statiques et générés) soient en XHTML strict (sauf
pour celui qui définit les iframes) et que des feuilles de style CSS leur soient associées,

n'oubliez pas la page de déconnexion.
Ajout de salons
Vous allez maintenant modifier votre application pour qu'elle prenne en charge plusieurs "salons de discussion".

dans le formulaire de connexion (index.html), ajoutez un champ permettant d'indiquer un nom de salon

pour l'instant, placez le nom du salon dans un attribut de session

faites en sorte que Message.jsp puisse gérer plusieurs listes de messages, correspondant aux différents
salons (déclenchez la création d'une liste à chaque nouveau nom de salon)
À ce stade, vous avez réalisé une application de chat basique, mais fonctionnelle.
Page 3 sur 4
Master 2 – Professionnel - SITW
Module : Web services
2015/2016
Partie 2 : amélioration de l'application
L'état actuel de votre application est le suivant : toutes les 5 secondes, chaque client interroge le serveur, qui
parcourt alors toute la liste de messages et re-génère dynamiquement un nouvel affichage contenant la totalité
des messages enregistrés, qui sera renvoyé à chaque client via le réseau. Si le nombre d'utilisateurs est grand
et/ou s'il y a de nombreux messages enregistrés dans la base, ce fonctionnement peut vite représenter une
charge de travail importante pour le serveur, ainsi qu'une consommation inutile de bande passante réseau.
L'objectif de cette partie est d'améliorer le processus de récupération et d'affichage des messages échangés par
les différents utilisateurs. Pour cela, vous allez permettre à votre application de déterminer si elle doit recalculer
l'affichage des messages pour un client, ou s'il n'y a pas lieu de le faire. Deux possibilités sont à votre
disposition.
Utilisation des en-têtes HTTP
La plupart des clients renvoient au serveur un en-tête HTTP If-Modified-Since, indiquant la date de leur dernier
chargement d'une page. Si cette date est postérieure à celle du dernier POST reçu, aucun nouveau message
n'est disponible. Plutôt que de renvoyer une réponse HTTP contenant une page complète, il suffit de renvoyer
juste un en-tête HTTP, avec le code de statut 204 indiquant au client que la page n'a pas été modifiée.
Pour cela :
1. vérifiez que votre serveur envoie bien au client un en-tête Last-Modified à la génération de la réponse ;
sinon, rajoutez-le dans « Affichage.jsp »
2. vérifiez que votre client vous renvoie bien cette valeur dans un en-tête If-Modified-Since lors de la
requête d'actualisation de la page « Messages.jsp »
3. rajoutez un attribut permettant de stocker la valeur de dernière modification de la liste des messages
dans le contexte de l'application et faites en sorte que « Stockage.jsp » actualise sa valeur à chaque
appel
4. lors de l'appel en GET de « Messages.jsp », comparez la valeur de l'en-tête If-Modified-Since reçu avec
celle de l'attribut du contexte applicatif et réagissez en conséquence (génération de la page ou code de
statut 304).
Utilisation des cookies
Si le numéro du dernier message mémorisé (i.e. le nombre total de messages) est égal à celui du dernier
message envoyé à un client (i.e. le nombre total de messages au moment où le serveur lui a servi la réponse),
cela signifie qu'aucun message n'est arrivé depuis la dernière requête du client. Il est donc inutile de lui
renvoyer la page.
1. rajoutez / updatez un cookie chez votre client indiquant le numéro du dernier message obtenu lors de
l'envoi d'une réponse par « Affichage.jsp »
2. lors de la réception d'une requête GET par « Messages.jsp », testez l'existence de ce cookie et
comparez sa valeur au nombre total de messages mémorisés
3. réagissez en conséquence.
L’énoncé de ce TP est tiré de la page d'accueil de l'UE "Programmation Web" de Master 1
Informatique de l'Université Claude Bernard Lyon 1, France.
Page 4 sur 4