6. rész. Servlet konténerek

Ez az anyag a "Bevezetés a vállalkozásfejlesztésbe" sorozat része. Korábbi cikkek:

• a hálózatépítésről
• a szoftver architektúráról
• a HTTP/HTTPS-ről
• a Maven alapjairól
• a szervletekről (egy egyszerű webalkalmazás írása)

Az utolsó cikkben megismerkedtünk a servletekkel, és megtanultuk, hogyan használhatjuk őket webes alkalmazások létrehozásához. Eljött az idő, hogy közelebbről is megvizsgáljuk ennek a szórakozásnak egy lényeges részét: a szervlet konténereket.

Tartalomjegyzék:

• Mi az a servlet konténer?
• Hogyan használják a servlet konténereket?
• A Tomcat telepítése és indítása
• Alkalmazás telepítése a Tomcatban
• HTTPS használata HTTP helyett
• Tanúsítvány generálása
• A szerver konfigurálása
• HTML oldalak dinamikus generálása
• A Tomcat alternatívái

Mi az a servlet konténer?

Ez egy olyan program, amely szerveren fut, és képes együttműködni az általunk létrehozott szervletekkel. Más szóval, ha a webalkalmazásunkat egy szerveren akarjuk futtatni, akkor először telepítünk egy servlet-tárolót, majd servleteket teszünk bele. A munkafolyamat egyszerű: amikor az ügyfél hozzáfér a szerverhez, a tároló feldolgozza a kérését, meghatározva, hogy melyik szervlet dolgozza fel, majd továbbítja a kérést.

Hogyan használják a servlet konténereket?

Az útválasztási kéréseken kívül a szervlet-tároló egyéb funkciókat is ellát:

1. Dinamikusan generál HTML-oldalakat JSP-fájlokból.
2. Titkosítja/visszafejti a HTTPS üzeneteket.
3. Korlátozott hozzáférést biztosít a szervlet adminisztrációjához.

Általában véve mindez jól hangzik. Most már csak azt kell kitalálnunk, hogyan alkalmazzuk mindezt a gyakorlatban. Nos, hogy megtanulj valamit használni, csak merülj bele és próbáld meg használni :) Szóval, ma gyakorolni fogunk! A legnépszerűbb szervlet-tároló az Apache Tomcat . Nyílt forráskódú, és ingyenesen használható. Töltsd le a Tomcat operációs rendszeredhez innen , és megvizsgáljuk a konténerekkel való munkavégzést.

A Tomcat telepítése és indítása

1. A Tomcat telepítéséhez egyszerűen csomagolja ki a letöltött archívumot a kívánt könyvtárba.

2. Kérjük, vegye figyelembe, hogy a Tomcat elindításához és futtatásához a Java 8-as vagy újabb verziója szükséges. Ellenőrizze, hogy a JAVA_HOME környezeti változó a JDK aktuális verziójára hivatkozik.

3. Ezután konfigurálnia kell a Tomcat felhasználói hozzáférését . Ez a tomcat-users.xml fájlban történik, amely a conf mappában található.

   A Tomcatben négy előre beállított szerep van:

   • manager-gui — Hozzáférés a grafikus felülethez és az állapotoldalhoz
   • manager-script — Hozzáférés a szöveges felülethez és az állapotoldalhoz
   • manager-jmx — Hozzáférés a JMX-hez és az állapotoldalhoz
   • manager-status — Csak az állapotoldal elérése

   A <tomcat-users> címkén belül kifejezetten megadjuk ezeket a szerepeket, és hozzárendeljük a felhasználónkhoz:

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

   Most minden készen áll az indulásra!

4. A bin mappában futtassa a startup.bat fájlt (startup.sh Linuxon).

5. Néhány másodperc múlva nyissa meg a http://localhost:8080/ hivatkozást a böngészőjében. Egy grafikus műszerfalat fog látni:

   Ha ilyen menüt lát, akkor a Tomcat fut.

6. Ha nem fut, manuálisan ellenőrizze a JAVA_HOME és CATALINA_HOME környezeti változókat:

   • JAVA_HOME — Ennek a Java 8+ aktuális verziójára kell hivatkoznia.
   • CATALINA_BASE – Ennek a Tomcat-re kell hivatkoznia, vagy hiányzik (nem hivatkozhat a Tomcat másik verziójára).

Alkalmazás telepítése a Tomcatban

Sikerült elindítani a Tomcat-et, így itt az ideje, hogy telepítsünk benne néhány projektet. Használjuk az előző cikk szervletjeit . 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");
   }
}

Üzembe helyezés előtt a servleteket WAR fájlba kell csomagolnunk. Általában a Maven-t használják erre, de egy WAR-fájl létrehozásához szükség van egy web.xml fájlra, amely rendelkezik az összes szervlet leképezésével. Az új @WebServlet annotációt használtuk a szervletek írásához, így nem rendelkezünk web.xml fájllal. Szerencsére az IDEA elvégezheti helyettünk a piszkos munkát, WAR fájlba csomagolva projektünket. Ehhez nyissa meg a projekt struktúráját (Ctrl+Shift+Alt+S) -> Műtermékek -> Válassza ki a kívánt WAR-fájlt -> Jelölje be a "Include in project build" melletti jelölőnégyzetet -> Kattintson az "OK" gombra. Építsük fel a projektet a Ctrl+F9 billentyűkombinációval. Most a WAR fájlunk a célkönyvtárban van. A fájl átnevezhető valami egyszerűbbre, pl. servlet.war, és áthelyezhető egy kényelmesebb helyre, pl. C:\\my\\.edénybe tesszük . Ennek két módja van.

1. A grafikus felület használata

   Ehhez kövesse ezt a hivatkozást: http://localhost:8080/manager/html . A Tomcatnak felhasználói nevet és jelszót kell kérnie.

   Ha eddig a pontig követett velem, akkor a felhasználónév "felhasználó", a jelszó pedig "jelszó" .

   Sikeres bejelentkezés után megjelenik a Tomcat Web Application Manager. Az „Alkalmazások” rész már 5 alkalmazást tartalmaz – ezek a Tomcat segédprogramok, amelyek megkönnyítik a Tomcat használatát. A jövőben törölhetők.

   Az alábbiakban a „Telepítés” szakasz található. Itt választhatja ki a telepíteni kívánt WAR archívumot. Adjuk meg manuálisan az elérési utat és a kontextust:

   Kattintson a "Deploy" gombra, és azt látjuk, hogy alkalmazásunk megjelent az "Alkalmazások" részben:

   A Tomcat grafikus felülete segítségével leállíthatunk, újraindíthatunk és törölhetünk egy munkamenetet, valamint beállíthatjuk a munkamenet hosszát. Az üzembe helyezéskor megadtuk a /demo kontextust, ami azt jelenti, hogy az alkalmazásunk a http://localhost:8080/demo címen érhető el . Ellenőrizd. Mindennek működnie kell.

2. A fájlrendszeren keresztül

   Az alkalmazás ilyen módon történő üzembe helyezéséhez meg kell nyitnia azt a könyvtárat, ahol a Tomcat kicsomagolta. Ezután lépjen a "webapps" mappába. Itt találja azokat a segédprogramokat, amelyekkel már találkoztunk:

   Csak át kell helyeznünk ide a servlet.war fájlt.

   Várunk néhány másodpercet, majd látjuk, hogy megjelent egy új "servlet" mappa. Ez azt jelenti, hogy az alkalmazásunk telepítve van. Nyissa meg az Alkalmazáskezelő felületét a http://localhost:8080/manager/ címen . Itt látjuk, hogy az alkalmazásunk a /servlet kontextusban van telepítve:

   Ilyen módon történő telepítéskor a környezet automatikusan hozzárendelődik a telepített WAR-fájl neve alapján. A kontextus megváltoztatásához átnevezheti az alkalmazást tartalmazó újonnan létrehozott mappát, de mielőtt ezt megtenné, el kell távolítania a WAR fájlt. Ellenkező esetben a Tomcat újratelepíti az alkalmazást az archívum nevével.

   Amint láthatja, az alkalmazások telepítése a Tomcatben sokkal egyszerűbb, mint amilyennek látszik. De egyéb funkciói is könnyen használhatók. Ellenőrizzük.

HTTPS használata HTTP helyett

