Część 6. Kontenery serwletów

Ten materiał jest częścią serii „Wprowadzenie do rozwoju przedsiębiorstwa”. Poprzednie artykuły:

W ostatnim artykule zapoznaliśmy się z serwletami i nauczyliśmy się ich używać do tworzenia aplikacji internetowych. Nadszedł czas, aby przyjrzeć się bliżej zasadniczej części tej zabawy: kontenerom serwletów.

Spis treści:

Co to jest kontener serwletów?

Jest to program, który działa na serwerze i może wchodzić w interakcje z serwletami, które stworzyliśmy. Innymi słowy, jeśli chcemy uruchomić naszą aplikację internetową na serwerze, najpierw wdrażamy kontener serwletów, a następnie umieszczamy w nim serwlety. Przepływ pracy jest prosty: gdy klient uzyskuje dostęp do serwera, kontener przetwarza swoje żądanie, określając, który aplet powinien je przetworzyć, a następnie przekazuje żądanie dalej. Część 6. Kontenery serwletów - 2

Jak używane są kontenery serwletów?

Oprócz żądań trasowania kontener serwletów spełnia inne funkcje:

Dynamicznie generuje strony HTML z plików JSP.
Szyfruje/odszyfrowuje wiadomości HTTPS.
Zapewnia ograniczony dostęp do administrowania serwletami.

Ogólnie to wszystko brzmi dobrze. Teraz musimy tylko wymyślić, jak zastosować to wszystko w praktyce. Cóż, aby nauczyć się czegoś używać, po prostu zanurkuj i spróbuj tego użyć :) Więc dzisiaj będziemy ćwiczyć! Najpopularniejszym kontenerem serwletów jest Apache Tomcat . Jest open source i może być używany za darmo. Pobierz Tomcat dla swojego systemu operacyjnego tutaj , a my przyjrzymy się pracy z kontenerami „w akcji”.

Instalowanie i uruchamianie Tomcata

Aby zainstalować Tomcata, po prostu rozpakuj pobrane archiwum do żądanego katalogu.
Należy pamiętać, że do uruchomienia i działania Tomcat wymaga oprogramowania Java w wersji 8 lub nowszej. Sprawdź, czy zmienna środowiskowa JAVA_HOME odwołuje się do bieżącej wersji pakietu JDK.
Następnie musisz skonfigurować dostęp użytkownika do Tomcat . Odbywa się to w pliku tomcat-users.xml, który znajduje się w folderze conf.

W Tomcat są cztery wstępnie ustawione role:
- manager-gui — Dostęp do interfejsu graficznego i strony stanu
- manager-script — Dostęp do interfejsu tekstowego i strony stanu
- manager-jmx — Dostęp do JMX i strony stanu
- status menedżera — dostęp tylko do strony stanu
Wewnątrz tagu <tomcat-users> wyraźnie określamy te role i przypisujemy je naszemu użytkownikowi:
```
<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"/>
```
Teraz wszystko jest gotowe do uruchomienia!
W folderze bin uruchom plik startup.bat (startup.sh w systemie Linux).
Po kilku sekundach otwórz link http://localhost:8080/ w przeglądarce. Zobaczysz graficzny pulpit nawigacyjny:

Jeśli zobaczysz takie menu, oznacza to, że Tomcat jest uruchomiony.
Jeśli nie działa, ręcznie sprawdź zmienne środowiskowe JAVA_HOME i CATALINA_HOME:
- JAVA_HOME — Musi odwoływać się do bieżącej wersji Java 8+.
- CATALINA_BASE — Musi odwoływać się do Tomcat lub być nieobecna (nie powinna odwoływać się do innej wersji Tomcat).

Wdrażanie aplikacji w Tomcat

Udało nam się uruchomić Tomcata, więc teraz czas na wdrożenie w nim jakiegoś projektu. Użyjmy serwletów z poprzedniego artykułu . Serwlet główny:

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

Serwlet indeksu:

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

