Parte 6. Contenedores de servlet

Este material forma parte de la serie "Introducción al desarrollo empresarial". Artículos anteriores:

• acerca de la creación de redes
• sobre arquitectura de software
• sobre HTTP/HTTPS
• sobre los conceptos básicos de Maven
• sobre servlets (escribir una aplicación web simple)

En el último artículo, nos familiarizamos con los servlets y aprendimos a usarlos para crear aplicaciones web. Ha llegado el momento de echar un vistazo más de cerca a una parte esencial de esta diversión: los contenedores de servlets.

Tabla de contenido:

• ¿Qué es un contenedor de servlets?
• ¿Cómo se utilizan los contenedores de servlets?
• Instalación e inicio de Tomcat
• Implementación de una aplicación en Tomcat
• Usar HTTPS en lugar de HTTP
• Generando un certificado
• Configurando el servidor
• Generación dinámica de páginas HTML
• Alternativas a Tomcat

¿Qué es un contenedor de servlets?

Es un programa que se ejecuta en un servidor y puede interactuar con los servlets que creamos. En otras palabras, si queremos ejecutar nuestra aplicación web en un servidor, primero implementamos un contenedor de servlets y luego colocamos los servlets en él. El flujo de trabajo es simple: cuando el cliente accede al servidor, el contenedor procesa su solicitud, determina qué servlet debe procesarlo y luego pasa la solicitud.

¿Cómo se utilizan los contenedores de servlets?

Además de enrutar solicitudes, un contenedor de servlet realiza otras funciones:

1. Genera dinámicamente páginas HTML a partir de archivos JSP.
2. Cifra/descifra los mensajes HTTPS.
3. Proporciona acceso restringido para la administración de servlets.

En general, todo esto suena bien. Ahora solo tenemos que descubrir cómo ponerlo todo en práctica. Bueno, para aprender a usar algo, simplemente sumérgete e intenta usarlo :) Entonces, ¡hoy vamos a practicar! El contenedor de servlet más popular es Apache Tomcat . Es de código abierto y se puede utilizar de forma gratuita. Descargue Tomcat para su sistema operativo aquí y exploraremos cómo trabajar con contenedores "en acción".

Instalación e inicio de Tomcat

1. Para instalar Tomcat, simplemente descomprima el archivo descargado en el directorio deseado.

2. Tenga en cuenta que Tomcat requiere la versión 8 de Java o superior para iniciarse y ejecutarse. Verifique que la variable de entorno JAVA_HOME haga referencia a la versión actual del JDK.

3. A continuación, debe configurar el acceso de los usuarios a Tomcat . Esto se hace en el archivo tomcat-users.xml, que se encuentra en la carpeta conf.

   Hay cuatro roles preestablecidos en Tomcat:

   • manager-gui — Acceso a la interfaz gráfica y a la página de estado
   • manager-script — Acceso a la interfaz de texto y a la página de estado
   • manager-jmx — Acceso a JMX y a la página de estado
   • manager-status — Acceso solo a la página de estado

   Dentro de la etiqueta <tomcat-users>, especificamos explícitamente estos roles y los asignamos a nuestro usuario:

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

   ¡Ya está todo listo para el lanzamiento!

4. En la carpeta bin, ejecute el archivo startup.bat (startup.sh en Linux).

5. Después de unos segundos, abra el enlace http://localhost:8080/ en su navegador. Verá un tablero gráfico:

   Si ve un menú como este, Tomcat se está ejecutando.

6. Si no se está ejecutando, verifique manualmente las variables de entorno JAVA_HOME y CATALINA_HOME:

   • JAVA_HOME: debe hacer referencia a la versión actual de Java 8+.
   • CATALINA_BASE: debe hacer referencia a Tomcat o estar ausente (no debe hacer referencia a otra versión de Tomcat).

Implementación de una aplicación en Tomcat

Logramos lanzar Tomcat, por lo que ahora es el momento de implementar algún proyecto en él. Usemos los servlets del artículo anterior . Servlet principal:

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

Antes de implementar, debemos empaquetar nuestros servlets en un archivo WAR. Maven generalmente se usa para hacer esto, pero para crear un archivo WAR necesita un archivo web.xml que tenga una asignación para todos los servlets. Usamos la nueva anotación @WebServlet para escribir los servlets, por lo que no tenemos un archivo web.xml. Afortunadamente, IDEA puede hacer el trabajo sucio por nosotros, envolviendo nuestro proyecto en un archivo WAR. Para hacer esto, abra la estructura del proyecto (Ctrl+Shift+Alt+S) -> Artefactos -> Seleccione el archivo WAR deseado -> Seleccione la casilla de verificación junto a "Incluir en la construcción del proyecto" -> Haga clic en "Aceptar". Construyamos el proyecto usando la combinación de teclas Ctrl+F9. Ahora nuestro archivo WAR está en el directorio de destino. Se puede cambiar el nombre del archivo a algo más simple, por ejemplo, servlet.war, y moverlo a un lugar más conveniente, por ejemplo, C:\\my\\.Lo pondremos en un recipiente . Hay dos maneras de hacer esto.

