les servlets-java EE

19Servlets
Objectifs
• Écrire des servlets et les exécuter grâce au serveur Web
du Kit de développement de Servlet Java (JSDK).
• Répondre aux requêtes HTTP GET et POST
d’un HttpServlet.
• Utiliser les cookies pour stocker des informations du client
pendant une session de navigation.
• Exploiter le suivi d’une session à partir d’un servlet.
• Lire et écrire des ﬁchiers à partir d’un servlet.
• Accéder à une base de données à partir d’un servlet.

936 SERVLETS CHAPITRE 19
Aperçu
19.1 Introduction
19.2 Aperçu de la technologie servlet
19.2.1 API de servlet
19.2.2 Classe HttpServlet
19.2.3 Interface HttpServletRequest
19.2.4 Interface HttpServletResponse
19.3 Télécharger le Kit de développement de servlet Java
19.4 Gérer les requêtes GET en HTTP
19.5 Gérer les requêtes POST en HTTP
19.6 Suivi de session
19.6.1 Cookies
19.6.2 Suivi de session avec HttpSession
19.7 Applications multitiers: utiliser le JDBC à partir d’un servlet
19.8 Commerce électronique
19.9 Ressources Internet et du Web sur les servlets
Résumé • Terminologie • Observations de génie logiciel • Exercices de révision
• Réponses aux exercices de révision • Exercices
19.1 Introduction
Cela bouge sur Internet et le Web! L’Internet relie le monde de l’information. Le Web facilite
l’usage de l’Internet et l’agrémente du style et des vibrations du multimédia. Les organisations
voient en l’Internet et le Web des éléments capitaux de leurs stratégies en systèmes d’information.
Java propose un certain nombre de possibilités prédéfinies de mise en réseau qui facilitent le
développement d’applications basées tant sur Internet que sur le Web. Non seulement Java spécifie
le parallélisme par le biais du multithread, mais il permet à des programmes de rechercher des
informations et de collaborer avec d’autres programmes qui fonctionnent sur des ordinateurs
distants, et, tout ceci, à travers le monde ou, plus simplement, au sein d’une même organisation. Java
va jusqu’à permettre à des applets et des applications qui fonctionnent sur le même ordinateur, de
communiquer les unes et les autres, tout en respectant des contraintes de sécurité.
La mise en réseau est un sujet vaste et complexe. Les étudiants en informatique et en génie
logiciel prennent en principe tout un semestre pour se consacrer à un cours de haut niveau sur la mise
en réseau d’ordinateurs, et ils prolongent cette étude au niveau universitaire. Java propose un
complément riche en possibilités de réseau et se positionne de ce fait comme un excellent support
des cours de mise en réseaux informatiques. Dans Comment programmer en Java, nous introduisons
une vaste panoplie de concepts et de fonctionnalités de la mise en réseau en Java.
Les fonctionnalités réseau de Java sont regroupées en plusieurs packages. Les caractéristiques
fondamentales de la mise en réseau sont définies par des classes et des interfaces du package
java.net, par le biais des communications par sockets qu’offre Java, permettant à des applications
de voir le réseau comme un ensemble de flux de données: un programme peut lire ou écrire dans un
socket, aussi simplement qu’il lirait ou écrirait dans un fichier. Les classes et les interfaces du package
java.net proposent aussi des communications par paquets, qui permettent la transmission de
paquets individuels d’informations; on les utilise fréquemment pour la transmission de l’audio et de la
vidéo par la voie de l’Internet. Au chapitre 21, nous montrons comment créer et exploiter les sockets,
et comment communiquer par l’entremise de paquets de données.

CHAPITRE 19 SERVLETS 937
Les classes et les interfaces des cinq packages java.rmi pour l’invocation de méthodes
distantes ou RMI (Remote Method Invocation), et les sept packages org.omg pour l’Architecture
d’intermédiaire de requête vers des objets communs ou CORBA (Common Object Request Broker
Architecture) qui font partie de l’API de Java 2, fournissent une vue de très haut niveau de la mise en
réseau. Les packages RMI permettent à des objets Java qui fonctionnent sur des machines virtuelles
Java, placées en principe sur des ordinateurs distincts, de communiquer entre elles par l’entremise
d’appels de méthodes distantes. De tels appels de méthodes semblent adressés à un objet du même
programme mais, en réalité, ils font intervenir le réseau, grâce aux possibilités du package java.net,
qui transmet les appels de méthodes à un autre objet, sur une machine distante. Les packages de
CORBA fournissent des fonctionnalités semblables à celles des packages RMI, avec cette différence
clé que le RMI n’est utilisable qu’entre des objets Java, tandis que CORBA est exploitable entre deux
applications quelconques, à condition qu’elles comprennent toutes deux CORBA, y compris les
applications écrites dans des langages de programmation différents. Le chapitre 20 présente les
caractéristiques du RMI de Java. Nous n’aborderons pas CORBA dans ce manuel.
Notre discussion de la mise en réseau, répartie sur les sept chapitres qui suivent, se concentre
sur les deux côtés de la relation client-serveur. Le client émet une requête en vue de l’exécution
d’une action, tandis que le serveur exécute cette action et répond au client. Ce modèle de
communication requête-réponse constitue la fondation pour le plus haut niveau de représentation de
la mise en réseau pratiquée par Java, à savoir les servlets. Un servlet étend les fonctionnalités d’un
serveur. Les packages javax.servlet et javax.servlet.http fournissent les classes et
les interfaces qui permettent de définir des servlets.
Le modèle de requête-réponse trouve une concrétisation usuelle dans la relation entre des
navigateurs Web et des serveurs Web. Lorsqu’un utilisateur sélectionne un site Web qu’il veut
visiter avec son navigateur (l’application du client), une requête est envoyée au serveur Web
approprié (l’application du serveur). Le serveur répond normalement au client en lui envoyant la
page Web adéquate en HTML.
Dans ce chapitre, nous entamons notre étude de la mise en réseau par celle des servlets, qui
étendent les fonctionnalités des serveurs Web, la forme de servlet la plus répandue aujourd’hui. La
technologie des servlets est actuellement principalement axée sur l’utilisation du protocole HTTP du
Web, mais des servlets sont aussi développés pour d’autres technologies. Les servlets se montrent
efficaces dans le développement de solutions Web qui garantissent un accès sécurisé à un site Web,
qui interagissent avec des bases de données pour le compte d’un client, qui génèrent de façon
dynamique des documents HTML sur mesure destinés à l’affichage sur un navigateur et qui
conservent des informations de session pour chaque client.
De nombreux développeurs perçoivent les servlets comme la bonne solution à des applications
de gestion intensive de bases de données destinées à communiquer avec ce que l’on appelle des
clients allégés, c’est-à-dire des applications qui ne requièrent qu’une activité minimale du côté des
clients. Le serveur est responsable de tout l’accès à la base de données. Les clients se connectent au
serveur à l’aide de protocoles normalisés, disponibles sur toutes les plates-formes clientes. Par
conséquent, le code de la logique ne doit être écrit qu’une seule fois et résider sur le serveur, pour
en donner ensuite l’accès aux clients.
Nos exemples de servlets utiliseront les possibilités des flux d’entrée-sortie que nous avons vus
au chapitre 17, ainsi que les possibilités d’accès aux bases de données JDBC exposés au chapitre 18.
Ce chapitre est intentionnellement placé à la suite de notre discussion sur le JDBC et les bases de
données, de manière à créer des applications multipartites en client-serveur, afin d’accéder à des
bases de données. Nous persistons à insister sur le fait que Java n’est pas qu’un simple langage, mais
bien tout un monde de technologie de l’information qui met au service des développeurs
d’applications, en particulier du niveau des grandes entreprises, une vaste panoplie de technologies.
Java est en effet prêt pour une grande audience.

19.2 Aperçu de la technologie servlet
Dans cette section, nous présentons un aperçu de la technologie servlet de Java. Nous envisageons
au plus haut niveau les classes, les méthodes et les exceptions relatives aux servlets. Les quelques
sections qui suivent présentent des exemples de code de la vie réelle qui nous permettront d’édifier
des systèmes client-serveur multipartites à l’aide des technologies des servlets et du JDBC.
L’Internet est construit sur de nombreux protocoles. Le protocole HTTP (HyperText Transfer
Protocol), qui forme la base du World Wide Web, utilise les URL (Uniform Resource Locators, ou
encore Universal Resource Locators) pour localiser des données sur l’Internet. Les URL usuels
représentent des fichiers ou des répertoires et peuvent aussi représenter des tâches complexes telles
que des recherches dans des bases de données ou même, d’une manière plus générale, sur l’Internet
tout entier. Pour de plus amples informations sur les formats des URL, rendez visite à:
http://www.ncsa.uiuc.edu/demoweb/url-primer.html
Pour de plus amples informations sur le protocole HTTP, visitez le site:
http://www.w3.org/Protocols/HTTP/
Pour des informations générales sur des sujets divers liés au Web, visitez le site:
http://www.w3.org
Les servlets sont au serveur ce que sont les applets au client. Les servlets sont normalement
exécutés au sein d’un serveur Web. En fait, ce qui fait toute la popularité des servlets, c’est qu’ils
sont aujourd’hui supportés par la plupart des principaux serveurs Web du marché, dont les serveurs
Web de Netscape, l’Internet Information Server (IIS) de Microsoft, le serveur Web Jigsaw du Web
Consortium, ainsi que le très populaire serveur Web Apache.
Les servlets de ce chapitre proposent des démonstrations de communications entre des clients
et des serveurs via le protocole HTTP du Web. Un client envoie une requête HTTP au serveur. Le
serveur reçoit la requête et la dirige vers les servlets adéquats, en vue de leur exécution. Les servlets
opèrent leurs traitements, qui comportent souvent une interaction avec des bases de données, puis
renvoient leurs résultats au client, en principe sous la forme de documents HTML à afficher dans un
navigateur, mais tous les autres formats, y compris les images et les données binaires, sont
susceptibles d’un tel traitement.
19.2.1 API de servlet
Sur le plan architecture, tous les servlets doivent implémenter l’interface Servlet. Comme c’est
le cas de nombreuses méthodes clés des applets, les méthodes de l’interface Servlet sont
invoquées automatiquement par le serveur sur lequel le servlet est installé. Cette interface définit
cinq méthodes décrites à la figure 19.1.
Observation du génie logiciel 19.1
Tous les servlets doivent implémenter l’interface javax.servlet.Servlet. 19.1
Les packages de servlet définissent deux classes abstraites qui implémentent l’interface
Servlet: la classe GenericServlet (servlet générique du package javax.servlet) et la
classe HttpServlet (du package javax.servlet.http). Ces classes apportent des
implémentations prédéfinies de toutes les méthodes de Servlet. La plupart des servlets étendent
soit GenericServlet, soit HttpServlet, et surchargent quelques-unes, ou toutes leurs
méthodes par des comportements adéquats, adaptés sur mesure.

Tous les exemples de ce chapitre étendent la classe HttpServlet, qui définit des possibilités
de traitement étendues des servlets, ceux-ci étendant à leur tour les fonctionnalités d’un serveur
Web. La méthode-clé de tout servlet est la méthode service, qui reçoit à la fois un objet
ServletRequest et un objet ServletResponse. Ces objets donnent accès à des flux
d’entrée et de sortie qui permettent au servlet de lire des données auprès d’un client et d’en envoyer
à ce client. Ces flux peuvent être des flux organisés soit sous la forme d’octets, sous la forme de
caractères. Si un problème apparaît pendant l’exécution d’un servlet, des exceptions soit
ServletException, soit IOException, sont levées pour signaler le problème.
19.2.2 Classe HttpServlet
Les servlets orientés Web étendent normalement la classe HttpServlet. La classe
HttpServlet surcharge la méthode service pour effectuer une distinction parmi les requêtes
typiques reçues en provenance d’un navigateur Web client. Les deux types de requêtes (ou méthodes
de requête) HTTP sont GET et POST. La requête GET obtient (ou recherche, get en anglais) des
informations sur le serveur. Les usages habituels des requêtes GET consistent à rechercher un
document HTML ou une image. La requête POST poste, envoie, des données au serveur. Les usages
courants des requêtes POST consistent à envoyer des information à un serveur à partir d’un
formulaire HTML dans lequel le client a inséré des données pour envoyer des informations, de sorte
qu’il puisse par exemple effectuer une recherche sur l’Internet, interroger une base de données pour
le compte du client, envoyer des informations d’authentification au serveur, et ainsi de suite.
Méthode Description
void init( ServletConfig config )
Cette méthode est automatiquement appelée une fois pendant le cycle d’exécution
d’un servlet pour initialiser ce servlet. L’argument ServletConfig est fourni
automatiquement par le serveur qui exécute le servlet.
ServletConfig getServletConfig()
Cette méthode renvoie une référence à un objet qui implémente l’interface
ServletConfig. Cet objet fournit un accès aux informations de configuration
du servlet, telles que les paramètres d’initialisation et le ServletContext
du servlet, qui donne au servlet l’accès à cet environnement, c’est-à-dire du serveur
sur lequel s’exécute le servlet.
void service( ServletRequest requete, ServletResponse reponse )
Ceci est la première méthode appelée dans chaque servlet en réponse à une requête
d’un client.
String getServletInfo()
Cette méthode est définie par le programmeur d’un servlet, pour renvoyer uneString
contenant des informations du servlet telles que son auteur et sa version.
void destroy()
Cette méthode de nettoyage est appelée quand un servlet est sur le point de se terminer,
par le serveur sur lequel il s’exécute. C’est là une bonne méthode pour libérer une
ressource utilisée par le servlet, comme par exemple un fichier ouvert ou une
connexion à une base de données.
Figure 19.1 Méthodes de l’interface Servlet.

