Deel 6. Servletcontainers

Dit materiaal maakt deel uit van de serie "Inleiding tot Enterprise Development". Vorige artikelen:

• over netwerken
• over software-architectuur
• over HTTP/HTTPS
• over de basis van Maven
• over servlets (een eenvoudige webapplicatie schrijven)

In het vorige artikel hebben we kennis gemaakt met servlets en geleerd hoe we ze kunnen gebruiken om webapplicaties te maken. Het is tijd om een ​​essentieel onderdeel van dit plezier onder de loep te nemen: servletcontainers.

Inhoudsopgave:

• Wat is een servletcontainer?
• Hoe worden servletcontainers gebruikt?
• Tomcat installeren en starten
• Een toepassing implementeren in Tomcat
• HTTPS gebruiken in plaats van HTTP
• Een certificaat genereren
• De server configureren
• Dynamisch genereren van HTML-pagina's
• Alternatieven voor Tomcat

Wat is een servletcontainer?

Het is een programma dat op een server draait en kan communiceren met de servlets die we hebben gemaakt. Met andere woorden, als we onze webapplicatie op een server willen draaien, zetten we eerst een servletcontainer in en plaatsen daar vervolgens servlets in. De workflow is eenvoudig: wanneer de client toegang krijgt tot de server, verwerkt de container zijn verzoek, bepaalt welke servlet het moet verwerken, en geeft het verzoek vervolgens door.

Hoe worden servletcontainers gebruikt?

Naast routeringsverzoeken voert een servletcontainer nog andere functies uit:

1. Het genereert dynamisch HTML-pagina's van JSP-bestanden.
2. Het codeert/decodeert HTTPS-berichten.
3. Het biedt beperkte toegang voor servletbeheer.

Over het algemeen klinkt dit allemaal goed. Nu moeten we alleen nog bedenken hoe we het allemaal in de praktijk kunnen brengen. Nou, om te leren hoe je iets moet gebruiken, duik je er gewoon in en probeer je het te gebruiken :) Dus vandaag gaan we oefenen! De meest populaire servletcontainer is Apache Tomcat . Het is open source en kan gratis worden gebruikt. Download hier Tomcat voor uw besturingssysteem en we verkennen het werken met containers "in actie".

Tomcat installeren en starten

1. Om Tomcat te installeren, pakt u eenvoudig het gedownloade archief uit in de gewenste map.

2. Houd er rekening mee dat Tomcat Java-versie 8 of hoger vereist om te starten en uit te voeren. Controleer of de omgevingsvariabele JAVA_HOME verwijst naar de huidige versie van de JDK.

3. Vervolgens moet u gebruikerstoegang tot Tomcat configureren . Dit gebeurt in het bestand tomcat-users.xml, dat zich in de map conf bevindt.

   Er zijn vier vooraf ingestelde rollen in Tomcat:

   • manager-gui — Toegang tot de grafische interface en statuspagina
   • manager-script — Toegang tot de tekstinterface en statuspagina
   • manager-jmx — Toegang tot JMX en de statuspagina
   • manager-status — Alleen toegang tot de statuspagina

   Binnen de tag <tomcat-users> specificeren we expliciet deze rollen en wijzen ze toe aan onze gebruiker:

   
   <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"/>
   

   Nu is alles klaar om te lanceren!

4. Voer in de map bin het bestand startup.bat uit (startup.sh op Linux).

5. Open na enkele seconden de link http://localhost:8080/ in uw browser. U ziet een grafisch dashboard:

   Als u een dergelijk menu ziet, is Tomcat actief.

6. Als het niet actief is, controleer dan handmatig de omgevingsvariabelen JAVA_HOME en CATALINA_HOME:

   • JAVA_HOME — Dit moet verwijzen naar de huidige versie van Java 8+.
   • CATALINA_BASE — Dit moet verwijzen naar Tomcat of afwezig zijn (het mag niet verwijzen naar een andere versie van Tomcat).

Een toepassing implementeren in Tomcat

