Parte 6. Contenitori servlet

Questo materiale fa parte della serie "Introduzione allo sviluppo aziendale". Articoli precedenti:

• sulla rete
• sull'architettura del software
• su HTTP/HTTPS
• sulle basi di Maven
• sui servlet (scrittura di una semplice applicazione web)

Nell'ultimo articolo, abbiamo familiarizzato con i servlet e imparato come usarli per creare applicazioni web. È giunto il momento di dare un'occhiata più da vicino a una parte essenziale di questo divertimento: i contenitori servlet.

Sommario:

• Che cos'è un contenitore servlet?
• Come vengono utilizzati i contenitori servlet?
• Installazione e avvio di Tomcat
• Distribuzione di un'applicazione in Tomcat
• Utilizzo di HTTPS invece di HTTP
• Generazione di un certificato
• Configurazione del server
• Generazione dinamica di pagine HTML
• Alternative a Tomcat

Che cos'è un contenitore servlet?

È un programma che gira su un server e può interagire con i servlet che abbiamo creato. In altre parole, se vogliamo eseguire la nostra applicazione Web su un server, prima distribuiamo un servlet container e poi vi inseriamo i servlet. Il flusso di lavoro è semplice: quando il client accede al server, il contenitore elabora la sua richiesta, determinando quale servlet deve elaborarla, quindi trasmette la richiesta.

Come vengono utilizzati i contenitori servlet?

Oltre a instradare le richieste, un servlet container svolge altre funzioni:

1. Genera dinamicamente pagine HTML da file JSP.
2. Crittografa/decrittografa i messaggi HTTPS.
3. Fornisce accesso limitato per l'amministrazione del servlet.

In generale, tutto questo suona bene. Ora dobbiamo solo capire come mettere tutto in pratica. Bene, per imparare a usare qualcosa, tuffati e prova a usarlo :) Allora, oggi ci eserciteremo! Il contenitore servlet più popolare è Apache Tomcat . È open source e può essere utilizzato gratuitamente. Scarica Tomcat per il tuo sistema operativo qui ed esploreremo il lavoro con i contenitori "in azione".

Installazione e avvio di Tomcat

1. Per installare Tomcat, è sufficiente decomprimere l'archivio scaricato nella directory desiderata.

2. Tieni presente che Tomcat richiede Java versione 8 o successiva per l'avvio e l'esecuzione. Verificare che la variabile di ambiente JAVA_HOME faccia riferimento alla versione corrente di JDK.

3. Successivamente, è necessario configurare l'accesso degli utenti a Tomcat . Questo viene fatto nel file tomcat-users.xml, che si trova nella cartella conf.

   Ci sono quattro ruoli preimpostati in Tomcat:

   • manager-gui — Accesso all'interfaccia grafica e alla pagina di stato
   • manager-script — Accesso all'interfaccia testuale e alla pagina di stato
   • manager-jmx — Accesso a JMX e alla pagina di stato
   • manager-status — Accesso solo alla pagina di stato

   All'interno del tag <tomcat-users>, specifichiamo esplicitamente questi ruoli e li assegniamo al nostro utente:

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

   Ora è tutto pronto per il lancio!

4. Nella cartella bin, esegui il file startup.bat (startup.sh su Linux).

5. Dopo alcuni secondi, apri il link http://localhost:8080/ nel tuo browser. Vedrai una dashboard grafica:

   Se vedi un menu come questo, Tomcat è in esecuzione.

