Del 6. Servletbeholdere

Dette materiale er en del af serien "Introduktion til virksomhedsudvikling". Tidligere artikler:

I den sidste artikel stiftede vi bekendtskab med servlets og lærte, hvordan man bruger dem til at lave webapplikationer. Tiden er inde til at se nærmere på en væsentlig del af denne sjove: Servletbeholdere.

Indholdsfortegnelse:

Hvad er en servletbeholder?

Det er et program, der kører på en server og kan interagere med de servlets, vi har oprettet. Med andre ord, hvis vi ønsker at køre vores webapplikation på en server, installerer vi først en servletcontainer og sætter derefter servlets i den. Arbejdsgangen er enkel: Når klienten får adgang til serveren, behandler containeren sin anmodning, bestemmer hvilken servlet der skal behandle den, og sender derefter anmodningen videre. Del 6. Servletbeholdere - 2

Hvordan bruges servletbeholdere?

Ud over routinganmodninger udfører en servletcontainer andre funktioner:

Det genererer dynamisk HTML-sider fra JSP-filer.
Det krypterer/dekrypterer HTTPS-meddelelser.
Det giver begrænset adgang til servlet-administration.

Generelt lyder det hele godt. Nu mangler vi bare at finde ud af, hvordan vi omsætter det hele i praksis. Nå, for at lære at bruge noget, skal du bare dykke ned og prøve at bruge det :) Så i dag skal vi øve! Den mest populære servletbeholder er Apache Tomcat . Det er open source og kan bruges gratis. Download Tomcat til dit operativsystem her , og vi vil undersøge arbejdet med containere "i aktion".

Installation og start af Tomcat

For at installere Tomcat skal du blot udpakke det downloadede arkiv i den ønskede mappe.
Bemærk venligst, at Tomcat kræver Java version 8 eller højere for at starte og køre. Kontroller, at miljøvariablen JAVA_HOME refererer til den aktuelle version af JDK.
Dernæst skal du konfigurere brugeradgang til Tomcat . Dette gøres i filen tomcat-users.xml, som er placeret i mappen conf.

