Gerenciando de Sessões HTTP

O gerenciador de replicação de sessão que é fornecido com o WebSphere eXtreme Scale pode trabalhar com o gerenciador de sessões padrão no servidor de aplicativos. Os dados da sessão são replicados de um processo para um outro processo para suportar alta disponibilidade de dados da sessão do usuário.

Características

O gerenciador de sessões foi projetado para que ele possa ser executado em qualquer contêiner do Java Platform, Enterprise Edition Versão 5 ou posterior. Como o gerenciador de sessões não tem nenhuma dependência nas APIs do WebSphere, ele pode suportar várias versões do WebSphere Application Server e também ambientes do servidor de aplicativos do fornecedor.

O gerenciador de sessões HTTP fornece recursos de replicação de sessão para um aplicativo associado. O gerenciador de replicação de sessão funciona com o gerenciador de sessões para o contêiner da web. Juntos, o gerenciador de sessões e o contêiner da web criam sessões HTTP e gerenciam os ciclos de vida de sessões HTTP que estão associadas ao aplicativo. Estas atividades de gerenciamento de ciclo de vida incluem: a invalidação de sessões baseada em um tempo limite ou um servlet explícito ou chamada JavaServer Pages (JSP) e a chamada de listeners de sessão que estão associados com a sessão ou ao aplicativo da web. O gerenciador de sessões persiste suas sessões em uma grade de dados particionados, totalmente replicada e em cluster. O uso do gerenciador de sessões do WebSphere eXtreme Scale permite que o gerenciador de sessões forneça suporte de failover da sessão HTTP quando os servidores de aplicativos são encerrados ou terminam de forma inesperada. O gerenciador de sessões também pode trabalhar em ambientes que não suportam afinidade, quando a afinidade não é forçada por uma camada do balanceador de carga que pulveriza pedidos para a camada do servidor de aplicativos.

Cenários de Uso

O gerenciador de sessões pode ser usado nos seguintes cenários:

Como o Gerenciador de Sessões Funciona

O gerenciador de replicação de sessão usa um listener de sessão para atender às mudanças de dados da sessão. O gerenciador de replicação de sessão persiste os dados da sessão para uma instância do ObjectGrid local ou remotamente. É possível incluir o listener de sessão e o filtro de servlet em cada módulo da web em seu aplicativo com o conjunto de ferramentas que é fornecido com o WebSphere eXtreme Scale. Você também pode incluir manualmente esses listeners e filtros no descritor de implementação da web de seu aplicativo.

Este gerenciador de replicação de sessão trabalha com cada gerenciador de sessões de contêiner da web do fornecedor para replicar dados da sessão entre Java virtual machines. Quando o servidor original para de funcionar, os usuários podem recuperar dados da sessão de outros servidores.

Figura 1. Topologia do Gerenciamento de Sessões HTTP com uma Configuração de Contêiner Remoto
Um navegador do cliente envia uma solicitação a um sprayer de solicitações HTTP, que acessa a camada do servidor de aplicativos. Atrás da camada do servidor de aplicativos, a camada do ObjectGrid hospeda os dados da sessão HTTP persistente.

Topologias de Implementação

O gerenciador de sessões pode ser configurado utilizando dois diferentes cenários de implementação dinâmicos:
Servidores de contêiner do eXtreme Scale conectados em rede, integrados
Neste cenário, os servidores eXtreme Scale são posicionados nos mesmos processos que os servlets. O gerenciador de sessões pode ser comunicar diretamente com a instância do local, evitando atrasos de rede caros. Este cenário é preferível ao executar com afinidade e o desempenho for crítico.
Servidores de contêiner do eXtreme Scale conectados em rede, remotos
Neste cenário, os servidores do eXtreme Scale são executados em processos externos a partir do processo no qual os servlets são executados. O gerenciador de sessões se comunica com uma grade do servidor eXtreme Scale remoto. Este cenário é preferível quando a camada do contêiner da web não tem a memória para armazenar os dados da sessão. Os dados da sessão são transferidos para uma camada separada, o que resulta em uso de memória inferior na camada do contêiner da web. A latência mais alta ocorre porque os dados estão em um local remoto.

Inicialização do Contêiner Integrado Genérico

O eXtreme Scale inicia automaticamente um contêiner do ObjectGrid integrado dentro de qualquer processo do servidor de aplicativos quando o contêiner da web inicializa o listener de sessão ou o filtro de servlet, se a propriedade do objectGridType é configurada como EMBEDDED. Veja detalhes em Parâmetros de inicialização do contexto do servlet.

Não é necessário empacotar um arquivo ObjectGrid.xml e um arquivo objectGridDeployment.xml em seu arquivo WAR ou EAR do aplicativo da web. Os arquivos ObjectGrid.xml e objectGridDeployment.xml padrão são empacotados no arquivo JAR do produto. Mapas dinâmicos são criados para vários contextos de aplicativos da web por padrão. Mapas estáticos do eXtreme Scale continuam a ser suportados.

Esta abordagem para iniciar contêineres do ObjectGrid integrados é aplicada a qualquer tipo de servidor de aplicativos. As abordagens envolvendo um componente do WebSphere Application Server ou GBean do WebSphere Application Server Community Edition são reprovadas.