La classe HttpServlet définit les méthodes doGet et doPut pour répondre
respectivement aux requêtes GET et POST d’un client. Ces méthodes sont appelées par la méthode
service de la classe HttpServlet, lorsqu’une requête arrive au serveur. La méthode
service détermine d’abord le type de la requête, puis appelle la méthode appropriée. La classe
propose aussi d’autres types de requêtes moins usuels, qui sortent du cadre de ce livre. Pour plus
d’informations sur le protocole HTTP, visitez le site:
http://www.w3.org/Protocols/
La figure 19.2 reprend les méthodes de la classe HttpServlet qui répondent aux autres types de
requêtes. Elles reçoivent toutes des paramètres des types HttpServletRequest et
HttpServletResponse et renvoient un void. Les méthodes de la figure 19.2 sont d’un usage
plutôt rare.
Les méthodes doGet et doPost reçoivent en arguments un objet HttpServletRequest
et un objet HttpServletResponse qui assurent l’interaction entre le client et le serveur. Les
méthodes de HttpServletRequest facilitent l’accès aux données fournies au sein de la requête.
Les méthodes HttpServletResponse facilitent le retour au client Web des résultats du servlet
au format HTML. Les deux sections suivantes étudient les interfaces HttpServletRequest et
HttpServletResponse.
19.2.3 Interface HttpServletRequest
Chaque appel à doGet ou doPost sur un HttpServlet reçoit un objet qui implémente
l’interface HttpServletRequest. Le serveur Web qui exécute le servlet crée un objet
HttpServletRequest et le passe à la méthode service du servlet, qui, à son tour, le passe à
doGet ou doPost. Cet objet contient la requête du client. Diverses méthodes permettent au servlet
de traiter la requête du client. Quelques-unes de ces méthodes proviennent de l’interface
ServletRequest, l’interface qu’étend HttpServletRequest. La figure 19.3 décrit
quelques-unes des méthodes-clés utilisées dans ce chapitre.
doDelete Appelée en réponse à une requête HTTP DELETE. Une telle requête sert normalement
à supprimer un ﬁchier sur le serveur. Il se peut qu’elle ne soit pas disponible sur
certains serveurs, à cause des risques évidents auxquels elle l’expose, au niveau de
la sécurité.
doOptions Appelée en réponse à une requête HTTP OPTIONS. Elle renvoit des informations
au client, indiquant les options HTTP acceptées par le serveur.
doPut Appelée en réponse à une requête HTTP PUT. Une telle requête est utilisée
normalement pour stocker un ﬁchier sur le serveur. Il se peut qu’elle ne soit pas
disponible sur certains serveurs étant donné les risques auxquels elles l’expose
au niveau de la sécurité.
doTrace Appelée en réponse à une requête HTTP TRACE. Une telle requête sert normalement
au débogage. L’implémentation de cette méthode renvoie automatiquement
un document HTML au client, contenant les informations d’en-tête de la requête
(soit les données envoyées par le fureteur au sein de la requête).
Figure 19.2 Méthodes importantes de la classe HttpServlet.

19.2.4 Interface HttpServletResponse
Chaque appel à doGet ou doPost pour un HttpServlet reçoit un objet qui implémente
l’interface HttpServletResponse. Le serveur Web qui exécute le servlet crée un objet
HttpServletResponse et le passe à la méthode service du servlet (qui, à son tour, le passe
à doGet ou doPost). Cet objet contient la réponse au client. Diverses méthodes sont également
fournies pour permettre au servlet de formuler sa réponse au client. Certaines de ces méthodes
proviennent de l’interface ServletResponse, l’interface que HttpServletResponse
étend. La figure 19.4 décrit quelques-unes de ces méthodes, exploitées dans ce chapitre.
String getParameter( String name )
Retourne la valeur associée à un paramètre envoyé par le servlet au sein de la requête
GET ou POST. L’argument name représente le nom du paramètre.
Enumeration getParameterNames()
Retourne le nom de tous les paramètres envoyés au servlet au sein d’une requête POST.
String[] getParameterValues( String name )
Renvoie un tableau de String contenant les valeurs d’un paramètre spécifié
d’un servlet.
Cookie[] getCookies()
Retourne un tableau d’objets Cookie stockés sur le client par le serveur.
Les Cookie servent à identifier de façon univoque des clients du servlet.
HttpSession getSession( boolean create )
Renvoie l’objet HttpSession associé à la session courante, de navigation du client.
Un objet HttpSession peut être créé par cette méthode (argument true) si aucun
objet HttpSession n’existe encore pour ce client. Les objets HttpSession sont
exploitables d’une manière semblable aux Cookie, pour identifier de façon univoque
les clients.
Figure 19.3 Méthodes importantes de l’interface HttpServletRequest.
void addCookie( Cookie cookie )
Ajoute un Cookie à l’en-tête de la réponse au client. L’âge maximum que peut
atteindre le Cookie et, si le client autorise l’enregistrement des Cookie, détermine
si oui ou non les Cookie seront stockés sur le client.
ServletOutputStream getOutputStream()
Obtient un flux de sortie en octets qui permet l’envoi de données binaires au client.
Figure 19.4 Méthodes importantes de HttpServletResponse. (1 de 2)

19.3 Télécharger le Kit de développement de servlet Java
Avant de pouvoir programmer des servlets, vous devez d’abord télécharger et installer le Kit de
développement de servlet Java (JSDK, Java Servlet Development Kit). Vous pouvez le télécharger
gratuitement du site Web de Sun Microsystems:
http://java.sun.com/products/servlet/index.html
Le téléchargement est accessible à partir de la partie inférieure du menu placé sur la gauche de cette
page Web (option Downloads & Specifications). Sun propose le téléchargement pour les plates-
formes Windows et UNIX. Au moment de la publication de ce livre, la version en cours du JSDK
était la version 2.1, mais la version 2.2 était dores et déjà disponible sous la forme d’un correctif.
Après avoir téléchargé le JSDK, installez-le sur votre ordinateur et lisez avec soin le fichier
README.txt incorporé au répertoire d’installation. Il explique comment mettre en place le JSDK
est explique comment démarrer les serveurs utilisables pour tester les servlets si vous ne disposez
pas d’un serveur Web acceptant les servlets. Pour développer des servlets, vous devez aussi copier
le fichier servlet.jar qui contient les fichiers de classes du JSDK à partir du répertoire
d’installation de votre répertoire d’extensions JDK (le répertoire c:jdk1.2.2jrelibext
sous Windows ou le répertoire ~/jdk1.2.2/jre/lib/ext sous UNIX).
Le World Wide Web Consortium (W3C) est une organisation internationale dédiée au
développement de protocoles communs pour le Web, qui «promeut son évolution et garantit son
interopérabilité». À cette fin, le W3C propose l’Open Source software (logiciel à source ouvert); une
des conséquences positives de tels logiciels est que leur utilisation est gratuite pour tout le monde.
Le W3C fournit, par l’entremise de sa licence Open Source un serveur Web baptisé Jigsaw
(«Puzzle»), écrit en totalité en Java et qui est complètement compatible avec les servlets. Jigsaw et
sa documentation sont disponibles par téléchargement à l’adresse:
http://www.w3.org/Jigsaw/
Pour de plus amples informations à propos de la licence Open Source, visitez le site:
http://www.opensource.org/
PrintWriter getWriter()
Obtient un flux de sortie de caractères qui permet l’envoi de données du genre texte
au client.
void setContentType( String type )
Spécifie le type MIME pour les réponses au navigateur. Le type MIME permet
au navigateur de déterminer la manière dont il doit afficher les données (ou
éventuellement quelle autre application il lui faut exécuter pour traiter ces données).
Par exemple, le type MIME "text/html" indique que la réponse est un document
HTML, de sorte que le navigateur affiche la page HTML.
Figure 19.4 Méthodes importantes de HttpServletResponse. (1 de 2)Figure 19.4 Méthodes importantes de HttpServletResponse. (2 de 2)

19.4 Gérer les requêtes GET en HTTP
Le but principal de la requête HTTP GET est de rechercher le contenu d’une URL spécifiée—
normalement le contenu est un document HTML, c’est-à-dire une page Web. Le servlet de la
figure 19.5 et le document HTML de la figure 19.6 proposent une démonstration d’un servlet qui
gère des requêtes GET en HTTP. Lorsque l’utilisateur clique sur le bouton Get du document
HTML dans le document HTML (figure 19.6), une requête GET est envoyée au servlet
HTTPGetServlet (figure 19.5). Le servlet répond à la requête en générant de façon dynamique
un document HTML destiné au client qui affiche la phrase «Bienvenue dans le monde des servlets!»
La figure 19.5 montre le code source de HTTPGetServlet.java. La figure 19.6 montre le
document HTML que le client charge pour accéder au servlet et les copies d’écrans de la fenêtre du
navigateur du client, avant et après l’interaction avec le servlet. Le document HTML de cet exemple
a été affiché à l’aide de l’Internet Explorer 5 de Microsoft, mais l’exemple fonctionne bien entendu
à partir de n’importe quel navigateur.
Les lignes 3 et 4 importent les packages javax.servlet et javax.servlet.http.
Nous utilisons plusieurs types de données de ces packages dans l’exemple.
Pour les servlets qui gèrent les requêtes GET et POST en HTTP, le JSDK fournit la superclasse
HttpServlet (du package javax.servlet.http). Cette classe implémente l’interface
javax.servlet.Servlet et ajoute des méthodes qui acceptent les requêtes de protocole
HTTP. La classe HTTPGetServlet étend HttpServlet (ligne 7) pour cette raison.
1 // Figure 19.5: HTTPGetServlet.java
2 // Création et envoi d’une page à un client.
3 import javax.servlet.*;
4 import javax.servlet.http.*;
5 import java.io.*;
6
7 public class HTTPGetServlet extends HttpServlet {
8 public void doGet( HttpServletRequest requete,
9 HttpServletResponse reponse )
10 throws ServletException, IOException
11 {
12 PrintWriter sortie;
13
14 reponse.setContentType( "text/html" ); // type de contenu.
15 sortie = reponse.getWriter(); // prendre scripteur.
16
17 // créer et envoyer la page HTML au client.
18 StringBuffer tamp = new StringBuffer();
19 tamp.append( "<HTML><HEAD><TITLE>n" );
20 tamp.append( "Exemple simple de servletn" );
21 tamp.append( "</TITLE></HEAD><BODY>n" );
22 tamp.append( "<H1>Bienvenue dans le monde des servlets!</H1>n" );
23 tamp.append( "</BODY></HTML>" );
24 sortie.println( tamp.toString() );
25 sortie.close(); // clre le flux PrintWriter.
26 }
27 }
Figure 19.5 Le HTTPGetServlet traite une requête GET en HTTP.

La superclasse HTTPServlet fournit la méthode doGet pour répondre aux requêtes GET. Sa
fonction par défaut consiste à signaler une erreur de requête incorrecte BAD_REQUEST. Une telle
erreur est normalement affichée dans l’Internet Explorer par une page Web indiquant «La page ne
peut être affichée», et dans le Communicator de Netscape par une page Web qui affirme «Erreur
HTTP 404». Nous surchargeons la méthode doGet (aux lignes 8 à 26) pour assurer le traitement
des requêtes GET édifiées sur mesure. La méthode doGet attend deux arguments: un objet qui
implémente javax.servlet.http.HttpServletRequest et un objet qui implémente
javax.servlet.http.HttpServletResponse. L’objet HttpServletRequest repré-
sente la requête du client et l’objet HttpServletResponse représente la réponse du serveur. Si
doGet est incapable de gérer la requête d’un client, il lance une javax.servlet.Servlet
Exception. Si doGet rencontre une erreur durant le traitement d’un flux, c’est-à-dire la lecture du
client ou l’écriture sur le client, il lève une java.io.IOException.
Pour montrer comment se passe la réponse à une requête GET, le servlet crée un petit document
HTML contenant le texte «Bienvenue dans le monde des servlets!» Le texte de ce
document HTML constitue la réponse au client. La réponse est envoyée au client par le biais de
l’objet PrintWriter, accessible par l’objet HTTPServletResponse. La ligne 12 déclare
sortie comme un PrintWriter.
La ligne 14 utilise la méthode setContentType de l’objet HTTPServletResponse
nommé reponse pour indiquer le type de contenu de la réponse au client. Ceci permet au
navigateur du client de comprendre d’abord, pour traiter ensuite le contenu. Dans cet exemple, nous
spécifions comme type de contenu text/html, ce qui indique au navigateur que la réponse est un
fichier texte en HTML. Le navigateur sait qu’il doit lire les balises HTML du fichier, mettre le
document en forme selon les indications des balises et l’afficher dans la fenêtre de navigation pour
que l’utilisateur puisse la consulter à sa guise.
La ligne 15 fait appel à la méthode getWriter de l’objet HTTPServletResponse nommé
reponse pour obtenir une référence à l’objet PrintWriter qui envoie le texte du document HTML
au client. Remarque: si la réponse est un ensemble de données binaires tel qu’une image, la méthode
getOutputStream permet d’obtenir une référence à un objet ServletOutputStream.
Les lignes 19 à 23,
tamp.append( "<HTML><HEAD><TITLE>n" );
tamp.append( "Exemple simple de servletn" );
tamp.append( "</TITLE></HEAD><BODY>n" );
tamp.append( "<H1>Bienvenue dans le monde des servlets!</H1>n" );
tamp.append( "</BODY></HTML>" );
créent le document HTML en ajoutant ces chaînes de caractères au StringBuffer nommé tamp.
La ligne 24,
sortie.println( tamp.toString() );
envoie la réponse, c’est-à-dire le contenu du StringBuffer, au client. La ligne 25 clôture le flux
de sortie PrintWriter nommé sortie. Ceci vide le contenu du tampon de sortie et envoie
effectivement les informations au client.
Le client ne peut accéder au servlet que s’il fonctionne sur un serveur. Les serveurs Web qui
acceptent les servlets, à savoir le serveur Web Java de Sun Microsystems, le serveur Jigsaw du Web
Consortium ou le serveur HTTP Apache du Apache Group, disposent normalement d’une procédure
d’installation des servlets. Si vous souhaitez exécuter le servlet au sein d’un serveur Web, vérifiez
cette procédure d’installation dans la documentation de votre serveur Web. Pour ce qui est de nos
exemples, leur démonstration est basée sur le serveur JSDK.

