Partea 6. Recipiente Servlet

Acest material face parte din seria „Introducere în dezvoltarea întreprinderii”. Articole anterioare:

În ultimul articol, ne-am familiarizat cu servlet-urile și am învățat cum să le folosim pentru a crea aplicații web. A sosit momentul să aruncăm o privire mai atentă asupra unei părți esențiale a acestei distracție: containerele servlet.

Cuprins:

Ce este un container servlet?

Este un program care rulează pe un server și poate interacționa cu servlet-urile pe care le-am creat. Cu alte cuvinte, dacă dorim să rulăm aplicația noastră web pe un server, mai întâi implementăm un container de servlet și apoi punem servlet-uri în el. Fluxul de lucru este simplu: atunci când clientul accesează serverul, containerul își procesează cererea, determinând ce servlet ar trebui să o proceseze și apoi transmite cererea. Partea 6. Recipiente Servlet - 2

Cum se folosesc containerele servlet?

Pe lângă cererile de rutare, un container de servlet îndeplinește și alte funcții:

Acesta generează în mod dinamic pagini HTML din fișiere JSP.
Criptează/decriptează mesajele HTTPS.
Oferă acces restricționat pentru administrarea servlet-urilor.

În general, toate acestea sună bine. Acum trebuie doar să ne dăm seama cum să punem totul în practică. Ei bine, pentru a învăța cum să folosești ceva, doar scufundă-te și încearcă să-l folosești :) Așadar, astăzi vom exersa! Cel mai popular container de servlet este Apache Tomcat . Este open source și poate fi folosit gratuit. Descărcați Tomcat pentru sistemul dvs. de operare aici și vom explora lucrul cu containerele „în acțiune”.

Instalarea și pornirea Tomcat

Pentru a instala Tomcat, pur și simplu dezarhivați arhiva descărcată în directorul dorit.
Vă rugăm să rețineți că Tomcat necesită Java versiunea 8 sau mai mare pentru a porni și rula. Verificați dacă variabila de mediu JAVA_HOME face referire la versiunea curentă a JDK.
Apoi, trebuie să configurați accesul utilizatorului la Tomcat . Acest lucru se face în fișierul tomcat-users.xml, care se află în folderul conf.

Există patru roluri prestabilite în Tomcat:
- manager-gui — Acces la interfața grafică și pagina de stare
- manager-script — Acces la interfața text și la pagina de stare
- manager-jmx — Acces la JMX și la pagina de stare
- manager-status — Acces numai la pagina de stare
În interiorul etichetei <tomcat-users>, specificăm în mod explicit aceste roluri și le atribuim utilizatorului nostru:
```
<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"/>
```
Acum totul este gata de lansare!
În folderul bin, rulați fișierul startup.bat (startup.sh pe Linux).
După câteva secunde, deschideți linkul http://localhost:8080/ în browser. Veți vedea un tablou de bord grafic:

Dacă vedeți un meniu ca acesta, atunci Tomcat rulează.
Dacă nu rulează, verificați manual variabilele de mediu JAVA_HOME și CATALINA_HOME:
- JAVA_HOME — Acesta trebuie să facă referire la versiunea curentă de Java 8+.
- CATALINA_BASE — Acesta trebuie să facă referire la Tomcat sau să fie absent (nu ar trebui să facă referire la o altă versiune de Tomcat).

Implementarea unei aplicații în Tomcat

Am reușit să lansăm Tomcat, așa că acum este timpul să implementăm un proiect în el. Să folosim servleturile din articolul anterior . 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");
   }
}

Înainte de implementare, trebuie să ne ambalăm servlet-urile într-un fișier WAR. Maven este de obicei folosit pentru a face acest lucru, dar pentru a crea un fișier WAR aveți nevoie de un fișier web.xml care are o mapare pentru toate servleturile. Am folosit noua adnotare @WebServlet pentru a scrie servleturile, deci nu avem un fișier web.xml. Din fericire, IDEA poate face treaba murdară pentru noi, împachetând proiectul nostru într-un fișier WAR. Pentru a face acest lucru, deschideți structura proiectului (Ctrl+Shift+Alt+S) -> Artefacte -> Selectați fișierul WAR dorit -> Bifați caseta de selectare de lângă „Include în construirea proiectului” -> Faceți clic pe „OK”. Partea 6. Recipiente Servlet - 4

Să construim proiectul folosind combinația de taste Ctrl+F9. Acum fișierul nostru WAR este în directorul țintă. Partea 6. Recipiente Servlet - 5

Fișierul poate fi redenumit în ceva mai simplu, de exemplu servlet.war, și mutat într-un loc mai convenabil, de exemplu C:\\my\\.îl vom pune într-un recipient . Există două moduri de a face acest lucru.

Utilizarea interfeței grafice

Pentru a face acest lucru, urmați acest link: http://localhost:8080/manager/html . Tomcat ar trebui să ceară un nume de utilizator și o parolă.

