Tomcat est un serveur d’applications Java

Tomcat est un serveur d’applications Java

  1. Objectifs

    • Être capable de déployer et gérer un serveur libre Tomcat.
  2. Serveur web http

    • Tomcat est un serveur d'applications Java

    • Le rôle principal d’un serveur web est d’intercepter les requêtes Http, sur un port (par défaut 80), les traiter et générer ensuite des réponses Http.
    • Tous les serveurs web embarquent un daemon Http (httpd) ou équivalent qui s’occupe de cette fonctionnalité.
    • A part sa fonction basique qui est d’intercepter et de répondre en Http, un serveur web peut avoir d’autres fonctionnalités tel que:
      • La gestion de la sécurité, comme les fonctionnalités de restriction des accès par domaine, par utilisateur, par groupe ou par adresse IP,
      • La gestion du contenu, comme la redirection des requêtes http, la personnalisation des messages d’erreurs, ou la gestion des timeout…
    • Pour exécuter des programmes écrits avec des langages de programmation ( java, php, C# ou autres )le serveur web doit avoir un conteneur web
    • Le conteneur web Tomcat, est composé d’un moteur jsp, un moteur servlet et d’un descripteur de déploiement pour les modules web de type war. Ces moteurs sont en réalité des API qui sont implémentés dans le serveur Tomcat, et qui permettent de faire déployer seulement des applications web Java de type war.
  3. Un serveur d’applications

    • Tomcat est un serveur d’applications Java. Nous avons déjà présenté ce qu’est une application web.
    • 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.



  4. Déroulement classique d’une requête vers un serveur d’applications

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

Source:

  • http://www-igm.univ-mlv.fr/~dr/XPOSE2003/tomcat/tomcat.php?rub=25/
  • http://tomcat.apache.org/whichversion.html