Dominio de Servlets y JSP: Arquitectura y Gestión de Estado

Arquitectura de Comunicación en Java Web

El desarrollo web con Java se fundamenta en el protocolo HTTP, el cual se divide en dos estructuras principales: la petición (request) y la respuesta (response). Una petición estándar consta de una línea de solicitud, cabeceras (headers) como Accept-Language o Content-Type, y un cuerpo (body) que contiene los datos en métodos POST.

En el lado del servidor, las respuestas utilizan códigos de estado para informar al cliante el resultado de la operación:

  • 200 OK: Éxito en la transacción.
  • 301/302: Redireccionamiento.
  • 400: Petición con sintaxis incorrecta.
  • 403: Acceso denegado (prohibido).
  • 404: Recurso no encontrado.
  • 500: Error interno del servidor.

Transferencia de Control: Forward vs Redirect

Existen dos mecanismos fundamentales para navegar entre recursos dentro de un contenedor de Servlets:

Request Forwarding (Despacho Interno)

Ocurre internamente en el servidor (Tomcat). El objeto request se transfiere de un Servlet a otro sin que el navegador cambie la URL original.

@Override
protected void doGet(HttpServletRequest solicitud, HttpServletResponse respuesta) 
        throws ServletException, IOException {
    // Definir un atributo personalizado
    solicitud.setAttribute("info_interna", "Datos de transferencia");
    
    // Realizar el despacho
    solicitud.getRequestDispatcher("/vistas/resultado.jsp").forward(solicitud, respuesta);
}

Redireccionamiento (Redirect)

El servidor envía una respuesta al navegador indicándole que debe realizar una nueva petición a una dirección distinta. Esto genera dos ciclos de petición/respuesta y la URL en la barra de direcciones cambia.

@Override
protected void doPost(HttpServletRequest req, HttpServletResponse resp) 
        throws IOException {
    // Redirigir al usuario fuera del contexto actual o a otra ruta
    resp.sendRedirect(req.getContextPath() + "/panel/inicio");
}

Persistencia de Datos: Cookies y Session

Uso de Cookies

Las cookies son pequeños fragmentos de texto almacenados en el cliente. Son útiles para recordar preferencias o tokens de identidad simples. Tienen un ciclo de vida definido por setMaxAge.

// Creación de una cookie de autenticación
@WebServlet("/auth/token")
public class AuthController extends HttpServlet {
    protected void doGet(HttpServletRequest peticion, HttpServletResponse respuesta) 
            throws IOException {
        Cookie tokenId = new Cookie("access_token", "X992183BA");
        tokenId.setMaxAge(3600 * 24); // Persistencia por 24 horas
        respuesta.addCookie(tokenId);
        respuesta.getWriter().write("Token generado");
    }
}

Gestión de Sesiones (HttpSession)

A diferencia de las cookies, la sesión reside en la memoria del servidor. Se vincula al cliente mediante un identificador único (JSESSIONID) enviado automáticamente en las cabeceras.

// Almacenamiento en sesión
HttpSession sesionUsuario = solicitud.getSession();
sesionUsuario.setAttribute("perfil", "ADMIN_ROLE");

// Recuperación en otro componente
String rol = (String) solicitud.getSession().getAttribute("perfil");

Ámbitos de Objetos en Java Web

Existen tres niveles principales de visibilidad para los datos:

  1. HttpServletRequest: Vida efímera, dura solo una petición.
  2. HttpSession: Vinculada a un usuario específico mientras dure su interacción.
  3. ServletContext: Ámbito global. Los datos aquí almacenados son visibles para todos los usuarios de la aplicación y persisten mientras la apliacción esté desplegada.
// Configuración de parámetros globales en ServletContext
ServletContext contexto = getServletContext();
contexto.setAttribute("version_app", "2.1.0");

Tratamiento de Codificación de Caracteres

Por defecto, los contenedores antiguos pueden usar ISO-8859-1. Para soportar caracteres especiales (como la 'ñ' o tildes), es necesario forzar UTF-8 tanto en la entrada como en la salida.

@Override
protected void doPost(HttpServletRequest peticion, HttpServletResponse respuesta) 
        throws IOException {
    // Configurar codificación antes de leer parámetros o escribir
    peticion.setCharacterEncoding("UTF-8");
    respuesta.setContentType("text/html; charset=UTF-8");
    
    String nombre = peticion.getParameter("nombre_usuario");
    respuesta.getWriter().println("Recibido: " + nombre);
}

Configuración Estándar en web.xml

El descriptor de despliegue web.xml permite definir comportamientos globales sin necesidad de anotaciones:

Páginas de Error Personalizadas

Evita mostrar trazas de error del sistema al usuario final para mejorar la seguridad.

<error-page>
    <error-code>404</error-code>
    <location>/paginas/error/no-encontrado.html</location>
</error-page>
<error-page>
    <error-code>500</error-code>
    <location>/paginas/error/error-interno.jsp</location>
</error-page>

Parámetros de Inicialización Global

Valores constantes accesibles desde cualquier parte del sistema.

<context-param>
    <param-name>correo_soporte</param-name>
    <param-value>admin@empresa.com</param-value>
</context-param>

Empaquetado y Despliegue

Las aplicaciones Java Web se distribuyen comúnmente en formato WAR (Web Application Archive). Este archivo comprimido contiene las clases compiladas, bibliotecas (JAR) y recursos estáticos. Para desplegarlo, se copia el archivo en el directorio /webapps de un servidor como Apache Tomcat, el cual lo descomprimirá y ejecutará automáticamente.

Etiquetas: JavaEE Servlets jsp JakartaEE tomcat

Publicado el 6-13 03:52