Apache Tomcat 6 - Guide d administration du serveur Java EE sous Windows et Linux

232 Pages·2008·6.98 MB·French

by  Etienne Langlet

Apache Tomcat 6 
Guide d'administration du serveur Java EE sous Windows et Linux

Étienne LANGLET  
Résumé

Ce livre sur Apache Tomcat 6 s’adresse à toute personne appelée à mettre en oeuvre ce serveur sous Windows ou Linux, que ce soit
pour des besoins de test, de développement, ou des besoins de production dans un environnement d’entreprise.
Après quelques rappels essentiels sur les technologies Internet et Java/Java EE, massivement utilisées par Tomcat, le livre détaille les
concepts fondamentaux de la mise en oeuvre de Tomcat 6 et approfondit la mise en place d’une véritable infrastructure d’entreprise
sécurisée et performante.
Si le lecteur est familier d’une version précédente de Tomcat, il pourra approfondir ses connaissances en trouvant dans ces pages une
information précise pour une mise en application immédiate.
L'auteur
Etienne Langlet est formateur, consultant et développeur sur les technologies Java/Java EE mais également spécialiste des produits
OpenSource. Dans ce contexte, il a eu l’occasion de mettre en oeuvre des serveurs Tomcat en environnement d'entreprise et propose
ainsi au lecteur un ouvrage réellement opérationnel sur le sujet.
Ce livre numérique a été conçu et est diffusé dans le respect des droits d’auteur. Toutes les marques citées ont été déposées par leur éditeur respectif. La loi du 11
Mars 1957 n’autorisant aux termes des alinéas 2 et 3 de l’article 41, d’une part, que les “copies ou reproductions strictement réservées à l’usage privé du copiste et non
destinées à une utilisation collective”, et, d’autre part, que les analyses et les courtes citations dans un but d’exemple et d’illustration, “toute représentation ou
reproduction intégrale, ou partielle, faite sans le consentement de l’auteur ou de ses ayants droit ou ayant cause, est illicite” (alinéa 1er de l’article 40). Cette
représentation ou reproduction, par quelque procédé que ce soit, constituerait donc une contrefaçon sanctionnée par les articles 425 et suivants du Code Pénal.
Copyright Editions ENI
© ENI Editions - All rigths reserved - 1 -
Rappel sur les architectures Internet/Intranet/Extranet 
Plus qu’un simple moyen pour diffuser l’information, l’Internet permet aujourd’hui de rendre accessible des applications 
complètes aux utilisateurs. L’utilisation des technologies Internet dans un réseau d’entreprise, l’Intranet, permettant aux 
employés d’avoir accès aux applications, ou bien dans un réseau d’entreprise partiellement ouvert à destination de 
partenaires, l’Extranet. 
Les  architectures  Internet,  Intranet,  et  Extranet  ont  en  commun  d’utiliser  des  technologies  et  protocoles  de 
communications communs, mais avec une ouverture différente. Ainsi, l’Internet désignant le réseau des réseaux, les 
applications sont diffusées à un très vaste public, au contraire, l’Intranet qualifiant un réseau privé d’entreprise, ces 
technologies et protocoles sont utilisés pour servir les employés. Entre les deux, l’Extranet, est une ouverture d’un 
Intranet d’entreprise à destination de partenaires bien définis. 
Parmi les technologies communes utilisées, on trouve le langageHTML (HyperText Markup Language) utilisé pour concevoir 
les pages diffusant le contenu, et le protocoleHTTP (HyperText Transfer Protocol), ou encoreHTTPS dans sa version 
sécurisée, pour faire transiter l’information entre le client, qui est en général un navigateur Web, et un serveur Web ou 
autre serveur capable de communiquer sur HTTP. 
1. Le protocole HTTP 
L’échange d’informations sur Internet se fait principalement en utilisant le protocole HTTP, il permet la communication 
entre le navigateur Web de l’internaute et un serveur dans un format spécifique orienté requête/réponse. 
Une requête HTTP est une demande de ressource (une page HTML par exemple), émise par le client via son navigateur, 
en cliquant sur un lien, ou bien en saisissant l’adresse d’un site Web. La réponse HTTP à cette demande contient la 
ressource demandée, ou bien une page d’erreur dans le cas où cette ressource n’existe pas, ou si son accès est 
protégé par exemple. Ces ressources sont accompagnées d’un code d’état HTTP, permettant de savoir si la demande a 
abouti correctement, ou bien, dans le cas contraire, les raisons de l’erreur. 

