JavaRush /Blog Java /Random-ES /Parte 6: Contenedores de Servlet

Nivel 41

28 febrero 2021
42 views
0 comments

Parte 6: Contenedores de Servlet

Este material es parte de la serie “Introducción al desarrollo empresarial”. Artículos anteriores:

En el último artículo nos familiarizamos con los servlets y aprendimos cómo crear aplicaciones web con su ayuda. Es hora de echar un vistazo más de cerca a lo que estas vacaciones no serían posibles sin los contenedores de servlets.

Contenido:

¿Qué es un contenedor de servlets?

Este es un programa que se ejecuta en el 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. La forma en que funciona es simple: cuando un cliente contacta al servidor, el contenedor procesa su solicitud, determina qué servlet debe procesarla y la transmite. Parte 6. Contenedores de servlets - 2

Cómo utilizar contenedores de servlets

Además de enrutar solicitudes, el contenedor de servlets realiza otras funciones:

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

En general suena bien, solo queda descubrir cómo aplicarlo todo. Bueno, para aprender a usar algo, sólo necesitas... intentar usarlo :) ¡Así que hoy practicaremos! El contenedor de servlets más popular es Apache Tomcat . Es de código abierto y de uso gratuito. Descarga Tomcat para tu sistema operativo desde este enlace y veamos cómo trabajar con contenedores en acción.

Instalación y ejecución de Tomcat

Para instalar Tomcat, simplemente descomprima el archivo descargado en el directorio deseado.
Tenga en cuenta que Tomcat requiere Java versión 8 o superior para ejecutarse. Asegúrese de que la variable de entorno JAVA_HOME haga referencia a la versión actual de jdk.
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.