We zijn erin geslaagd om Tomcat te lanceren, dus het is nu tijd om er een project in te implementeren. Laten we de servlets uit het vorige artikel gebruiken . HoofdServlet:

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");
   }
}

Voordat we deze implementeren, moeten we onze servlets verpakken in een WAR-bestand. Maven wordt meestal gebruikt om dit te doen, maar om een ​​WAR-bestand te maken, hebt u een web.xml-bestand nodig dat een toewijzing heeft voor alle servlets. We hebben de nieuwe @WebServlet-annotatie gebruikt om de servlets te schrijven, dus we hebben geen web.xml-bestand. Gelukkig kan IDEA het vuile werk voor ons opknappen door ons project in een WAR-dossier te verpakken. Open hiervoor de projectstructuur (Ctrl+Shift+Alt+S) -> Artifacts -> Selecteer het gewenste WAR-bestand -> Schakel het selectievakje naast "Include in project build" in -> Klik op "OK". Laten we het project bouwen met de toetscombinatie Ctrl+F9. Ons WAR-bestand bevindt zich nu in de doeldirectory. Het bestand kan worden hernoemd naar iets eenvoudigers, bijv. servlet.war, en naar een handiger plaats worden verplaatst, bijv. C:\\my\\.we stoppen het in een container . Er zijn twee manieren om dit te doen.

1. De grafische interface gebruiken

   Volg hiervoor deze link: http://localhost:8080/manager/html . Tomcat zou om een ​​gebruikersnaam en wachtwoord moeten vragen.

   Als je me tot nu toe hebt gevolgd, dan is de gebruikersnaam "gebruiker" en het wachtwoord "wachtwoord" .

   Nadat u zich succesvol hebt aangemeld, ziet u de Tomcat Web Application Manager. Het gedeelte "Toepassingen" bevat al 5 toepassingen - dit zijn Tomcat-hulpprogramma's, waardoor Tomcat gemakkelijker te gebruiken is. Ze kunnen in de toekomst worden verwijderd.

   Hieronder vindt u het gedeelte "Implementeren". Hier kunt u het WAR-archief selecteren dat u wilt implementeren. Laten we het pad en de context handmatig invoeren:

   Klik op "Inzetten" en we zien dat onze applicatie is verschenen in het gedeelte "Toepassingen":

   Met behulp van de grafische interface van Tomcat kunnen we een sessie stoppen, herstarten en verwijderen, en de sessieduur instellen. Bij de implementatie hebben we de /demo-context gespecificeerd, wat betekent dat onze applicatie wordt benaderd via http://localhost:8080/demo . Controleer het. Alles zou moeten werken.

2. Via het bestandssysteem

   Om de toepassing op deze manier te implementeren, moet u de map openen waarin Tomcat is uitgepakt. Ga dan naar de map "webapps". Hier vindt u de hulpprogramma's die we al zijn tegengekomen:

   Het enige dat nodig is, is dat we ons servlet.war-bestand hierheen verplaatsen.

   We wachten een paar seconden en zien dan dat er een nieuwe "servlet"-map is verschenen. Dit betekent dat onze applicatie wordt ingezet. Ga naar de Application Manager-interface op http://localhost:8080/manager/ . Hier zien we dat onze applicatie wordt ingezet in de /servlet-context:

   Wanneer het op deze manier wordt geïmplementeerd, wordt de context automatisch toegewezen op basis van de naam van het geïmplementeerde WAR-bestand. Om de context te wijzigen, kunt u de nieuw gemaakte map met de toepassing hernoemen, maar voordat u dat doet, moet u het WAR-bestand verwijderen. Anders zal Tomcat de toepassing opnieuw implementeren met de archiefnaam.

   Zoals u kunt zien, is het implementeren van applicaties in Tomcat veel eenvoudiger dan het lijkt. Maar ook de andere functies zijn gemakkelijk te gebruiken. Laten we het controleren.

HTTPS gebruiken in plaats van HTTP