Der er fire forudindstillede roller i Tomcat:
- manager-gui — Adgang til den grafiske grænseflade og statussiden
- manager-script — Adgang til tekstgrænsefladen og statussiden
- manager-jmx — Adgang til JMX og statussiden
- manager-status — Adgang kun til statussiden
Inde i <tomcat-users> tagget specificerer vi eksplicit disse roller og tildeler dem til vores bruger:
```
<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 er alt klar til lancering!
Kør filen startup.bat (startup.sh på Linux) i bin-mappen.
Efter et par sekunder skal du åbne linket http://localhost:8080/ i din browser. Du vil se et grafisk dashboard:

Hvis du ser en menu som denne, kører Tomcat.
Hvis det ikke kører, skal du manuelt kontrollere miljøvariablerne JAVA_HOME og CATALINA_HOME:
- JAVA_HOME — Dette skal referere til den aktuelle version af Java 8+.
- CATALINA_BASE — Dette skal referere til Tomcat eller være fraværende (det bør ikke referere til en anden version af Tomcat).

Implementering af en applikation i Tomcat

Det lykkedes os at lancere Tomcat, så det er nu tid til at implementere nogle projekter i den. Lad os bruge servlets fra den forrige artikel . 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");
   }
}

Før vi implementerer, skal vi pakke vores servlets i en WAR-fil. Maven bruges normalt til at gøre dette, men for at oprette en WAR-fil skal du bruge en web.xml-fil, der har en mapping for alle servlets. Vi brugte den nye @WebServlet-annotation til at skrive servlets, så vi har ikke en web.xml-fil. Heldigvis kan IDEA gøre det beskidte arbejde for os ved at pakke vores projekt ind i en WAR-fil. For at gøre dette skal du åbne projektstrukturen (Ctrl+Shift+Alt+S) -> Artefakter -> Vælg den ønskede WAR-fil -> Marker afkrydsningsfeltet ud for "Inkluder i projektopbygning" -> Klik på "OK". Del 6. Servletbeholdere - 4

Lad os bygge projektet ved hjælp af Ctrl+F9-tastkombinationen. Nu er vores WAR-fil i målmappen. Del 6. Servletbeholdere - 5

Filen kan omdøbes til noget enklere, f.eks. servlet.war, og flyttes til et mere bekvemt sted, f.eks. C:\\my\\.vi lægger det i en beholder . Der er to måder at gøre dette på.

Brug af den grafiske grænseflade

For at gøre dette skal du følge dette link: http://localhost:8080/manager/html . Tomcat bør bede om et brugernavn og en adgangskode.

Hvis du har fulgt mig op til dette punkt, så er brugernavnet "bruger", og adgangskoden er "adgangskode" .

Når du har logget ind, vil du se Tomcat Web Application Manager. Sektionen "Applikationer" indeholder allerede 5 applikationer — disse er Tomcat-værktøjer, som gør Tomcat nemmere at arbejde med. De kan slettes i fremtiden.

Nedenfor er sektionen "Deploy". Her kan du vælge det WAR-arkiv, der skal implementeres. Lad os indtaste stien og konteksten manuelt:

Klik på "Deploy", og vi ser, at vores applikation er dukket op i sektionen "Applications":
Ved at bruge Tomcats grafiske grænseflade kan vi stoppe, genstarte og slette en session, samt indstille sessionslængden. Ved implementeringen specificerede vi /demo-konteksten, hvilket betyder, at vores applikation tilgås ved hjælp af http://localhost:8080/demo . Tjekke det. Alt burde virke.
Gennem filsystemet

For at implementere applikationen på denne måde skal du åbne den mappe, hvor Tomcat blev pakket ud. Gå derefter til mappen "webapps". Her finder du de værktøjer, vi allerede har stødt på:

Det eneste, der kræves, er, at vi flytter vores servlet.war-fil hertil.

Vi venter et par sekunder og ser så, at en ny "servlet"-mappe er dukket op. Det betyder, at vores applikation er implementeret. Gå til Application Manager-grænsefladen på http://localhost:8080/manager/ . Her ser vi, at vores applikation er implementeret i /servlet-konteksten:

Når den implementeres på denne måde, tildeles konteksten automatisk baseret på navnet på den installerede WAR-fil. For at ændre konteksten kan du omdøbe den nyoprettede mappe, der indeholder programmet, men før du gør det, skal du fjerne WAR-filen. Ellers vil Tomcat geninstallere applikationen med arkivnavnet.

Som du kan se, er implementering af applikationer i Tomcat meget nemmere, end det måske ser ud til. Men dens andre funktioner er også nemme at bruge. Lad os tjekke.

Brug af HTTPS i stedet for HTTP

Hvis du husker det, så vi på forskellen mellem HTTP og HTTPS i en separat artikel . HTTPS er den samme protokol som HTTP, men den krypterer de data, der overføres. På klientsiden er browseren ansvarlig for kryptering, men vi skal sørge for krypteringen på serversiden. Da Tomcat accepterer og dirigerer HTTP-anmodninger, giver det mening at uddelegere kryptering til den. For at gøre dette skal vi:

Generer et selvsigneret certifikat
Foretag yderligere serverindstillinger

Lad os øve os i at gøre dette.

Generering af et certifikat

Uanset versionen inkluderer JDK et stort antal hjælpeprogrammer. Et af dem er keytool . Dette er et værktøj til at generere og arbejde med krypteringsnøgler. For at bruge det skal du på kommandolinjen gå til mappen C:\\Program Files\\Java\\jdk1.8.0_181\\bin og køre kommandoen keytool -genkey -alias tomcat -keyalg RSA .

keytool — Navnet på det værktøj, som vi kører med kommandolinjeindstillinger
-genkey — Angiv, at vi ønsker at generere en ny nøgle
-alias tomcat — Opret et nøglealias
-keyalg RSA — Vælg RSA som nøglegenereringsalgoritmen

Efter at have udført kommandoen, starter hjælpeprogrammet en dialog med os: Del 6. Servletbeholdere - 11

Indtast de nødvendige oplysninger. Nu har vi oprettet et nøglelager i vores hjemmemappe (for Windows er dette C:\\Users\\{brugernavn}\\.keystore) og en tomcat-nøgle i den. Vi genererede et simpelt certifikat, som de fleste browsere vil klage over. Et sådant certifikat er ikke egnet til kommercielle anvendelser: det kan kun bruges til testformål. På en produktionsserver skal du bruge et certifikat fra en certificeringsmyndighed (f.eks. https://letsencrypt.org/ ).

Konfiguration af serveren

Nu hvor certifikatet er klar, skal vi justere serverindstillingerne, nemlig SSL-stikket. Dette gøres i server.xml filen, som er placeret i apache-tomcat-9.0.30/conf/ . I den finder vi blokke som dette:

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

og vi sætter vores konfiguration ved siden af dem:

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

Vi tildeler de seneste værdier til keystoreFile og keystorePass parametrene, gemmer filen og genstarter derefter Tomcat ved hjælp af shutdown.bat og startup.bat filerne. Nu er serveren klar til at behandle HTTPS-anmodninger. Adressen har ændret sig lidt: https://localhost:8443/demo/hello . Når du klikker på linket, vil du modtage en advarsel om certifikatets troværdighed, hvilket ikke er overraskende. Som vi sagde lidt tidligere, skal du bruge tjenesterne fra en af certificeringsmyndighederne for at opnå et normalt certifikat. Men indtil videre har vi nået vores mål: applikationen kører ved hjælp af HTTPS-protokollen, og det er vigtigt!

Dynamisk generering af HTML-sider

Nu fortsætter vi vores oversigt over servlet-containere ved at overveje en anden funktion: dynamisk generering af HTML-sider. Forestil dig en perfekt verden, hvor du i stedet for kedelig statisk HTML-kode kunne skrive Java-kode ved hjælp af variabler, loops, arrays og andre sprogkonstruktioner. Kunne du forestille dig det? Den gode nyhed er, at der findes noget lignende. Den dårlige nyhed er, at den ikke helt opnår denne fantasi. Hvis du ikke har gættet, taler vi om JavaServer Pages (JSP). Kort sagt er dette teknologi, der lader dig indsætte stykker Java-kode på en HTML-side. Ganske vist konverteres denne Java-kode stadig til HTML, før den sendes til klienten, men den HTML vil blive dynamisk genereret under hensyntagen til forskellige faktorer. For eksempel, du kan bruge betingede erklæringer og returnere forskelligt indhold afhængigt af en betingelse. Eksempel på JSP-side:

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

Du kan læse mere om JSP her. I sidste ende handler denne artikel ikke om JSP - vi er her for at tale om servlet-beholdere! Så hvorfor nævnte vi JSP? Det er enkelt: En servlet-container er det, der konverterer Java-kode fra JSP til HTML. Når en servlet skal returnere JSP-indhold som et svar, tager containeren det til efterretning og konverterer det først til en browservenlig HTML-side, før den sender sådant indhold til klienten. I dag er der mange analoger til JSP-teknologi - Thymeleaf, FreeMarket, Moustache og andre. De arbejder alle på samme måde. Hvilken af dem du skal vælge til dit arbejde er en smagssag. Det gælder også ved valg af servletbeholder. I disse eksempler brugte vi Tomcat, den mest almindelige container, men nogle projekter bruger andre containere. Det er umagen værd at kort gennemgå de mest populære og overveje, hvordan de adskiller sig fra Tomcat.

Alternativer til Tomcat

GlassFish er en open source-beholder, hvis udvikling er understøttet af Oracle.

I modsætning til Tomcat er det en fuldgyldig webserver, som udover servlets kan fungere med andre komponenter fra JavaEE frameworket. Når det er sagt, bruger den meget mere RAM. Der er større fleksibilitet ved finjustering af serveren, hvilket komplicerer brugen af den. Det skal bruges ved udvikling af applikationer på JavaEE-rammeværket.
WildFly var tidligere kendt som JBoss . Det er også open source. Det er udviklet af Red Hat. Navnet blev ændret for at undgå forveksling med et andet af virksomhedens produkter - JBoss Enterprise Application Platform.

Ligesom GlassFish er WildFly en fuldgyldig webserver. Under motorhjelmen bruger WildFly i øvrigt Tomcat som servletbeholder. I modsætning til GlassFish er WildFly mere let og nem at konfigurere.
Jetty er ligesom de foregående open source. Det er udviklet af Eclipse.

Ligesom Tomcat er det en simpel servlet-beholder uden understøttelse af alle komponenterne i JavaEE-rammeværket. Samtidig er den mere let og kan endda køres på en mobiltelefon. Den starter og stopper hurtigt og skalerer godt. I modsætning til Tomcat har den et mindre fællesskab og vidensbase.
WebLogic er licenseret software, der skal købes før brug. Det tilhører Oracle.

Den har lidt bredere funktionalitet end Tomcat. Det kan arbejde med FTP-protokollen. Men det er ikke så fleksibelt, når man udvikler og tester applikationer.
WebSphere (WebSphere Application Server, for at være præcis) er betalt software. Det er udviklet af IBM. I lighed med WildFly og GlassFish er det en komplet applikationsserver. Men den har en venligere konfigurationsgrænseflade plus høj driftssikkerhed.

Dens mangler omfatter det faktum, at det bruger mange ressourcer og tager lang tid at starte og stoppe, hvilket ikke er særlig praktisk, når man udvikler små projekter.

Valget af den rigtige servletcontainer eller applikationsserver afhænger af det specifikke projekt. Der er projekter, hvor selv en klar underdog kan vise sig at være et glimrende valg, men i første omgang er det bedst at lave en dybdegående undersøgelse af en servletbeholder. Tomcat er sandsynligvis den perfekte kandidat til denne undersøgelse. Og vi har allerede taget de første skridt i at studere det, men herfra er det op til dig! I de sidste artikler i serien "Introduktion til virksomhedsudvikling" lærer vi MVC-mønsteret at kende. Del 7. Introduktion til MVC-mønsteret (Model-View-Controller).