- despre crearea de rețele
- despre arhitectura software
- despre HTTP/HTTPS
- despre elementele de bază ale lui Maven
- despre servlet-uri (scrierea unei aplicații web simple)

Cuprins:
- Ce este un container servlet?
- Cum se folosesc containerele servlet?
- Instalarea și pornirea Tomcat
- Implementarea unei aplicații în Tomcat
- Folosind HTTPS în loc de HTTP
- Generarea unui certificat
- Configurarea serverului
- Generarea dinamică a paginilor HTML
- Alternative la Tomcat
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.
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.
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”. 

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

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.
GO TO FULL VERSION