Als je het je herinnert, hebben we in een apart artikel naar het verschil tussen HTTP en HTTPS gekeken . HTTPS is hetzelfde protocol als HTTP, maar versleutelt de verzonden gegevens. Aan de clientzijde is de browser verantwoordelijk voor de codering, maar wij moeten de codering aan de serverzijde leveren. Aangezien Tomcat HTTP-verzoeken accepteert en doorstuurt, is het logisch om er codering aan te delegeren. Om dit te doen, moeten we:

1. Genereer een zelfondertekend certificaat
2. Maak aanvullende serverinstellingen

Laten we oefenen om dit te doen.

Een certificaat genereren

Ongeacht de versie bevat de JDK een groot aantal hulpprogramma's. Een daarvan is keytool . Dit is een hulpmiddel voor het genereren van en werken met coderingssleutels. Om het te gebruiken, gaat u op de opdrachtregel naar de map C:\\Program Files\\Java\\jdk1.8.0_181\\bin en voert u de opdracht keytool -genkey -alias tomcat -keyalg RSA uit .

• keytool — De naam van het hulpprogramma dat we uitvoeren met opdrachtregelopties
• -genkey — Geef aan dat we een nieuwe sleutel willen genereren
• -alias kater — Maak een sleutelalias
• -keyalg RSA — Selecteer RSA als algoritme voor het genereren van sleutels

