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.editionseni.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 cidessus, une section contenant ensuite les entê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’entê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 entêtes HTTP © ENI Editions - All rigths reserved - 3 - Les entê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 entêtes de requêtes HTTP des entêtes de réponses HTTP. Pendant ces échanges, il est courant que des serveurs ajoutent leurs propres entêtes, c’est notamment le cas des serveurs proxy, mais les entêtes sont suffisamment paramétrables pour qu’ils puissent être également modifiés par les développeurs d’applications Web. Entêtes de requête: Entête HTTP Description Type de contenu accepté par le navigateur (par Accept exemple text/html). AcceptEncoding Codage de données accepté par le navigateur. AcceptLanguage Langage attendu par le navigateur Web. Type de codage des données dans le corps de la ContentEncoding requête. Type de contenu du corps de la requête (par exemple ContentType text/html). ContentLength 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 UserAgent le nom et la version du navigateur, du système d’exploitation. Entêtes de réponse: Entête HTTP Description ContentEncoding Type de codage du corps de la réponse. Type de contenu du corps de la réponse (par exemple ContentType text/html). ContentLength 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 SetCookie 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 plateforme Microsoft .NET propose des solutions pour ce type d’application, l L’environnement Eclipse RCP (Rich Client Platform), est une plateforme 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 plateforme 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 plateforme Open Source en pleine évolution, notamment avec l’apport dans la dernière version de l’orienté objet. l La plateforme 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
Description: