Del 6. Servletbeholdere

Dette materialet er en del av serien "Introduksjon til bedriftsutvikling". Tidligere artikler:

I den siste artikkelen ble vi kjent med servlets og lærte å bruke dem til å lage webapplikasjoner. Tiden er inne for å se nærmere på en viktig del av denne moroa: Servletbeholdere.

Innholdsfortegnelse:

Hva er en servletbeholder?

Det er et program som kjører på en server og kan samhandle med servletene vi har laget. Med andre ord, hvis vi ønsker å kjøre nettapplikasjonen vår på en server, distribuerer vi først en servletbeholder og legger deretter servlets i den. Arbeidsflyten er enkel: når klienten får tilgang til serveren, behandler containeren forespørselen sin, bestemmer hvilken servlet som skal behandle den, og sender deretter forespørselen videre. Del 6. Servletbeholdere - 2

Hvordan brukes servletbeholdere?

I tillegg til rutingforespørsler, utfører en servletbeholder andre funksjoner:

Den genererer dynamisk HTML-sider fra JSP-filer.
Den krypterer/dekrypterer HTTPS-meldinger.
Det gir begrenset tilgang for servletadministrasjon.

Generelt høres dette bra ut. Nå må vi bare finne ut hvordan vi skal sette det hele i praksis. Vel, for å lære å bruke noe er det bare å dykke ned og prøve å bruke det :) Så, i dag skal vi øve! Den mest populære servletbeholderen er Apache Tomcat . Det er åpen kildekode og kan brukes gratis. Last ned Tomcat for operativsystemet ditt her , så skal vi utforske arbeidet med containere "i aksjon".

Installere og starte Tomcat

For å installere Tomcat, pakke ut det nedlastede arkivet til ønsket katalog.
Vær oppmerksom på at Tomcat krever Java versjon 8 eller høyere for å starte og kjøre. Kontroller at miljøvariabelen JAVA_HOME refererer til gjeldende versjon av JDK.
Deretter må du konfigurere brukertilgang til Tomcat . Dette gjøres i filen tomcat-users.xml, som ligger i conf-mappen.

Det er fire forhåndsinnstilte roller i Tomcat:
- manager-gui — Tilgang til det grafiske grensesnittet og statussiden
- manager-script — Tilgang til tekstgrensesnittet og statussiden
- manager-jmx — Tilgang til JMX og statussiden
- manager-status — Bare tilgang til statussiden
Inne i <tomcat-users>-taggen spesifiserer vi disse rollene eksplisitt og tildeler dem til brukeren vår:
```
<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"/>
```
Nå er alt klart til lansering!
I bin-mappen kjører du startup.bat-filen (startup.sh på Linux).
Etter noen sekunder åpner du lenken http://localhost:8080/ i nettleseren din. Du vil se et grafisk dashbord:

Hvis du ser en meny som denne, kjører Tomcat.
Hvis den ikke kjører, sjekk miljøvariablene JAVA_HOME og CATALINA_HOME manuelt:
- JAVA_HOME — Dette må referere til gjeldende versjon av Java 8+.
- CATALINA_BASE — Dette må referere til Tomcat eller være fraværende (det skal ikke referere til en annen versjon av Tomcat).

Distribuere en applikasjon i Tomcat

Vi klarte å lansere Tomcat, så det er nå på tide å distribuere noen prosjekter i den. La oss bruke servletene fra forrige artikkel . 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 distribuerer, må vi pakke servletene våre i en WAR-fil. Maven brukes vanligvis til dette, men for å lage en WAR-fil trenger du en web.xml-fil som har en mapping for alle servletene. Vi brukte den nye @WebServlet-kommentaren til å skrive servletene, så vi har ikke en web.xml-fil. Heldigvis kan IDEA gjøre det skitne arbeidet for oss, og pakke inn prosjektet vårt i en WAR-fil. For å gjøre dette, åpne prosjektstrukturen (Ctrl+Shift+Alt+S) -> Artefakter -> Velg ønsket WAR-fil -> Merk av i boksen ved siden av "Inkluder i prosjektbygging" -> Klikk på "OK". Del 6. Servletbeholdere - 4

La oss bygge prosjektet ved å bruke Ctrl+F9 tastekombinasjonen. Nå er WAR-filen vår i målkatalogen. Del 6. Servletbeholdere - 5

Filen kan omdøpes til noe enklere, f.eks. servlet.war, og flyttes til et mer praktisk sted, f.eks. C:\\my\\.vi legger den i en beholder . Det er to måter å gjøre dette på.

Bruke det grafiske grensesnittet

For å gjøre dette, følg denne linken: http://localhost:8080/manager/html . Tomcat bør be om brukernavn og passord.

Hvis du fulgte meg frem til dette punktet, er brukernavnet "bruker", og passordet er "passord" .