Na het uitvoeren van de opdracht begint het hulpprogramma een dialoog met ons: Voer de benodigde informatie in. Nu hebben we een keystore gemaakt in onze homedirectory (voor Windows is dit C:\\Users\\{username}\\.keystore) en een katersleutel erin. We hebben een eenvoudig certificaat gegenereerd waar de meeste browsers over zullen klagen. Een dergelijk certificaat is niet geschikt voor commerciële toepassingen: het kan alleen gebruikt worden voor testdoeleinden. Op een productieserver moet u een certificaat van een certificeringsinstantie gebruiken (bijvoorbeeld https://letsencrypt.org/ ).

De server configureren

Nu het certificaat klaar is, moeten we de serverinstellingen aanpassen, namelijk de SSL-connector. Dit wordt gedaan in het bestand server.xml, dat zich bevindt in apache-tomcat-9.0.30/conf/ . Daarin vinden we blokken zoals deze:

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

en we zetten onze configuratie ernaast:

    <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"/>

We wijzen de nieuwste waarden toe aan de parameters keystoreFile en keystorePass, slaan het bestand op en starten Tomcat vervolgens opnieuw op met behulp van de bestanden shutdown.bat en startup.bat. Nu is de server klaar om HTTPS-verzoeken te verwerken. Het adres is een beetje veranderd: https://localhost:8443/demo/hello . Wanneer u op de link klikt, krijgt u een waarschuwing over de betrouwbaarheid van het certificaat, wat niet verwonderlijk is. Zoals we eerder zeiden, moet u gebruik maken van de diensten van een van de certificeringsinstanties om een ​​normaal certificaat te verkrijgen. Maar voor nu hebben we ons doel bereikt: de applicatie draait met het HTTPS-protocol, en dat is belangrijk!

Dynamisch genereren van HTML-pagina's

Nu gaan we verder met ons overzicht van servletcontainers door een andere functie te overwegen: het dynamisch genereren van HTML-pagina's. Stel je een perfecte wereld voor waarin je, in plaats van saaie statische HTML-code, Java-code zou kunnen schrijven met behulp van variabelen, loops, arrays en andere taalconstructies. Kon je het je voorstellen? Het goede nieuws is dat er iets soortgelijks bestaat. Het slechte nieuws is dat het deze fantasie niet helemaal waarmaakt. Als je het nog niet geraden hebt, hebben we het over JavaServer Pages (JSP). Kort gezegd is dit technologie waarmee je stukjes Java-code in een HTML-pagina kunt invoegen. Toegegeven, deze Java-code wordt nog steeds omgezet in HTML voordat deze naar de client wordt verzonden, maar die HTML wordt dynamisch gegenereerd, rekening houdend met verschillende factoren. Bijvoorbeeld, u kunt voorwaardelijke verklaringen gebruiken en verschillende inhoud retourneren, afhankelijk van een bepaalde voorwaarde. Voorbeeld JSP-pagina:

<%@ 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>

U kunt hier meer lezen over JSP. Uiteindelijk gaat dit artikel niet over JSP - we zijn hier om te praten over servletcontainers! Dus waarom hebben we JSP genoemd? Het is eenvoudig: een servletcontainer converteert Java-code van JSP naar HTML. Wanneer een servlet JSP-inhoud als antwoord retourneert, merkt de container dit op en converteert deze eerst naar een browservriendelijke HTML-pagina voordat dergelijke inhoud naar de client wordt verzonden. Tegenwoordig zijn er veel analogen met JSP-technologie: Thymeleaf, FreeMarket, Moustache en andere. Ze werken allemaal op een vergelijkbare manier. Welke van hen u voor uw werk kiest, is een kwestie van smaak. Dit geldt ook voor het kiezen van een servletcontainer. In deze voorbeelden hebben we Tomcat gebruikt, de meest voorkomende container, maar sommige projecten gebruiken andere containers. Het is de moeite waard om kort de meest populaire te bekijken en na te gaan hoe ze verschillen van Tomcat.

Alternatieven voor Tomcat

1. GlassFish is een open source container waarvan de ontwikkeling wordt ondersteund door Oracle.

   In tegenstelling tot Tomcat is het een volwaardige webserver, die naast servlets ook met andere componenten uit het JavaEE-framework kan werken. Dat gezegd hebbende, het gebruikt veel meer RAM. Er is meer flexibiliteit bij het afstemmen van de server, wat het gebruik ervan bemoeilijkt. Het moet worden gebruikt bij het ontwikkelen van applicaties op het JavaEE-framework.

2. WildFly was voorheen bekend als JBoss . Het is ook open source. Het is ontwikkeld door RedHat. De naam is gewijzigd om verwarring met een ander product van het bedrijf te voorkomen: JBoss Enterprise Application Platform.

   Net als GlassFish is WildFly een volwaardige webserver. Overigens gebruikt WildFly onder de motorkap Tomcat als servletcontainer. In tegenstelling tot GlassFish is WildFly lichter en eenvoudiger te configureren.

3. Jetty is, net als de vorige, open source. Het is ontwikkeld door Eclipse.

   Net als Tomcat is het een eenvoudige servletcontainer, zonder ondersteuning voor alle componenten van het JavaEE-framework. Tegelijkertijd is het lichter en kan het zelfs op een mobiele telefoon worden gebruikt. Hij start en stopt snel en schaalt goed. In tegenstelling tot Tomcat heeft het een kleinere community en kennisbank.

4. WebLogic is gelicentieerde software die voor gebruik moet worden aangeschaft. Het is van Oracle.

   Het heeft een iets bredere functionaliteit dan Tomcat. Het kan werken met het FTP-protocol. Maar het is niet zo flexibel bij het ontwikkelen en testen van applicaties.

5. WebSphere (WebSphere Application Server, om precies te zijn) is betaalde software. Het is ontwikkeld door IBM. Net als WildFly en GlassFish is het een complete applicatieserver. Maar het heeft een vriendelijkere configuratie-interface en een hoge bedrijfszekerheid.

   De tekortkomingen zijn onder meer dat het veel middelen gebruikt en dat het lang duurt om te starten en te stoppen, wat niet erg handig is bij het ontwikkelen van kleine projecten.

De keuze van de juiste servletcontainer of applicatieserver hangt af van het specifieke project. Er zijn projecten waar zelfs een duidelijke underdog een uitstekende keuze kan blijken te zijn, maar in eerste instantie is het het beste om een ​​diepgaande studie te maken van één servletcontainer. Tomcat is waarschijnlijk de perfecte kandidaat voor deze studie. En we hebben al de eerste stappen gezet om het te bestuderen, maar vanaf hier is het aan jou! In de laatste artikelen van de serie "Inleiding tot Enterprise Development" zullen we het MVC-patroon leren kennen. Deel 7. Introductie van het MVC-patroon (Model-View-Controller).