Dacă m-ați urmărit până în acest moment, atunci numele de utilizator este „utilizator”, iar parola este „parolă” .

După conectarea cu succes, veți vedea Tomcat Web Application Manager. Secțiunea „Aplicații” conține deja 5 aplicații - acestea sunt utilitare Tomcat, care fac Tomcat mai ușor de lucrat. Ele pot fi șterse în viitor.

Mai jos este secțiunea „Implementare”. Aici puteți selecta arhiva WAR de implementat. Să introducem manual calea și contextul:

Faceți clic pe „Deploy” și vedem că aplicația noastră a apărut în secțiunea „Aplicații”:
Folosind interfața grafică Tomcat, putem opri, reporni și șterge o sesiune, precum și setarea duratei sesiunii. La implementare, am specificat contextul /demo, ceea ce înseamnă că aplicația noastră este accesată folosind http://localhost:8080/demo . Verifică. Totul ar trebui să funcționeze.
Prin sistemul de fișiere

Pentru a implementa aplicația în acest fel, trebuie să deschideți directorul în care a fost dezarhivat Tomcat. Apoi accesați folderul „webapps”. Aici veți găsi utilitățile pe care le-am întâlnit deja:

Tot ceea ce este necesar este ca noi să mutăm fișierul nostru servlet.war aici.

Așteptăm câteva secunde și apoi vedem că a apărut un nou folder „servlet”. Aceasta înseamnă că aplicația noastră este implementată. Accesați interfața Manager de aplicații la http://localhost:8080/manager/ . Aici vedem că aplicația noastră este implementată în contextul /servlet:

Când este implementat în acest mod, contextul este atribuit automat pe baza numelui fișierului WAR implementat. Pentru a schimba contextul, puteți redenumi folderul nou creat care conține aplicația, dar înainte de a face asta trebuie să eliminați fișierul WAR. În caz contrar, Tomcat va redistribui aplicația cu numele arhivei.

După cum puteți vedea, implementarea aplicațiilor în Tomcat este mult mai ușoară decât ar părea. Dar celelalte funcții ale sale sunt, de asemenea, ușor de utilizat. Sa verificam.

Folosind HTTPS în loc de HTTP

Dacă vă amintiți, am analizat diferența dintre HTTP și HTTPS într-un articol separat . HTTPS este același protocol ca HTTP, dar criptează datele transmise. Pe partea clientului, browserul este responsabil pentru criptare, dar trebuie să furnizăm criptarea pe partea serverului. Deoarece Tomcat acceptă și direcționează cererile HTTP, este logic să îi delegeți criptarea. Pentru a face acest lucru, trebuie să:

Generați un certificat autosemnat
Faceți setări suplimentare pentru server

Să exersăm să faci asta.

Generarea unui certificat

Indiferent de versiune, JDK include un număr mare de utilitare. Unul dintre ele este instrumentul cheie . Acesta este un instrument pentru generarea și lucrul cu chei de criptare. Pentru a-l folosi, pe linia de comandă, accesați directorul C:\\Program Files\\Java\\jdk1.8.0_181\\bin și rulați comanda keytool -genkey -alias tomcat -keyalg RSA .

keytool — Numele utilitarului pe care îl rulăm cu opțiunile din linia de comandă
-genkey — Indică faptul că dorim să generăm o nouă cheie
-alias tomcat — Creați un alias cheie
-keyalg RSA — Selectați RSA ca algoritm de generare a cheilor

După executarea comenzii, utilitarul începe un dialog cu noi: Partea 6. Recipiente Servlet - 11

