Configuration du gestionnaire de sessions HTTP pour divers serveurs d'applications

WebSphere eXtreme Scale est regroupé avec une implémentation de gestion de session qui remplace le gestionnaire de sessions par défaut pour un conteneur Web. Cette implémentation fournit l réplication de session, la haute disponibilité, améliore l'évolutivité et des options de configuration. Vous pouvez activer le gestionnaire de réplication de session WebSphere eXtreme Scale et le démarrage du conteneur intégré ObjectGrid générique.

Pourquoi et quand exécuter cette tâche

Vous pouvez utiliser le gestionnaire de sessions HTTP avec d'autres serveurs d'applications qui n'exécutent pas WebSphere Application Server, WebSphere Application Server Community Edition, par exemple. Pour configurer d'autres serveurs d'applications pour qu'ils utilisent la grille de données, vous devez raccorder votre application et incorporer des fichiers WebSphere eXtreme Scale Java archive (JAR) dans votre application.

Procédure

  1. Raccordez votre application de sorte qu'elle puisse utiliser le gestionnaire de sessions. Pour utiliser le gestionnaire de sessions, vous devez ajouter les déclarations de filtre appropriées aux descripteurs de déploiement Web de l'application. En outre, les paramètres de configuration du gestionnaire de sessions sont transmis au gestionnaire de sessions sous la forme de paramètres d'initialisation du contexte de servlet dans les descripteurs de déploiement. Vous disposez de trois manières de présenter ces informations dans votre application :
    • Script addObjectGridFilter :

      Utilisez un script de ligne de commande fourni avec eXtreme Scale pour raccorder une application avec des déclarations de filtre et une configuration sous forme de paramètres d'initialisation de contexte de servlet. Le script rép_base_wxs/session/bin/addObjectGridFilter.sh|bat accepte deux paramètres : le chemin absolu d'accès au fichier EAR (enterprise archive) ou au fichier WAR (web archive) à raccorder et le chemin absolu au fichier des propriétés splicer qui contient diverses propriétés de configuration. La syntaxe de ce script est la suivante :

      [Windows]
      addObjectGridFilter.bat <ear_or_war_file> <splicer_properties_file>
      [Unix]
      addObjectGridFilter.sh <ear_or_war_file> <splicer_properties_file>

      [Unix] Exemple d'utilisation de eXtreme Scale installé dans un répertoire autonome sur UNIX :

      1. cd rép_base_wxs/session/bin
      2. addObjectGridFilter.sh /tmp/mySessionTest.ear rép_base_wxs/session/samples/splicer.properties
      Le filtre de servlet qui est joint conserve les valeurs de configuration par défaut. Vous pouvez remplacer ces valeurs par défaut par des options de configuration que vous spécifiez dans le fichier de propriétés, dans le second argument. Pour une liste des paramètres que vous pouvez utiliser, voir Paramètres d'initialisation du contexte de servlet.

      Vous pouvez modifier et utiliser l'exemple de fichier splicer.properties fourni avec l'installation d'eXtreme Scale. Vous pouvez également utiliser le script addObjectGridServlets, qui insère le gestionnaire de sessions en étendant chaque servlet. Mais le script recommandé est le script addObjectGridFilter.

    • Script de génération Ant :

      WebSphere eXtreme Scale est fourni avec un fichier build.xml qui peut être utilisé par Apache Ant, qui est inclus dans le dossier racine_was/bin d'une installation WebSphere Application Server. Vous pouvez modifier le fichier build.xml pour changer les propriétés de configuration du gestionnaire de sessions. Les propriétés de configuration sont identiques aux noms de propriété dans le fichier splicer.properties. Une fois que le fichier build.xml a été modifié, appelez le processus Ant en exécutant ant.sh, ws_ant.sh (UNIX) ou ant.bat, ws_ant.bat (Windows).

    • Mise à jour manuelle du descripteur Web :

      Editez le fichier web.xml qui est packagé avec l'application Web pour incorporer la déclaration de filtre, son mappage de servlets et les paramètres d'initialisation du contexte de servlet. N'utilisez pas cette méthode car elle est source d'erreurs possibles.

    Pour une liste des paramètres que vous pouvez utiliser, voir Paramètres d'initialisation du contexte de servlet.
  2. Incorporez dans votre application les fichiers JAR du gestionnaire de réplication de sessions d'WebSphere eXtreme Scale. Vous pouvez incorporer les fichiers dans le répertoire WEB-INF/lib des modules d'application ou dans le chemin d'accès aux classes du serveur d'applications. Les fichiers JAR requis varient selon le type de conteneurs utilisés :
    • Serveurs de conteneur distants : ogclient.jar et sessionobjectgrid.jar
    • Serveurs de conteneur intégrés : objectgrid.jar et sessionobjectgrid.jar
  3. Facultatif : Si vous utilisez des serveurs de conteneur distant, démarrez les serveurs de conteneur. Pour plus de détails, reportez-vous à la rubrique Démarrage des serveurs de conteneur.
  4. Déployez l'application. Déployez l' application à l'aide de votre procédure normale pour un serveur ou un cluster. Une fois que vous avez déployé l'application, vous pouvez la démarrer.
  5. Accédez à l'application. Vous pouvez maintenant accéder à l'application, qui interagit avec le gestionnaire de sessions et WebSphere eXtreme Scale.

Que faire ensuite

Vous pouvez modifier la majorité des attributs de configuration du gestionnaire de sessions lorsque vous instrumentez votre application pour utiliser le gestionnaire de sessions. Ces attributs sont des variantes du type de réplication (synchrone ou asynchrone), la taille de la table des sessions en mémoire, etc. En dehors des attributs modifiables lors de l'instrumentation de l'application, les seuls autres attributs de configuration que vous pouvez modifier après le déploiement de l'application sont ceux liés à la topologie des clusters de serveurs WebSphere eXtreme Scale et à la manière dont leurs clients (gestionnaires de sessions) s'y connectent.
Comportement dans le scénario distant : si l'ensemble de la grille de données qui héberge les données de session d'application est inaccessible depuis le client du conteneur Web, le client utilise à la place le conteneur Web de base du serveur d'applications pour gérer les sessions. La grille de données peut être inaccessible dans les scénarios suivants :
  • Problème de réseau entre le conteneur Web et les serveurs de conteneur distants
  • Arrêt des processus serveur de conteneur distant
Le nombre de références de session conservées en mémoire, spécifié par le paramètre sessionTableSize, est toujours maintenu lorsque les sessions sont stockées dans le conteneur Web de base. Les sessions les moins utilisées sont invalidées à partir du cache de session du conteneur Web lorsque la valeur sessionTableSize est dépassée. Si la grille de données distante devient disponible, les sessions ayant été invalidées à partir du cache du conteneur Web peuvent extraire les données de la grille de données distante et charger les données dans une nouvelle session. Si l'ensemble de la grille de données distante n'est pas disponible et que la session est invalidée dans le cache de session, les données de session utilisateur sont perdues. Compte tenu de ce problème, n'arrêtez pas l'ensemble de la grille de données distante de production lorsque le système est chargé.