Etter vellykket pålogging vil du se Tomcat Web Application Manager. "Applikasjoner"-delen inneholder allerede 5 applikasjoner - disse er Tomcat-verktøy, som gjør Tomcat lettere å jobbe med. De kan slettes i fremtiden.

Nedenfor er "Deploy"-delen. Her kan du velge WAR-arkivet som skal distribueres. La oss legge inn banen og konteksten manuelt:

Klikk "Deploy" og vi ser at applikasjonen vår har dukket opp i "Applikasjoner"-delen:
Ved å bruke Tomcats grafiske grensesnitt kan vi stoppe, starte på nytt og slette en økt, samt angi øktlengden. Ved distribusjon spesifiserte vi /demo-konteksten, noe som betyr at applikasjonen vår åpnes ved å bruke http://localhost:8080/demo . Sjekk det. Alt skal fungere.
Gjennom filsystemet

For å distribuere applikasjonen på denne måten, må du åpne katalogen der Tomcat ble pakket ut. Gå deretter til "webapps"-mappen. Her finner du verktøyene vi allerede har møtt:

Alt som kreves er at vi flytter filen servlet.war hit.

Vi venter noen sekunder og ser så at en ny "servlet"-mappe har dukket opp. Dette betyr at applikasjonen vår er distribuert. Gå til Application Manager-grensesnittet på http://localhost:8080/manager/ . Her ser vi at applikasjonen vår er distribuert i /servlet-konteksten:

Når den distribueres på denne måten, tildeles konteksten automatisk basert på navnet på den distribuerte WAR-filen. For å endre konteksten kan du gi nytt navn til den nyopprettede mappen som inneholder applikasjonen, men før du gjør det må du fjerne WAR-filen. Ellers vil Tomcat omdistribuere applikasjonen med arkivnavnet.

Som du kan se, er det mye enklere å distribuere applikasjoner i Tomcat enn det kan virke. Men de andre funksjonene er også enkle å bruke. La oss sjekke.

Bruker HTTPS i stedet for HTTP

Hvis du husker, så vi på forskjellen mellom HTTP og HTTPS i en egen artikkel . HTTPS er samme protokoll som HTTP, men den krypterer dataene som overføres. På klientsiden er nettleseren ansvarlig for kryptering, men vi må sørge for krypteringen på serversiden. Siden Tomcat godtar og ruter HTTP-forespørsler, er det fornuftig å delegere kryptering til den. For å gjøre dette må vi:

Generer et selvsignert sertifikat
Gjør flere serverinnstillinger

La oss øve på dette.

Generering av et sertifikat

Uavhengig av versjonen inkluderer JDK et stort antall verktøy. En av dem er nøkkelverktøy . Dette er et verktøy for å generere og arbeide med krypteringsnøkler. For å bruke den, på kommandolinjen, gå til C:\\Program Files\\Java\\jdk1.8.0_181\\bin -katalogen og kjør kommandoen keytool -genkey -alias tomcat -keyalg RSA .

keytool — Navnet på verktøyet som vi kjører med kommandolinjealternativer
-genkey — Indikerer at vi ønsker å generere en ny nøkkel
-alias tomcat — Opprett et nøkkelalias
-keyalg RSA — Velg RSA som nøkkelgenereringsalgoritmen

Etter å ha utført kommandoen, starter verktøyet en dialog med oss: Del 6. Servletbeholdere - 11

