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
 
             
Les serveurs d'applications

 

Un serveur d'applications

Tomcat est un serveur d'applications Java. Nous avons déjà présenté ce qu'est une application web. Elle permet de générer une réponse HTML à une requête après avoir effectué un certain nombre d'opérations (connexion à une base de données, à un annuaire LDAP...). Pour le client (un navigateur web en général), il n'y a pas de différence avec une page web statique : il reçoit toujours du HTML, seul langage qu'il comprend. Seule la manière dont la réponse est formée côté serveur change.

Les requêtes, pour le client, ne diffèrent pas non plus. Qu'il souhaite accéder à une ressource statique ou à une application web, il utilise toujours une URL au même format (standard HTTP). C'est donc côté serveur que la distinction doit s'opérer. Le schéma suivant montre le déroulement classique d'une requête vers un serveur d'applications :

 

  • 1) Le client émet une requête (i.e. appelle une URL) pour demander une ressource au serveur. Exemple : http://leserveur.com/welcome. Il ne sait pas ici si la réponse qui va lui parvenir est statique (page HTML simple) ou dynamique (générée par une application web). Dans notre cas, il s'agit d'une application répondant à l'adresse welcome sur le serveur leserveur.com.

  • 2) Côté serveur, c'est le serveur web (exemple : Apache) qui traite les requêtes HTTP entrantes. Il traite donc toutes les requêtes, qu'elles demandent une ressource statique ou dynamique. Seulement, un serveur HTTP ne sait répondre qu'aux requêtes visant des ressources statiques. Il ne peut que renvoyer des pages HTML, des images,... existantes.

  • 3) Ainsi, si le serveur HTTP s'aperçoit que la requête reçue est destinée au serveur d'applications, il la lui transmet. Les deux serveurs sont reliés par un canal, nommé connecteur.

  • 4) Le serveur d'applications (exemple : Tomcat !) reçoit la requête à son tour. Il est, lui, en mesure de la traiter. Il exécute donc le morceau d'application (la servlet) auquel est destinée la requête, en fonction de l'URL. Cette opération est effectuée à partir de la configuration du serveur. La servlet est donc invoquée, et le serveur lui fournit notamment deux objets Java (Tomcat est un serveur d'applications Java) exploitables : un représentant la requête, l'autre représentant la réponse. La servlet peut maintenant travailler, et générer la réponse à la demande. Cela peut passer par la consultation de sources de données, comme des bases de données (4'' sur le schéma). Ou bien par l'interrogation d'autres serveurs ou systèmes (4' sur le schéma), l'environnement Java web permettant de se connecter à de nombreux systèmes.

  • 5) Une fois sa réponse générée, le serveur d'applications la renvoie, par le connecteur, au serveur web. Celui-ci la récupère comme s'il était lui-même allé chercher une ressource statique. Il a simplement délégué la récupération de la réponse, et celle-ci a été générée, mais ce n'est plus le problème.

  • 6) La réponse est dorénavant du simple code HTML, compréhensible par un navigateur. Le serveur HTTP peut donc retourner la réponse au client.

 

Serveur web / serveur d'applications

Dans le schéma en haut de la page, nous avons séparé le serveur web et le serveur d'applications. Ces deux composants sont en effet nécessaires côté serveur, puisqu'ils se complètent : le serveur d'applications ne sait pas traiter une requête HTTP, le serveur web ne sait pas exécuter d'applications !

Si ces deux composantes sont indispensables, elles ne sont pas nécessairement séparées. Tomcat inclut ainsi un serveur web, et est donc capable de fonctionner en autonomie (StandAlone), pour traiter à la fois les requêtes HTTP simples (ressources statiques) et les applications web. Le principe est de changer de connecteur (par rapport à notre schéma en haut de la page), pour en utiliser un comprenant les requêtes HTTP et non plus les requêtes triées venant du serveur web.

Dans certains cas, cette possibilité est extrêmement intéressante. Elle permet de proposer un serveur web complet en installant le minimum de logiciels. Néanmoins, ce n'est pas une fin en soi. Pour des besoins de production plus importants, il est intéressant de scinder les deux activités, ne serait-ce que pour alléger la tâche de chacun des serveurs. Tomcat peut ainsi se concentrer uniquement sur l'exécution des applications. Cela économise également sa mémoire et augmente ses performances, en lui permettant notamment de créer moins d'objets... En outre, dans certains cas, comme la mise en place d'un serveur sécurisé (SSL), on préférera gérer la sécurisation sur le serveur web, et pas sous Tomcat, même si celui-ci est capable de mettre en place un environnement sécurisé.

 

 

en résumé...

 

- Un serveur d'applications est un serveur capable d'exécuter des applications web. C'est-à-dire des applications destinées à traiter des requêtes web entrantes, et à générer une réponse adéquate.

- Un serveur d'applications a un rôle distinct de celui d'un serveur web. Ce sont deux composants indispensables. Tomcat sait faire les deux.