Le JSDK est fourni avec le serveur Web WebServer JSDK, de sorte que vous pouvez
parfaitement tester vos servlets. Le WebServer JSDK table sur l’hypothèse que les fichiers .class
des servlets sont installés dans le sous-répertoire
webpagesWEB-INFservlets
du répertoire d’installation du JSDK, sous Windows, ou
webpages/WEB-INF/servlets
sous UNIX. Pour installer un servlet, il faut d’abord compiler le servlet avec javac comme vous
le feriez normalement pour n’importe quel autre fichier de code source Java. Placez ensuite le fichier
.class obtenu, contenant la classe du servlet compilée, dans le répertoire servlets. C’est
seulement alors que le servlet est installé sur le WebServer JSDK.
Dans le répertoire d’installation de JSDK se trouvent un fichier de commandes par lots
Windows (startserver.bat) et un script d’environnement UNIX (startserver)
utilisables pour démarrer le WebServer JSDK sous Windows et sous UNIX, respectivement.
Remarque: le JSDK propose aussi stopserver.bat et stopserver qui permettent de clôturer
le WebServer JSDK sous Windows et sous UNIX, respectivement. Tapez la commande appropriée
sur votre plate-forme dans une fenêtre de ligne de commande. Lorsque le serveur commence son
exécution, il affiche les lignes suivantes en mode ligne de commande,
JSDK WebServer Version 2.1
Loaded configuration from file:D:jsdk2.1/default.cfg
endpoint created: :8080
qui indiquent que le WebServer JSDK s’est mis en attente de requêtes sur le numéro de port 8080
de l’ordinateur. Remarque: les ports n’ont strictement rien à voir avec les ports matériels, physiques,
sur lesquels on branche des câbles; ce sont en fait des entiers qui permettent à des clients de
demander différents services sur le même serveur. Le numéro de port spécifie où le serveur attend
des connexions des clients et les reçoit: On appelle souvent cela le point de rencontre. Lorsqu’un
client se connecte à un serveur pour demander un service, le client doit spécifier le numéro de port
adéquat; sinon, la requête du client ne peut être traitée. Les numéros de ports sont des entiers positifs
compris entre 0 et 65535. De nombreux systèmes d’exploitation réservent les numéros de ports
inférieurs à 1024 à des services systèmes, tels que les serveurs de courrier et les serveurs Web. Ces
ports ne peuvent généralement pas intervenir dans les connexions des programmes utilisateurs. En
fait, certains systèmes d’exploitation imposent même des privilèges d’accès spéciaux pour accéder
aux ports de numéros inférieurs à 1024.
Il y a tant de numéros de ports que point la question: lesquels utiliser? Comment un client peut-il
connaître le port à utiliser lorsqu’il demande un service? Vous entendrez souvent parler du vocable
numéro de port usuel, dans le contexte de la description des services usuels sur l’Internet, tels que
les serveurs Web et les serveurs de courrier électronique. Par exemple, un serveur Web attend que
ses clients émettent des requêtes sur le port prédéfini 80. Tous les navigateurs Web connaissent ce
numéro de port comme étant le numéro de port usuel d’un serveur Web sur lequel des demandes de
documents HTML sont effectuées. Ainsi donc, lorsque vous introduisez un URL dans un navigateur
Web, celui-ci se connecte normalement sur le port 80 du serveur. D’une manière semblable, le
WebServer JSDK utilise le 8080 somme son numéro de port usuel. Vous pouvez imposer un numéro
de port différent au WebServer JSDK en modifiant le contenu du fichier default.cfg du
répertoire d’installation du JSDK. Changez-y la ligne
server.port=8080
pour forcer le port sur lequel vous voulez que le WebServer JSDK attende toujours ses requêtes.

Une fois que le WebServer JSDK fonctionne, vous pouvez charger le document HTML
HTTPGetServlet.html de la figure 19.6 dans votre navigateur Web favori (voir la première
copie d’écran). Remarque: copiez le fichier HTML dans le sous-répertoire webpages du répertoire
d’installation du JSDK, sous Windows ou sous UNIX. Ainsi, il vous suffira d’introduire dans la
barre d’adresse l’URL http://localhost:8080/HTTPGetServlet.html
La ligne 1 montre un commentaire HTML sur plusieurs lignes. Les commentaires HTML
commencent avec un . La ligne 2 donne la marque de début des
balises HTML présentes dans le document.
Les lignes 3 à 7 forment la section d’en-tête du document HTML, qui débute avec la balise
<HEAD> et se termine avec la balise </HEAD>. La section d’en-tête contient normalement le titre
du document («Exemple de Servlet Get HTTP»), comme il a été spécifié entre les balises
<TITLE> et </TITLE>.
1 
2 <HTML>
3 <HEAD>
4 <TITLE>
5 Exemple de Servlet GET HTTP
6 </TITLE>
7 </HEAD>
8 <BODY>
9 <FORM
10 ACTION="http://localhost:8080/servlet/HTTPGetServlet"
11 METHOD="GET">
12 <P>Cliquez sur le bouton pour que le servlet envoie
13 un document HTML</P>
14 <INPUT TYPE="submit" VALUE="Get du document HTML">
15 </FORM>
16 </BODY>
17 </HTML>
Figure 19.6 Le document HTML qui envoie la requête GET au HTTPGetServlet.

Le corps du document (body en anglais), aux lignes 8 à 16, définit les éléments de la page Web
que le navigateur affiche à l’utilisateur. Le corps apparaît entre les balises <BODY> et </BODY>, et
contient du texte littéral et des balises qui permettent au navigateur de mettre la page Web en forme.
La partie importante du document qui nous intéresse dans cet exemple est le form (pour
formulaire) spécifié aux lignes 9 à 15, entre les balises <FORM> et </FORM>.
<FORM
ACTION="http://localhost:8080/servlet/HTTPGetServlet"
METHOD="GET">
<P>Cliquez sur le bouton pour que le servlet envoie
un document HTML</P>
<INPUT TYPE="submit" VALUE="Get du document HTML">
</FORM>
Les trois premières lignes indiquent que l’ACTION pour ce formulaire est
"http://localhost:8080/servlet/HTTPGetServlet"
et que la METHOD est "GET" (de l’anglais «obtenir»). L’ACTION spécifie le gestionnaire de formulaire
de la partie serveur, soit, dans ce cas-ci, le servlet HTTPGetServlet. La METHOD est le type de
requête que le serveur utilise pour décider de la manière dont il doit gérer la requête et, éventuellement,
imposer au navigateur de joindre des arguments à la suite de l’URL spécifié dans l’ACTION.
Accordons un examen plus attentif à l’URL utilisé dans l’ACTION. Le serveur localhost est
un nom de serveur usuel sur la plupart des ordinateurs qui acceptent les protocoles de réseau fondés sur
TCP/IP, tel HTTP. Le serveur localhost fait en réalité référence à votre propre ordinateur.
localhost sert souvent dans ce livre pour effectuer les démonstrations de programmes en réseau sur
un seul ordinateur, de sorte que les étudiants qui ne disposent pas d’une connexion réseau puisse
poursuivre leur étude des concepts de la programmation en réseau. Dans cet exemple, localhost
indique que le serveur sur lequel le servlet est installé fonctionne en fait sur la machine locale. Le nom
d’hôte du serveur est suivi de «:8080», ce qui donne le numéro de port sur lequel le WebServer JSDK
attend indéfiniment les requêtes de ses clients. Rappelez-vous que les navigateurs Web tablent sur le
fait que le port 80 est celui qui, par définition, constitue le port de serveur sur lequel les clients déposent
leurs requêtes, mais le WebServer JSDK, lui, attend les requêtes de ses clients sur le port 8080. Si nous
ne spécifions pas explicitement le numéro de port dans l’URL, le servlet ne recevra jamais notre
requête, puisque le navigateur l’envoie systématiquement au numéro de port usuel, à savoir 80, et
un message d’erreur sera affiché par le navigateur. Remarquez que l’URL pour cette ACTION contient
/servlet comme répertoire, ce qui correspond au répertoire dans lequel nous avons placé notre
servlet, ainsi que tous ceux que nous créerons. La plupart des serveurs Web ont un répertoire spécifique
destiné à l’accueil de servlets, pour que ceux-ci soient «installés». Ce répertoire est souvent nommé
servlet ou servlets. Le WebServer JSDK simule ceci en montrant à l’utilisateur que le servlet
HTTPGetServlet se trouve dans le répertoire servlet sur le serveur. Tout servlet qui s’exécute
par l’entremise du WebServer JSDK doit suivre la même voie d’accès.
La ligne 14,
<INPUT TYPE="submit" VALUE="Get HTML Document">
indique le type de composant d’interface utilisateur graphique du formulaire à afficher, soit un élément
d’entrée INPUT. Le TYPE de cet élément est "submit" (soumettre, normalement représenté par un
bouton) et la valeur à y afficher, c’est-à-dire l’étiquette qui apparaît sur le bouton, est "Get du
Document HTML". L’étiquette par défaut d’un bouton submit est Submit Query (soumettre
requête) si aucune VALUE n’est donnée au bouton. Lorsque l’utilisateur clique sur le bouton submit
dans un formulaire, celui-ci effectue son ACTION: le navigateur se connecte au serveur spécifié au

numéro de port donné (ou le port 80 si aucun port n’est fourni au protocole HTTP) et demande le
service (HTTPGetServlet). Dans cet exemple, le navigateur contacte le WebServer JSDK,
c’est-à-dire le gestionnaire de formulaire, spécifié dans l’ACTION et indique que la METHOD est
un GET. Le WebServer JSDK invoque la méthode service du servlet et lui passe un objet
HTTPServletRequest qui contient la METHOD (donc GET) spécifiée par le client, ainsi qu’un
objet HTTPServletResponse. La méthode service détermine le type de requête (GET) et
y répond par un appel à sa méthode doGet, qui renvoie la page Web montrée dans la seconde
copie d’écran de la figure 19.6.
Dans cette seconde copie d’écran, remarquez que le champ Adresse du navigateur pour ce
document HTML contient l’URL spécifié dans notre précédente ACTION. Notez également le «?»
situé à la fin de l’URL. S’il y a d’autres paramètres à passer au gestionnaire de formulaire du côté
serveur, le «?» distingue l’URL des arguments.
Vous pouvez aussi voir l’effet de ce servlet en introduisant l’URL
http://localhost:8080/servlet/HTTPGetServlet
comme page Web que doit afficher le navigateur. L’action par défaut du navigateur Web est en effet
de placer une requête GET sur le serveur, soit un HTTPGetServlet dans ce cas-ci.
19.5 Gérer les requêtes POST en HTTP
La requête POST en HTTP sert souvent à poster des données d’un formulaire HTML à un
gestionnaire de formulaires sur un serveur, qui traite les données. Lorsque vous répondez par
exemple à un sondage sur le Web, une requête POST fournit normalement les informations que vous
introduisez dans le formulaire HTML et que vous envoyez au serveur Web.
Les navigateurs placent souvent en cache, c’est-à-dire qu’ils sauvent sur disque, les pages Web
consultées, de façon à les charger rapidement à la prochaine visite. Il n’y a aucun changement entre
la version enregistrée dans le cache et la version qui se trouve actuellement sur le Web. Ceci accélère
fortement la consultation de pages, tout en réduisant magistralement la quantité de données qui
doivent transiter par le réseau ou la ligne téléphonique, pour vous permettre de voir une page Web.
Les navigateurs ne placent cependant pas en cache la réponse d’un serveur à une requête POST, car
une même requête POST suivante n’aura très probablement pas le même résultat. Dans un sondage,
par exemple, de nombreux utilisateurs visitent la même page Web et répondent à une question. Le
résultat du sondage étant affiché sur une page, chaque nouvelle réponse change le résultat global de
l’enquête, donc la page.
Lorsque vous utilisez un moteur de recherche sur le Web, une requête GET contient
normalement les informations que vous spécifiez dans le formulaire HTML du moteur de recherche.
Ce dernier effectue la recherche, puis vous renvoie les résultats dans une page Web. De telles pages
sont souvent mises en cache, pour le cas où vous effectueriez une nouvelle fois cette même
recherche. Comme dans le cas des requêtes POST, les requêtes GET peuvent comporter des
paramètres dans la requête au serveur Web.
Le servlet de la figure 19.7 stocke les résultats d’une enquête concernant vos animaux de
compagnie préférés sur le serveur. Lorsqu’un utilisateur répond à l’enquête, le servlet
HTTPPostServlet envoie un document HTML au client qui résume les résultats de l’enquête
jusqu’à ce stade. L’utilisateur choisit son animal préféré dans un bouton radio de la page Web de la
figure 19.8, puis appuie sur Soumettre. Le navigateur envoie une requête POST en HTTP au
servlet; celui-ci réagit en lisant les résultats précédents de l’enquête dans un fichier sur le serveur, il
met les résultats du sondage à jour, les réinscrit sur le fichier du serveur, et il envoie enfin une page
Web au client qui lui indique les résultats cumulés de l’enquête. Pour les besoins de cet exemple,
nous avons chargé le document HTML dans le navigateur Netscape Communicator 4.7.

