Java & le web
x Le web dynamique
x Java & le web

Intro à Tomcat
x Serveur d'applications
x Présentation Tomcat
x Installation
x Arborescence

Configuration
x Introduction
x Server
x Service
x Engine
x Host
x Context
x DefaultContext
x Logger
x Loader
x Realm
x Valve

Connecteurs
x Balise Connector
x Coyote HTTP/1.1

Sécurisation accès
x La balise Realm
x Memory Based
x JDBC Database
x Protéger ressources
x Cryptage password

Les Valve
x La balise Valve
x Access Log
x Single Sign-On

Fonctionnalités
x Déploiement auto.
x Class loaders

Eclipse & Tomcat
x Plug-in pour Eclipse
x Projet Tomcat
x Debugger des JSP

Créer une appli web
x Présentation
x Architecture
x Fichier web.xml
x Déploiement

Tomcat 5
x Nouveautés

Tomcat's Corner
x Crédits
x Liens
 
             
Architecture d'une application web

 

 

Qu'est-ce qu'une application web ?

Comme nous avons déjà eu l'occasion de l'évoquer, une application web est une application contenant des objets spéciaux, capables de recevoir des requêtes web (HTTP) et de renvoyer des réponses à ces requêtes. Ces objets s'appellent en Java des servlets.

 

Déployée ou packagée...

L'organisation d'une application web répond à un standard, présenté plus bas. Une webapp peut revêtir deux formes. La première consiste à posséder physiquement, sur un système de fichiers, tous les fichiers et répertoires de l'architecture de la webapp. Cette version est dite déployée (ou décompactée). Elle est utilisée généralement pendant les phases de développement, puisqu'elle permet une modification immédiate des ressources qui le nécessitent.

La seconde possibilité est de créer une archive WAR (Web Application aRchive), contenant, sous forme compressée ou non, cette même architecture. Cette version est dite packagée (ou compactée). On l'utilise en règle générale pour "livrer" une application, la distribuer. Il est bien sûr dans ce cas plus simple de fournir un seul fichier !

Comme nous l'avons déjà évoqué dans la configuration, une archive WAR sera en règle générale automatiquement déployée au premier redémarrage du serveur après son ajout. On peut néanmoins configurer que les WAR ne soient pas déployées, et qu'ainsi les applications soient exécutées depuis le WAR directement.

 

Architecture d'une application web

Le répertoire racine d'une application web (celui dans lequel seront déposées toutes les ressources de l'application) est appelé document root de l'application. Il correspond à l'attribut docBase d'un Context, dans la configuration du serveur.

Dans le document root, on doit obligatoirement trouver un répertoire nommé WEB-INF. Sans cela, vous n'aurez pas créé d'application web. Ce répertoire doit obligatoirement exister et en contenir deux autres, WEB-INF/classes et WEB-INF/lib. Ceux-ci, comme évoqué précédemment, contiendront respectivement les classes et les librairies accessibles uniquement à cette application web. C'est par exemple dans le répertoire WEB-INF/classes que nous trouverons notre classe exemple PremiereServlet.class. Ce répertoire ne doit pas nécessairement contenir que des servlets. Toutes les classes Java utilisées par l'application doivent s'y trouver, et nulle part ailleurs (sauf accesibles par les autres class loaders). Attention toutefois à respecter vos packages Java. Si la classe PremiereServlet était située dans le package org.test.servlet, la classe compilée devrait se trouver dans WEB-INF/classes/org/test/servlet.

Le document root doit également contenir un fichier web.xml, appelé descripteur de déploiement de l'application web. Il contient les différentes caractéristiques et paramètres de la webapp, notamment la description des servlets ou des paramètres d'initialisation. La structure de ce fichier est présentée par la suite.

La capture ci-dessous montre le répertoire WEB-INF d'une application de base.

On peut constater qu'un répertoire src est également présent. Celui-ci n'est en aucun cas indispensable. Mais il indique que vous pouvez tout à fait mettre les fichiers ou les répertoires que vous voulez dans WEB-INF. Tant que les ressources obligatoires sont présentes, le reste n'a pas d'importance (en terme de respect des spécifications). Néanmoins, on évitera de mettre n'importe quoi dans ce répertoire ! Les images, par exemple, n'ont rien à y faire (nous y revenons au paragraphe suivant). Un répertoire src est acceptable, au sens où il contient les sources des classes dont les versions compilées sont dans WEB-INF/classes. Cela respecte donc encore une certaine logique, même arbitraire.

Enfin, quid des autres ressources de l'application ? En effet, une application web n'utilise pas nécessairement que des classes et librairies Java - il est même rare que ce soit le cas. On aura sans doute besoin également d'images, de pages HTML statiques, et bien sûr de pages JSP (et autres fichiers vidéo, son, ...). Où doivent être placées ces ressources ? Encore une fois, il n'y a pas de règle à respecter pour ces éléments. Vous pouvez les placer où vous voulez à partir du document root. La pratique veut tout de même qu'on ne les mette pas sous WEB-INF. Dans le cas d'une petite application, on aura tendance à les laisser directement dans le document root. Mais, selon vos besoins ou vos désirs, vous pouvez créer toute une arborescence dans le document root pour accueillir vos différentes ressources "statiques" (oui d'accord, les JSP ne sont pas des ressources statiques, mais on va faire comme si...).

 

Ressources partagées

N'oublions pas non plus qu'il est possible de partager des ressources (classes ou librairies) entre toutes les applications web d'un serveur, comme nous l'avons déjà vu. Dans le répertoire TOMCAT_HOME/shared, on peut mutualiser des ressources entre toutes les applications web. Et dans le répertoire TOMCAT_HOME/common, mutualiser entre toutes les applications et même rendre les ressources accessibles aux classes internes du serveur. Reportez-vous à la page concernant les class loaders de Tomcat pour plus d'informations.