Ha emlékszel, egy külön cikkben megvizsgáltuk a HTTP és a HTTPS közötti különbséget . A HTTPS ugyanaz, mint a HTTP protokoll, de titkosítja a továbbított adatokat. Kliens oldalon a böngésző felelős a titkosításért, de a szerver oldalon nekünk kell biztosítanunk a titkosítást. Mivel a Tomcat elfogadja és továbbítja a HTTP kéréseket, célszerű a titkosítást átruházni rá. Ehhez a következőket kell tenni:

1. Hozzon létre egy önaláírt tanúsítványt
2. Adjon meg további szerverbeállításokat

Gyakoroljuk ezt.

Tanúsítvány generálása

A verziótól függetlenül a JDK számos segédprogramot tartalmaz. Az egyik a keytool . Ez egy eszköz a titkosítási kulcsok generálására és kezelésére. Használatához a parancssorban lépjen a C:\\Program Files\\Java\\jdk1.8.0_181\\bin könyvtárba, és futtassa a keytool -genkey -alias tomcat -keyalg RSA parancsot .

• keytool — A parancssori opciókkal futtatott segédprogram neve
• -genkey — Jelzi, hogy új kulcsot szeretnénk generálni
• -alias tomcat — Hozzon létre egy kulcsálnevet
• -keyalg RSA — Válassza ki az RSA-t kulcsgeneráló algoritmusként