Introduceți informațiile necesare. Acum am creat un depozit de chei în directorul nostru principal (pentru Windows, acesta este C:\\Users\\{username}\\.keystore) și o cheie tomcat în el. Am generat un certificat simplu de care majoritatea browserelor se vor plânge. Un astfel de certificat nu este potrivit pentru aplicații comerciale: poate fi utilizat doar în scopuri de testare. Pe un server de producție, trebuie să utilizați un certificat de la o autoritate de certificare (de exemplu, https://letsencrypt.org/ ).

Configurarea serverului

Acum că certificatul este gata, trebuie să ajustăm setările serverului, și anume conectorul SSL. Acest lucru se face în fișierul server.xml, care se află în apache-tomcat-9.0.30/conf/ . În el, găsim blocuri ca acesta:

<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 punem configurația noastră lângă ele:

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

Atribuim cele mai recente valori parametrilor keystoreFile și keystorePass, salvăm fișierul și apoi repornim Tomcat folosind fișierele shutdown.bat și startup.bat. Acum serverul este gata să proceseze solicitările HTTPS. Adresa s-a schimbat doar puțin: https://localhost:8443/demo/hello . Când faceți clic pe link, veți primi un avertisment cu privire la credibilitatea certificatului, ceea ce nu este surprinzător. După cum am spus puțin mai devreme, trebuie să utilizați serviciile uneia dintre autoritățile de certificare pentru a obține un certificat normal. Dar, deocamdată, ne-am atins obiectivul: aplicația rulează folosind protocolul HTTPS și asta este important!

Generarea dinamică a paginilor HTML

Acum vom continua privirea de ansamblu asupra containerelor de servlet, luând în considerare o altă caracteristică: generarea dinamică a paginilor HTML. Imaginați-vă o lume perfectă în care, în loc de cod HTML static plictisitor, puteți scrie cod Java, folosind variabile, bucle, matrice și alte constructe de limbaj. Ai fost în stare să-ți imaginezi? Vestea bună este că există ceva asemănător. Vestea proastă este că nu realizează în totalitate această fantezie. Dacă nu ați ghicit, vorbim despre JavaServer Pages (JSP). Pe scurt, aceasta este o tehnologie care vă permite să inserați bucăți de cod Java într-o pagină HTML. Adevărat, acest cod Java este încă convertit în HTML înainte de a fi trimis către client, dar acel cod HTML va fi generat dinamic, ținând cont de diverși factori. De exemplu, puteți folosi declarații condiționate și puteți returna conținut diferit în funcție de anumite condiții. Exemplu de pagină 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>

Puteți citi mai multe despre JSP aici. La sfârșitul zilei, acest articol nu este despre JSP - suntem aici pentru a vorbi despre containerele de servlet! Deci, de ce am menționat JSP? Este simplu: un container servlet este cel care convertește codul Java din JSP în HTML. Când un servlet va returna conținut JSP ca răspuns, containerul ia notă și îl convertește mai întâi într-o pagină HTML prietenoasă cu browserul înainte de a trimite un astfel de conținut către client. Astăzi, există multe analoge ale tehnologiei JSP - Thymeleaf, FreeMarket, Mustache și altele. Toate lucrează într-un mod similar. Pe care dintre ele să o alegi pentru munca ta este o chestiune de gust. Acest lucru este valabil și pentru alegerea unui container servlet. În aceste exemple, am folosit Tomcat, cel mai comun container, dar unele proiecte folosesc alte containere. Merită să le revizuim pe scurt pe cele mai populare și să ne gândim la modul în care diferă de Tomcat.

Alternative la Tomcat

GlassFish este un container open source a cărui dezvoltare este susținută de Oracle.

Spre deosebire de Tomcat, este un server web cu drepturi depline, care, pe lângă servlet-uri, poate funcționa cu alte componente din cadrul JavaEE. Acestea fiind spuse, folosește mult mai mult RAM. Există o flexibilitate mai mare la reglarea fină a serverului, ceea ce complică utilizarea acestuia. Ar trebui utilizat atunci când se dezvoltă aplicații pe framework-ul JavaEE.
WildFly era cunoscut anterior ca JBoss . Este, de asemenea, open source. Este dezvoltat de Red Hat. Numele a fost schimbat pentru a evita confuzia cu un alt produs al companiei — JBoss Enterprise Application Platform.

La fel ca GlassFish, WildFly este un server web cu drepturi depline. De altfel, sub capotă, WildFly folosește Tomcat ca container de servlet. Spre deosebire de GlassFish, WildFly este mai ușor și mai ușor de configurat.
Jetty , ca și precedentele, este open source. Este dezvoltat de Eclipse.

La fel ca Tomcat, este un simplu container de servlet, fără suport pentru toate componentele framework-ului JavaEE. În același timp, este mai ușor și poate fi rulat chiar și pe un telefon mobil. Pornește și se oprește rapid și se scalează bine. Spre deosebire de Tomcat, are o comunitate mai mică și o bază de cunoștințe.
WebLogic este un software licențiat care trebuie achiziționat înainte de utilizare. Aparține Oracle.

Are o funcționalitate puțin mai largă decât Tomcat. Poate funcționa cu protocolul FTP. Dar nu este atât de flexibil atunci când se dezvoltă și se testează aplicații.
WebSphere (WebSphere Application Server, mai exact) este un software plătit. Este dezvoltat de IBM. Similar cu WildFly și GlassFish, este un server de aplicații complet. Dar are o interfață de configurare mai prietenoasă, plus fiabilitate ridicată în funcționare.

Deficiențele sale includ faptul că folosește o mulțime de resurse și durează mult timp pentru a porni și opri, ceea ce nu este foarte convenabil atunci când se dezvoltă proiecte mici.

Alegerea containerului de servlet sau a serverului de aplicații potrivit depinde de proiectul respectiv. Există proiecte în care chiar și un defavorabil clar se poate dovedi a fi o alegere excelentă, dar la început este mai bine să faceți un studiu aprofundat al unui container de servlet. Tomcat este probabil candidatul perfect pentru acest studiu. Și am făcut deja primii pași în studierea lui, dar de aici depinde de tine! În articolele finale ale seriei „Introducere în dezvoltarea întreprinderii”, vom cunoaște modelul MVC. Partea 7. Prezentarea modelului MVC (Model-View-Controller).