1 // Figure 19.7: HTTPPostServlet.java
2 // Un servlet de sondage élémentaire.
5 import java.text.*;
6 import java.io.*;
7 import java.util.*;
8
9 public class HTTPPostServlet extends HttpServlet {
10 private String nomsAnimaux[] =
11 { "chien", "chat", "oiseau", "serpent", "aucun" };
12
13 public void doPost( HttpServletRequest requete,
16 {
17 int animaux[] = null, total = 0;
18 File f = new File( "sondage.txt" );
19
20 if ( f.exists() ) {
21 // déterminer le nombre de réponses à l’enquête jusque là.
22 try {
23 ObjectInputStream entree = new ObjectInputStream(
24 new FileInputStream( f ) );
25
26 animaux = (int []) entree.readObject();
27 entree.close(); // fermer le flux.
28
29 for ( int i = 0; i < animaux.length; ++i )
30 total += animaux[ i ];
31 }
32 catch( ClassNotFoundException cnfe ) {
33 cnfe.printStackTrace();
34 }
35 }
36 else
37 animaux = new int[ 5 ];
38
39 // lire la réponse courante au sondage.
40 String valeur =
41 requete.getParameter( "animal" );
42 ++total; // mettre total à jour pour toutes réponses.
43
44 // déterminer lequel est choisi et mettre son total à jour.
45 for ( int i = 0; i < nomsAnimaux.length; ++i )
46 if ( valeur.equals( nomsAnimaux[ i ] ) )
47 ++animaux[ i ];
48
49 // écrire les totaux mis à jour sur disque.
50 ObjectOutputStream sortie = new ObjectOutputStream(
51 new FileOutputStream( f ) );
52
Figure 19.7 Le HTTPPostServlet qui traite une requête POST en HTTP. (1 de 2)

53 sortie.writeObject( animaux );
54 sortie.flush();
55 sortie.close();
56
57 // calculer les pourcentages.
58 double pourcentages[] = new double[ animaux.length ];
59
60 for ( int i = 0; i < pourcentages.length; ++i )
61 pourcentages[ i ] = 100.0 * animaux[ i ] / total;
62
63 // envoyer un message de remerciement au client.
64 reponse.setContentType( "text/html" ); // type de contenu.
65
66 PrintWriter sortieReponse = reponse.getWriter();
67 StringBuffer tamp = new StringBuffer();
68 tamp.append( "<html>n" );
69 tamp.append( "<title>Merci!</title>n" );
70 tamp.append( "Merci pour votre participation.n" );
71 tamp.append( "<BR>Résultats:n<PRE>" );
72
73 DecimalFormat twoDigits = new DecimalFormat( "#0.00" );
74 for ( int i = 0; i < pourcentages.length; ++i ) {
75 tamp.append( "<BR>" );
76 tamp.append( nomsAnimaux[ i ] );
77 tamp.append( ": " );
78 tamp.append( twoDigits.format( pourcentages[ i ] ) );
79 tamp.append( "% réponses: " );
80 tamp.append( animaux[ i ] );
81 tamp.append( "n" );
82 }
83
84 tamp.append( "n<BR><BR>Total réponses: " );
85 tamp.append( total );
86 tamp.append( "</PRE>n</html>" );
87
88 sortieReponse.println( tamp.toString() );
89 sortieReponse.close();
90 }
91 }
Figure 19.7 Le HTTPPostServlet qui traite une requête POST en HTTP. (2 de 2)
Comme à la figure 19.5, le HTTPPostServlet étend HttpServlet à la ligne 9, de sorte
que chaque HTTPPostServlet est capable de gérer les requêtes GET et POST en HTTP. Les
lignes 10 et 11 définissent le tableau de String nomsAnimaux qui contient les noms des animaux
repris dans le sondage. Ceux-ci servent à déterminer la réponse au sondage et à mettre le compteur
à jour pour l’animal adéquat.
La méthode doPost des lignes 13 à 90 répond aux requêtes POST. Sa fonctionnalité
prédéfinie consiste à indiquer une erreur BAD_REQUEST. Donc nous surchargeons cette méthode
pour apporter le traitement approprié et sur mesure de la requête POST qui nous intéresse. La
méthode doPost reçoit les deux mêmes arguments que le doGet de l’exemple précédent: un
objet qui implémente javax.servlet.http.HttpServletRequest et un objet qui

implémente javax.servlet.http.HttpServletResponse pour représenter respec-
tivement la requête du client et la réponse du servlet. La méthode doPost lève une
javax.servlet.ServletException si elle est incapable de gérer la requête du client et
lève une IOException si un problème se produit pendant la gestion du flux.
La méthode doPost commence par déterminer si le fichier sondage.txt existe sur le
serveur. La ligne 18 définit un objet File nommé f dans ce but. Le programme ne fournit pas
d’emplacement pour le fichier. Par défaut, les fichiers créés par un servlet exécuté par le WebServer
JSDK sont stockés dans le répertoire d’installation du JSDK (jsdk2.1). Vous pouvez imposer
l’emplacement de stockage du fichier au moment de la création de l’objet File. À la ligne 20, si le
fichier existe, son contenu est lu par le servlet, de sorte que les résultats du sondage seront mis à jour
et renvoyés au client en cours. Si le fichier n’existe pas, c’est-à-dire si la requête actuelle est la toute
première réponse au sondage, la méthode doPost crée le fichier un peu plus loin dans le code.
Le tableau d’entiers animaux stocke le nombre de réponses pour chaque type d’animal. Si le
fichier qui contient les résultats précédents au sondage existe, alors les lignes 23 à 30 ouvrent un
ObjectInputStream pour lire le tableau d’entiers animaux et totaliser le nombre de réponses
qui ont été reçues jusqu’à cette étape. Lorsque le servlet crée le fichier et stocke le tableau d’entiers,
il utilise un ObjectOutputStream pour écrire le fichier.
Les lignes 40 et 41,
String valeur =
requete.getParameter( "animal" );
font appel à la méthode getParameter de l’interface javax.servlet.ServletRequest
pour rechercher et lire la réponse au sondage postée par le client. Cette méthode attend comme
argument le nom du paramètre ("animal"), tel qu’il a été spécifié dans le document HTML de la
figure 19.8; nous allons le commenter un peu plus loin. La méthode retourne une String qui
contient la valeur du paramètre, ou null si le paramètre est introuvable. Le fichier HTML de la
figure 19.8, qui utilise ce servlet comme gestionnaire de formulaire, contient cinq boutons radios,
tous nommés animal (lignes 11 à 15 de la figure 19.8). Du fait qu’un seul bouton radio est
sélectionnable à la fois, la String retournée par getParameter représente le seul bouton radio
choisi par l’utilisateur. La valeur de chaque bouton radio est une des chaînes du tableau
nomsAnimaux créé dans le servlet. Remarque: si nous traitions un formulaire susceptible de
renvoyer de nombreuses valeurs pour un paramètre particulier, nous utiliserions plutôt la méthode
getParameterValues pour obtenir directement un tableau de String contenant les valeurs.
La ligne 42 incrémente le total pour indiquer qu’il y a une réponse de plus au sondage. Les
lignes 45 à 47 déterminent l’animal sélectionné par le client et mettent à jour le total de l’animal
adéquat. Les lignes 50 à 55 ouvrent un ObjectOutputStream pour stocker les résultats mis à
jour de l’enquête dans le fichier sondage.txt. Ce fichier garantit que, même si le servlet est
interrompu et redémarré, les résultats du sondage demeurent sur disque.
Les lignes 58 à 61 préparent le pourcentage du total des votes qui représentent chaque
animal. Ces résultats sont renvoyés à l’utilisateur dans une partie de la HttpServletResponse.
Nous préparons la réponse à partir de la ligne 64, où la méthode setContentType de
ServletResponse spécifie que le contenu sera du texte d’un document HTML (text/html).
La ligne 66 utilise la méthode getWriter de ServletResponse pour obtenir une
référence à un objet PrintWriter et affecte celle-ci à sortieReponse. Cette référence sert à
envoyer la réponse au client. Le StringBuffer tamp de la ligne 67 stocke le contenu de la
réponse pendant que le servlet prépare le document HTML. Les lignes 68 à 86 préparent son contenu
par une suite d’appels à la méthode append de StringBuffer. Les lignes 71 et 86 ajoutent les

balises HTML <PRE> et </PRE> pour spécifier que le texte compris entre elles est un texte
préformatté. Un texte préformatté est normalement affiché dans une police à largeur fixe (qualifiée
de monospaced en anglais) où tous les caractères ont la même largeur. Plusieurs lignes introduisent
aussi l’étiquette <BR> pour indiquer une interruption (break), demandant au navigateur de
commencer une nouvelle ligne de texte.
La ligne 88
sortieReponse.println( tamp.toString() );
envoie le contenu de tamp au client. La ligne 89 clôture le flux sortieReponse.
Une fois que le servlet s’exécute, vous pouvez charger le document HTML HTTPPost
Servlet.html de la figure 19.8 dans un navigateur (voir la première copie d’écran).
1 
2 <HTML>
3 <HEAD>
4 <TITLE>Exemple de servlet Post en HTTP</TITLE>
5 </HEAD>
6
7 <BODY>
8 <FORM METHOD="POST" ACTION=
9 "http://localhost:8080/servlet/HTTPPostServlet">
10 Quel est votre animal favori?<BR><BR>
11 <INPUT TYPE=radio NAME=animal VALUE=chien>Chien<BR>
12 <INPUT TYPE=radio NAME=animal VALUE=chat>Chat<BR>
13 <INPUT TYPE=radio NAME=animal VALUE=oiseau>Oiseau<BR>
14 <INPUT TYPE=radio NAME=animal VALUE=serpent>Serpent<BR>
15 <INPUT TYPE=radio NAME=animal VALUE=aucun CHECKED>Aucun
16 <BR><BR><INPUT TYPE=submit VALUE="Soumettre">
17 <INPUT TYPE=reset VALUE="Réinitialiser">
18 </FORM>
19 </BODY>
20 </HTML>
Figure 19.8 Résultat de la requête POST au HTTPPostServlet. (1 de 2)

Figure 19.8 Résultat de la requête POST au HTTPPostServlet. (2 de 2)
La partie importante du document HTML de cet exemple réside dans le formulaire spécifié aux
lignes 8 à 18:
<FORM METHOD="POST" ACTION=
"http://localhost:8080/servlet/HTTPPostServlet">
Quel est votre animal favori?<BR><BR>
<INPUT TYPE=radio NAME=animal VALUE=chien>Chien<BR>
<INPUT TYPE=radio NAME=animal VALUE=chat>Chat<BR>
<INPUT TYPE=radio NAME=animal VALUE=oiseau>Oiseau<BR>
<INPUT TYPE=radio NAME=animal VALUE=serpent>Serpent<BR>
<INPUT TYPE=radio NAME=animal VALUE=aucun CHECKED>Aucun
<BR><BR><INPUT TYPE=submit VALUE="Soumettre">
<INPUT TYPE=reset VALUE="Réinitialiser">
</FORM>
La ligne 8 indique que la METHOD de ce formulaire est "POST" et que l’ACTION est:
"http://localhost:8080/servlet/HTTPGetServlet"
L’ACTION spécifie le gestionnaire de formulaire du côté serveur: HTTPPostServlet. La
METHOD permet au servlet de décider comment gérer la requête et d’amener éventuellement le
navigateur à associer des arguments à la fin de l’URL spécifié dans l’ACTION.
Les lignes 11 à 15 spécifient les composants boutons radios du formulaire. Le TYPE de tous ces
éléments est radio, leur nom, NAME, est animal et leur valeur, valeur, est la chaîne à poster
lorsque le contenu du formulaire est envoyé au servlet par le POST. Pourvu que le même nom soit
donné à chacun de ces boutons radio, le navigateur sait qu’ils font tous partie du même groupe et
qu’un seul d’entre eux est sélectionnable à la fois. Au départ, le bouton radio défini à la ligne 15 est
coché, CHECKED, c’est-à-dire sélectionné. À la suite de la balise <INPUT> de chacune des lignes
11 à 15, apparaît la chaîne de caractères que le navigateur affiche à la droite de chaque bouton radio
dans le document HTML. La ligne 16 définit le bouton submit qui provoque l’exécution de
l’ACTION du formulaire. Quand l’utilisateur clique sur ce bouton, le navigateur envoie une requête
POST au servlet spécifié dans l’ACTION. Puisque la METHOD est POST, le navigateur attache aussi
à la requête les valeurs associées à chaque composant de formulaire HTML. Dans le cas du groupe
de boutons radios, la valeur du bouton sélectionné est ajoutée à la requête. Le servlet lit les valeurs

soumises au sein de la requête à l’aide de la méthode getParameter de l’interface
javax.servlet.ServletRequest. Si l’utilisateur clique sur le bouton Réinitialiser, défini
à la ligne 17 du document HTML, le navigateur réinitialise le formulaire à son état initial, avec
l’option Aucun sélectionnée.
Remarquez que, au fur et à mesure que vous déposez des votes, le servlet conserve une trace
de tous les votes émis jusque là, et ceci même si vous achevez le servlet et le relancez. Vous
pouvez répéter le dépôt de vote en cliquant sur Soumettre pour déposer un vote, en cliquant
sur le bouton Précédente du navigateur pour revenir à la page de sondage, en sélectionnant
un autre animal, ou le même, et en cliquant de nouveau sur le bouton Soumettre. Vous pouvez
aussi charger de nouveau le fichier HTTPPostServlet.html dans le navigateur, et ainsi de
suite. Nous ne synchronisons pas les accès au fichier dans cet exemple. Il est donc possible que
deux clients accèdent au sondage en même temps et que deux ou plusieurs threads du serveur
tentent de modifier le fichier au même moment. Il existe deux manières de régler ce problème:
la première consiste à exploiter les techniques de synchronisation exposées au chapitre 15,
Gestion du multithread, la seconde consiste à mettre en place l’interface de balisage
javax.servlet.SingleThreadModel. Celle-ci indique que le servlet d’implémen-
tation ne peut servir les requêtes que d’un seul client à la fois.
19.6 Suivi de session
De nombreux sites Web actuels fournissent des pages Web et (ou) des fonctionnalités sur mesure et
sur base d’une relation de client à client. Par exemple, certains sites Web vous permettent d’adapter
leur page d’accueil en fonction de vos propres besoins. Un excellent exemple de cette tendance est
mis en évidence sur le site Web de Yahoo! Si vous vous rendez sur le site
http://my.yahoo.com/
vous pouvez y adapter la manière dont le site Yahoo! vous apparaît à l’avenir lorsque vous visitez
de nouveau le site. Remarquez que vous devez obtenir pour ce faire un identifiant Yahoo! gratuit.
Le protocole HTTP ne permet pas le maintient d’informations permanentes qui permettent à un
serveur Web de déterminer qu’une requête provient d’un client déterminé. Du point de vue du seul
serveur, toutes les requêtes peuvent provenir du même client ou de clients tous différents.
Un autre exemple de service sur mesure adapté client par client réside dans le chariot de
supermarché mis en place pour effectuer des achats sur le Web. Bien évidemment, le serveur doit
pratiquer la distinction parmi les clients, de sorte que la société puisse déterminer les articles choisis
et les porter au compte du client adéquat. Après tout, quand nous nous rendons dans une grande
surface, nous n’achetons pas tous les mêmes articles!
Un troisième but de l’adaptation en fonction du client se situe au niveau du marketing. Les
sociétés suivent souvent à la trace les pages que vous visitez au sein d’un même site pour pouvoir
afficher des publicités appropriées à vos propres tendances de navigation. Un problème apparaît
alors dans le fait que bien des gens considèrent comme une intrusion dans leur vie privée que de
suivre ainsi leur trace: cette tendance est en croissance permanente dans notre société informatisée.
Pour permettre au serveur de bien distinguer les clients, chaque client doit s’identifier auprès du
serveur. Plusieurs techniques existent, pratiquées de façon usuelle, qui permettent ainsi de distinguer
les clients. Pour les besoins de ce chapitre, nous en présentons deux qui permettent de suivre les
clients de manière individuelle: les cookies (section 19.6.1) et le suivi de session (section 19.6.2).
19.6.1 Cookies
Une manière très usuelle d’adapter des pages Web consiste à utiliser des cookies. Les cookies
peuvent stocker des informations sur l’ordinateur de l’utilisateur en vue de leur récupération

ultérieure dans la même session de navigation ou dans des sessions ultérieures. Nous utiliserions des
cookies par exemple dans une application de commerce électronique pour indiquer les préférences
du client. Quand le servlet reçoit une nouvelle communication de la part d’un client, le servlet peut
examiner le(s) cookie(s) qu’il a envoyé(s) au client dans une communication précédente pour
identifier les préférences du client et donc afficher immédiatement les produits qui l’intéressent.
Les cookies sont de petits fichiers envoyés par un servlet, ou toute autre technologie analogue,
au sein d’une réponse à un client. Toute interaction en HTTP entre un client et un serveur inclut un
en-tête, contenant des informations relatives à la requête (lorsque la communication va du serveur
au client). Quand un HttpServlet accueille une requête, l’en-tête contient des informations telles
que le type de requête, c’est-à-dire GET ou POST, et les cookies stockés par le serveur sur la machine
du client. Lorsque le serveur formule sa réponse, l’en-tête contient tous les cookies que le serveur
souhaite déposer sur l’ordinateur client.
Certains clients n’acceptent pas l’écriture de cookies en leur sein. Quand un client décline l’invitation
à déposer un cookie en son sein, il est important de l’avertir de ce que ce refus peut l’empêcher de
naviguer sur le site associé, bien entendu. 19.2
En fonction de l’âge maximum d’un cookie, le navigateur Web soit maintient le cookie pendant la
session de navigation, c’est-à-dire jusqu’à ce que l’utilisateur quitte le navigateur Web, soit stocke le
cookie sur l’ordinateur client en vue d’une utilisation ultérieure. Lorsque le navigateur émet une
requête auprès d’un serveur, les cookies déposés précédemment par le serveur sur le client sont
renvoyés au serveur, s’ils n’ont pas expiré, au sein de la requête formulée par le navigateur. Les cookies
sont automatiquement effacés lorsqu’ils expirent, c’est-à-dire lorsqu’ils atteignent leur âge maximum.
L’exemple suivant propose une démonstration de cookies. Le servlet de la figure 19.9 gère les
requêtes tant GET que POST. Le document HTML de la figure 19.10 contient quatre boutons radios
(C, C++, Java et Visual Basic 6) et deux boutons Soumettre et Réinitialiser. Quand
l’utilisateur clique sur Soumettre, le servlet est invoqué avec une requête POST. Le servlet répond
en ajoutant un cookie qui contient le langage sélectionné à l’en-tête de la réponse et envoie une page
HTML au client. Chaque fois que l’utilisateur clique sur Soumettre, un cookie lui est envoyé. Cet
exemple ne permet pas d’écrire des cookies en double. Le document HTML de la figure 19.11
présente à l’utilisateur un bouton qu’il peut presser pour recevoir une proposition de lecture basée
sur le langage de programmation qu’il a sélectionné précédemment dans un document HTML.
Quand l’utilisateur presse le bouton Conseils de lecture, il appelle le servlet de la figure 19.9 avec
une requête GET. Le navigateur envoie au servlet tout cookie reçu auparavant en provenance du servlet.
Le servlet répond en réceptionnant les cookies de l’en-tête de la requête et en créant un document HTML
qui recommande un livre pour chaque langage que l’utilisateur a sélectionné dans le document HTML
de la figure 19.10. Nous analysons d’abord le servlet, puis les deux documents HTML.
Les lignes 2 et 10 déclarent des tableaux de String qui stockent respectivement le nom des
langages de programmation et les numéros ISBN des livres que nous recommanderons ensuite.
Remarque: ISBN est l’anagramme de «International Standard Book Number», ou Numéro de livre
normalisé au niveau international—un schéma de numérotation que les éditeurs du monde entier
utilisent pour donner à tout livre distinct un numéro d’identification unique. La méthode doPost
de la ligne 14 est invoquée en réponse à la requête POST envoyée par le biais du document HTML
de la figure 19.10. La ligne 19 récupère la sélection de langage de l’utilisateur (la valeur du bouton
radio choisi sur la page Web) avec la méthode getParameter.
La ligne 21 passe la valeur du langage au constructeur de la classe javax.servlet.
http.Cookie par l’instruction:
Cookie c = new Cookie( langage, getISBN( langage ) );

1 // Figure 19.9: CookieExemple.java
2 // Utilisation des cookies.
5 import java.io.*;
6
7 public class CookieExemple extends HttpServlet {
8 private String noms[] = { "C", "C++", "Java",
9 "Visual Basic 6" };
10 private String isbn[] = {
11 "0-13-226119-7", "0-13-528910-6",
12 "0-13-012507-5", "0-13-528910-6" };
13
17 {
19 String langage = requete.getParameter( "lang" );
20
21 Cookie c = new Cookie( langage, getISBN( langage ) );
22 c.setMaxAge( 120 ); // retrait du cookie après 120 secondes.
23 reponse.addCookie( c ); // doit précéder getWriter.
24
25 reponse.setContentType( "text/html" );
26 sortie = reponse.getWriter();
27
28 // envoie la page HTML au client.
29 sortie.println( "<HTML><HEAD><TITLE>" );
30 sortie.println( "Cookies" );
31 sortie.println( "</TITLE></HEAD><BODY>" );
32 sortie.println( "<P>Bienvenue dans le monde des cookies!<BR>" );
33 sortie.println( "<P>" );
34 sortie.println( langage );
35 sortie.println( " est un langage réputé." );
36 sortie.println( "</BODY></HTML>" );
37
38 sortie.close(); // clôturer le flux.
39 }
40
44 {
46 Cookie cookies[];
47
48 cookies = requete.getCookies(); // get des cookies du client.
49
52
Figure 19.9 Démonstration de l’utilisation des cookies. (1 de 2)

54 sortie.println( "Cookies: le retour" );
56
57 if ( (cookies != null) && (cookies.length != 0) ) {
58 sortie.println( "<H1>Recommandations</H1>" );
59
60 // get du nom de chaque cookie.
61 for ( int i = 0; i < cookies.length; i++ )
62 sortie.println(
63 cookies[ i ].getName() + " How To Program. " +
64 "ISBN#: " + cookies[ i ].getValue() + "<BR>" );
65 }
66 else {
67 sortie.println( "<H1>Aucune recommandation</H1>" );
68 sortie.println( "Soit vous n’avez pas sélectionné de langage,"
);
69 sortie.println( "soit les cookies ont expiré." );
70 }
71
73 sortie.close(); // clôturer le flux.
74 }
75
76 private String getISBN( String lang )
77 {
78 for ( int i = 0; i < noms.length; ++i )
79 if ( lang.equals( noms[ i ] ) )
80 return isbn[ i ];
81
82 return ""; // aucune chaîne correspondante trouvée.
83 }
84 }
Figure 19.9 Démonstration de l’utilisation des cookies. (2 de 2)
Le premier argument de ce constructeur spécifie le nom du cookie (le langage) et le second
argument spécifie la valeur du cookie. Le nom du cookie identifie le cookie et la valeur du cookie
est l’information associée au cookie. Comme valeur de Cookie dans cet exemple, nous utilisons le
numéro ISBN d’un livre que nous recommandons à l’utilisateur lorsque le servlet reçoit une requête
GET. Notez que l’utilisateur d’un navigateur peut désactiver les cookies, de sorte que cet exemple
risque de ne pas fonctionner correctement sur l’ordinateur de certains utilisateurs, et aucune erreur
n’est signalée si les cookies sont désactivées. Un minimum de 20 cookies par site Web et un
maximum de 300 cookies par utilisateur sont autorisés par les navigateurs qui acceptent les cookies.
Les navigateurs peuvent limiter la taille des cookies à 4K, soit 4 096 octets. Les cookies ne sont
utilisables que par le serveur qui les a créés.
La ligne 22,
c.setMaxAge( 120 ); // retrait du cookie après 120 secondes.
définit l’âge maximum du cookie. Dans cet exemple, le cookie existe pendant 120 secondes, soit
2 minutes. L’argument de setMaxAge est une valeur entière. Cette méthode permet de définir
l’âge maximum d’un cookie jusque 2 147 483 647, soit approximativement 24 855 jours. Nous
réduisons l’âge maximum du Cookie dans cet exemple pour mettre en évidence le fait que les
cookies sont automatiquement supprimés lorsque leur délai expire.

Par défaut, les cookies n’existent que dans la session de navigation courante, c’est-à-dire jusqu’à ce
que l’utilisateur quitte son navigateur. Pour conserver les cookies au-delà de la session en cours,
appelez la méthode setMaxAge de Cookie pour imposer le nombre de secondes au-delà desquelles
le cookie expire. 19.3
La ligne 23,
reponse.addCookie( c ); // doit précéder getWriter.
ajoute le cookie à la réponse du client. L’envoi des cookies s’effectue par le biais de l’en-tête HTTP,
qui contient des informations telles qu’une requête, l’état de la requête, etc. Les informations d’en-
tête sont toujours fournies en premier lieu au client, de sorte que les cookies doivent s’ajouter à la
reponse avec addCookie avant toute autre information.
Appelez la méthode addCookie pour ajouter un cookie à la HTTPServletResponse avant
d’écrire toute autre information destinée au client. 19.4
Après l’ajout du cookie, le servlet envoie un document HTML au client (voir la seconde copie
d’écran de la figure 19.10).
La méthode doGet de la ligne 41 est invoquée en réponse à la requête GET en provenance du
document HTML de la figure 19.11. La méthode lit tout Cookie écrit au client par doPost. Pour
chaque Cookie écrit, le servlet recommande un livre de Deitel sur le sujet. La page Web créée par
le servlet peut afficher un maximum de quatre livres.
La ligne 48,
cookies = requete.getCookies(); // get des cookies du client.
retrouve les cookies en provenance du client à l’aide de la méthode getCookies de
HttpServletRequest, qui renvoie un tableau de Cookie. Lorsqu’une opération GET ou
POST est effectuée pour invoquer le servlet, les cookies associés à ce serveur sont automatiquement
envoyés au servlet.
Si la méthode getCookies ne renvoie pas null, cette dernière valeur indiquant l’absence de
cookie, la structure for de la ligne 61 récupère le nom de chaque Cookie grâce à la méthode
getName de Cookie, la valeur de chaque Cookie, c’est-à-dire le numéro ISBN, grâce à la
méthode getValue de Cookie et écrit une ligne à destination du client indiquant le nom du livre
recommandé et le numéro ISBN de ce livre.
La figure 19.10 montre le document HTML que l’utilisateur charge pour sélectionner le langage
de programmation. Les lignes 7 et 8 spécifient que l’ACTION du formulaire est de POSTer des
informations au servlet CookieExemple.
1 
2 <HTML>
3 <HEAD>
4 <TITLE>Cookies</TITLE>
5 </HEAD>
Figure 19.10 Le document HTML qui appelle le servlet de cookie à l’aide d’une requête
POST et passe en argument la sélection de langue de l’utilisateur. (1 de 2)

6 <BODY>
7 <FORM ACTION="http://localhost:8080/servlet/CookieExemple"
8 METHOD="POST">
9 <STRONG>Sélectionnez un langage de programmation:<br>
10 </STRONG><BR>
11 <PRE>
12 <INPUT TYPE="radio" NAME="lang" VALUE="C">C<BR>
13 <INPUT TYPE="radio" NAME="lang" VALUE="C++">C++<BR>
14 <INPUT TYPE="radio" NAME="lang" VALUE="Java"
15 CHECKED>Java<BR>
16 <INPUT TYPE="radio" NAME="lang"
17 VALUE="Visual Basic 6">Visual Basic 6
18 </PRE>
19 <INPUT TYPE="submit" VALUE="Soumettre">
20 <INPUT TYPE="reset" VALUE="Réinitialiser"> </P>
21 </FORM>
22 </BODY>
23 </HTML>
Figure 19.10 Le document HTML qui appelle le servlet de cookie à l’aide d’une requête
POST et passe en argument la sélection de langue de l’utilisateur. (2 de 2)

Le document HTML de la figure 19.11 invoque le servlet en réponse à la pression sur un bouton.
Les lignes 7 et 8 spécifient que l’ACTION du formulaire consiste à obtenir (GET) des informations
en provenance du servlet CookieExemple. Puisque nous avons imposé 2 minutes pour l’âge
maximum du cookie, vous devez charger ce document HTML et appuyer sur Conseils de lecture
dans les 2 minutes de votre interaction avec le servlet, à partir du document HTML de la
figure 19.10. Sinon, le cookie expire avant que vous ayez reçu le conseil de lecture. Normalement,
la durée de vie d’un cookie est mise à une valeur plus élevée. Nous avons volontairement imposé
une valeur faible pour vous montrer que les cookies sont effectivement supprimés automatiquement
lorsqu’ils expirent. Après avoir obtenu votre proposition de lecture, attendez 2 minutes pour être
certain que le cookie expire. Ensuite, revenez au document HTML de la figure 19.11 et appuyez une
nouvelle fois sur Conseils de lecture. La troisième copie d’écran de la figure 19.11 montre le
document HTML retourné quand aucun cookie ne fait plus partie de la requête en provenance du
client. Remarque: tous les navigateurs Web n’adhèrent pas nécessairement au principe de la date
d’expiration d’un cookie.
1 
2 <HTML>
3 <HEAD>
4 <TITLE>Cookies</TITLE>
5 </HEAD>
6 <BODY>
7 <FORM ACTION="http://localhost:8080/servlet/CookieExemple"
8 METHOD="GET">
9 Cliquez sur "Conseils de lecture" pour une liste de livres.
10 <INPUT TYPE=submit VALUE="Conseils de lecture">
11 </FORM>
12 </BODY>
13 </HTML>
Figure 19.11 Le document HTML nécessaire pour qu’un servlet lise les cookies d’un client.
(1 de 2)

Figure 19.11 Le document HTML nécessaire pour qu’un servlet lise les cookies d’un client.
(2 de 2)
Vous disposez de diverses méthodes de Cookie pour manipuler les membres d’un Cookie.
La figure 19.12 en décrit quelques-unes.
getComment() Renvoie une String qui décrit le but du cookie (ou null si aucun
commentaire n’a été défini par setComment).
getDomain() Renvoie une String qui contient le domaine du cookie. Celui-ci
détermine les serveurs qui peuvent recevoir le cookie. Par défaut,
les cookies sont envoyés au serveur qui a envoyé le cookie au client.
getMaxAge() Retourne un int qui représente l’âge maximum du cookie en secondes.
getName() Retourne une String contenant le nom du cookie tel qu’il a été défini
par le constructeur.
getPath() Retourne une String contenant le préfixe d’URL du cookie. Les cookies
peuvent cibler des URL spécifiques qui incluent des répertoires du serveur
Web. Par défaut, un cookie est renvoyé à des services opérant dans le même
répertoire que celui du service qui a envoyé le cookie ou un sous-répertoire
de ce répertoire.
getSecure() Renvoie une valeur boolean qui indique si le cookie doit être transmis
par le biais d’un protocole sécurisé (true).
getValue() Retourne une String contenant la valeur du cookie telle qu’elle a été
définie par setValue ou par le constructeur.
getVersion() Retourne un int qui contient la version du protocole de cookie utilisé
pour le créer. Les cookies sont en cours de normalisation en ce moment.
Une valeur 0, prédéfinie, indique le protocole de cookie original, tel qu’il
a été défini par Netscape. La valeur 1 désigne la version en cours de
normalisation.
Figure 19.12 Les méthodes importantes de la classe Cookie. (1 de 2)

19.6.2 Suivi de session avec HttpSession
Une approche alternative à celle des cookies consiste à exploiter les interfaces et les classes du
package javax.servlet.http du JSDK pour suivre une session. Pour la démonstration des
techniques de base du suivi de session, nous avons modifié le servlet de la figure 19.9 qui présentait
les cookies, pour utiliser cette fois des objets qui implémentent l’interface HttpSession
(figure 19.13). Cette fois aussi, le servlet gère les requêtes GET et POST. Le document HTML de la
figure 19.14 contient quatre boutons radios, soit C, C++, Java et Visual Basic 6, ainsi que deux
boutons Soumettre et Réinitialiser. Quand l’utilisateur appuie sur Soumettre, le servlet
(figure 19.13) est invoqué avec une requête POST. Le servlet répond en créant une session liée à ce
client (ou en utilisant une session déjà existante liée au client), il ajoute le langage de programmation
sélectionné et le numéro ISBN de la lecture conseillée à l’objet HttpSession, puis il envoie une
page HTML au client. À chaque clic de l’utilisateur sur Soumettre, un nouveau couple
langage/ISBN est ajouté à l’objet HttpSession. Si le langage avait déjà été ajouté à l’objet
HttpSession, il est tout simplement remplacé par le nouveau couple de valeurs. Le document
HTML de la figure 19.15 présente à l’utilisateur un bouton qui lui permet d’obtenir une
recommandation de lecture en fonction de sa sélection de langage dans le document HTML
précédent. Lorsqu’il appuie sur le bouton Conseils de lecture, le servlet de la figure 19.13 est
appelé avec une requête GET. Le servlet répond en récupérant les noms de valeurs, c’est-à-dire les
langages, dans l’objet HttpSession et en créant un document HTML qui recommande un livre
pour chaque langage sélectionné par l’utilisateur dans le document HTML de la figure 19.14.
L’analyse du servlet précède celle des deux documents HTML.
setComment( String ) Le commentaire décrivant le but du cookie, présenté par le navigateur
à son utilisateur (certains navigateurs permettent à l’utilisateur d’accepter
les cookies un par un).
setDomain( String ) Détermine les serveurs qui peuvent recevoir le cookie. Par défaut, les
cookies sont envoyés au seul serveur qui a envoyé le cookie au client, à
l’origine. Le domaine est spécifié dans la forme ".goulet.ca", ce qui
indique que tous les serveurs dont le nom de domaine se termine par
.goulet.ca peuvent recevoir le cookie.
setMaxAge( int ) Définit l’âge maximum du cookie au nombre de secondes imposé.
setPath( String ) Définit l’URL cible, soit les répertoires du serveur conduisant aux services
qui peuvent recevoir ce cookie.
setSecure( boolean ) La valeur true indique que le cookie doit être envoyé par l’entremise
d’un protocole sécurisé.
setValue( String ) Définit la valeur d’un cookie.
setVersion( int ) Définit le protocole de cookie pour ce cookie.

1 // Figure 19.13: ExempleSession.java
2 // Utilisation des sessions.
5 import java.io.*;
6
7 public class ExempleSession extends HttpServlet {
8 private final static String noms[] =
9 { "C", "C++", "Java", "Visual Basic 6" };
10 private final static String isbn[] = {
11 "0-13-226119-7", "0-13-528910-6",
12 "0-13-012507-5", "0-13-528910-6" };
13
17 {
19 String langage = requete.getParameter( "lang" );
20
21 // Get de l’objet session de l’utilisateur.
22 // Créer une session (true) s’il n’en existe pas encore.
23 HttpSession session = requete.getSession( true );
24
25 // ajouter une valeur pour le choix utilisateur à la session.
26 session.putValue( langage, getISBN( langage ) );
27
30
31 // envoi de la page HTML au client.
33 sortie.println( "Sessions" );
35 sortie.println( "<P>Bienvenue dans le monde des sessions!<BR>" );
36 sortie.println( "<P>" );
37 sortie.println( langage );
38 sortie.println( " est un langage réputé." );
40
41 sortie.close(); // clôture du flux.
42 }
43
47 {
49
50 // Get de l’objet session de l’utilisateur.
51 // Ne pas créer de session (false) si elle n’existe pas.
52 HttpSession session = requete.getSession( false );
53
Figure 19.13 Exemple de suivi de session. (1 de 2)

54 // get des noms de valeurs de l’objet session.
55 String nomsValeurs[];
56
57 if ( session != null )
58 nomsValeurs = session.getValueNames();
59 else
60 nomsValeurs = null;
61
64
66 sortie.println( "Sessions II" );
68
69 if ( nomsValeurs != null && nomsValeurs.length != 0 ) {
70 sortie.println( "<H1>Recommandations</H1>" );
71
72 // get valeur de chaque nom dans nomsValeurs.
73 for ( int i = 0; i < nomsValeurs.length; i++ ) {
74 String valeur =
75 (String) session.getValue( nomsValeurs[ i ] );
76
77 sortie.println(
78 nomsValeurs[ i ] + " How to Program. " +
79 "ISBN#: " + valeur + "<BR>" );
80 }
81 }
82 else {
83 sortie.println( "<H1>Aucune recommandation</H1>" );
84 sortie.println( "Soit vous n’avez pas sélectionné de langage,"
);
85 sortie.println( "soit la session a expiré." );
86 }
87
89 sortie.close(); // clôture du flux.
90 }
91
92 private String getISBN( String lang )
93 {
94 for ( int i = 0; i < noms.length; ++i )
95 if ( lang.equals( noms[ i ] ) )
96 return isbn[ i ];
97
98 return ""; // aucune chaîne correspondante trouvée.
99 }
100 }
Figure 19.13 Exemple de suivi de session. (2 de 2)
Les lignes 8 et 10 déclarent les tableaux de String qui stockent respectivement le nom des
langages de programmation et les numéros ISBN des livres que nous recommanderons. La méthode
doPost (ligne 14) est appelée en réponse à la requête POST du document HTML de la figure 19.14.

La ligne 19 récupère la sélection de langage de l’utilisateur (la valeur du bouton radio coché sur
la page Web) par l’entremise de la méthode getParameter.
La ligne 23,
HttpSession session = requete.getSession( true );
obtient l’objet HttpSession pour le client grâce à la méthode getSession de
HttpServletRequest. Si le client avait déjà un objet HttpSession du fait d’une requête
précédente au cours de sa session de navigation, la méthode getSession renvoie cet objet
HttpSession. Sinon, l’argument true indique que le servlet doit créer un objet HttpSession
unique pour le client (un argument false provoquerait de la part de la méthode getSession le
renvoi de null si l’objet HttpSession de ce client n’existait pas encore).
La ligne 26,
session.putValue( langage, getISBN( langage ) );
place le langage et le numéro ISBN du livre recommandé dans l’objet HttpSession.
Les couples de valeurs de noms ajoutés à l’objet HttpSession avec putValue demeurent
disponibles jusqu’à la fin de la session de navigation de l’utilisateur, ou jusqu’à ce que la session soit
explicitement déclarée comme non valable par un appel à la méthode invalidate de l’objet
HttpSession. 19.5
Après l’ajout des valeurs à l’objet HttpSession, le servlet envoie un document HTML au
client, comme le montre la deuxième copie d’écran de la figure 19.14.
Un appel à la méthode doGet de la ligne 44 répond à la requête GET en provenance du
document HTML de la figure 19.15. La méthode récupère l’objet HttpSession du client, lit les
données qui y sont stockées et, pour chaque valeur stockée dans la session, recommande une lecture
sur le sujet. La page Web créée par le servlet affiche au maximum quatre livres.
La ligne 52,
HttpSession session = requete.getSession( false );
récupère l’objet HttpSession du client à l’aide de la méthode getSession de HttpServlet
Request.Si aucun objet HttpSession n’existe pour le client, l’argument false indique que le
servlet ne peut en créer une.
Si la méthode getSession ne renvoie pas null, c’est-à-dire qu’aucun objet HttpSession
n’existe pour ce client, la ligne 58,
nomsValeurs = session.getValueNames();
demande à la méthode getValueNames de HttpSession de récupérer les noms des valeurs,
soit les noms utilisés en premier argument de la méthode putValue de HttpSession, et
d’affecter le tableau de String à nomsValeurs. Chaque nom sert à récupérer l’ISBN d’un livre
au départ de l’objet HttpSession. La structure for des lignes 73 à 80 exploite l’instruction
String valeur =
(String) session.getValue( nomsValeurs[ i ] );
pour récupérer la valeur associée à chaque nom de nomsValeurs. La méthode getValue reçoit
le nom et renvoie une référence à un Object correspondant à la valeur. L’opérateur de
remplacement de type permet au programme d’utiliser la référence renvoyée comme une référence
à une String. Ensuite, une ligne est écrite dans la réponse au client, contenant le titre du livre
recommandé et son numéro ISBN.

La figure 19.14 montre le document HTML que l’utilisateur charge ne vue d’opérer sa sélection
de langage. Les lignes 7 et 8 spécifient que l’ACTION du formulaire consiste à POSTer des
informations au servlet SessionExemple.
1 
2 <HTML>
3 <HEAD>
4 <TITLE>Sessions</TITLE>
5 </HEAD>
6 <BODY>
7 <FORM ACTION="http://localhost:8080/servlet/ExempleSession"
8 METHOD="POST">
9 <STRONG>Choisissez un langage de programmation:<br>
10 </STRONG><BR>
11 <PRE>
12 <INPUT TYPE="radio" NAME="lang" VALUE="C">C<BR>
13 <INPUT TYPE="radio" NAME="lang" VALUE="C++">C++<BR>
14 <INPUT TYPE="radio" NAME="lang" VALUE="Java"
15 CHECKED>Java<BR>
16 <INPUT TYPE="radio" NAME="lang"
17 VALUE="Visual Basic 6">Visual Basic 6
18 </PRE>
19 <INPUT TYPE="submit" VALUE="Soumettre">
20 <INPUT TYPE="reset" VALUE="Réinitialiser"> </P>
21 </FORM>
22 </BODY>
23 </HTML>
Figure 19.14 Le document HTML qui appelle le servlet de suivi de session dans
une requête POST et transmet en argument la langue sélectionnée
par l’utilisateur. (1 de 2)

Figure 19.14 Le document HTML qui appelle le servlet de suivi de session dans
une requête POST et transmet en argument la langue sélectionnée
par l’utilisateur. (2 de 2).
Le document HTML de la figure 19.15 invoque le servlet en réponse à la pression d’un bouton.
Les lignes 7 et 8 spécifient que l’ACTION du formulaire consiste à obtenir (GET) des informations
en provenance du servlet ExempleSession. La troisième copie d’écran de la figure 19.15 montre
le document HTML retourné quand il n’y a pas d’objet HttpSession pour ce client ou quand il
n’y a aucune valeur ajoutée à l’objet HttpSession.
1 
2 <HTML>
3 <HEAD>
4 <TITLE>Sessions</TITLE>
5 </HEAD>
6 <BODY>
7 <FORM ACTION="http://localhost:8080/servlet/ExempleSession"
8 METHOD="GET">
9 Cliquez sur "Conseils de lecture" pour une liste de livres.
10 <INPUT TYPE=submit VALUE="Conseils de lecture">
11 </FORM>
12 </BODY>
13 </HTML>
Figure 19.15 La page HTML qui interagit avec le servlet de suivi de session pour lire les
informations de session et retourner les conseils de lecture à l’utilisateur. (1 de 2)

Figure 19.15 La page HTML qui interagit avec le servlet de suivi de session pour lire les
informations de session et retourner les conseils de lecture à l’utilisateur. (2 de 2)
19.7 Applications multitiers: utiliser le JDBC à partir d’un servlet
Les servlets sont en mesure de communiquer avec des bases de données via la Connectivité de Java
à des bases de données, ou JDBC (Java Database Connectivity). Comme l’indique le chapitre 18, le
JDBC met à disposition une manière uniforme de connecter un programme Java à toute une série de
bases de données, sans pour autant devoir s’adapter aux spécificités de ces différents systèmes de
bases de données.
De nombreuses applications actuelles sont des applications réparties tri-partites, qui consistent
en une interface utilisateur, une logique commerciale et un accès à une base de données. L’interface
utilisateur dans une telle application est souvent basée sur le HTML, comme dans les exemples de
ce chapitre, ou sur le HTML dynamique. Dans certains cas, les applets Java interviennent dans cette
tranche. Le HTML est le mécanisme préféré de représentation de l’interface utilisateur lorsque les
impératifs de portabilité priment. Du fait que le HTML est accepté par tous les navigateurs, la
conception d’une interface utilisateur accessible par le biais de tout navigateur Web représente une
garantie de portabilité de l’application parmi toutes les plates-formes qui disposent de navigateurs.
Grâce aux fonctionnalités de réseau garanties par le navigateur, l’interface utilisateur peut
communiquer avec la logique commerciale intermédiaire. La partie intermédiaire peut ensuite
accéder à la base de données pour accéder aux données et les manipuler. Les trois parties peuvent
résider sur des ordinateurs distincts, connectés à un réseau.
Dans les architectures tri-partites, l’utilisation des serveurs Web prend une importance
grandissante dans la partie intermédiaire. Ils assurent la logique commerciale qui manipule les
données des bases de données et communiquent avec les navigateurs Web des clients. Les servlets,
grâce au JDBC, peuvent agir sur les systèmes de bases de données les plus appréciés. Les
développeurs ne doivent plus se familiariser avec ces différents, tellement différents, systèmes de

gestion de bases de données puisque quelques requêtes SQL, associées à un pilote JDBC adéquat,
permettent de gérer les spécificités de chaque système de gestion de bases de données.
Les figures 19.16 et 19.17 proposent une démonstration d’une application répartie tri-partite qui
affiche son interface utilisateur en HTML dans un navigateur. La partie intermédiaire est le servlet Java
qui gère les requêtes en provenance du navigateur du client et prend en charge l’accès à la troisième
partie: une base de données Access de Microsoft, définie comme une source de données ODBC et
accessible via le JDBC. Le servlet dans cet exemple est un livre d’or, permettant à un utilisateur de
s’inscrire à plusieurs listes de messagerie. Lorsque le servlet reçoit une requête POST du document
HTML de la figure 19.17, il vérifie que les champs de données adéquats sont bien présents, puis il
stocke les données dans la base de données et envoie une page de confirmation au client.
1 // Figure 19.16: ServletLivreDOr.java
2 // Exemple d’application tri-partite.
3 import java.io.*;
6 import java.util.*;
7 import java.sql.*;
8
9 public class ServletLivreDOr extends HttpServlet {
10 private Statement instruction = null;
11 private Connection connexion = null;
12 private String URL = "jdbc:odbc:LivreDOr";
13
14 public void init( ServletConfig config )
15 throws ServletException
16 {
17 super.init( config );
18
19 try {
20 Class.forName( "sun.jdbc.odbc.JdbcOdbcDriver" );
21 connexion =
22 DriverManager.getConnection( URL, "", "" );
23 }
24 catch ( Exception e ) {
25 e.printStackTrace();
26 connexion = null;
27 }
28 }
29
30 public void doPost( HttpServletRequest req,
31 HttpServletResponse res )
33 {
34 String courriel, prenom, nomFamille, societe,
35 listeMsgGallinace, listeCpp, listeJava, listeVB,
36 listeIwww;
37
38 courriel = req.getParameter( "Courriel" );
39 prenom = req.getParameter( "Prenom" );
40 nomFamille = req.getParameter( "NomFam" );
Figure 19.16 Le servlet ServletLivreDOr, qui permet à des clients de s’inscrire
dans des listes de messagerie. (1 de 3).

41 societe = req.getParameter( "Societe" );
42 listeMsgGallinace = req.getParameter( "messagerie" );
43 listeCpp = req.getParameter( "c_cpp" );
44 listeJava = req.getParameter( "java" );
45 listeVB = req.getParameter( "vb" );
46 listeIwww = req.getParameter( "iwww" );
47
48 PrintWriter sortie = res.getWriter();
49 res.setContentType( "text/html" );
50
51 if ( courriel.equals( "" ) ||
52 prenom.equals( "" ) ||
53 nomFamille.equals( "" ) ) {
54 sortie.println( "<H3> Veuillez cliquer sur le bouton " +
55 "Précédente et remplir tous " +
56 "les champs.</H3>" );
57 sortie.close();
58 return;
59 }
60
61 /* Note: la base de données LivreDOr contient en fait les
62 * champs Adresse1, Adresse2, Ville, Etat et CP, inutilisés
63 * dans cet exemple. Toutefois, l’insertion dans la base de
64 * données doit conserver des champs. */
65 boolean succes = insererDansBD(
66 "'" + courriel + "','" + prenom + "','" + nomFamille +
67 "','" + societe + "',' ',' ',' ',' ',' ','" +
68 ( listeMsgGallinace != null ? "oui" : "non" ) + "','" +
69 ( listeCpp != null ? "oui" : "non" ) + "','" +
70 ( listeJava != null ? "oui" : "non" ) + "','" +
71 ( listeVB != null ? "oui" : "non" ) + "','" +
72 ( listeIwww != null ? "oui" : "non" ) + "'" );
73
74 if ( succes )
75 sortie.print( "<H2>Merci " + prenom +
76 " pour votre inscription.</H2>" );
77 else
78 sortie.print( "<H2>Une erreur s’est produite. " +
79 "Veuillez réessayer plus tard.</H2>" );
80
81 sortie.close();
82 }
83
84 private boolean insererDansBD( String chaineAInserer )
85 {
86 try {
87 instruction = connexion.createStatement();
88 instruction.execute(
89 "INSERT INTO LivreDOr VALUES (" +
90 chaineAInserer + ");" );
91 instruction.close();
92 }
dans des listes de messagerie. (2 de 3)

93 catch ( Exception e ) {
94 System.err.println(
95 "ERREUR: problème à l’ajout d’une entrée" );
96 e.printStackTrace();
97 return false;
98 }
99
100 return true;
101 }
102
103 public void destroy()
104 {
105 try {
106 connexion.close();
107 }
108 catch( Exception e ) {
109 System.err.println( "Problème à la fermeture de" +
110 " la base de données" );
111 }
112 }
113 }
dans des listes de messagerie. (3 de 3)
La classe ServletLivreDOr étend la classe HttpServlet (ligne 9), de sorte qu’elle est
capable de répondre à des requêtes GET et POST. Les servlets s’initialisent par surcharge de la
méthode init (ligne 14). La méthode init est appelée exactement une fois dans la vie du servlet
et est certaine de s’achever avant l’acceptation de la moindre requête. La méthode init prend un
argument ServletConfig et lève une ServletException. L’argument fournit au servlet des
informations relatives à ses paramètres d’initialisation, c’est-à-dire aux paramètres qui ne sont pas
associés à une requête, mais passées au servlet en vue de l’initialisation des variables du servlet. Ces
paramètres peuvent provenir d’un fichier appelé en principe servlets.properties, qui réside
dans le sous-répertoire webpagesWEB-INF du répertoire d’installation du JSDK (d’autres
serveurs Web nomment sans doute ce fichier autrement et il se peut qu’ils le stockent ailleurs, dans
un répertoire qui leur est spécifique). Les propriétés les plus usuelles sont habituellement reprises
par nomservlet.code et nomservlet.initparams, où nomservlet est le nom quelconque que
vous donnez à votre servlet. Ce nom sera utilisé lors de l’appel du servlet au départ d’une page Web.
Un échantillon de fichier servlets.properties est fourni avec le JSDK, dans le sous-
répertoire webpagesWEB-INF du répertoire d’installation du JSDK.
Dans l’exemple de cette section-ci, la méthode init du servlet effectue la connexion à la base
de données Microsoft Access. La méthode charge le JdbcOdbcDriver à la ligne 20 par:
Class.forName( "sun.jdbc.odbc.JdbcOdbcDriver" );
Les lignes 21 et 22 tentent d’ouvrir une connexion à la base de données LivreDOr. Quand le
servlet appelle la méthode insererDansBD (ligne 84), les lignes 87 à 91,
instruction = connexion.createStatement();
instruction.execute(
"INSERT INTO LivreDOr VALUES (" +
chaineAInserer + ");" );
instruction.close();

créent une instruction pour effectuer l’insertion suivante dans la base de données, appellent
instruction.execute pour exécuter l’instruction INSERT INTO (chaineAInserer est
la String transmise à insererDansBD) et clôturent l’instruction pour garantir que
l’opération d’insertion soit bel et bien clôturée sur la base de données.
Quand une requête POST est reçue en provenance du document HTML de la figure 19.17, la
méthode doPost de la ligne 30 répond en lisant les valeurs des champs du formulaire HTML dans
la requête POST, tout en mettant les valeurs des champs en forme de String pur leur utilisation
dans une opération INSERT INTO sur la base de données et en envoyant la String à la méthode
insererDansBD de la ligne 84 pour effectuer l’opération d’insertion. La valeur de chaque champ
du formulaire est récupérée aux lignes 38 à 46.
La structure if des lignes 51 à 59 détermine si l’adresse de courriel, le prénom, ou le nom de
famille sont des chaînes vides. Si c’est le cas, la réponse du servlet consiste à demander à l’utilisateur
de revenir au formulaire précédent et à compléter ces champs.
Les lignes 65 à 72 formulent l’appel à insererDansBD. La méthode retourne une valeur
boolean qui indique si l’insertion dans la base de données s’est déroulée avec succès.
Les lignes 103 et suivantes définissent la méthode destroy pour garantir que la connexion à
la base de données est bien fermée avant la fin du servlet.
La figure 19.17 définit le document HTML qui présente le formulaire du livre d’or à l’utilisateur
et poste les informations au servlet de la figure 19.16.
1 
2 <HTML>
3 <HEAD>
4 <TITLE>Formulaire Livre d’Or des Éditions Goulet</TITLE>
5 </HEAD>
6
7 <BODY>
8 <H1>Livre d’Or</H1>
9 <FORM
10 ACTION="http://localhost:8080/servlet/ServletLivreDOr"
11 METHOD="POST"><PRE>
12 * Adresse de courriel: <INPUT TYPE=text NAME=Courriel>
13 * Prénom: <INPUT TYPE=text NAME=Prenom>
14 * Nom: <INPUT TYPE=text NAME=NomFam>
15 Société: <INPUT TYPE=text NAME=Societe>
16
17 Les champs marqués * sont obligatoires.
18 </PRE>
19
20 <P>Sélectionnez les listes dont vous souhaitez
21 recevoir des informations.<BR>
22 <INPUT TYPE=CHECKBOX NAME=mail VALUE=messagerie>
23 Courriel des Gallinacées<BR>
24 <INPUT TYPE=CHECKBOX NAME=c_cpp VALUE=c_cpp>
25 <I>Comment programmer en C++ & La Bible du Programmeur
26 en C/C++ </I><BR>
27 <INPUT TYPE=CHECKBOX NAME=java VALUE=java>
28 <I>Comment programmer en Java</I><BR>
29 <INPUT TYPE=CHECKBOX NAME=vb VALUE=vb>
30 <I>Programmation avec Visual Basic 6.0</I><BR>
Figure 19.17 La page HTML qui appelle le ServletLivreDOr. (1 de 2)

31 <INPUT TYPE=CHECKBOX NAME=iwww VALUE=iwww>
32 <I>Créer des sites Web spectaculaires</I><BR>
33 </P>
34 <INPUT TYPE=SUBMIT Value="Soumettre">
35 </FORM>
36 </BODY>
37 </HTML>
Figure 19.17 La page HTML qui appelle le ServletLivreDOr. (2 de 2)
Les lignes 9 à 11 spécifient que l’ACTION est de POSTer les informations au
ServletLivreDOr. Les copies d’écran montrent le fomulaire rempli d’un jeu d’informations
(le premier écran), et la page Web de confirmation renvoyée au client en réponse à la requête POST.

19.8 Commerce électronique
Une véritable révolution est en train de se produire dans le domaine du commerce électronique. Au
moment où la version américaine de ce livre a été mise en production, près d’un tiers du stock a été
vendu sur l’Internet à des particuliers. Des sociétés telles que amazon.com, barnesandnoble.com et
borders.com gèrent des volumes considérables de ventes électroniques. La technologie des servlets
permettra à de plus nombreuses organismes d’être présents sur le marché du commerce électronique.
Une véritable explosion est également en cours dans ce que l’on nomme les transactions
d’affaires entre sociétés, ou business-to-business, pour emprunter le terme anglais. Alors que les
transmissions par l’Internet deviennent plus sécurisées, de plus en plus de sociétés confient des
parties de plus en plus importantes de leurs activités commerciales à l’Internet.
Les sociétés perçoivent qu’il leur est possible de proposer à leur clients toutes sortes de services
à valeur ajoutée. Les gens n’hésitent plus aujourd’hui à contacter directement les sociétés par
l’Internet et à leur présenter leurs propres informations, plutôt que de les contacter verbalement par
téléphone.
Deux applications que de nombreuses sociétés ont placées sur le Web, sont devenues monnaie
courante: ce sont les suivis d’expédition d’une part et de factures d’autre part. Les gens veulent savoir
où sont les produits qu’ils ont commandés. Les vendeurs veulent savoir quand ils seront payés.
Les petites sociétés montent une certaine excitation à l’idée des potentialités du commerce
électronique. En édifiant un site Web d’une qualité respectable, elles ont la possibilité de se présenter
elles-mêmes au monde entier et d’apporter un véritable effet de cliquet à leurs activités commerciales.
Dans le cadre des systèmes en client-serveur, nombre de développeurs préfèrent une solution
totalement en Java, avec des applets chez les clients et des servlets sur les serveurs.
19.9 Ressources Internet et du Web sur les servlets
Cette section reprend toute une séries de ressources liées aux servlets, disponibles sur l’Internet et
les décrivent en bref. L’annexe B, Ressources Java, liste d’autres sites d’informations disponibles
sur l’Internet et relatifs à Java.
Toutes ces ressources, sauf mention explicite, sont en langue anglaise.
http://java.sun.com/products/servlet/index.html
La page consacrée aux servlets sur le site Web de Sun Microsystems, Inc. Java fournit un accès aux
dernières informations sur ce sujet, des ressources consacrées aux servlets et le Kit de développement de
servlets ou JSDK (Java Servlet Development Kit).
http://www.servlets.com
C’est là le site Web du livre Java Servlet Programming édité par O’Reilly. Ce livre, dont la version
française s’intitule Servlets Java, Guide du programmeur (adresse http://www.editions-
oreilly.fr/java.html), propose diverses ressources. Le livre lui-même est une excellente source
d’informations pour les programmeurs qui étudient les servlets.
http://www.servletcentral.com
Servlet Central est un magazine en ligne pour les programmeurs Java du côté des serveurs. Il comprend
des articles techniques, des encarts, des nouvelles et la possibilité d’interroger des spécialistes («Ask the
Experts»). Les ressources citées comptent des livres, des liens à de la documentation sur les servlets
disponible sur le Web, un archivage consacré aux servlets, une liste d’applications et de serveurs
compatibles avec les servlets, et des outils de développement de servlets.
http://www.servletsource.com
ServletSource.com est un site généraliste de ressources consacrées aux servlets, contenant du code, des astuces,
des tutoriels et des liens vers de très nombreux sites Web comportant des informations sur les servlets.
http://www.cookiecentral.com
Un bon site de ressources consacré aux cookies.

Résumé
• Souvent, la mise en réseau consiste en une relation client-serveur. Le client pose la requête qu’une action
quelconque soit effectuée, le serveur exécute cette action et répond au client.
• Une utilisation courante du modèle requête-réponse s’établit entre les navigateurs Web et les serveurs Web.
Lorsqu’un utilisateur sélectionne un site Web qu’il souhaite visiter avec son navigateur Web (l’application
client), une requête est envoyée au serveur Web approprié (l’application serveur), qui répond normalement
au client en lui envoyant une page Web adéquate en HTML.
• Un servlet étend les fonctionnalités d’un serveur. La plupart des servlets étendent les fonctionnalités des
serveurs Web.
• L’Internet offre de nombreux protocoles, le plus usuel est le protocole HTTP (HyperText Transfer Protocol)
qui forme la fondation du Web.
• Tous les servlets implémentent l’interface Servlet.
• Comme c’est le cas de toutes les méthodes clés des applets, les méthodes de l’interface Servlet sont
appelées automatiquement (par le serveur sur lequel le servlet est installé).
• La méthode init de Servlet prend un argument ServletConfig et lève une ServletException.
L’argument ServletConfig fournit au servlet des informations concernant ses paramètres d’initialisa-
tion, c’est-à-dire des paramètres dissociés de toute requête, et passés au servlet pour qu’il initialise ses
propres variables de servlet.
• La méthode getServletConfig de Servlet retourne une référence à un objet qui implémente
l’interface ServletConfig. Cet objet fournit un accès aux informations de conﬁguration du servlet, telles
que ses paramètres d’initialisation et le ServletContext du servlet.
• Les packages de servlet définissent deux classes abstraites qui implémentent l’interface Servlet:
GenericServlet et HttpServlet. Ces classes fournissent les implémentations prédéfinies de toutes
les méthodes de l’interface Servlet. La plupart des servlets étendent une de ces classes et surchargent
quelques-unes de leurs méthodes avec les comportements adaptés et appropriés.
• La méthode clé dans tout servlet est la méthode service, qui reçoit un objet ServletRequest et un
objet ServletResponse. Ces objets donnent respectivement l’accès aux flux d’entrée et de sortie qui
permettent au servlet de lire des données en provenance du client et d’envoyer des données au client.
• Les servlets destinés au Web étendent en principe la classe HttpServlet. La classe HttpServlet
surcharge la méthode service pour opérer une distinction entre les requêtes types reçues de la part d’un
navigateur Web client.
• Les deux types de requêtes usuels en HTTP, que l’on nomme aussi méthodes de requête, sontGET et POST.
• La classe HttpServlet définit les méthodes doGet et doPut qui permettent de répondre
respectivement aux requêtes GET et POST en provenance d’un client. Ces méthodes sont appelées par la
méthode service de la classe HttpServlet, qui détermine d’abord le type de requête, puis appelle la
méthode appropriée.
• Les méthodes doGet et doPost reçoivent chacune en argument un objet HttpServletRequest et un
objet HttpServletResponse qui permettent d’assurer l’interaction entre le client et le serveur. L’objet
HttpServletRequest représente la requête du client et l’objet HttpServletResponse représente
la réponse du serveur.
• La méthode getParameter de l’interface ServletRequest récupère la réponse au questionnaire
POSTé par le client. La méthode renvoie une String contenant la valeur du paramètre ou un null si le
paramètre est introuvable.
• La méthode getParameterNames de l’interface ServletRequest renvoie une Enumeration de
noms sous la forme de String pour tous les paramètres POSTés par le client.
• La méthode getOutputStream de HttpServletResponse obtient un flux de sortie de type octets,
qui permet d’envoyer des données binaires au client.

• La méthode getWriter de HttpServletResponse obtient un flux de sortie de type caractères qui
permet l’envoi de données texte au client.
• La méthode setContentType de HttpServletResponse spécifie le type MIME de la réponse au
navigateur. Le type MIME permet au navigateur de déterminer comment il doit afficher les données qu’il
reçoit et, éventuellement, à quelles autres applications il doit faire appel pour afficher les données. Par
exemple, le type "text/html" indique que la réponse est un document HTML, de sorte que le navigateur
affichera la page en HTML.
• Si doGet ou doPut sont incapables de gérer la requête d’un client, elles lèvent une javax.servlet
.ServletException. Si doGet rencontre une erreur durant le traitement d’un flux (erreur de lecture
en provenance du client ou d’écriture vers le client), elle lève une java.io.IOException.
• Le client ne peut accéder à un servlet que si le servlet fonctionne sur le serveur. Le WebServer JSDK permet
de tester les servlets.
• Lorsqu’un client se connecte à un serveur pour demander un service, il doit spécifier le numéro de port
correct; sinon, la requête du client ne pourra être gérée.
• Le terme de numéro de port usuel décrit le port par défaut de nombreux services Internet. Par exemple, un
serveur Web attend que les clients déposent des requêtes au numéro de port usuel 80, et ceci par défaut.
• Le WebServer JSDK utilise le port 8080 comme numéro de port usuel.
• Un FORM en HTML permet au client de soumettre des information au serveur.
• L’attribut ACTION de FORM spécifie le gestionnaire de formulaire du côté serveur, c’est-à-dire le
programme qui gère la requête. L’ACTION est effectuée quand l’utilisateur soumet le formulaire.
• L’attribut METHOD de FORM désigne le type de requête que le serveur utilise pour décider de la manière dont
il doit gérer la requête et, éventuellement, impose au navigateur d’ajouter des arguments à la fin de l’URL
de l’ACTION.
• Le serveur localhost est un nom de serveur usuel, connu sur tous les ordinateurs qui gèrent les protocoles
de réseau fondés sur TCP/IP, tels que HTTP. Le serveur localhost fait en réalité référence à votre propre
ordinateur.
• La balise HTML INPUT crée un composant GUI pour le formulaire. Le genre du composant GUI est spécifié
dans l’attribut TYPE. Parmi les types usuels, citons les «submit» et les «radio».
• Les navigateurs placent souvent en cache (comprendre sur disque) les pages Web qu’il visitent, de manière
à charger très rapidement les pages déjà visitées. Toutefois, les navigateurs ne placent en principe pas en
cache la réponse du serveur à une requête POST parce que la requête POST suivante n’a que peu de chance
d’apporter le même résultat.
• De nombreux sites Web gardent une trace des clients individuels qui les visitent de manière à conserver des
informations spécifiques à propos de chaque utilisateur distinct. Ceci a pour but fréquent d’offrir un contenu
particulier, adapté au client, et (ou) d’obtenir des données sur les habitudes de navigation des clients.
• Deux techniques usuelles utilisées pour suivre les clients individuellement sont celles des cookies et du suivi
de session.
• Les cookies sont de tout petits fichiers envoyés par un servlet (ou toute autre technologie semblable) au sein
d’un en-tête HTTP, qui peuvent mémoriser des informations sur l’ordinateur de l’utilisateur, en vue de leur
récupération ultérieure ou de futures sessions de navigation.
• Quand le navigateur dépose une requête sur un serveur, les cookies envoyés précédemment au client par le
serveur sont renvoyés au serveur, si leur durée de validité n’a pas expiré, au sein de la requête formulée par
le navigateur. Les cookies sont automatiquement supprimés lorsqu’ils expirent, c’est-à-dire quand ils
atteignent leur âge maximal.
• La méthode setMaxAge de la classe Cookie impose l’âge maximal d’un cookie. La méthode getMaxAge
de la classe Cookie retourne l’âge maximum du cookie.
• L’utilisateur d’un navigateur peut désactiver les cookies.

• La méthode getCookies de HttpServletRequest, qui renvoie un tableau de Cookies, récupère
les cookies en provenance du client. La méthode addCookie de HttpServletResponse ajoute un
Cookie à l’en-tête de la réponse.
• La méthode getName de la classe Cookie retourne une String qui contient le nom du cookie tel qu’il
a été défini par setName ou par le constructeur.
• La méthode getValue de la classe Cookie retourne une String contenant le nom du cookie tel qu’il a
été défini par setValue ou par le constructeur.
• Le suivi de session est basé sur des objets HttpSession.
• La méthode getSession de HttpServletRequest renvoie les objets HttpSession liés au client.
La fourniture d’un booléen true comme argument à cette méthode provoque la création d’une session s’il
n’en existe pas déjà une.
• La méthode getValue de HttpSession renvoie l’objet qui était associé à un nom particulier, défini par
putValue.
• La méthode getValueNames de HttpSession renvoie une liste de noms de valeurs déjà définies.
• Les servlets peuvent communiquer avec des bases de données grâce à la Connectivité de Java à des bases de
données, ou JDBC (Java Database Connectivity).
• De nombreuses applications modernes suivent le principe de l’application répartie tri-partite, constituée
d’une interface utilisateur, d’une logique commerciale et d’un accès à une base de données. L’interface
utilisateur d’une telle application est souvent créée en HTML ou en HTML dynamique. Les applets Java
jouent également leur rôle dans cette partie du travail.
• Dans les architectures tri-partites, les serveurs Web occupent de plus en plus la niche intermédiaire. Ils
apportent en effet la logique commerciale qui manipule les données des bases de données et communiquent
avec les navigateurs Web des clients.
• Les servlets, par l’entremise de JDBC, interagissent avec les systèmes de gestion de bases de données les
plus connus. Les développeurs ne doivent plus se familiariser avec les spécificités de chaque système de
gestion de base de données, puisqu’ils peuvent se contenter d’émettre des requêtes SQL et de les soumettre
au pilote JDBC adéquat pour interagir avec chaque programme distinct de gestion de base de données.
Terminologie
applications réparties tri-partites ﬁchier servlet.properties
argument java.nomservlet.code HTML dynamique
argument java.nomservlet.initargs INPUT, type «radio»
attribut HTML ACTION INPUT, type «submit»
attribut HTML METHOD interface HttpServletRequest
attribut HTML TYPE interface HttpServletResponse
attribut HTML VALUE interface HttpSession
balises HTML <BODY> et </BODY> interface Servlet
balises HTML <FORM> et </FORM> localhost
balises HTML <HEAD> et </HEAD> logique commerciale
balise HTML INPUT méthode addCookie
balises HTML <TITLE> et </TITLE> méthode destroy de l’interface Servlet
classe Cookie méthode setSecure de la classe Cookie
classe GenericServlet méthode setValue de la classe Cookie
classe HttpServlet méthode setVersion de la classe Cookie
classe ServletConfig modèle requête-réponse
clients allégés numéro de port usuel
communications par sockets objet ServletRequest
en-tête objet ServletResponse
erreur BAD_REQUEST package javax.servlet

Observations de génie logiciel
19.1 Tous les servlets doivent implémenter l’interface javax.servlet.Servlet.
19.2 Certains clients n’acceptent pas l’écriture de cookies en leur sein. Quand un client décline l’invitation
à déposer un cookie en son sein, il est important de l’avertir de ce que ce refus peut l’empêcher de
naviguer sur le site associé, bien entendu.
19.3 Par défaut, les cookies n’existent que dans la session de navigation courante, c’est-à-dire jusqu’à ce que
l’utilisateur quitte son navigateur. Pour conserver les cookies au-delà de la session en cours, appelez la
méthode setMaxAge de Cookie pour imposer le nombre de secondes au-delà desquelles le cookie
expire.
19.4 Appelez la méthode addCookie pour ajouter un cookie à la HTTPServletResponse avant
d’écrire toute autre information destinée au client.
19.5 Les couples de valeurs de noms ajoutés à l’objet HttpSession avec putValue demeurent
disponibles jusqu’à la fin de la session de navigation de l’utilisateur, ou jusqu’à ce que la session soit
explicitement déclarée comme non valable par un appel à la méthode invalidate de l’objet
HttpSession.
Exercices de révision
19.1 Complétez chacune des propositions suivantes:
a) Les classes HttpServlet et GenericServlet implémentent l’interface .
b) La classe HttpServlet définit les méthodes et pour répondre aux
requêtes GET et POST en provenance d’un client.
c) La méthode de HttpServletResponse obtient un flux de sortie de type caractères
qui permet l’envoi de texte au client.
d) L’attribut de FORM spécifie le gestionnaire de formulaire du côté serveur, c’est-à-dire
le programme qui doit gérer la requête.
package javax.servlet.http méthode getValue de la classe Cookie
packages java.rmi méthode getValue d’interface HttpSession
packages org.omg méthode getValueNames de HttpSession
méthode doDelete de la classe HttpServlet méthode getVersion de la classe Cookie
méthode doGet de la classe HttpServlet méthode getWriter
méthode doOptions de classe HttpServlet méthode init de l’interface Servlet
méthode doPost de la classe HttpServlet méthode putValue d’interface HttpSession
méthode doPut de la classe HttpServlet méthode setComment de la classe Cookie
méthode doTrace de la classe HttpServlet méthode setContentType
méthode getComment de la classe Cookie méthode setDomain de la classe Cookie
méthode getCookies méthode setMaxAge de la classe Cookie
méthode getDomain de la classe Cookie méthode setPath de la classe Cookie
méthode getMaxAge de la classe Cookie point de rencontre
méthode getName de la classe Cookie protocole HTTP
méthode getOutputStream relation client-serveur
méthode getParameter requête GET
méthode getParameterNames requête POST
méthode getPath de la classe Cookie ServletException
méthode getSecure de la classe Cookie servlets
méthode getServletConfig de Servlet startserver
méthode service de l’interface Servlet startserver.bat
méthode getServletInfo de Servlet types de requête / méthodes de requête
méthode getSession WebServer JSDK