1. Uso de la interfaz gráfica

   Para hacer esto, siga este enlace: http://localhost:8080/manager/html . Tomcat debe solicitar un nombre de usuario y una contraseña.

   Si me siguió hasta este punto, entonces el nombre de usuario es "usuario" y la contraseña es "contraseña" .

   Después de iniciar sesión con éxito, verá el Administrador de aplicaciones web de Tomcat. La sección "Aplicaciones" ya contiene 5 aplicaciones: estas son utilidades de Tomcat, que facilitan el trabajo con Tomcat. Se pueden eliminar en el futuro.

   A continuación se muestra la sección "Implementar". Aquí puede seleccionar el archivo WAR para implementar. Ingresemos la ruta y el contexto manualmente:

   Hacemos clic en "Desplegar" y vemos que nuestra aplicación ha aparecido en la sección "Aplicaciones":

   Usando la interfaz gráfica de Tomcat, podemos detener, reiniciar y eliminar una sesión, así como establecer la duración de la sesión. Al implementar, especificamos el contexto /demo, lo que significa que se accede a nuestra aplicación usando http://localhost:8080/demo . Revisalo. Todo debería funcionar.

2. A través del sistema de archivos

   Para implementar la aplicación de esta manera, debe abrir el directorio donde se descomprimió Tomcat. Luego vaya a la carpeta "webapps". Aquí encontrarás las utilidades que ya hemos encontrado:

   Todo lo que se requiere es que movamos nuestro archivo servlet.war aquí.

   Esperamos unos segundos y luego vemos que ha aparecido una nueva carpeta "servlet". Esto significa que nuestra aplicación está implementada. Vaya a la interfaz del administrador de aplicaciones en http://localhost:8080/manager/ . Aquí vemos que nuestra aplicación se implementa en el contexto /servlet:

   Cuando se implementa de esta manera, el contexto se asigna automáticamente según el nombre del archivo WAR implementado. Para cambiar el contexto, puede cambiar el nombre de la carpeta recién creada que contiene la aplicación, pero antes de hacerlo, debe eliminar el archivo WAR. De lo contrario, Tomcat volverá a implementar la aplicación con el nombre del archivo.

   Como puede ver, implementar aplicaciones en Tomcat es mucho más fácil de lo que parece. Pero sus otras funciones también son fáciles de usar. Vamos a revisar.

Usar HTTPS en lugar de HTTP

Si recuerda, vimos la diferencia entre HTTP y HTTPS en un artículo separado . HTTPS es el mismo protocolo que HTTP, pero cifra los datos que se transmiten. Del lado del cliente, el navegador es responsable del cifrado, pero debemos proporcionar el cifrado del lado del servidor. Dado que Tomcat acepta y enruta solicitudes HTTP, tiene sentido delegarle el cifrado. Para ello, debemos:

1. Generar un certificado autofirmado
2. Hacer configuraciones de servidor adicionales

Practiquemos hacer esto.

Generando un certificado

Independientemente de la versión, el JDK incluye una gran cantidad de utilidades. Uno de ellos es keytool . Esta es una herramienta para generar y trabajar con claves de cifrado. Para usarlo, en la línea de comando, vaya al directorio C:\\Program Files\\Java\\jdk1.8.0_181\\bin y ejecute el comando keytool -genkey -alias tomcat -keyalg RSA .

• keytool — El nombre de la utilidad que estamos ejecutando con opciones de línea de comando
• -genkey — Indicar que queremos generar una nueva clave
• -alias tomcat — Crear un alias clave
• -keyalg RSA: seleccione RSA como el algoritmo de generación de claves

