Partie 6. Conteneurs de servlets

Ce matériel fait partie de la série "Introduction au développement d'entreprise". Articles précédents :

• sur le réseautage
• sur l'architecture logicielle
• à propos de HTTP/HTTPS
• sur les bases de Maven
• à propos des servlets (écriture d'une application web simple)

Dans le dernier article, nous nous sommes familiarisés avec les servlets et avons appris à les utiliser pour créer des applications Web. Le moment est venu d'examiner de plus près une partie essentielle de ce plaisir : les conteneurs de servlets.

Table des matières:

• Qu'est-ce qu'un conteneur de servlet ?
• Comment les conteneurs de servlet sont-ils utilisés ?
• Installation et démarrage de Tomcat
• Déploiement d'une application dans Tomcat
• Utiliser HTTPS au lieu de HTTP
• Génération d'un certificat
• Configuration du serveur
• Génération dynamique de pages HTML
• Alternatives à Tomcat

Qu'est-ce qu'un conteneur de servlet ?

C'est un programme qui s'exécute sur un serveur et peut interagir avec les servlets que nous avons créés. En d'autres termes, si nous voulons exécuter notre application Web sur un serveur, nous déployons d'abord un conteneur de servlets, puis nous y mettons des servlets. Le flux de travail est simple : lorsque le client accède au serveur, le conteneur traite sa requête, détermine quel servlet doit la traiter, puis transmet la requête.

Comment les conteneurs de servlet sont-ils utilisés ?

Outre le routage des requêtes, un conteneur de servlet remplit d'autres fonctions :

1. Il génère dynamiquement des pages HTML à partir de fichiers JSP.
2. Il chiffre/déchiffre les messages HTTPS.
3. Il fournit un accès restreint pour l'administration des servlets.

En général, tout cela sonne bien. Il ne nous reste plus qu'à trouver comment mettre tout cela en pratique. Eh bien, pour apprendre à utiliser quelque chose, il suffit de plonger et d'essayer de l'utiliser :) Alors, aujourd'hui, nous allons nous entraîner ! Le conteneur de servlet le plus populaire est Apache Tomcat . Il est open source et peut être utilisé gratuitement. Téléchargez Tomcat pour votre système d'exploitation ici et nous explorerons le travail avec les conteneurs "en action".

Installation et démarrage de Tomcat

1. Pour installer Tomcat, décompressez simplement l'archive téléchargée dans le répertoire souhaité.

2. Veuillez noter que Tomcat nécessite Java version 8 ou supérieure pour démarrer et s'exécuter. Vérifiez que la variable d'environnement JAVA_HOME fait référence à la version actuelle du JDK.

3. Ensuite, vous devez configurer l'accès des utilisateurs à Tomcat . Cela se fait dans le fichier tomcat-users.xml, qui se trouve dans le dossier conf.

   Il existe quatre rôles prédéfinis dans Tomcat :

   • manager-gui — Accès à l'interface graphique et à la page d'état
   • manager-script — Accès à l'interface texte et à la page d'état
   • manager-jmx — Accès à JMX et à la page d'état
   • manager-status — Accès uniquement à la page de statut

   Dans la balise <tomcat-users>, nous spécifions explicitement ces rôles et les attribuons à notre utilisateur :

   
   <role rolename="manager-gui"/>
   <role rolename="manager-script"/>
   <role rolename="manager-jmx"/>
   <role rolename="manager-status"/>
   <user username="user" password="password"
       roles="manager-gui, manager-script, manager-jmx, manager-status"/>
   

   Maintenant, tout est prêt à être lancé !

4. Dans le dossier bin, exécutez le fichier startup.bat (startup.sh sous Linux).

5. Après quelques secondes, ouvrez le lien http://localhost:8080/ dans votre navigateur. Vous verrez un tableau de bord graphique :

   Si vous voyez un menu comme celui-ci, alors Tomcat est en cours d'exécution.

6. S'il n'est pas en cours d'exécution, vérifiez manuellement les variables d'environnement JAVA_HOME et CATALINA_HOME :

   • JAVA_HOME — Cela doit faire référence à la version actuelle de Java 8+.
   • CATALINA_BASE — Cela doit faire référence à Tomcat ou être absent (il ne doit pas faire référence à une autre version de Tomcat).

Déploiement d'une application dans Tomcat

Nous avons réussi à lancer Tomcat, il est donc temps d'y déployer un projet. Utilisons les servlets de l' article précédent . MainServlet :

import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import java.io.IOException;
import java.io.PrintWriter;

@WebServlet("/hello")
public class MainServlet extends HttpServlet {

   @Override
   protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
       HttpSession session = req.getSession();
       Integer visitCounter = (Integer) session.getAttribute("visitCounter");
       if (visitCounter == null) {
           visitCounter = 1;
       } else {
           visitCounter++;
       }
       session.setAttribute("visitCounter", visitCounter);
       String username = req.getParameter("username");
       resp.setContentType("text/html");
       PrintWriter printWriter = resp.getWriter();
       if (username == null) {
           printWriter.write("Hello, Anonymous" + "
");
       } else {
           printWriter.write("Hello, " + username + "
");
       }
       printWriter.write("Page was visited " + visitCounter + " times.");
       printWriter.close();
   }
}

IndexServlet :

import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

@WebServlet("/")
public class IndexServlet extends HttpServlet {

   @Override
   protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
       resp.sendRedirect(req.getContextPath() + "/hello");
   }
}

Avant de déployer, nous devons empaqueter nos servlets dans un fichier WAR. Maven est généralement utilisé pour cela, mais pour créer un fichier WAR, vous avez besoin d'un fichier web.xml contenant un mappage pour tous les servlets. Nous avons utilisé la nouvelle annotation @WebServlet pour écrire les servlets, nous n'avons donc pas de fichier web.xml. Heureusement, IDEA peut faire le sale boulot pour nous, en enveloppant notre projet dans un fichier WAR. Pour ce faire, ouvrez la structure du projet (Ctrl+Maj+Alt+S) -> Artefacts -> Sélectionnez le fichier WAR souhaité -> Cochez la case à côté de "Inclure dans la construction du projet" -> Cliquez sur "OK". Construisons le projet en utilisant la combinaison de touches Ctrl+F9. Maintenant, notre fichier WAR est dans le répertoire cible. Le fichier peut être renommé en quelque chose de plus simple, par exemple servlet.war, et déplacé vers un emplacement plus pratique, par exemple C:\\my\\.nous allons le mettre dans un conteneur . Il y a deux façons de faire ça.

1. Utilisation de l'interface graphique

   Pour cela, suivez ce lien : http://localhost:8080/manager/html . Tomcat devrait demander un nom d'utilisateur et un mot de passe.

   Si vous m'avez suivi jusqu'à présent, le nom d'utilisateur est "user" et le mot de passe est "password" .

   Une fois connecté, vous verrez le gestionnaire d'applications Web Tomcat. La section "Applications" contient déjà 5 applications - ce sont des utilitaires Tomcat, qui facilitent l'utilisation de Tomcat. Ils peuvent être supprimés à l'avenir.

   Ci-dessous se trouve la section "Déployer". Ici, vous pouvez sélectionner l'archive WAR à déployer. Entrons manuellement le chemin et le contexte :

   Cliquez sur « Déployer » et nous voyons que notre application est apparue dans la section « Applications » :

   À l'aide de l'interface graphique de Tomcat, nous pouvons arrêter, redémarrer et supprimer une session, ainsi que définir la durée de la session. Lors du déploiement, nous avons spécifié le contexte /demo, ce qui signifie que notre application est accessible via http://localhost:8080/demo . Vérifie ça. Tout devrait fonctionner.

2. Via le système de fichiers

   Pour déployer l'application de cette manière, vous devez ouvrir le répertoire dans lequel Tomcat a été décompressé. Allez ensuite dans le dossier "webapps". Vous trouverez ici les utilitaires que nous avons déjà rencontrés :

   Il nous suffit de déplacer notre fichier servlet.war ici.

   Nous attendons quelques secondes puis voyons qu'un nouveau dossier "servlet" est apparu. Cela signifie que notre application est déployée. Accédez à l'interface du gestionnaire d'applications à l' adresse http://localhost:8080/manager/ . Ici, nous voyons que notre application est déployée dans le contexte /servlet :

   Lorsqu'il est déployé de cette manière, le contexte est attribué automatiquement en fonction du nom du fichier WAR déployé. Pour changer le contexte, vous pouvez renommer le dossier nouvellement créé qui contient l'application, mais avant cela, vous devez supprimer le fichier WAR. Sinon, Tomcat redéploie l'application avec le nom de l'archive.

   Comme vous pouvez le constater, le déploiement d'applications dans Tomcat est beaucoup plus simple qu'il n'y paraît. Mais ses autres fonctions sont également faciles à utiliser. Allons vérifier.

Utiliser HTTPS au lieu de HTTP

Si vous vous en souvenez, nous avons examiné la différence entre HTTP et HTTPS dans un article séparé . HTTPS est le même protocole que HTTP, mais il crypte les données transmises. Côté client, le navigateur est responsable du cryptage, mais nous devons fournir le cryptage côté serveur. Étant donné que Tomcat accepte et achemine les requêtes HTTP, il est logique de lui déléguer le chiffrement. Pour ce faire, nous devons :

1. Générer un certificat auto-signé
2. Définir des paramètres de serveur supplémentaires

Entraînons-nous à faire cela.

Génération d'un certificat

Quelle que soit la version, le JDK comprend un grand nombre d'utilitaires. L'un d'eux est keytool . Il s'agit d'un outil pour générer et travailler avec des clés de chiffrement. Pour l'utiliser, sur la ligne de commande, accédez au répertoire C:\\Program Files\\Java\\jdk1.8.0_181\\bin et exécutez la commande keytool -genkey -alias tomcat -keyalg RSA .

• keytool — Le nom de l'utilitaire que nous exécutons avec les options de ligne de commande
• -genkey — Indique que nous voulons générer une nouvelle clé
• -alias tomcat — Crée un alias de clé
• -keyalg RSA — Sélectionnez RSA comme algorithme de génération de clé

Après avoir exécuté la commande, l'utilitaire entame un dialogue avec nous : Entrez les informations nécessaires. Nous avons maintenant créé un magasin de clés dans notre répertoire personnel (pour Windows, il s'agit de C:\\Users\\{nom d'utilisateur}\\.keystore) et une clé Tomcat dedans. Nous avons généré un certificat simple dont la plupart des navigateurs se plaindront. Un tel certificat n'est pas adapté aux applications commerciales : il ne peut être utilisé qu'à des fins de test. Sur un serveur de production, vous devez utiliser un certificat d'une autorité de certification (par exemple, https://letsencrypt.org/ ).

Configuration du serveur

Maintenant que le certificat est prêt, nous devons ajuster les paramètres du serveur, à savoir le connecteur SSL. Cela se fait dans le fichier server.xml, qui se trouve dans apache-tomcat-9.0.30/conf/ . On y trouve des blocs comme celui-ci :

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
               maxThreads="150" SSLEnabled="true">
        <SSLHostConfig>
            <Certificate certificateKeystoreFile="conf/localhost-rsa.jks"
                         type="RSA" />
        </SSLHostConfig>
 </Connector>

et nous mettons notre configuration à côté d'eux:

    <Connector
           protocol="org.apache.coyote.http11.Http11NioProtocol"
           port="8443" maxThreads="200"
           scheme="https" secure="true" SSLEnabled="true"
           keystoreFile="C:\Users\user\.keystore" keystorePass="mypass"
           clientAuth="false" sslProtocol="TLS"/>

Nous attribuons les dernières valeurs aux paramètres keystoreFile et keystorePass, enregistrons le fichier, puis redémarrons Tomcat à l'aide des fichiers shutdown.bat et startup.bat. Le serveur est maintenant prêt à traiter les requêtes HTTPS. L'adresse a juste un peu changé : https://localhost:8443/demo/hello . Lorsque vous cliquez sur le lien, vous recevez un avertissement concernant la fiabilité du certificat, ce qui n'est pas surprenant. Comme nous l'avons dit un peu plus tôt, vous devez utiliser les services d'une des autorités de certification pour obtenir un certificat normal. Mais pour l'instant, nous avons atteint notre objectif : l'application fonctionne avec le protocole HTTPS, et c'est important !

Génération dynamique de pages HTML

Nous allons maintenant poursuivre notre tour d'horizon des conteneurs de servlets en considérant une autre fonctionnalité : la génération dynamique de pages HTML. Imaginez un monde parfait où, au lieu de code HTML statique ennuyeux, vous pourriez écrire du code Java, en utilisant des variables, des boucles, des tableaux et d'autres constructions de langage. Avez-vous pu l'imaginer ? La bonne nouvelle est que quelque chose de similaire existe. La mauvaise nouvelle est qu'il ne réalise pas entièrement ce fantasme. Si vous ne l'avez pas deviné, nous parlons de JavaServer Pages (JSP). En bref, il s'agit d'une technologie qui permet d'insérer des morceaux de code Java dans une page HTML. Certes, ce code Java est toujours converti en HTML avant d'être envoyé au client, mais ce HTML sera généré dynamiquement, en tenant compte de divers facteurs. Par exemple, vous pouvez utiliser des instructions conditionnelles et renvoyer un contenu différent en fonction de certaines conditions. Exemple de page JSP :

<%@ page language="java"" %>
<html>
<head>
<title>JSP</title>
</head>

<body>
<%
String firstName="name";
String secondName="surname";
    
    if (firstName.equals("name")){
      out.print("Hello: "+firstName+"<br>");
    }

    if (firstName.equals("name") && secondName.equals("surname"))
    {
      out.print("Hello, my dear friend! <br>");
    }
    else
    {
      out.print("I don't know you. Go away! <br>");
    }
%>
</body>
</html>

Vous pouvez en savoir plus sur JSP ici. En fin de compte, cet article ne concerne pas JSP — nous sommes ici pour parler de conteneurs de servlets ! Alors pourquoi avons-nous mentionné JSP ? C'est simple : un conteneur de servlet est ce qui convertit le code Java de JSP en HTML. Lorsqu'un servlet va renvoyer du contenu JSP en réponse, le conteneur en prend note et le convertit d'abord en une page HTML conviviale pour le navigateur avant d'envoyer ce contenu au client. Aujourd'hui, il existe de nombreux analogues à la technologie JSP - Thymeleaf, FreeMarket, Moustache et autres. Ils fonctionnent tous de la même manière. Lequel choisir pour votre travail est une question de goût. Cela s'applique également au choix d'un conteneur de servlets. Dans ces exemples, nous avons utilisé Tomcat, le conteneur le plus courant, mais certains projets utilisent d'autres conteneurs. Il vaut la peine de passer brièvement en revue les plus populaires et de voir en quoi ils diffèrent de Tomcat.

Alternatives à Tomcat

1. GlassFish est un conteneur open source dont le développement est soutenu par Oracle.

   Contrairement à Tomcat, il s'agit d'un serveur Web à part entière, qui, en plus des servlets, peut fonctionner avec d'autres composants du framework JavaEE. Cela dit, il utilise beaucoup plus de RAM. Il y a une plus grande flexibilité lors du réglage fin du serveur, ce qui complique son utilisation. Il doit être utilisé lors du développement d'applications sur le framework JavaEE.

2. WildFly était auparavant connu sous le nom de JBoss . Il est également open source. Il est développé par Red Hat. Le nom a été modifié pour éviter toute confusion avec un autre produit de la société, JBoss Enterprise Application Platform.

   Comme GlassFish, WildFly est un serveur Web à part entière. Incidemment, sous le capot, WildFly utilise Tomcat comme conteneur de servlet. Contrairement à GlassFish, WildFly est plus léger et facile à configurer.

3. Jetty , comme les précédents, est open source. Il est développé par Eclipse.

   Comme Tomcat, il s'agit d'un simple conteneur de servlets, sans prise en charge de tous les composants du framework JavaEE. En même temps, il est plus léger et peut même être exécuté sur un téléphone portable. Il démarre et s'arrête rapidement et évolue bien. Contrairement à Tomcat, il a une communauté et une base de connaissances plus petites.

4. WebLogic est un logiciel sous licence qui doit être acheté avant utilisation. Il appartient à Oracle.

   Il a des fonctionnalités légèrement plus larges que Tomcat. Il peut fonctionner avec le protocole FTP. Mais il n'est pas aussi flexible lors du développement et du test d'applications.

5. WebSphere (WebSphere Application Server, pour être précis) est un logiciel payant. Il est développé par IBM. Semblable à WildFly et GlassFish, il s'agit d'un serveur d'applications complet. Mais il a une interface de configuration plus conviviale, ainsi qu'une grande fiabilité de fonctionnement.

   Ses défauts incluent le fait qu'il utilise beaucoup de ressources et prend beaucoup de temps pour démarrer et s'arrêter, ce qui n'est pas très pratique lors du développement de petits projets.

Le choix du bon conteneur de servlets ou du bon serveur d'applications dépend du projet particulier. Il existe des projets où même un outsider clair peut s'avérer être un excellent choix, mais au début, il est préférable de faire une étude approfondie d'un conteneur de servlet. Tomcat est probablement le candidat idéal pour cette étude. Et nous avons déjà fait les premiers pas pour l'étudier, mais à partir de là, c'est à vous de décider ! Dans les derniers articles de la série "Introduction au développement d'entreprise", nous apprendrons à connaître le modèle MVC. Partie 7. Présentation du modèle MVC (Modèle-Vue-Contrôleur)