e) est le nom de serveur usuel qui fait référence à votre propre ordinateur.
f) La méthode de Cookie renvoie une String contenant le nom du cookie tel qu’il a
été défini par ou par le constructeur.
g) La méthode getSession de HttpServletRequest retourne un objet
pour le client.
19.2 Établissez que chacune des propositions suivantes est soit vraie, soit fausse. Si elle est fausse, expliquez
pourquoi.
a) Les servlets sont généralement utilisés du côté client d’une application en réseau.
b) Les méthodes des servlets sont exécutées automatiquement.
c) Les deux requêtes les plus usuelles en HTTP sont GET et PUT.
d) Le numéro de port usuel des requêtes Web est 55.
e) Les cookies n’expirent jamais.
f) Une HttpSession n’expire que lorsque la session de navigation courante se termine ou lors d’un
appel à la méthode invalidate.
g) La méthode getValue de HttpSession renvoie l’objet associé à un nom particulier.
Réponses aux exercices de révision
19.1 a) Servlet. b) doGet, doPost. c) getWriter. d) ACTION. e) localhost.
f) getName, setName. g) HttpSession.
19.2 a) Faux. Les servlets s’utilisent généralement du côté serveur.
b) Vrai.
c) Faux. Les deux requêtes les plus fréquentes en HTTP sont les GET et les POST.
d) Faux. Le numéro de port usuel des requêtes Web est 80.
e) Faux. Les cookies expirent lorsqu’ils atteignent leur âge maximum.
f) Vrai.
g) Vrai.
Exercices
19.3 Modifiez l’exemple des Cookie aux figures 19.9 à 19.11 pour y ajouter la liste des prix de chaque
proposition de lecture. Permettez aussi à l’utilisateur de sélectionner l’un ou l’autre de ces livres conseillés et
d’en passer commande.
19.4 Modifiez l’exemple de HttpSession des figures 19.13 à 19.15 pour ajouter la liste des prix de
chaque livre proposé en lecture. Permettez à l’utilisateur d’en sélectionner l’un ou l’autre et d’en passer
commande.
19.5 Modifiez l’exemple du LivreDOr des figures 19.16 et 19.17 pour mettre en place les champs
Adresse1, Adresse2, Ville, Etat et CP. Modifiez cet exemple pour rechercher un visiteur par son nom ou
son adresse de courriel, et retourner une page HTML avec toutes les informations des visiteurs.
19.6 Modifiez le servlet de la figure 19.7 pour permettre de synchroniser l’accès au fichier sondage.txt
à l’aide des techniques illustrées au chapitre 15, Gestion du multithread.
19.7 Modifiez le servlet de la figure 19.7 pour synchroniser l’accès au fichier sondage.txt en faisant en
sorte que la classe HTTPPostServlet implémente javax.servlet.SingleThreadModel.
19.8 (Projet: Servlet d’enchères) Créez votre propre servlet d’enchères. Créez une base de données de
plusieurs articles à vendre aux enchères. Créez une page Web qui permette à un utilisateur de sélectionner un
article et de placer une offre pour cet article. Quand l’utilisateur place son offre, avertissez-le de ce que, si son
offre est inférieure à l’offre la plus élevée précédente, il peut soumettre une nouvelle offre. Permettez à
l’utilisateur de revenir au servlet et de lui demander s’il a remporté les enchères.
19.9 Modifiez l’exercice 19.8 pour utiliser un tel suivi de session que, lorsque le client se connecte de
nouveau au servlet, il reçoive automatiquement une page Web lui indiquant l’état des enchères des articles sur
lesquels il a placé ses propres offres.

les servlets-java EE

Contenu connexe

Tendances

En vedette

Similaire à les servlets-java EE

Dernier

les servlets-java EE