Tomcat viene provisto de cuatro funciones:
- 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>, escribiremos explícitamente estos roles y se los asignaremos 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"/>
```
¡Ahora todo está listo para lanzarse!
En la carpeta bin, ejecute el archivo startup.bat (startup.sh en Linux).
Después de unos segundos, abra el enlace http://localhost:8080/ en su navegador . Allí aparecerá el administrador gráfico:

Si ve un menú de este tipo, significa que Tomcat se está ejecutando.
Si no funciona, 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_HOME: debe hacer referencia a Tomcat o estar ausente (no debe apuntar a otra versión de Tomcat).

Implementación de una aplicación en Tomcat

Logramos lanzar Tomcat, por lo que es hora de implementar algún tipo de 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();
   }
}

Servlet de índice:

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 del despliegue, nuestros servlets deben empaquetarse en un archivo de guerra. Por lo general, se usa Maven para esto, pero para crear un archivo war necesita un archivo web.xml en el que estén mapeados todos los servlets. Escribimos servlets usando la nueva anotación @WebServlet, por lo que no tenemos web.xml. Afortunadamente, IDEA puede hacer el trabajo sucio por nosotros y envolver nuestro proyecto individualmente en un archivo de guerra. Para hacer esto, debe abrir la estructura del proyecto (Ctrl + Shift + Alt + S) -> Artefactos -> Seleccione la compilación deseada -> Marque la casilla junto a "Incluir en la compilación del proyecto" -> Haga clic en "Aceptar". Parte 6: Contenedores de Servlet - 4

Construya un proyecto usando la combinación Ctrl + F9. Ahora nuestro archivo war está en el directorio de destino. Parte 6: Contenedores de Servlet - 5

Al archivo se le puede cambiar el nombre a algo más simple, por ejemplo, servlet.war, y moverlo a un lugar más conveniente, en C:\my\. Cuando la infusión esté lista para usar, colóquela en un recipiente . Esto se puede hacer de dos formas.

A través de GUI

Para hacer esto, siga el enlace http://localhost:8080/manager/html . Tomcat debería solicitarle un nombre de usuario y una contraseña.

Si repitió todos los pasos después de mí, entonces el inicio de sesión es usuario, la contraseña es contraseña .

Después de la autorización exitosa, verá Tomcat Web Application Manager. La sección Aplicaciones ya contiene 5 aplicaciones: estas son las aplicaciones de utilidad de Tomcat necesarias para simplificar el trabajo con él. Se pueden eliminar en el futuro.

A continuación se muestra la sección Implementar. Al usarlo, puede seleccionar un archivo de guerra para implementarlo. Ingresemos la ruta y el contexto manualmente:

Pulsamos “Implementar”, vemos que nuestra aplicación ha aparecido en la sección Aplicaciones:
Usando la GUI de Tomcat podemos detenerlo, reiniciarlo, establecer la duración de la sesión y eliminarlo. Al implementar, especificamos el contexto /demo, lo que significa que se debe acceder a nuestra aplicación a través del enlace http://localhost:8080/demo . Compruébalo, todo debería funcionar.
A través del sistema de archivos

Para implementar una aplicación de esta manera, debe abrir el directorio en el que está descomprimido Tomcat e ir a webapps. Estas son las aplicaciones de utilidad con las que estamos familiarizados:

Todo lo que tenemos que hacer es mover nuestro servlet.war aquí.

Esperamos unos segundos, vemos que ha aparecido una nueva carpeta de servlets, lo que significa que nuestra aplicación está desplegada. Vayamos a la interfaz familiar del Administrador de aplicaciones: http://localhost:8080/manager/ . Aquí vemos que nuestra aplicación está implementada en el contexto /servlet:

Cuando se implementa de esta manera, el contexto se asigna automáticamente al nombre del archivo de guerra implementado. Para cambiar el contexto, puede cambiar el nombre de la carpeta recién creada con la aplicación, pero antes debe eliminar el archivo: 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 son fáciles de usar. Vamos a revisar.

Usar el protocolo HTTPS en lugar de HTTP

Si recuerda, analizamos la diferencia entre HTTP y HTTPS en un artículo aparte . HTTPS es el mismo protocolo que HTTP, pero utiliza cifrado de los datos que se transfieren. En el lado del cliente, el cifrado lo maneja el navegador y debemos proporcionar cifrado en el lado del servidor. Dado que Tomcat acepta y enruta las solicitudes HTTP, sería lógico delegarle el cifrado. Para hacer esto necesitas:

Generar un certificado autofirmado;
Realice configuraciones adicionales del servidor.

Practiquemos esto.

Generando un certificado

El JDK viene con una gran cantidad de utilidades, independientemente de la versión, una de las cuales es keytool . Esta es una herramienta para generar claves de cifrado y trabajar con ellas. Para usarlo, usando 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: inicia la utilidad con parámetros;
-genkey - indica que queremos generar una nueva clave;
-alias tomcat: crea un alias de clave;
-keyalg RSA: seleccione RSA como algoritmo de generación de claves.

Después de ejecutar el comando, la utilidad iniciará un diálogo con nosotros: Parte 6: Contenedores de Servlet - 11

Ingrese la información necesaria. Ahora hemos creado un almacén de claves en nuestro directorio de inicio (para Windows es C:\Users\{username}\.keystore) y una clave Tomcat en él. Hemos generado un certificado simple que la mayoría de los navegadores aceptarán. Este certificado no es adecuado para aplicaciones comerciales: sólo puede utilizarse con fines de prueba. En el servidor de producción, debe utilizar un certificado de una autoridad certificadora (por ejemplo, https://letsencrypt.org/ ).

Configurando el servidor

Ahora que el certificado está listo, debe 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/ . Encontramos bloques como:

<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 al lado de ellos colocamos nuestra configuración:

<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 a los parámetros keystoreFile y keystorePass los valores que sean relevantes para nosotros, guardamos y reiniciamos Tomcat usando los archivos Shutdown.bat y Startup.bat. Ahora el servidor está listo para procesar solicitudes https, solo un poco en la dirección modificada: https://localhost:8443/demo/hello . Al hacer clic en el enlace, verá una advertencia acerca de que el certificado es cuestionable, lo cual no es sorprendente. Como se describió un poco antes, para obtener un certificado normal es necesario utilizar los servicios de uno de los servicios de certificación. Pero hasta ahora hemos logrado nuestro objetivo: la aplicación funciona mediante el protocolo HTTPS, ¡y esto es lo principal!

Generación dinámica de páginas HTML.

Ahora continuemos nuestra revisión de otras características de los contenedores de servlets: generación dinámica de páginas HTML. Imagine un mundo ideal en el que, en lugar de aburrido código HTML estático, pudiera escribir código JAVA utilizando variables, bucles, matrices y otras construcciones del lenguaje. ¿Te imaginaste? La buena noticia es que existe algo similar, la mala noticia es que no existe del todo. Si no lo has adivinado, estamos hablando de la tecnología JSP (Java Server Pages). En resumen, se trata de una tecnología que permite insertar fragmentos de código JAVA en una página HTML. Es cierto que este código aún se convierte en HTML antes de enviarlo al cliente, pero se generará dinámicamente teniendo en cuenta varios factores. Por ejemplo, puede utilizar construcciones condicionales y ofrecer contenido diferente según 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>

Puede leer más sobre JSP aquí . En realidad... ¡no estamos aquí para esto, sino por el bien de los contenedores de servlets! ¿Qué tiene que ver JSP con esto? Es simple: la transformación del código JAVA de JSP a código HTML la realiza el contenedor de servlets. Cuando un servlet está a punto de devolver contenido JSP como respuesta, el contenedor se da cuenta y primero lo convierte en una página HTML legible por el navegador antes de enviar ese contenido al cliente. Hoy en día existen muchos análogos de la tecnología JSP: Thymeleaf, FreeMarket, Moustache y otros. Todos funcionan según un principio similar. Cuál elegir para trabajar es cuestión de gustos. Esto también se aplica a la elección de un contenedor de servlets. En los ejemplos utilizamos Tomcat, el contenedor más común, pero algunos proyectos utilizan otros. Vale la pena familiarizarse brevemente con los más populares y observar sus diferencias con respecto a Tomcat.

Alternativas a Tomcat

GlassFish es un contenedor de código abierto respaldado por Oracle.

A diferencia de Tomcat, es un servidor web completo que, además de los servlets, puede operar otros componentes del marco JavaEE. Al mismo tiempo, utiliza mucha más RAM. Más flexibilidad a la hora de ajustar el servidor, lo que dificulta su uso. Vale la pena utilizarlo al desarrollar aplicaciones utilizando el marco JavaEE.
WildFly : anteriormente Jboss . También de código abierto. Desarrollado por Red Hat. El nombre se cambió para evitar confusión con otro producto de la empresa: JBoss Enterprise Application Platform.

WildFly, al igual que GlassFish, es un servidor web completo. Por cierto, bajo el capó, WildFly usa Tomcat como contenedor de servlets. A diferencia de GlassFish, WildFly es más liviano y más fácil de configurar.
Jetty – similar a los anteriores, es de código abierto. Desarrollado por Eclipse.

Al igual que Tomcat, es un contenedor de servlets simple, sin soporte para todos los componentes del marco JavaEE. Al mismo tiempo, es más liviano y se puede ejecutar incluso en un teléfono móvil. Comienza y se detiene rápidamente y escala bien. A diferencia de Tomcat, tiene una comunidad y una base de conocimientos más pequeñas.
WebLogic es un software con licencia que requiere compra antes de su uso. Propiedad de Oráculo.

En comparación con Tomcat, su funcionalidad es un poco más amplia. Puede trabajar con el protocolo ftp. Pero no es tan flexible a la hora de desarrollar y probar aplicaciones.
WebSphere (WebSphere Application Server para ser precisos) es un software pago. Desarrollado por IBM. Similar a WildFly y GlassFish, es un servidor de aplicaciones completo. Pero tiene una interfaz de configuración más amigable y una alta confiabilidad operativa.

La desventaja es que consume muchos recursos, tarda mucho en iniciarse y detenerse, lo que no resulta muy conveniente a la hora de desarrollar proyectos pequeños.

Qué contenedor de servlets o servidor de aplicaciones elegir depende del proyecto específico. Hay proyectos en los que incluso un extraño evidente podrá demostrar su valía con la más alta calidad, pero al principio es mejor comprender una cosa a fondo. Probablemente el candidato ideal para este sea Tomcat. Nosotros ya hemos dado los primeros pasos para estudiarlo y luego ¡tú decides! En los artículos finales de la serie "Introducción al desarrollo empresarial", nos familiarizaremos con el patrón MVC. Parte 7. Introducción al patrón MVC (Modelo-Vista-Controlador) Parte 8. Escribir una pequeña aplicación en spring-boot

Comentarios

TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION