Gestión de sesiones HTTP

El gestor de réplica de sesiones que se envía con WebSphere eXtreme Scale puede funcionar con el gestor de sesiones predeterminado en el servidor de aplicaciones. Los datos de sesión se replican de un proceso a otro proceso para soportar la alta disponibilidad de datos de sesión de usuario.

Características

El gestor de sesiones se ha diseñado para poderse ejecutar en cualquier contenedor de Java Platform, Enterprise Edition Versión 5 o posterior. Dado que el gestor de sesiones no tiene dependencias en las API de WebSphere, puede admitir varias versiones de WebSphere Application Server así como de entornos de servidor de aplicaciones de proveedores.

El gestor de sesiones HTTP proporciona funciones de réplica de sesiones para una aplicación asociada. El gestor de réplica de sesión funciona con el gestor de sesiones para el contenedor web. Juntos, el gestor de sesiones y el contenedor web crean sesiones HTTP y gestionan los ciclos de vida de las sesiones HTTP que están asociadas con la aplicación. Estas actividades de gestión de ciclo de vida incluyen: la invalidación de sesiones basadas en un tiempo de espera o una llamada a un servlet explícito o JavaServer Pages (JSP) y la invocación de escuchas de sesión asociados a la sesión o a la aplicación web. El gestor de sesiones continúa las sesiones en una cuadrícula de datos totalmente replicada, en clúster y particionada. El uso del gestor de sesiones de WebSphere eXtreme Scale permite al gestor de sesiones proporcionar soporte de migración tras error de sesiones HTTP cuando los servidores de aplicaciones concluyen o finalizan inesperadamente. El gestor de sesiones también puede funcionar en entornos que no admitan afinidad, si la afinidad no la aplica un nivel de equilibrador de carga que distribuya solicitudes al nivel de servidor de aplicaciones.

Escenarios de uso

El gestor de sesiones se puede utilizar en los siguientes escenarios:

Cómo funciona el gestor de sesiones

El gestor de réplica de sesiones utiliza un escucha de sesión para escuchar los cambios de los datos de sesión. El gestor de réplica de sesiones continúa los datos de sesión en una instancia de ObjectGrid de forma local o remota. Puede añadir el escucha de sesión y el filtro de servlet en todos los módulos web de la aplicación con las herramientas que se proporcionan con WebSphere eXtreme Scale. También puede añadir estos escuchas y filtros de forma manual al descriptor de despliegue web de la aplicación.

Este gestor de réplica de sesión funciona con cada gestor de sesión de contenedor web de proveedor para replicar los datos de sesión en las máquinas virtuales Java. Cuando el servidor original queda inactivo, los usuarios pueden recuperar datos de sesión de otros servidores.

Figura 1. Topología de gestión de sesiones HTTP con una configuración de contenedor remoto
Un navegador de cliente envía una solicitud a un distribuidos de solicitudes HTTP, que va a la capa del servidor de aplicaciones. Detrás de la capa del servidor de aplicaciones, la capa de ObjectGrid aloja los datos de sesión HTTP persistentes.

Topologías de despliegue

El gestor de sesiones puede configurarse mediante el uso de dos escenarios de despliegue dinámico diferentes:
Servidores de contenedor de eXtreme Scale incorporados conectados a red
En este escenario, los servidores eXtreme Scale se colocan en los mismos procesos que los servlets. El gestor de sesiones se puede comunicar directamente con la instancia de ObjectGrid local, lo que evita costosos retrasos de red. Este escenario es preferible al ejecutar con afinidad y el rendimiento es crítico.
Servidores de contenedor de eXtreme Scale remotos conectados a red
En este escenario, los servidores eXtreme Scale ejecutan en procesos externos desde el proceso en el que se ejecutan los servlets. El gestor de sesiones se comunica con una cuadrícula de servidor de eXtreme Scale remoto. Este caso de ejemplo es preferible cuando el nivel del contenedor web no tiene la memoria para almacenar los datos de sesión. Los datos de sesión se descargan a un nivel independiente, lo que produce un uso de memoria más bajo en el nivel de contenedor web. Se produce una latencia más alta porque los datos están en una ubicación remota.

Inicio del contenedor incorporado genérico

eXtreme Scale inicia automáticamente un contenedor de ObjectGrid incorporado dentro de cualquier proceso de servidor de aplicaciones cuando el contenedor web inicializa el escucha de sesión o el filtro de servlet, si la propiedad objectGridType se establece en EMBEDDED. Consulte Parámetros de inicialización del contexto del servlet si desea más detalles.

No es necesario empaquetar un archivo ObjectGrid.xml y un archivo objectGridDeployment.xml en el archivo WAR o EAR de aplicación web. Los archivos ObjectGrid.xml y objectGridDeployment.xml predeterminados están empaquetados en el archivo JAR de producto. De forma predeterminada, se crean correlaciones dinámicas para distintos contextos de aplicaciones web. Se siguen admitiendo las correlaciones estáticas de eXtreme Scale.

Este enfoque para iniciar contenedores ObjectGrid incorporados se aplica a cualquier tipo de servidor de aplicaciones. Los enfoques relacionados con un componente WebSphere Application Server o WebSphere Application Server Community Edition GBean están en desuso.