Część 6: Kontenery serwletów

Materiał ten stanowi część serii „Wprowadzenie do rozwoju przedsiębiorstwa”. Poprzednie artykuły:

• o sieci ;
• o architekturze oprogramowania ;
• o protokołach HTTP/HTTPS ;
• o podstawach Mavena;
• o serwletach (pisanie prostej aplikacji internetowej) .

W ostatnim artykule zapoznaliśmy się z serwletami i dowiedzieliśmy się, jak za ich pomocą tworzyć aplikacje internetowe. Czas przyjrzeć się bliżej temu, bez czego te wakacje nie byłyby możliwe – kontenerów na serwlety.

Treść:

• Co to jest kontener serwletów
• Jak korzystać z kontenerów serwletów
• Instalowanie i uruchamianie Tomcat”
• Wdrażanie aplikacji w Tomcat
• Używanie protokołu HTTPS zamiast HTTP
• Generowanie certyfikatu
• Konfiguracja serwera
• Dynamiczne generowanie stron HTML
• Alternatywa dla Tomcata

Co to jest kontener serwletów

Jest to program, który działa na serwerze i może wchodzić w interakcję z utworzonymi przez nas serwletami. 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. Zasada działania jest prosta: kiedy klient kontaktuje się z serwerem, kontener przetwarza jego żądanie, określa, który serwlet powinien je przetworzyć i przekazuje dalej.

Jak korzystać z kontenerów serwletów

Oprócz kierowania żądań kontener serwletu spełnia inne funkcje:

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

Ogólnie brzmi nieźle, pozostaje tylko wymyślić, jak to wszystko zastosować. No cóż, żeby nauczyć się czegoś używać, wystarczy... spróbować tego użyć :) Zatem dzisiaj będziemy ćwiczyć! Najpopularniejszym kontenerem serwletów jest Apache Tomcat . Jest oprogramowaniem typu open source i można z niego korzystać bezpłatnie. Pobierz Tomcat dla swojego systemu operacyjnego , korzystając z tego linku i zobaczmy, jak pracować z kontenerami w akcji.

Instalowanie i uruchamianie Tomcata

1. Aby zainstalować Tomcat, wystarczy rozpakować pobrane archiwum do żądanego katalogu.

2. Należy pamiętać, że Tomcat wymaga do działania Java w wersji 8 lub nowszej. Upewnij się, że zmienna środowiskowa JAVA_HOME odnosi się do bieżącej wersji jdk.

3. Następnie musisz skonfigurować dostęp użytkowników do Tomcat . Odbywa się to w pliku tomcat-users.xml, który znajduje się w folderze conf.

   Tomcat jest fabrycznie wyposażony w cztery role:

   • manager-gui - dostęp do interfejsu graficznego i strony statusu;
   • manager-script - dostęp do interfejsu tekstowego i strony statusu;
   • manager-jmx - dostęp do JMX i strony statusu;
   • status menedżera - dostęp tylko do strony statusu.

   Wewnątrz tagu <tomcat-users> wyraźnie zapiszemy te role i przypiszemy 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!

4. W folderze bin uruchom plik startup.bat (startup.sh w systemie Linux).

5. Po kilku sekundach otwórz link http://localhost:8080/ w swojej przeglądarce . Pojawi się tam menedżer graficzny:

   Jeśli widzisz takie menu, oznacza to, że Tomcat jest uruchomiony.

6. Jeśli to nie zadziała, sprawdź ręcznie zmienne środowiskowe JAVA_HOME i CATALINA_HOME:

   • JAVA_HOME - musi odnosić się do aktualnej wersji Java 8+;
   • CATALINA_HOME — musi odnosić się do Tomcata lub być nieobecny (nie może wskazywać na inną wersję Tomcata).

Wdrażanie aplikacji w Tomcat

Udało nam się uruchomić Tomcata, czas więc wdrożyć w nim jakiś projekt. Użyjmy serwletów z poprzedniego artykułu . Główny serwlet:

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

