Gestion des sessions HTTP

Le gestionnaire de réplication de session fourni avec WebSphere eXtreme Scale peut fonctionner avec le gestionnaire de session par défaut dans le serveur d'applications. Les données de session sont répliquées d'un processus vers l'autre pour prendre en charge la haute disponibilité des données de session utilisateur.

Caractéristiques

Le gestionnaire de session est conçu pour fonctionner dans n'importe quelle version Java Platform, Enterprise Edition et les versions suivantes. Le gestionnaire de sessions ne dépendant en aucune façon des API WebSphere, il peut prendre en charge les diverses versions de WebSphere Application Server ainsi que les environnement de serveurs d'applications du commerce.

Le gestionnaire de sessions HTTP offre des fonctions de réplication de sessions pour une application associée. Le gestionnaire de réplication de session fonctionne avec le gestionnaire de session du conteneur Web. Conjointement, le gestionnaire de session et le conteneur Web créent des sessions HTTP et gèrent les cycles de vie des sessions HTTP associés à l'application. La gestion du cycle de vie comprend : l'invalidation des sessions en fonction d'un délai d'attente, d'un servlet explicite ou d'un appel à des JSP (JavaServer Pages). Autre activité de gestion du cycle de vie : l'invocation de programmes d'écoute des sessions associées à la session ou à l'application Web. Le gestionnaire de sessions conserve ses sessions dans une grille de données complètement partitionnée, clusterisée et répliquée. L'utilisation du gestionnaire de sessions WebSphere eXtreme Scale permet aux gestionnaires de session de fournir le support de basculement de session HTTP lorsque les serveurs d'applications sont arrêtés ou s'arrêtent inopinément. Le gestionnaire de sessions peut également être exécuté dans des environnements qui ne prennent pas en charge l'affinité lorsque cette dernière n'est pas appliquée par un groupe de serveurs d'équilibrage de charge qui diffusent les demandes au groupe de serveurs d'applications.

Scénarios d'utilisation

Le gestionnaire de sessions est particulièrement utile dans les cas suivants :

Fonctionnement du gestionnaire de sessions

Le gestionnaire de réplication de session utilise un programme d'écoute de sessions pour écouter les modifications des données de session. Le gestionnaire de réplication de session conserve les données de session dans une instance ObjectGrid localement ou à distance. Des outils livrés avec WebSphere eXtreme Scale vous permettent d'ajouter l'écouteur de session et le filtre de servlet à chacun des modules Web de votre application. Vous pouvez également ajouter manuellement ces écouteurs et ces filtres au descripteur de déploiement Web de votre application.

Ce gestionnaire de réplication de session fonctionne avec chaque gestionnaire de session de conteneur Web de fournisseur pour répliquer les données de session sur les machines virtuelles Java. Lorsque le serveur d'origine expire, les utilisateurs peuvent extraire des données de session d'autres serveurs.

Figure 1. Topologie de gestion de session HTTP avec configuration de conteneur à distance
Un navigateur client envoie une demande à un diffuseur de demandes HTTP qui est transmise au groupe des serveurs d'applications. Derrière le groupe des serveurs d'applications, le groupe des grilles d'objets héberge les données de session HTTP persistantes.

Topologies de déploiement

Le gestionnaire de sessions peut être configuré à l'aide de deux scénarios de déploiement dynamiques :
Serveurs de conteneur eXtreme Scale connectés au réseau intégrés
Dans ce scénario, les serveurs eXtreme Scale sont regroupés dans les mêmes processus que les servlets. Le gestionnaire de sessions peut communiquer directement avec l'instance ObjectGrid locale, pour éviter les retards coûteux du réseau. Ce scénario est préférable dans une exécution avec affinité où les performances sont vitales.
Serveurs de conteneur eXtreme Scale connectés au réseau distants
Dans ce scénario, les serveurs eXtreme Scale s'exécutent dans des processus externes au processus dans lequel les servlets sont exécutés. Le gestionnaire de sessions communique avec une grille du serveur eXtreme Scale distant. Ce scénario est préférable lorsque le groupe de serveurs de conteneur Web ne dispose pas de la mémoire pour stocker les données de session. Les données de session sont déchargées vers un groupe distinct, ce qui réduit la consommation de la mémoire sur le groupe de serveurs de conteneur Web. La latence augmente, car les données se trouvent dans un emplacement distant.

Démarrage du conteneur intégré générique

eXtreme Scale démarre automatiquement un conteneur ObjectGrid intégré dans un processus serveur d'applications lorsque le conteneur Web initialise le programme d'écoute de session ou le filtre de servlet si la propriété objectGridType a la valeur EMBEDDED. Pour plus de détails, reportez-vous à la rubrique Paramètres d'initialisation du contexte de servlet.

Vous n'êtes pas obligé de regrouper un fichier ObjectGrid.xml et un fichier objectGridDeployment.xml dans votre fichier WAR ou EAR d'application. Les fichiers par défaut ObjectGrid.xml et objectGridDeployment.xml sont regroupés dans le fichier JAR du produit. Des mappes dynamiques sont créées par défaut pour les différents contextes de l'application Web. Les mappes eXtreme Scale statiques n'en sont pas moins toujours prises en charge.

Ce démarrage des conteneurs ObjectGrid intégrés s'applique à tous les types de serveurs d'applications. L'utilisation de composant WebSphere Application Server ou d'un GBean WebSphere Application Server Community Edition GBean est abandonnée.