6. Se non è in esecuzione, controlla manualmente le variabili di ambiente JAVA_HOME e CATALINA_HOME:

   • JAVA_HOME — Deve fare riferimento alla versione corrente di Java 8+.
   • CATALINA_BASE — Deve fare riferimento a Tomcat o essere assente (non deve fare riferimento a un'altra versione di Tomcat).

Distribuzione di un'applicazione in Tomcat

Siamo riusciti a lanciare Tomcat, quindi è giunto il momento di implementare qualche progetto al suo interno. Usiamo i servlet dell'articolo precedente . Servlet principale:

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

IndiceServlet:

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

Prima della distribuzione, dobbiamo impacchettare i nostri servlet in un file WAR. Maven viene solitamente utilizzato per eseguire questa operazione, ma per creare un file WAR è necessario un file web.xml con una mappatura per tutti i servlet. Abbiamo usato la nuova annotazione @WebServlet per scrivere i servlet, quindi non abbiamo un file web.xml. Fortunatamente, IDEA può fare il lavoro sporco per noi, avvolgendo il nostro progetto in un file WAR. Per fare ciò, apri la struttura del progetto (Ctrl+Shift+Alt+S) -> Artefatti -> Seleziona il file WAR desiderato -> Seleziona la casella di controllo accanto a "Includi nella build del progetto" -> Fai clic su "OK". Costruiamo il progetto usando la combinazione di tasti Ctrl+F9. Ora il nostro file WAR è nella directory di destinazione. Il file può essere rinominato in qualcosa di più semplice, ad esempio servlet.war, e spostato in una posizione più comoda, ad esempio C:\\my\\.lo metteremo in un contenitore . Ci sono due modi per farlo.

1. Utilizzo dell'interfaccia grafica

   Per fare ciò, segui questo link: http://localhost:8080/manager/html . Tomcat dovrebbe chiedere un nome utente e una password.

   Se mi hai seguito fino a questo punto, il nome utente è "user" e la password è "password" .

   Dopo aver effettuato correttamente l'accesso, vedrai Tomcat Web Application Manager. La sezione "Applicazioni" contiene già 5 applicazioni: si tratta di utilità Tomcat, che semplificano l'utilizzo di Tomcat. Possono essere cancellati in futuro.

   Di seguito è riportata la sezione "Distribuzione". Qui puoi selezionare l'archivio WAR da distribuire. Inseriamo manualmente il percorso e il contesto:

   Fai clic su "Distribuisci" e vediamo che la nostra applicazione è apparsa nella sezione "Applicazioni":

   Utilizzando l'interfaccia grafica di Tomcat, possiamo interrompere, riavviare ed eliminare una sessione, nonché impostare la durata della sessione. Durante la distribuzione, abbiamo specificato il contesto /demo, il che significa che si accede alla nostra applicazione utilizzando http://localhost:8080/demo . Controllalo. Tutto dovrebbe funzionare.

2. Attraverso il file system

   Per distribuire l'applicazione in questo modo, è necessario aprire la directory in cui è stato decompresso Tomcat. Quindi vai alla cartella "webapps". Qui troverai le utilità che abbiamo già incontrato:

   Tutto ciò che è richiesto è spostare qui il nostro file servlet.war.

   Aspettiamo qualche secondo e poi vediamo che è apparsa una nuova cartella "servlet". Ciò significa che la nostra applicazione è distribuita. Vai all'interfaccia di Application Manager all'indirizzo http://localhost:8080/manager/ . Qui vediamo che la nostra applicazione è distribuita nel contesto /servlet:

   Quando distribuito in questo modo, il contesto viene assegnato automaticamente in base al nome del file WAR distribuito. Per cambiare il contesto, puoi rinominare la cartella appena creata che contiene l'applicazione, ma prima di farlo devi rimuovere il file WAR. In caso contrario, Tomcat ridistribuirà l'applicazione con il nome dell'archivio.

   Come puoi vedere, la distribuzione di applicazioni in Tomcat è molto più semplice di quanto possa sembrare. Ma anche le sue altre funzioni sono facili da usare. Controlliamo.

Utilizzo di HTTPS invece di HTTP

Se ricordi, abbiamo esaminato la differenza tra HTTP e HTTPS in un articolo separato . HTTPS è lo stesso protocollo di HTTP, ma crittografa i dati trasmessi. Sul lato client, il browser è responsabile della crittografia, ma dobbiamo fornire la crittografia sul lato server. Poiché Tomcat accetta e instrada le richieste HTTP, ha senso delegargli la crittografia. Per fare questo, dobbiamo:

1. Genera un certificato autofirmato
2. Effettua ulteriori impostazioni del server

Esercitiamoci a farlo.

Generazione di un certificato

Indipendentemente dalla versione, il JDK include un gran numero di utilità. Uno di questi è keytool . Questo è uno strumento per generare e lavorare con le chiavi di crittografia. Per usarlo, sulla riga di comando, vai alla directory C:\\Program Files\\Java\\jdk1.8.0_181\\bin ed esegui il comando keytool -genkey -alias tomcat -keyalg RSA .

• keytool — Il nome dell'utilità che stiamo eseguendo con le opzioni della riga di comando
• -genkey — Indica che vogliamo generare una nuova chiave
• -alias tomcat — Crea un alias chiave
• -keyalg RSA — Selezionare RSA come algoritmo di generazione della chiave

Dopo aver eseguito il comando, l'utilità avvia un dialogo con noi: inserisci le informazioni necessarie. Ora abbiamo creato un keystore nella nostra home directory (per Windows, questo è C:\\Users\\{username}\\.keystore) e una chiave Tomcat al suo interno. Abbiamo generato un semplice certificato di cui la maggior parte dei browser si lamenterà. Tale certificato non è adatto per applicazioni commerciali: può essere utilizzato solo a scopo di test. Su un server di produzione, è necessario utilizzare un certificato di un'autorità di certificazione (ad esempio, https://letsencrypt.org/ ).

Configurazione del server

Ora che il certificato è pronto, dobbiamo regolare le impostazioni del server, ovvero il connettore SSL. Questo viene fatto nel file server.xml, che si trova in apache-tomcat-9.0.30/conf/ . In esso troviamo blocchi come questo:

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

e mettiamo la nostra configurazione accanto a loro:

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

Assegniamo i valori più recenti ai parametri keystoreFile e keystorePass, salviamo il file e quindi riavviamo Tomcat utilizzando i file shutdown.bat e startup.bat. Ora il server è pronto per elaborare le richieste HTTPS. L'indirizzo è leggermente cambiato: https://localhost:8443/demo/hello . Quando fai clic sul collegamento riceverai un avviso sull'affidabilità del certificato, il che non è sorprendente. Come abbiamo detto poco prima, è necessario utilizzare i servizi di una delle autorità di certificazione per ottenere un normale certificato. Ma per ora abbiamo raggiunto il nostro obiettivo: l'applicazione viene eseguita utilizzando il protocollo HTTPS, e questo è importante!

Generazione dinamica di pagine HTML

Ora continueremo la nostra panoramica dei contenitori servlet considerando un'altra caratteristica: la generazione dinamica di pagine HTML. Immagina un mondo perfetto in cui, invece di noioso codice HTML statico, potresti scrivere codice Java, usando variabili, loop, array e altri costrutti linguistici. Siete riusciti ad immaginarlo? La buona notizia è che esiste qualcosa di simile. La cattiva notizia è che non realizza interamente questa fantasia. Se non hai indovinato, stiamo parlando di JavaServer Pages (JSP). In breve, si tratta di una tecnologia che consente di inserire parti di codice Java in una pagina HTML. È vero, questo codice Java viene ancora convertito in HTML prima di essere inviato al client, ma quell'HTML verrà generato dinamicamente, tenendo conto di vari fattori. Per esempio, puoi utilizzare istruzioni condizionali e restituire contenuti diversi a seconda di alcune condizioni. Esempio di pagina 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>

Puoi leggere di più su JSP qui. Alla fine della giornata, questo articolo non riguarda JSP: siamo qui per parlare di contenitori servlet! Allora perché abbiamo menzionato JSP? È semplice: un contenitore servlet è ciò che converte il codice Java da JSP a HTML. Quando un servlet restituirà il contenuto JSP come risposta, il contenitore ne prende nota e lo converte prima in una pagina HTML compatibile con il browser prima di inviare tale contenuto al client. Oggi ci sono molti analoghi alla tecnologia JSP: Thymeleaf, FreeMarket, Moustache e altri. Funzionano tutti in modo simile. Quale di loro scegliere per il tuo lavoro è una questione di gusti. Questo vale anche per la scelta di un contenitore servlet. In questi esempi abbiamo utilizzato Tomcat, il contenitore più comune, ma alcuni progetti utilizzano altri contenitori. Vale la pena rivedere brevemente i più popolari e considerare in che modo differiscono da Tomcat.

Alternative a Tomcat

1. GlassFish è un contenitore open source il cui sviluppo è supportato da Oracle.

   A differenza di Tomcat, è un server Web completo che, oltre ai servlet, può funzionare con altri componenti del framework JavaEE. Detto questo, utilizza molta più RAM. C'è una maggiore flessibilità durante la messa a punto del server, il che ne complica l'utilizzo. Dovrebbe essere utilizzato durante lo sviluppo di applicazioni sul framework JavaEE.

2. WildFly era precedentemente noto come JBoss . È anche open source. È sviluppato da Red Hat. Il nome è stato cambiato per evitare confusione con un altro dei prodotti dell'azienda: JBoss Enterprise Application Platform.

   Come GlassFish, WildFly è un server web completo. Per inciso, sotto il cofano, WildFly utilizza Tomcat come contenitore servlet. A differenza di GlassFish, WildFly è più leggero e facile da configurare.

3. Jetty , come i precedenti, è open source. È sviluppato da Eclipse.

   Come Tomcat, è un semplice contenitore servlet, senza supporto per tutti i componenti del framework JavaEE. Allo stesso tempo, è più leggero e può essere eseguito anche su un telefono cellulare. Si avvia e si arresta rapidamente e si adatta bene. A differenza di Tomcat, ha una comunità e una base di conoscenza più piccole.

4. WebLogic è un software con licenza che deve essere acquistato prima dell'uso. Appartiene a Oracle.

   Ha funzionalità leggermente più ampie rispetto a Tomcat. Può funzionare con il protocollo FTP. Ma non è così flessibile durante lo sviluppo e il test delle applicazioni.

5. WebSphere (WebSphere Application Server, per la precisione) è un software a pagamento. È sviluppato da IBM. Simile a WildFly e GlassFish, è un application server completo. Ma ha un'interfaccia di configurazione più amichevole, oltre a un'elevata affidabilità operativa.

   I suoi difetti includono il fatto che utilizza molte risorse e richiede molto tempo per l'avvio e l'arresto, il che non è molto conveniente quando si sviluppano piccoli progetti.

La scelta del contenitore servlet o del server delle applicazioni corretto dipende dal progetto specifico. Ci sono progetti in cui anche un chiaro sfavorito può rivelarsi una scelta eccellente, ma all'inizio è meglio fare uno studio approfondito di un contenitore servlet. Tomcat è probabilmente il candidato perfetto per questo studio. E abbiamo già mosso i primi passi nello studiarlo, ma da qui tocca a te! Negli articoli finali della serie "Introduzione allo sviluppo aziendale", conosceremo il modello MVC. Parte 7. Presentazione del pattern MVC (Model-View-Controller).