Exemple:  informations  transmises  dans  la  requête  HTTP  lors  de  la  connexion  d’un  navigateur  à  l’adresse 
http://www.editions­eni.fr 
GET / HTTP/1.1
Host: www.editions-eni.fr
Données reçues par le navigateur: 
HTTP/1.1 200 OK
Date: Fri, 5 Oct 2007 22:03:31 GMT
Server: Microsoft-IIS/6.0
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Content-Type: text/html; charset=utf-8
Content-Length: 81254
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>Editions ENI - Accueil</title>
../..
</html>
Il y a trois parties dans cette réponse fournie par le serveur Web. D’abord le code d’état HTTP retourné par ce serveur 
suite à la requête, 200 OK dans l’exemple ci­dessus, une section contenant ensuite les en­têtes HTTP, et enfin les 
données de la ressource demandée (en gras). 
© ENI Editions - All rigths reserved - 1 -
La première version pleinement exploitable du protocole HTTP fut la version 0.9, elle permettait un transfert de données 
simples. Puis par l’ajout de la notion d’en­tête, la version 1.0 peut ensuite permettre le transfert de données 
extrêmement variées. 
La version actuelle, la 1.1, a apporté de nombreuses améliorations, notamment: 
l les connexions permanentes, 
l le support d’un mécanisme de cryptage des connexions (via SSL ou TLS), 
l des mécanismes pour l’identification des utilisateurs d’un site, 
l des méthodes de transfert d’informations supplémentaires, 
l l’hébergement de multiples sites Web à la même adresse IP. 
HTTP utilise la notion d’URL (Uniform Resource Locator) pour permettre la localisation d’une ressource sur un serveur 
Web. Les URL en HTTP ont la syntaxe suivante : 
http://<adresse du serveur>:<port du serveur>/<chemin>/<ressource>
Dans cette URL, le port du serveur est facultatif s’il vaut 80, de plus le chemin et le nom de la ressource doivent être 
saisis en respectant la distinction majuscule/minuscule. 
a. Les méthodes HTTP 
Le protocole HTTP offre plusieurs possibilités pour gérer le transfert des informations entre le client et le serveur, 
appelées méthodes HTTP. Les méthodes HTTP les plus communément utilisées sont par exemple la méthode GET 
pour émettre une demande de ressource telle une page HTML, ou encore la méthode PUT pour transmettre des 
données à destination du serveur en utilisant un formulaire HTML. 
Voici un résumé des différentes méthodes HTTP: 
Méthode  Description 
Demande d’une ressource au serveur. C’est la 
méthode utilisée lorsqu’un utilisateur clique sur le lien 
GET 
d’une page Web, ou bien entre l’adresse d’un site 
Web dans son navigateur. 
Envoi de données vers le serveur, plus précisément, 
vers un programme hébergé par ce serveur, et qui 
POST 
sera capable de comprendre ces données pour les 
traiter. 
Comme pour GET, elle permet de demander une 
ressource, mais la ressource n’est pas envoyée dans 
HEAD  la réponse, cette méthode est utilisée pour faire des 
vérifications d’existence d’une ressource, pour des 
tests… 
PUT  Permet d’envoyer une ressource vers le serveur. 
Permet de connaître toutes les options de 
OPTIONS  communication pour obtenir une ressource 
particulière. 
DELETE  Suppression d’une ressource sur le serveur. 
Méthode de contrôle, elle demande au serveur de 
TRACE 
renvoyer la requête telle qu’elle a été reçue. 
Toutes ces méthodes HTTP ne sont pas autorisées dans la configuration par défaut d’un serveur Web, et ce pour des 
raisons évidentes de sécurité, de plus, la navigation sur Internet ne requiert rarement plus que les méthodes GET et 
- 2 - © ENI Editions - All rigths reserved
POST. Les méthodes PUT et DELETE sont quant à elle très pratiques pour un webmaster qui veut mettre son site 
Web à jour. 
b. Les codes d’état HTTP 
Lorsqu’un serveur répond à une requête HTTP, il renvoie, en plus des ressources de type page HTML et images, un 
code d’état et des informations de contrôle. Ces codes d’état permettent de connaître l’issue de la conversation entre 
le client navigateur Web et le serveur. 
Les codes de la plage 1xx sont des informations communiquées au client concernant l’état d’une requête. Ils sont 
rarement utilisés. 
Les codes de la plage 2xx indiquent que la requête a été reçue, comprise et acceptée par le serveur. 
Les codes de la plage 3xx indiquent que la ressource existe mais à un emplacement différent de celui demandé. 
Les codes de la plage 4xx indiquent une erreur de la part du client. Par exemple, ci ce dernier demande une ressource 
qui n’existe pas sur le serveur, le code 404 lui sera renvoyé. 
Enfin, les codes de la plage 5xx indiquent une erreur de la part du serveur. Dans le cas où un programme tel qu’un 
CGI, par exemple, rencontre une erreur lors de son exécution. 
Résumé des codes HTTP les plus courants: 
Code  Message  Description 
La requête a été reçue et traitée 
correctement par le serveur, la 
200  OK 
réponse est envoyée dans la 
suite. 
La ressource demandée a été 
déplacée. La nouvelle adresse de 
301  Moved  la ressource est transmise au 
client pour qu’il puisse faire une 
nouvelle demande. 
La ressource demandée n’a pas 
304  Not Modified  été modifiée et peut donc être 
obtenue à partir du cache. 
La syntaxe de la requête est 
304  Bad Request  incorrecte, ou cette requête ne 
peut pas être satisfaite. 
La ressource demandée nécessite 
une autorisation pour être 
401  Unauthorized  obtenue, le client doit reformuler 
sa requête en incluant les 
autorisations nécessaires. 
Le ressource demandée n’est pas 
403  Forbidden 
autorisée pour ce client. 
La ressource ne peut pas être 
404  Not Found 
trouvée sur ce serveur. 
Le serveur a rencontré une erreur 
500  Server Error  pendant le traitement de cette 
requête. 
Le serveur ne peut pas répondre, 
503  Service Unavailable  c’est le cas par exemple quand il 
est trop sollicité. 
c. Les en­têtes HTTP 
© ENI Editions - All rigths reserved - 3 -
Les en­têtes HTTP sont des informations de contrôle transmises lors de la communication entre un navigateur Web et 
un serveur Web. Ils servent, par exemple, à distinguer la langue préférée d’un navigateur Web pour que le serveur 
soit en mesure de servir la page dans la langue adéquate. Il convient de distinguer les en­têtes de requêtes HTTP des 
en­têtes de réponses HTTP. 
Pendant ces échanges, il est courant que des serveurs ajoutent leurs propres en­têtes, c’est notamment le cas des 
serveurs proxy, mais les en­têtes sont suffisamment paramétrables pour qu’ils puissent être également modifiés par 
les développeurs d’applications Web. 
En­têtes de requête: 
En­tête HTTP  Description 
Type de contenu accepté par le navigateur (par 
Accept 
exemple text/html). 
Accept­Encoding  Codage de données accepté par le navigateur. 
Accept­Language  Langage attendu par le navigateur Web. 
Type de codage des données dans le corps de la 
Content­Encoding 
requête. 
Type de contenu du corps de la requête (par exemple 
Content­Type 
text/html). 
Content­Length  Taille des données transmises. 
Utilisé par le navigateur pour envoyer, dans la 
Cookie 
requête, un cookie vers le serveur. 
Date de début de transfert des données, au format 
Date 
GMT. 
Referrer  URL du lien à partir duquel la requête a été effectuée. 
Chaîne donnant des informations sur le client, comme 
User­Agent  le nom et la version du navigateur, du système 
d’exploitation. 
En­têtes de réponse: 
En­tête HTTP  Description 
Content­Encoding  Type de codage du corps de la réponse. 
Type de contenu du corps de la réponse (par exemple 
Content­Type 
text/html). 
Content­Length  Taille des données transmises. 
Date de début de transfert des données au format 
Date 
GMT. 
Expires  Date limite de validité des données. 
Location  Redirection vers une nouvelle URL. 
Server  Caractéristiques du serveur ayant envoyé la réponse. 
Utilisé par le serveur, dans la réponse, pour envoyer 
Set­Cookie 
un cookie sur le navigateur. 
- 4 - © ENI Editions - All rigths reserved
d. Gestion des sessions utilisateurs: les cookies HTTP 
Le protocole HTTP est qualifié de protocole sans état, c’est­à­dire qu’il est absolument incapable de permettre le 
maintien d’une conversation entre un client et un serveur, de ce fait, chaque couple requête/réponse est totalement 
indépendant du précédent et du suivant. 
Cette caractéristique est assez gênante puisqu’il n’est pas possible de conserver des informations pour un client lors 
de sa navigation. 
Ainsi, un utilisateur naviguant sur un site de commerce électronique, pourrait choisir d’acheter un livre sur une page du 
site Web, puis en cliquant sur un lien, c’est­à­dire en formulant une nouvelle requête, décider d’acheter un disque sur 
cette nouvelle page. Le fonctionnement par défaut du protocole HTTP, ferait que à ce stade de la navigation, le 
serveur aurait déjà oublié le livre! 
Le protocole HTTP utilise donc un mécanisme supplémentaire pour régler ce problème : il s’agit des cookies HTTP. Les 
cookies HTTP, ou plus simplement cookies, sont des informations sur la navigation d’un utilisateur, qu’un serveur Web 
peut ajouter dans la réponse qu’il fournit, toutes les requêtes suivantes de cet utilisateur vers ce serveur incluront les 
cookies que le navigateur à déjà reçu. 
Illustration du fonctionnement des cookies: 

