Une requête HTTP provient d'un client, le plus souvent un navigateur web, et porte avec elle des paramètres. Ces paramètres peuvent être techniques (les paramètres standard HTTP), ou applicatifs, comme le contenu d'un formulaire.
La réponse provient du serveur, et est destinée le plus souvent à être affichée dans un navigateur. Ce peut être une page HTML, dynamique ou non, une image, ou bien un code d'erreur HTTP, accompagné d'un message.
De nombreuses applications web ont besoin de reconnaître un utilisateur donné de requête en requête.
Malheureusement, le protocole HTTP ne permet pas cela : rien n'est prévu pour garder la mémoire
de ce client. La façon la plus répandue de pallier ce problème, est d'utiliser des cookies. Le principe
est le suivant : le serveur envoie au navigateur un cookie, qui, techniquement,
est un petit fichier texte. Ce fichier contient des informations telles que le nom du serveur qui
en est à l'origine, quel serveur a le droit de le lire, une date de péremption, et bien sûr,
une donnée d'identification. Une fois le cookie accepté (il peut être refusé), le navigateur le
renvoie systématiquement avec chaque requête. Charge donc au serveur de se souvenir de la personne
à qui il a envoyé ce cookie, de façon à la reconnaître. L'API Servlet définit un cookie :
JSESSIONID
, ce qui lui permet de définir la notion de session.
Une session est simplement un ensemble de cycles requêtes / réponses avec un utilisateur donné. Une
session est reconnue grâce à un cookie nommé JSESSIONID
.
Nous avons déjà beaucoup utilisé ce terme, sans en donner de définition précise. Une application web est un ensemble d'éléments statiques (pages HTML, images, etc...) et de servlets, qui forment une application complète pouvant être gérée par un serveur web. Une application web est associée à un point de montage dans une URL, qui est le préfixe de toutes les URL qu'elle gère. Une application web est un élément portable, qui peut être déployé sur tout serveur d'applications supportant le standard Servlet.
Le standard Servlet définit trois contextes d'exécution pour une servlet. Ces trois contextes sont :
La requête : l'exécution d'une servlet se déroule dans le contexte d'une requête unique.
La session : de la même façon, une servlet est exécutée dans le contexte d'une unique session. Une session est définie par un ensemble de requêtes successives en provenance d'un même client. Elle peut durer les quelques minutes du temps d'une visite sur un site de commerce électronique, ou beaucoup plus longtemps, et conserver les données d'identification d'un internaute d'une journée à l'autre.
L'application : enfin une servlet appartient à une application web unique.
Ces trois contextes exposent les mêmes méthodes setAttribute(String, Object)
,
getAttribute(String)
et getAttributeNames()
. Ces méthodes permettent
d'attacher des objets Java quelconques à ces contextes, et de les récupérer. En fonction de la
durée de vie de ces objets (une requête, une session ou toute l'application), on choisira le
bon contexte pour sauvegarder les informations dont on a besoin.
On notera cependant que l'entretien du contexte session
peut être coûteux, notamment
en mémoire. Certaines applications choisissent d'ailleurs de ne pas l'utiliser, pour des raisons
de perfomance. D'une façon générale, on évitera de stocker trop d'information dans ce contexte.
La notion de cycle de vie est une notion qui existe pour tous les types de composant qu'un serveur d'application peut gérer. Entre le moment où un serveur d'application démarre, et le moment où les composants qu'il gère sont prêts à être utilisés, chaque composant passe par différents états, définis dans les standards. Ces états, les transitions qui permettent de passer de l'un à l'autre, et les conditions qui permettent d'activer ces transitions forment un ensemble que l'on appelle le cycle de vie d'un composant.
À chaque changement d'état d'un composant, l'application qui possède ce composant est notifiée par le serveur d'application. Techniquement, cette notification consiste en l'appel d'une méthode d'un objet particulier, défini dans le standard. Cet objet est fourni par l'application, s'il n'est pas déclaré, alors la notification n'a pas lieu. On appelle ces objets particuliers des listeners.
En tant que composant standard, les servlets ont un cycle de vie, sur lequel il est possible de poser des listeners. Lors de ce cycle de vie, certaines méthodes particulières des servlets sont invoquées, nous verrons ce point dans la suite.