Skriv inn nødvendig informasjon. Nå har vi opprettet et nøkkellager i hjemmekatalogen vår (for Windows er dette C:\\Users\\{brukernavn}\\.keystore) og en tomcat-nøkkel i den. Vi genererte et enkelt sertifikat som de fleste nettlesere vil klage på. Et slikt sertifikat er ikke egnet for kommersielle applikasjoner: det kan bare brukes til testformål. På en produksjonsserver må du bruke et sertifikat fra en sertifiseringsinstans (for eksempel https://letsencrypt.org/ ).

Konfigurering av serveren

Nå som sertifikatet er klart, må vi justere serverinnstillingene, nemlig SSL-kontakten. Dette gjøres i server.xml-filen, som ligger i apache-tomcat-9.0.30/conf/ . I den finner vi blokker 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 legger vår konfigurasjon ved siden av 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 nyeste verdiene til keystoreFile og keystorePass-parameterne, lagrer filen og starter deretter Tomcat på nytt ved å bruke filene shutdown.bat og startup.bat. Nå er serveren klar til å behandle HTTPS-forespørsler. Adressen har bare endret seg litt: https://localhost:8443/demo/hello . Når du klikker på lenken vil du motta en advarsel om påliteligheten til sertifikatet, noe som ikke er overraskende. Som vi sa litt tidligere, må du bruke tjenestene til en av sertifiseringsmyndighetene for å få et vanlig sertifikat. Men foreløpig har vi nådd målet vårt: applikasjonen kjører ved hjelp av HTTPS-protokollen, og det er viktig!

Dynamisk generering av HTML-sider

Nå fortsetter vi vår oversikt over servletbeholdere ved å vurdere en annen funksjon: dynamisk generering av HTML-sider. Se for deg en perfekt verden hvor du, i stedet for kjedelig statisk HTML-kode, kan skrive Java-kode ved å bruke variabler, løkker, arrays og andre språkkonstruksjoner. Klarte du å forestille deg det? Den gode nyheten er at noe lignende finnes. Den dårlige nyheten er at den ikke helt oppnår denne fantasien. Hvis du ikke har gjettet, snakker vi om JavaServer Pages (JSP). Kort fortalt er dette teknologi som lar deg sette inn deler av Java-kode på en HTML-side. Riktignok konverteres denne Java-koden fortsatt til HTML før den sendes til klienten, men denne HTML vil bli dynamisk generert, tatt i betraktning ulike faktorer. For eksempel, du kan bruke betingede utsagn og returnere forskjellig innhold avhengig av en tilstand. 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 lese mer om JSP her. På slutten av dagen handler ikke denne artikkelen om JSP – vi er her for å snakke om servlet-beholdere! Så hvorfor nevnte vi JSP? Det er enkelt: en servletbeholder er det som konverterer Java-kode fra JSP til HTML. Når en servlet skal returnere JSP-innhold som et svar, tar beholderen det til etterretning og konverterer det først til en nettleservennlig HTML-side før slikt innhold sendes til klienten. I dag er det mange analoger til JSP-teknologi - Thymeleaf, FreeMarket, Moustache og andre. De jobber alle på samme måte. Hvilken av dem du skal velge for arbeidet ditt er en smakssak. Dette gjelder også ved valg av servletbeholder. I disse eksemplene brukte vi Tomcat, den vanligste beholderen, men noen prosjekter bruker andre beholdere. Det er verdt å kort gjennomgå de mest populære og vurdere hvordan de skiller seg fra Tomcat.

Alternativer til Tomcat

GlassFish er en åpen kildekodebeholder hvis utvikling støttes av Oracle.

I motsetning til Tomcat er det en fullverdig webserver, som i tillegg til servlets kan operere med andre komponenter fra JavaEE-rammeverket. Når det er sagt, bruker den mye mer RAM. Det er større fleksibilitet ved finjustering av serveren, noe som kompliserer bruken. Det bør brukes når du utvikler applikasjoner på JavaEE-rammeverket.
WildFly var tidligere kjent som JBoss . Det er også åpen kildekode. Den er utviklet av Red Hat. Navnet ble endret for å unngå forvirring med et annet av selskapets produkter - JBoss Enterprise Application Platform.

I likhet med GlassFish er WildFly en fullverdig webserver. Forresten, under panseret bruker WildFly Tomcat som en servletbeholder. I motsetning til GlassFish er WildFly mer lett og enkel å konfigurere.
Jetty , som de forrige, er åpen kildekode. Den er utviklet av Eclipse.

Som Tomcat er det en enkel servlet-beholder, uten støtte for alle komponentene i JavaEE-rammeverket. Samtidig er den mer lett og kan til og med kjøres på en mobiltelefon. Den starter og stopper raskt og skalerer godt. I motsetning til Tomcat, har den et mindre fellesskap og kunnskapsbase.
WebLogic er lisensiert programvare som må kjøpes før bruk. Den tilhører Oracle.

Den har litt bredere funksjonalitet enn Tomcat. Det kan fungere med FTP-protokollen. Men det er ikke så fleksibelt når man utvikler og tester applikasjoner.
WebSphere (WebSphere Application Server, for å være nøyaktig) er betalt programvare. Den er utviklet av IBM. I likhet med WildFly og GlassFish er det en komplett applikasjonsserver. Men den har et vennligere konfigurasjonsgrensesnitt, pluss høy driftssikkerhet.

Manglene inkluderer det faktum at det bruker mye ressurser og tar lang tid å starte og stoppe, noe som ikke er veldig praktisk når man utvikler små prosjekter.

Valget av riktig servletbeholder eller applikasjonsserver avhenger av det aktuelle prosjektet. Det er prosjekter der selv en klar underdog kan vise seg å være et utmerket valg, men til å begynne med er det best å foreta en grundig studie av én servletbeholder. Tomcat er sannsynligvis den perfekte kandidaten for denne studien. Og vi har allerede tatt de første skrittene i å studere det, men herfra er det opp til deg! I de siste artiklene i serien "Introduksjon til bedriftsutvikling" skal vi bli kjent med MVC-mønsteret. Del 7. Vi introduserer MVC-mønsteret (Model-View-Controller).