Les serveurs Web et autres serveurs d’applications tels Tomcat 5, utilisent massivement cette technologie pour 
conserver des informations sur la navigation d’un utilisateur sur un site ou une application. 
2. Les serveurs Web 
Sur Internet, le rôle d’un serveur Web est de rendre disponibles les différentes pages HTML qui composent un site, ainsi 
que les ressources qu’elles peuvent contenir comme par exemple des images, du son, de la vidéo. 
Aujourd’hui les serveurs Web les plus utilisés sont : 
l Apache HTTP Server de la fondation Apache, 
l Internet Information Server de Microsoft, 
l Sun ONE de Sun Microsystems, anciennement iPlanet de Netscape Corp. 
Chacun de ces serveurs propose de nombreuses options de configuration et permettent d’héberger de multiples sites 
et applications. De plus, les considérations de sécurité étant d’actualité, ils proposent également des fonctionnalités de 
sécurité, notamment le support du protocole HTTP sécurisé: HTTPS. 
3. Les technologies côté client 
Les technologies côté client sont les technologies de développement d’application ou bien de sites Web utilisées pour 
concevoir l’interface utilisateur et prendre en charge les différents événements déclenchés par les utilisateurs. 
Trois types d’applications clientes sont majoritairement utilisés: 
l Les clients lourds, 
l Les clients légers, 
l Les clients riches. 
Les clients lourds
© ENI Editions - All rigths reserved - 5 -
Ce sont des clients proposant une interface graphique fenêtrée telle qu’une application de traitement de texte par 
exemple. 
Les technologies utilisés sont variables et dépendent du langage de programmation dans lequel l’application a été 
programmée. Ce type d’application présente, en général, une interface riche en contrôle et composants visuelles offrant 
une ergonomie maximale à l’utilisateur. 
En plus de la partie interface utilisateur, ces applications intègrent également une partie non négligeable de la logique 
de traitement, et peuvent s’intégrer à des ressources d’un système d’information, tel qu’un serveur de base de 
données, par exemple. 
Les technologies utilisées sont, par exemple : 
l Les bibliothèques de composants graphiques AWT et Swing en Java, MFC et ATL en langage C++ sous 
Windows, 
l Les bibliothèques d’accès aux bases de données JDBC pour Java, ADO et ODBC pour les technologies Microsoft. 
Les clients légers
Il s’agit majoritairement de navigateurs Web utilisant les technologies Internet pour proposer une interface graphique à 
l’utilisateur. Ces applications sont en principe développées en utilisant les langages de programmation compréhensibles 
par un navigateur Web, mais également d’autres technologies moyennant l’installation d’extensions. 
Ces différentes ressources sont rendues disponibles au client par un serveur Web avec lequel elles communiquent 
grâce au protocole HTTP. Les technologies de développement de clients légers sont aujourd’hui très souvent utilisées 
conjointement avec des technologies côté serveur permettant une génération dynamique des interfaces utilisateurs. 
Les clients légers tirent leur nom du fait qu’ils ne sont responsables que de la partie interface utilisateur, tous les 
traitements de l’application sont déportés sur un serveur spécifique : un serveur Web, ou un serveur d’application. 
Ces applications utilisent les mêmes technologies que pour le développement des sites Internet : 
l HTML: le langage de présentation des données. 
l JavaScript: pour ajouter de l’interactivité et du dynamisme à l’interface. 
l CSS : pour créer des styles de présentation réutilisables. 
De plus, ces technologies nativement compréhensibles par un navigateur Web peuvent être enrichies par d’autres, qui 
nécessitent souvent des extensions sur le navigateur Web : 
l Applets Java: programmes graphiques Java embarqués dans les pages HTML, cette technologie requiert un 
environnement d’exécution Java sur le poste client. 
l ActiveX: technologie Microsoft semblable aux Applets, mais uniquement utilisable avec le navigateur Web 
Internet Explorer. 
Les clients riches
Les clients riches sont un compromis entre les clients lourds et les clients légers. L’interface graphique de ce type 
d’application est développée en utilisant un langage de programmation spécifique qui leur confère une ergonomie aussi 
agréable que les clients lourds, quelques traitements basiques sont également intégrés à ces interfaces, mais la 
majorité des traitements se font sur un serveur d’application, comme pour les clients légers. Ce nouveau type 
d’application offre des perspectives intéressantes, comme par exemple la possibilité d’utiliser l’interface client en mode 
connecté ou déconnecté du serveur d’application, très pratique pour les utilisateurs nomades. 
Ce type de développement d’application étant relativement récent, les technologies permettant de les développer sont 
assez peu nombreuses : 
l La plate­forme Microsoft .NET propose des solutions pour ce type d’application, 
l L’environnement Eclipse RCP (Rich Client Platform), est une plate­forme Open Source utilisant les technologies 
Java. 
4. Les technologies côté serveur 
- 6 - © ENI Editions - All rigths reserved
Les technologies côté serveur permettent le développement des parties d’une application qui vont réaliser le plus gros 
des traitements pour cette application. Les composants logiciels ainsi développés, ont besoins d’être hébergés dans un 
environnement spécifique, permettant la connectivité avec les parties clientes de ces applications: c’est le serveur 
d’applications. 
Ces technologies sont également utilisées pour développer des composants capables de générer dynamiquement les 
interfaces graphiques des applications. Par opposition aux ressources statiques, telles que les pages HTML, ces 
ressources sont dynamiques, puisque le contenu généré l’est dynamiquement, en fonction de l’utilisateur par exemple. 
Aujourd’hui trois grandes technologies sortent du lot pour le développement côté serveur : 
l La plate­forme Microsoft .NETqui permet le développement de ressources dynamiques avec la technologie 
ASP.NET, et les composants métier en COM, DCOM, ou plus récemment .NET remoting. 
l La technologie PHP, une plate­forme Open Source en pleine évolution, notamment avec l’apport dans la 
dernière version de l’orienté objet. 
l La plate­forme JEE, basée sur le langage Java, qui propose les composants Servlet et JSP (Java Server Pages) 
en tant que ressources dynamiques, et la technologie EJB  (Enterprise JavaBeans) et JavaBean pour les 
composants métier. Une présentation plus précise de ces composants est proposée dans le chapitre La Plate­
forme JEE 5 de cet ouvrage, dans la mesure où certains d’entre eux sont utilisés avec Tomcat. 
5. Les architectures n/tiers 
Les architectures de développement ont énormément évolué avec le temps. La tendance actuelle du développement 
d’application met l’accent sur la séparation des traitements afin de mieux maîtriser la complexité grandissante de ces 
applications, et de permettre une évolution plus facile. 
Lesarchitectures client/serveur proposaient des applications intégrant la totalité de la logique métier et utilisant des 
serveurs de ressources et de données. La puissance du poste de travail de l’utilisateur était alors utilisée. 
Lesarchitectures 3/tiers ont ensuite proposé un modèle de structuration permettant une séparation de l’interface 
graphique  utilisateur,  de  la  logique  de  traitement  de  l’application,  et  des  serveurs  hébergeant  les  données  et 
ressources utilisées par ces applications. 
Les avantages de ce type d’architectures sont notables, notamment par rapport à l’ancien modèle client serveur: 
l Les interfaces graphiques fonctionnant sur le poste client peuvent être allégées. 
l Le gros des traitements est réalisé sur un serveur d’application, et non plus sur le poste client; 
l La mise à jour d’un composant de traitement se fait sur le serveur et n’impose aucune mise à jour côté client. 
Cependant, si la partie cliente est un client lourd, il faut installer cette application sur chacun des postes utilisateurs. 
Exemple d’architecture 3/tiers:
© ENI Editions - All rigths reserved - 7 -
Les tendances du développement d’application se sont donc orientées vers un modèle encore plus souple, utilisant 
massivement les clients légers et donc les technologies de l’Internet: les architectures n/tiers. 
Dans ces architectures, le bénéfice apporté par l’inclusion d’un serveur d’applications pour les traitements est conservé, 
des serveurs Web sont ajoutés pour prendre en charge les ressources Web statiques telles que les pages HTML et les 
images. Les serveurs d’application vont également héberger les ressources dynamiques. 
Ce type d’architecture permet une utilisation des traitements hébergés sur le serveur d’application, aussi bien par les 
clients lourds que par les clients légers. 
Exemple d’architecture n/tiers:

Les technologies JEE abordées dans cet ouvrage et sur lesquelles reposent le serveur Tomcat préconisent l’utilisation 
de ce type d’architecture. 
- 8 - © ENI Editions - All rigths reserved