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 : 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.

Les filtres sont des composants qui font partie du standard Servlet. Le but d'un filtre est de pouvoir appliquer une transformation aux éléments de la requête (que ce soit les éléments techniques comme les en-tête HTTP, ou les paramètres envoyés par le client), ou aux éléments de la réponse.