Przed wdrożeniem musimy spakować nasze serwlety do pliku WAR. Maven jest zwykle używany do tego celu, ale aby utworzyć plik WAR, potrzebujesz pliku web.xml, który zawiera mapowanie dla wszystkich serwletów. Użyliśmy nowej adnotacji @WebServlet do napisania serwletów, więc nie mamy pliku web.xml. Na szczęście IDEA może wykonać za nas brudną robotę, opakowując nasz projekt w plik WAR. Aby to zrobić, otwórz strukturę projektu (Ctrl+Shift+Alt+S) -> Artefakty -> Wybierz żądany plik WAR -> Zaznacz pole wyboru obok „Uwzględnij w kompilacji projektu” -> Kliknij „OK”. Część 6. Kontenery serwletów - 4

Zbudujmy projekt za pomocą kombinacji klawiszy Ctrl+F9. Teraz nasz plik WAR znajduje się w katalogu docelowym. Część 6. Kontenery serwletów - 5

Można zmienić nazwę pliku na prostszą, np. servlet.war, i przenieść w wygodniejsze miejsce, np. C:\\my\\.włożymy do pojemnika . Można to zrobić na dwa sposoby.

Korzystanie z interfejsu graficznego

Aby to zrobić, kliknij ten link: http://localhost:8080/manager/html . Tomcat powinien poprosić o nazwę użytkownika i hasło.

Jeśli podążałeś za mną do tego momentu, nazwa użytkownika to „user”, a hasło to „hasło” .

Po pomyślnym zalogowaniu zobaczysz Menedżera aplikacji internetowych Tomcat. Sekcja „Aplikacje” zawiera już 5 aplikacji — są to narzędzia Tomcat, które ułatwiają pracę z Tomcatem. Można je usunąć w przyszłości.

Poniżej znajduje się sekcja „Wdrażanie”. Tutaj możesz wybrać archiwum WAR do wdrożenia. Wprowadźmy ścieżkę i kontekst ręcznie:

Kliknij „Deploy” i widzimy, że nasza aplikacja pojawiła się w sekcji „Applications”:
Korzystając z interfejsu graficznego Tomcata, możemy zatrzymać, ponownie uruchomić i usunąć sesję, a także ustawić długość sesji. Podczas wdrażania określiliśmy kontekst /demo, co oznacza, że dostęp do naszej aplikacji uzyskuje się za pomocą http://localhost:8080/demo . Sprawdź to. Wszystko powinno działać.
Poprzez system plików

Aby wdrożyć aplikację w ten sposób, musisz otworzyć katalog, w którym Tomcat został rozpakowany. Następnie przejdź do folderu „webapps”. Tutaj znajdziesz narzędzia, które już napotkaliśmy:

Wystarczy, że przeniesiemy tutaj nasz plik servlet.war.

Czekamy kilka sekund, a następnie widzimy, że pojawił się nowy folder „servlet”. Oznacza to, że nasza aplikacja została wdrożona. Przejdź do interfejsu Menedżera aplikacji pod adresem http://localhost:8080/manager/ . Tutaj widzimy, że nasza aplikacja jest wdrażana w kontekście /servlet:

W przypadku wdrożenia w ten sposób kontekst jest przypisywany automatycznie na podstawie nazwy wdrożonego pliku WAR. Aby zmienić kontekst, możesz zmienić nazwę nowo utworzonego folderu zawierającego aplikację, ale zanim to zrobisz, musisz usunąć plik WAR. W przeciwnym razie Tomcat ponownie wdroży aplikację z nazwą archiwum.

Jak widać, wdrażanie aplikacji w Tomcat jest znacznie łatwiejsze niż mogłoby się wydawać. Ale jego inne funkcje są również łatwe w użyciu. Sprawdźmy.

Korzystanie z HTTPS zamiast HTTP

Jeśli pamiętasz, przyjrzeliśmy się różnicy między HTTP i HTTPS w osobnym artykule . HTTPS jest tym samym protokołem co HTTP, ale szyfruje przesyłane dane. Po stronie klienta za szyfrowanie odpowiada przeglądarka, jednak my musimy zapewnić szyfrowanie po stronie serwera. Ponieważ Tomcat akceptuje i kieruje żądania HTTP, sensowne jest delegowanie do niego szyfrowania. Aby to zrobić, musimy:

Wygeneruj samopodpisany certyfikat
Wprowadź dodatkowe ustawienia serwera

Poćwiczmy to robić.

Generowanie certyfikatu

Niezależnie od wersji JDK zawiera dużą liczbę narzędzi. Jednym z nich jest keytool . Jest to narzędzie do generowania i pracy z kluczami szyfrującymi. Aby z niego skorzystać, w wierszu poleceń przejdź do katalogu C:\\Program Files\\Java\\jdk1.8.0_181\\bin i uruchom polecenie keytool -genkey -alias tomcat -keyalg RSA .

keytool — Nazwa narzędzia, które uruchamiamy z opcjami wiersza poleceń
-genkey — wskazuje, że chcemy wygenerować nowy klucz
-alias tomcat — Utwórz alias klucza
-keyalg RSA — Wybierz RSA jako algorytm generowania klucza

Po wykonaniu polecenia narzędzie rozpoczyna z nami dialog: Część 6. Kontenery serwletów - 11

Wprowadź niezbędne informacje. Teraz utworzyliśmy magazyn kluczy w naszym katalogu domowym (dla systemu Windows jest to C:\\Users\\{username}\\.keystore) i klucz Tomcat w nim. Wygenerowaliśmy prosty certyfikat, na który narzeka większość przeglądarek. Taki certyfikat nie nadaje się do zastosowań komercyjnych: może być używany wyłącznie do celów testowych. Na serwerze produkcyjnym musisz użyć certyfikatu z urzędu certyfikacji (na przykład https://letsencrypt.org/ ).

Konfigurowanie serwera

Teraz, gdy certyfikat jest gotowy, musimy dostosować ustawienia serwera, a mianowicie złącze SSL. Odbywa się to w pliku server.xml, który znajduje się w apache-tomcat-9.0.30/conf/ . Znajdziemy w nim takie bloki:

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

a obok nich umieszczamy naszą konfigurację:

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

Przypisujemy najnowsze wartości parametrom keystoreFile i keystorePass, zapisujemy plik, a następnie ponownie uruchamiamy Tomcata przy użyciu plików shutdown.bat i startup.bat. Teraz serwer jest gotowy do przetwarzania żądań HTTPS. Adres zmienił się tylko trochę: https://localhost:8443/demo/hello . Po kliknięciu w link otrzymasz ostrzeżenie o wiarygodności certyfikatu, co nie jest zaskakujące. Jak powiedzieliśmy nieco wcześniej, aby uzyskać normalny certyfikat, musisz skorzystać z usług jednego z urzędów certyfikacji. Ale na razie osiągnęliśmy nasz cel: aplikacja działa przy użyciu protokołu HTTPS, a to ważne!

Dynamiczne generowanie stron HTML

Teraz będziemy kontynuować nasz przegląd kontenerów serwletów, rozważając inną funkcję: dynamiczne generowanie stron HTML. Wyobraź sobie idealny świat, w którym zamiast nudnego, statycznego kodu HTML możesz pisać kod w Javie, używając zmiennych, pętli, tablic i innych konstrukcji językowych. Czy byłeś w stanie to sobie wyobrazić? Dobra wiadomość jest taka, że istnieje coś podobnego. Zła wiadomość jest taka, że nie spełnia całkowicie tej fantazji. Jeśli nie zgadłeś, mówimy o JavaServer Pages (JSP). Krótko mówiąc, jest to technologia, która umożliwia wstawianie fragmentów kodu Java do strony HTML. To prawda, że ten kod Java jest nadal konwertowany na HTML przed wysłaniem do klienta, ale ten kod HTML będzie generowany dynamicznie, z uwzględnieniem różnych czynników. Na przykład, możesz użyć instrukcji warunkowych i zwrócić inną treść w zależności od warunku. Przykładowa strona 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>

Więcej o JSP można przeczytać tutaj. W końcu ten artykuł nie dotyczy JSP — jesteśmy tutaj, aby porozmawiać o kontenerach serwletów! Dlaczego więc wspomnieliśmy o JSP? To proste: kontener serwletu jest tym, co konwertuje kod Java z JSP na HTML. Kiedy aplet ma zwrócić treść JSP jako odpowiedź, kontener przyjmuje to do wiadomości i najpierw konwertuje ją na przyjazną dla przeglądarki stronę HTML przed wysłaniem takiej treści do klienta. Obecnie istnieje wiele odpowiedników technologii JSP — Thymeleaf, FreeMarket, Mustache i inne. Wszystkie działają w podobny sposób. Który z nich wybrać do swojej pracy, jest kwestią gustu. Dotyczy to również wyboru kontenera serwletu. W tych przykładach użyliśmy najpopularniejszego kontenera Tomcat, ale niektóre projekty używają innych kontenerów. Warto krótko przejrzeć te najpopularniejsze i zastanowić się, czym różnią się od Tomcata.

Alternatywy dla Tomcata

GlassFish to kontener typu open source, którego rozwój jest wspierany przez firmę Oracle.

W przeciwieństwie do Tomcata jest pełnoprawnym serwerem WWW, który oprócz serwletów może współpracować z innymi komponentami z frameworka JavaEE. To powiedziawszy, zużywa znacznie więcej pamięci RAM. Istnieje większa elastyczność podczas dostrajania serwera, co komplikuje jego użytkowanie. Powinien być używany podczas tworzenia aplikacji na frameworku JavaEE.
WildFly był wcześniej znany jako JBoss . Jest to również oprogramowanie typu open source. Jest rozwijany przez firmę Red Hat. Nazwa została zmieniona, aby uniknąć pomylenia z innym produktem firmy — JBoss Enterprise Application Platform.

Podobnie jak GlassFish, WildFly jest pełnoprawnym serwerem WWW. Nawiasem mówiąc, pod maską WildFly używa Tomcata jako kontenera serwletów. W przeciwieństwie do GlassFish, WildFly jest lżejszy i łatwiejszy w konfiguracji.
Jetty , podobnie jak poprzednie, jest open source. Jest rozwijany przez Eclipse.

Podobnie jak Tomcat, jest to prosty kontener serwletów, bez obsługi wszystkich komponentów środowiska JavaEE. Jednocześnie jest lżejszy i można go nawet uruchomić na telefonie komórkowym. Szybko się uruchamia i zatrzymuje, dobrze skaluje. W przeciwieństwie do Tomcata ma mniejszą społeczność i bazę wiedzy.
WebLogic to licencjonowane oprogramowanie, które należy zakupić przed użyciem. Należy do Oracle'a.

Ma nieco szerszą funkcjonalność niż Tomcat. Może współpracować z protokołem FTP. Ale nie jest tak elastyczny podczas tworzenia i testowania aplikacji.
WebSphere (dokładnie WebSphere Application Server) jest płatnym oprogramowaniem. Jest rozwijany przez IBM. Podobnie jak WildFly i GlassFish, jest to kompletny serwer aplikacji. Ale ma bardziej przyjazny interfejs konfiguracyjny, a do tego wysoką niezawodność działania.

Do jego wad można zaliczyć to, że zużywa dużo zasobów i długo się uruchamia i zatrzymuje, co nie jest zbyt wygodne przy opracowywaniu małych projektów.

Wybór odpowiedniego kontenera serwletów lub serwera aplikacji zależy od konkretnego projektu. Istnieją projekty, w których nawet wyraźnie słabszy gracz może okazać się doskonałym wyborem, ale na początek najlepiej jest przeprowadzić dogłębną analizę jednego kontenera serwletów. Tomcat jest prawdopodobnie idealnym kandydatem do tego badania. Podjęliśmy już pierwsze kroki w jej badaniu, ale od tego momentu wszystko zależy od Ciebie! W ostatnich artykułach z serii „Wprowadzenie do rozwoju przedsiębiorstwa” poznamy wzorzec MVC. Część 7. Wprowadzenie do wzorca MVC (Model-View-Controller).