Przed wdrożeniem nasze serwlety muszą zostać spakowane w archiwum wojennym. Zwykle używa się do tego Mavena, ale do stworzenia archiwum wojennego potrzebny jest plik web.xml, w którym zmapowane są wszystkie serwlety. Napisaliśmy serwlety, korzystając z nowej adnotacji @WebServlet, więc nie mamy pliku web.xml. Na szczęście IDEA może odwalić za nas brudną robotę i zapakować nasz projekt indywidualnie do archiwum wojennego. Aby to zrobić, musisz otworzyć strukturę projektu (Ctrl + Shift + Alt + S) -> Artefakty -> Wybierz żądany napar -> Zaznacz pole obok „Uwzględnij w kompilacji projektu” -> Kliknij „OK”. Zbuduj projekt za pomocą kombinacji Ctrl + F9. Teraz nasze archiwum wojenne znajduje się w katalogu docelowym. Można zmienić nazwę pliku na prostszą - np. servlet.war - i przenieść w wygodniejsze miejsce - do C:\my\. Gdy napar będzie gotowy do użycia, przełóż go do pojemnika . Można to zrobić na dwa sposoby.

1. Za pośrednictwem interfejsu graficznego

   Aby to zrobić, kliknij link http://localhost:8080/manager/html . Tomcat powinien wyświetlić monit o podanie loginu i hasła.

   Jeśli powtórzyłeś za mną wszystkie kroki, login to użytkownik, hasło to hasło .

   Po pomyślnej autoryzacji zobaczysz Menedżera aplikacji internetowych Tomcat. Sekcja Aplikacje zawiera już 5 aplikacji - są to aplikacje narzędziowe Tomcat niezbędne do uproszczenia pracy z nim. W przyszłości można je usunąć.

   Poniżej znajduje się sekcja Wdrażanie. Za jego pomocą możesz wybrać archiwum wojenne do rozmieszczenia. Wprowadźmy ścieżkę i kontekst ręcznie:

   Kliknij „Wdróż”, widzimy, że nasza aplikacja pojawiła się w sekcji Aplikacje:

   Za pomocą interfejsu GUI Tomcat możemy go zatrzymać, uruchomić ponownie, ustawić długość sesji i usunąć. Podczas wdrażania określiliśmy kontekst /demo, co oznacza, że ​​dostęp do naszej aplikacji musi odbywać się poprzez link http://localhost:8080/demo . Sprawdź, wszystko powinno działać.

2. Przez system plików

   Aby wdrożyć aplikację w ten sposób, należy otworzyć katalog, w którym rozpakowano Tomcat i przejść do webapps. Oto aplikacje narzędziowe, które znamy:

   Wszystko, co musimy zrobić, to przenieść tutaj nasz plik servlet.war.

   Czekamy kilka sekund, widzimy, że pojawił się nowy folder serwletu, co oznacza, że ​​nasza aplikacja została wdrożona. Przejdźmy do znanego interfejsu Menedżera aplikacji - http://localhost:8080/manager/ . Tutaj widzimy, że nasza aplikacja jest wdrożona w kontekście /servlet:

   Po wdrożeniu w ten sposób kontekst jest automatycznie przypisywany do nazwy wdrożonego archiwum wojennego. Aby zmienić kontekst, możesz zmienić nazwę nowo utworzonego folderu z aplikacją, ale wcześniej musisz usunąć plik: w przeciwnym razie Tomcat ponownie wdroży aplikację z nazwą archiwum.

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

Używanie protokołu HTTPS zamiast HTTP

Jeśli pamiętasz, różnicę między HTTP a HTTPS omówiliśmy w osobnym artykule . HTTPS to ten sam protokół co HTTP, ale wykorzystuje szyfrowanie przesyłanych danych. Po stronie klienta szyfrowanie jest obsługiwane przez przeglądarkę, a my musimy zapewnić szyfrowanie po stronie serwera. Ponieważ żądania HTTP są akceptowane i kierowane przez Tomcat, logiczne byłoby delegowanie mu szyfrowania. Aby to zrobić, potrzebujesz:

1. Wygeneruj certyfikat z podpisem własnym;
2. Wprowadź dodatkowe ustawienia serwera.

Poćwiczmy to.

Generowanie certyfikatu

JDK zawiera dużą liczbę narzędzi, niezależnie od wersji, jednym z nich jest keytool . Jest to narzędzie do generowania kluczy szyfrujących i pracy z nimi. Aby z niego skorzystać, za pomocą wiersza poleceń przejdź do katalogu C:\Program Files\Java\jdk1.8.0_181\bin i uruchom polecenie keytool -genkey -alias tomcat -keyalg RSA .

• keytool - uruchom narzędzie z parametrami;
• -genkey - wskazuje, że chcemy wygenerować nowy klucz;
• -alias Tomcat — utwórz kluczowy alias;
• -keyalg RSA - wybierz RSA jako algorytm generowania klucza.

Po wykonaniu polecenia narzędzie rozpocznie z nami dialog: Wprowadź niezbędne informacje. Teraz utworzyliśmy magazyn kluczy w naszym katalogu domowym (w systemie Windows jest to C:\Users\{username}\.keystore) i znajdujący się w nim klucz Tomcat. Wygenerowaliśmy prosty certyfikat, który akceptuje większość przeglądarek. Ten certyfikat nie nadaje się do zastosowań komercyjnych: można go używać wyłącznie do celów testowych. Na serwerze produkcyjnym musisz użyć certyfikatu wydanego przez urząd certyfikacji (na przykład https://letsencrypt.org/ ).

Konfiguracja serwera

Teraz, gdy certyfikat jest już gotowy, należy dostosować ustawienia serwera, czyli złącze SSL. Odbywa się to w pliku server.xml, który znajduje się w Apache-Tomcat-9.0.30/conf/ . Znajdujemy bloki takie jak:

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

i umieść obok nich 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"/>

Parametrom keystoreFile i keystorePass przypisujemy istotne dla nas wartości, zapisujemy i restartujemy Tomcata za pomocą plików Shutdown.bat i Startup.bat. Teraz serwer jest gotowy do przetwarzania żądań https, wystarczy trochę pod zmienionym adresem - https://localhost:8443/demo/hello . Kiedy klikniesz na link, zobaczysz ostrzeżenie o wątpliwości certyfikatu, co nie jest zaskakujące. Jak opisano nieco wcześniej, aby uzyskać normalny certyfikat, należy skorzystać z usług jednego z serwisów certyfikacyjnych. Ale jak dotąd osiągnęliśmy nasz cel: aplikacja działa w oparciu o protokół HTTPS i to jest najważniejsze!

Dynamiczne generowanie stron HTML

Kontynuujmy teraz nasz przegląd innych funkcji kontenerów serwletów - dynamicznego generowania stron HTML. Wyobraź sobie idealny świat, w którym zamiast nudnego, statycznego kodu HTML możesz pisać kod w języku JAVA, używając zmiennych, pętli, tablic i innych konstrukcji językowych. Wyobraziłeś sobie? Dobra wiadomość jest taka, że ​​istnieje coś podobnego, zła jest taka, że ​​nie istnieje w pełni. Jeśli nie zgadłeś, mówimy o technologii JSP (Java Server Pages). Krótko mówiąc, jest to technologia umożliwiająca wstawianie fragmentów kodu JAVA na stronę HTML. Co prawda, wtedy ten kod jest jeszcze przekształcany w HTML przed wysłaniem do klienta, ale będzie generowany dynamicznie z uwzględnieniem różnych czynników. Na przykład możesz używać konstrukcji warunkowych i wyświetlać różne treści w zależności od pewnego 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żesz przeczytać tutaj . Właściwie... nie jesteśmy tu po to, ale ze względu na kontenery serwletów! Co ma z tym wspólnego JSP? To proste: transformacja kodu JAVA z JSP na kod HTML odbywa się za pomocą kontenera serwletu. Kiedy serwlet ma zamiar zwrócić w odpowiedzi treść JSP, kontener to zauważa i najpierw przekształca ją w stronę HTML czytelną dla przeglądarki, a następnie wysyła tę treść do klienta. Obecnie istnieje wiele analogów technologii JSP - Thymeleaf, FreeMarket, Mustache i inne. Wszystkie działają na podobnej zasadzie. To, który wybrać do pracy, jest kwestią gustu. Dotyczy to również wyboru kontenera serwletów. W przykładach użyliśmy Tomcata, najpopularniejszego kontenera, ale niektóre projekty korzystają z innych. Warto pokrótce zapoznać się z najpopularniejszymi z nich i przyjrzeć się, czym różnią się od Tomcata.

Alternatywa dla Tomcata

1. GlassFish to kontener typu open source obsługiwany przez firmę Oracle.

   W przeciwieństwie do Tomcat jest to pełnoprawny serwer WWW, który oprócz serwletów może obsługiwać inne komponenty z frameworka JavaEE. Jednocześnie zużywa znacznie więcej pamięci RAM. Większa elastyczność przy dostrajaniu serwera, co utrudnia korzystanie z niego. Warto z niego skorzystać przy tworzeniu aplikacji wykorzystujących framework JavaEE.

2. WildFly - dawniej Jboss . Również open source. Opracowany przez firmę Red Hat. Nazwę zmieniono, aby uniknąć pomylenia z innym produktem firmy - JBoss Enterprise Application Platform.

   WildFly, podobnie jak GlassFish, 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.

3. Jetty - podobnie jak poprzednie, jest oprogramowaniem typu open source. Opracowany przez Eclipse.

   Podobnie jak Tomcat, jest to prosty kontener serwletów, bez obsługi wszystkich komponentów frameworku JavaEE. Jednocześnie jest lżejszy i można go uruchomić nawet na telefonie komórkowym. Szybko się uruchamia i kończy, dobrze się skaluje. W przeciwieństwie do Tomcat ma mniejszą społeczność i bazę wiedzy.

4. WebLogic to licencjonowane oprogramowanie, które wymaga zakupu przed użyciem. Należy do Oracle.

   W porównaniu do Tomcata jego funkcjonalność jest nieco szersza. Może współpracować z protokołem FTP. Ale nie jest tak elastyczny podczas tworzenia i testowania aplikacji.

5. WebSphere (dokładniej WebSphere Application Server) jest oprogramowaniem płatnym. Opracowany przez IBM. Podobnie jak WildFly i GlassFish, jest to pełnoprawny serwer aplikacji. Ma jednak bardziej przyjazny interfejs konfiguracji i wysoką niezawodność działania.

   Wadą jest to, że zużywa dużo zasobów, uruchamianie i zatrzymywanie zajmuje dużo czasu, co nie jest zbyt wygodne przy opracowywaniu małych projektów.

Wybór kontenera serwletów lub serwera aplikacji zależy od konkretnego projektu. Są projekty, w których nawet oczywisty outsider będzie w stanie wykazać się najwyższą jakością, ale na początek lepiej dokładnie zrozumieć jedną rzecz. Prawdopodobnie idealnym kandydatem na to jest Tomcat. My już zrobiliśmy pierwsze kroki w jego studiowaniu, a potem decyzja należy do Ciebie! W końcowych artykułach z serii „Wprowadzenie do rozwoju przedsiębiorstwa” zapoznamy się ze wzorcem MVC. Część 7. Wprowadzenie do wzorca MVC (Model-View-Controller) Część 8. Pisanie małej aplikacji w trybie spring-boot