Después de ejecutar el comando, la utilidad inicia un diálogo con nosotros: ingrese la información necesaria. Ahora hemos creado un almacén de claves en nuestro directorio de inicio (para Windows, esto es C:\\Users\\{nombre de usuario}\\.keystore) y una clave tomcat en él. Generamos un certificado simple del que la mayoría de los navegadores se quejarán. Dicho certificado no es adecuado para aplicaciones comerciales: solo se puede utilizar con fines de prueba. En un servidor de producción, debe usar un certificado de una autoridad de certificación (por ejemplo, https://letsencrypt.org/ ).

Configurando el servidor

Ahora que el certificado está listo, debemos ajustar la configuración del servidor, es decir, el conector SSL. Esto se hace en el archivo server.xml, que se encuentra en apache-tomcat-9.0.30/conf/ . En él encontramos bloques como este:

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

y ponemos nuestra configuración junto a ellos:

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

Asignamos los últimos valores a los parámetros keystoreFile y keystorePass, guardamos el archivo y luego reiniciamos Tomcat usando los archivos shutdown.bat y startup.bat. Ahora el servidor está listo para procesar solicitudes HTTPS. La dirección ha cambiado solo un poco: https://localhost:8443/demo/hello . Cuando haga clic en el enlace, recibirá una advertencia sobre la confiabilidad del certificado, lo cual no es sorprendente. Como dijimos un poco antes, debe utilizar los servicios de una de las autoridades de certificación para obtener un certificado normal. Pero por ahora, hemos logrado nuestro objetivo: la aplicación se ejecuta con el protocolo HTTPS, ¡y eso es importante!

Generación dinámica de páginas HTML

Ahora continuaremos con nuestra descripción general de los contenedores de servlets considerando otra característica: la generación dinámica de páginas HTML. Imagine un mundo perfecto donde, en lugar del aburrido código HTML estático, podría escribir código Java, usando variables, bucles, matrices y otras construcciones de lenguaje. ¿Eras capaz de imaginarlo? La buena noticia es que existe algo similar. La mala noticia es que no logra del todo esta fantasía. Si no lo ha adivinado, estamos hablando de JavaServer Pages (JSP). En resumen, esta es una tecnología que le permite insertar fragmentos de código Java en una página HTML. Es cierto que este código Java todavía se convierte en HTML antes de enviarlo al cliente, pero ese HTML se generará dinámicamente, teniendo en cuenta varios factores. Por ejemplo, puede usar declaraciones condicionales y devolver contenido diferente dependiendo de alguna condición. Ejemplo de página 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>

Puedes leer más sobre JSP aquí. Al final del día, este artículo no trata sobre JSP: ¡estamos aquí para hablar sobre los contenedores de servlets! Entonces, ¿por qué mencionamos JSP? Es simple: un contenedor de servlet es lo que convierte el código Java de JSP a HTML. Cuando un servlet va a devolver contenido JSP como respuesta, el contenedor toma nota y primero lo convierte en una página HTML compatible con el navegador antes de enviar dicho contenido al cliente. Hoy en día, existen muchos análogos a la tecnología JSP: Thymeleaf, FreeMarket, Moustache y otros. Todos funcionan de manera similar. Cuál de ellos elegir para tu trabajo es cuestión de gustos. Esto también se aplica a la elección de un contenedor de servlet. En estos ejemplos, usamos Tomcat, el contenedor más común, pero algunos proyectos usan otros contenedores. Vale la pena revisar brevemente los más populares y considerar en qué se diferencian de Tomcat.

Alternativas a Tomcat

1. GlassFish es un contenedor de código abierto cuyo desarrollo cuenta con el apoyo de Oracle.

   A diferencia de Tomcat, es un servidor web completo que, además de los servlets, puede operar con otros componentes del marco JavaEE. Dicho esto, utiliza mucha más memoria RAM. Hay mayor flexibilidad a la hora de afinar el servidor, lo que complica su uso. Debe usarse al desarrollar aplicaciones en el marco JavaEE.

2. WildFly se conocía anteriormente como JBoss . También es de código abierto. Está desarrollado por Red Hat. Se cambió el nombre para evitar confusiones con otro de los productos de la empresa: JBoss Enterprise Application Platform.

   Al igual que GlassFish, WildFly es un servidor web completo. Por cierto, bajo el capó, WildFly usa Tomcat como contenedor de servlet. A diferencia de GlassFish, WildFly es más liviano y fácil de configurar.

3. Jetty , al igual que los anteriores, es de código abierto. Está desarrollado por Eclipse.

   Al igual que Tomcat, es un contenedor de servlet simple, sin soporte para todos los componentes del marco JavaEE. Al mismo tiempo, es más ligero e incluso se puede ejecutar en un teléfono móvil. Arranca y se detiene rápidamente y escala bien. A diferencia de Tomcat, tiene una comunidad y una base de conocimiento más pequeñas.

4. WebLogic es un software con licencia que debe comprarse antes de su uso. Pertenece a Oracle.

   Tiene una funcionalidad ligeramente más amplia que Tomcat. Puede trabajar con el protocolo FTP. Pero no es tan flexible a la hora de desarrollar y probar aplicaciones.

5. WebSphere (WebSphere Application Server, para ser precisos) es un software de pago. Es desarrollado por IBM. Similar a WildFly y GlassFish, es un servidor de aplicaciones completo. Pero tiene una interfaz de configuración más amigable, además de una alta confiabilidad en la operación.

   Entre sus deficiencias se encuentra el hecho de que consume muchos recursos y tarda mucho en iniciarse y detenerse, lo que no es muy conveniente a la hora de desarrollar proyectos pequeños.

La elección del contenedor de servlet o servidor de aplicaciones correcto depende del proyecto en particular. Hay proyectos en los que incluso un claro desvalido puede resultar una excelente opción, pero al principio es mejor hacer un estudio en profundidad de un contenedor de servlets. Tomcat es probablemente el candidato perfecto para este estudio. Y ya hemos dado los primeros pasos para estudiarlo, ¡pero a partir de aquí te toca a ti! En los artículos finales de la serie "Introducción al desarrollo empresarial", conoceremos el patrón MVC. Parte 7. Introducción al patrón MVC (Modelo-Vista-Controlador)