A parancs végrehajtása után a segédprogram párbeszédet kezd velünk: Adja meg a szükséges információkat. Most létrehoztunk egy kulcstárolót a kezdőkönyvtárunkban (Windows esetén ez a C:\\Users\\{felhasználónév}\\.keystore), és egy tomcat kulcsot. Létrehoztunk egy egyszerű tanúsítványt, amelyre a legtöbb böngésző panaszkodni fog. Az ilyen tanúsítvány kereskedelmi használatra nem alkalmas: csak tesztelési célokra használható. Éles kiszolgálón egy hitelesítésszolgáltatótól származó tanúsítványt kell használnia (például https://letsencrypt.org/ ).

A szerver konfigurálása

Most, hogy a tanúsítvány készen van, módosítanunk kell a szerver beállításait, nevezetesen az SSL-csatlakozót. Ez a server.xml fájlban történik, amely az apache-tomcat-9.0.30/conf/ fájlban található . Ebben a következőhöz hasonló blokkokat találunk:

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

és melléjük tesszük a konfigurációnkat:

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

A legfrissebb értékeket hozzárendeljük a keystoreFile és a keystorePass paraméterekhez, elmentjük a fájlt, majd újraindítjuk a Tomcat programot a shutdown.bat és startup.bat fájlokkal. Most a szerver készen áll a HTTPS kérések feldolgozására. A cím csak egy kicsit változott: https://localhost:8443/demo/hello . A linkre kattintva figyelmeztetést kap a tanúsítvány megbízhatóságáról, ami nem meglepő. Amint azt egy kicsit korábban mondtuk, a normál tanúsítvány megszerzéséhez az egyik tanúsító hatóság szolgáltatásait kell igénybe vennie. De egyelőre elértük a célunkat: az alkalmazás HTTPS protokollt használva fut, és ez fontos!

HTML oldalak dinamikus generálása

Most folytatjuk a servlet-tárolók áttekintését egy másik funkció figyelembevételével: a HTML-oldalak dinamikus generálása. Képzeljen el egy tökéletes világot, ahol az unalmas statikus HTML-kód helyett Java-kódot írhat, változók, hurkok, tömbök és más nyelvi konstrukciók segítségével. El tudtad képzelni? A jó hír az, hogy létezik valami hasonló. A rossz hír az, hogy nem valósítja meg teljesen ezt a fantáziát. Ha még nem gondolta volna, akkor a JavaServer Pagesről (JSP) beszélünk. Röviden, ez a technológia lehetővé teszi Java kódrészletek beszúrását egy HTML oldalba. Igaz, ezt a Java-kódot még mindig HTML-vé alakítják, mielőtt elküldenék a kliensnek, de a HTML dinamikusan generálódik, különféle tényezők figyelembevételével. Például, feltételes utasításokat használhat, és bizonyos feltételtől függően különböző tartalmat adhat vissza. Példa JSP-oldalra:

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

A JSP-ről bővebben itt olvashat. Végső soron ez a cikk nem a JSP-ről szól – azért vagyunk itt, hogy a servlet-tárolókról beszéljünk! Akkor miért említettük a JSP-t? Egyszerű: a servlet konténer konvertálja a Java kódot JSP-ről HTML-re. Amikor egy szervlet válaszként JSP-tartalmat kíván visszaadni, a tároló tudomásul veszi, és először böngészőbarát HTML-oldallá alakítja, mielőtt elküldi az ilyen tartalmat az ügyfélnek. Manapság számos analógja létezik a JSP technológiának – Thymeleaf, FreeMarket, Bajusz és mások. Mindegyik hasonló módon működik. Ízlés kérdése, hogy melyiket választja a munkájához. Ez vonatkozik a szervlet konténer kiválasztására is. Ezekben a példákban a Tomcat, a leggyakoribb tárolót használtuk, de egyes projektek más tárolókat is használnak. Érdemes röviden áttekinteni a legnépszerűbbeket, és átgondolni, miben különböznek a Tomcat-től.

A Tomcat alternatívái

1. A GlassFish egy nyílt forráskódú tároló, amelynek fejlesztését az Oracle támogatja.

   A Tomcattal ellentétben egy teljes értékű webszerver, amely a servletek mellett a JavaEE keretrendszer egyéb összetevőivel is tud működni. Ennek ellenére sokkal több RAM-ot használ. Nagyobb rugalmasság érhető el a szerver finomhangolásakor, ami megnehezíti a használatát. JavaEE keretrendszeren történő alkalmazások fejlesztésekor kell használni.

2. A WildFly korábban JBoss néven volt ismert . Ez is nyílt forráskódú. Ezt a Red Hat fejlesztette ki. A nevet megváltoztattuk, hogy elkerüljük a cég másik termékével – a JBoss Enterprise Application Platform – való összetéveszthetőséget.

   A GlassFishhez hasonlóan a WildFly is egy teljes értékű webszerver. Mellesleg a motorháztető alatt a WildFly a Tomcatet servlet konténerként használja. A GlassFish-től eltérően a WildFly könnyebb és könnyen konfigurálható.

3. A Jetty az előzőekhez hasonlóan nyílt forráskódú. Az Eclipse fejlesztette ki.

   A Tomcathoz hasonlóan ez is egy egyszerű szervlet konténer, amely nem támogatja a JavaEE keretrendszer összes összetevőjét. Ugyanakkor könnyebb, és akár mobiltelefonon is futtatható. Gyorsan indul és leáll, és jól skálázódik. A Tomcattal ellentétben kisebb közösséggel és tudásbázissal rendelkezik.

4. A WebLogic licencelt szoftver, amelyet használat előtt meg kell vásárolni. Az Oracle-hez tartozik.

   Valamivel szélesebb funkcionalitású, mint a Tomcat. Működhet az FTP protokollal. De nem olyan rugalmas az alkalmazások fejlesztése és tesztelése során.

5. A WebSphere (pontosabban WebSphere Application Server) fizetős szoftver. Az IBM fejlesztette. Hasonlóan a WildFly-hez és a GlassFish-hez, ez egy teljes alkalmazásszerver. De barátságosabb konfigurációs felülettel, valamint nagyfokú működési megbízhatósággal rendelkezik.

   Hiányosságai közé tartozik, hogy sok erőforrást használ fel, és hosszú időt vesz igénybe az indítás és a leállítás, ami kis projektek fejlesztésekor nem túl kényelmes.

A megfelelő szervlet-tároló vagy alkalmazáskiszolgáló kiválasztása az adott projekttől függ. Vannak olyan projektek, ahol még az egyértelmű esélytelenség is kiváló választásnak bizonyulhat, de először érdemes alaposan áttanulmányozni egy szervlet tárolót. A Tomcat valószínűleg a tökéletes jelölt erre a tanulmányra. És már megtettük az első lépéseket a tanulmányozásában, de innentől már csak rajtad múlik! A "Bevezetés a Vállalkozásfejlesztésbe" sorozat utolsó cikkeiben megismerkedünk az MVC mintával. 7. rész Az MVC (Model-View-Controller) minta bemutatása