Exemple BeenThere - Notes techniques


Recherche du code source
Notes relatives au codage


Recherche du code source

Le code source de l'application BeenThere se trouve dans le répertoire racine_profil/samples/src/BeenThere, où <racine_profil> est le chemin d'accès complet au profil du gestionnaire de déploiement.

Clients z/OS : L'arborescence du code source des exemples n'est pas fournie sur la plateforme z/OS car les applications ne sont pas générées sur cette plateforme.



Notes relatives au codage

Présentation

L'application BeenThere illustre les capacités de gestion de la charge de travail (WLM) d'IBM WebSphere Application Server Network Deployment Edition. Elle contient le servlet BeenThere et le bean enterprise session sans état BeenThere. Le servlet BeenThere présente le serveur d'applications faisant partie d'un cluster et vers lequel une demande HTTP est acheminée. Le bean enterprise BeenThere présente le serveur d'applications faisant partie d'un cluster et vers lequel une requête de bean enterprise a été acheminée. Le bean enterprise BeenThere est appelé par le servlet BeenThere.

Le servlet BeenThere affiche les informations ci-dessous.


De plus, le servlet BeenThere peut exécuter les actions ci-dessous.


Environnement

L'environnement exemple utilisé pour présenter la gestion de la charge de travail du conteneur Web et du conteneur d'EJB est décrit dans l'illustration suivante :



Figure 1   Environnement exemple


Les machines qui composent cet environnement sont présentées ci-dessous.



La configuration contient deux clusters de serveurs, MyWebCluster et MyEJBCluster. Un cluster de serveurs se compose d'un groupe de serveurs d'applications. En cas de défaillance de l'un des serveurs membres du cluster, les requêtes sont dirigées vers d'autres membres du cluster. Chacun des clusters exemple sont constitués de deux membres de cluster. Le cluster MyWebCluster a pour membres WebServer1 et WebServer2, et le cluster MyEJBCluster, EJBServer1 et EJBServer2.

Cet environnement configuré est un exemple utilisé uniquement pour illustrer l'exécution de l'application BeenThere. Dans un environnement de production, il convient de planifier avec soin la prévision de charge afin de déterminer combien de membres de serveur d'applications doivent être créés sur un nombre de machines donné, en fonction du volume de requêtes client attendu.

Gestion de la charge de travail

WebSphere Application Server Network Deployment Edition fournit une fonction de gestion de la charge de travail (WLM) pour les demandes HTTP et les requêtes EJB.

Gestion de la charge de travail de conteneur Web

La gestion de la charge de travail pour les demandes HTTP est assurée par le plug-in du serveur Web.

Examinez la configuration présentée Figure 1. La machine web exécute une instance IBM HTTP Server qui achemine les demandes HTTP à chacun des serveurs d'applications WebServer1 et WebServer2 qui sont membres du cluster MyWebCluster et exécutent le servlet BeenThere. Ces serveurs d'applications sont configurés sur les machines app1 et app2, respectivement. De plus, le plug-in IBM HTTP Server est configuré de telle sorte que la pondération WLM du serveur WebServer1 a la valeur 2 et que celle du serveur WebServer2 a la valeur 3. Ces valeurs de pondération peuvent être considérées comme des compteurs dont la valeur de départ a été configurée et diminue d'une unité à chaque fois qu'une requête est traitée. Les requêtes sont acheminées selon un processus de permutation circulaire à n'importe quel serveur d'applications ayant une valeur de pondération supérieure à 0. Un serveur d'applications pour lequel cette valeur est égale à 0 est ignoré. Une fois que tous les compteurs de pondération ont été décrémentés et atteignent la valeur 0, la valeur de départ configurée pour les compteurs est rétablie pour tous les serveurs d'applications et le processus d'acheminement recommence.

Gestion de la charge de travail de conteneur d'EJB

La gestion de la charge de travail pour les requêtes EJB est assurée en interne par WLM Controller dans WebSphere Application Server.

Examinez la configuration présentée Figure 1. Un cluster, MyEJBCluster, est défini et comprend les membres de serveur d'applications EJBServer1 et EJBServer2 qui sont responsables de l'exécution du bean enterprise session sans état BeenThere. Le servlet BeenThere appelle le bean enterprise pour obtenir des informations d'exécution sur le serveur d'applications sur lequel le bean enterprise est exécuté. De plus, ces serveurs sont configurés avec les valeurs de pondération 1 et 3, respectivement.

Sur la plateforme z/OS, les valeurs de pondération sont utilisées pour équilibrer les demandes HTTP, mais ne sont pas utilisées pour équilibre les requêtes IIOP (Internet Inter-ORB Protocol).

Interfaces API d'administration WebSphere

L'application BeenThere utilise les interfaces API d'administration dans WebSphere Application Server. Par le biais de ces interfaces, les applications peuvent accéder aux informations de configuration d'environnement et d'exécution.


AdminService

Fournit les interfaces côté serveur permettant d'obtenir les informations d'attribut de serveur d'applications et d'exécuter des fonctions de gestion de MBean JMX standard.

AdminClient

Fournit les interfaces côté client permettant d'accéder à un objet AdminService éloigné. La classe AdminClient fournit un proxy à l'objet AdminService éloigné par l'intermédiaire de l'un des connecteurs JMX (Java Management Extensions) pris en charge.

ConfigService

Fournit les interfaces permettant d'interroger ou de modifier les données de configuration, en local ou à distance, et gère l'emplacement et le contenu des documents de configuration du serveur d'applications.

Pour illustrer la puissance et la souplesse dont disposent les applications lors de l'utilisation des interfaces d'administration WebSphere Application Server, l'application BeenThere utilise toutes ces interfaces comme indiqué ci-dessous.


AdminService

L'interface AdminService est utilisée à la fois par le servlet et le bean enterprise BeenThere pour obtenir le nom du noeud, le nom du serveur d'applications et l'ID de processus du serveur d'applications sur lequel ils sont exécutés. Le segment de code suivant indique comment obtenir les informations d'attribut du serveur :


// Obtention de WebSphere AdminService.
AdminService adminService = AdminServiceFactory.getAdminService();

// Obtention de l'instance WebSphere Admin Local Server MBean.
ObjectName localServer = adminService.getLocalServer();

// Obtention du nom du noeud.
nodeName = (String) adminService.getAttribute(localServer, "nomNoeud");

// Obtention du nom du serveur d'applications.
serverName = (String) adminService.getAttribute(localServer, "nom");

// Obtention de l'ID de processus du serveur d'applications.
serverPid = (String) adminService.getAttribute(localServer, "pid");

AdminClient

L'interface AdminClient permet de se connecter au processus du gestionnaire de déploiement afin d'extraire les valeurs de pondération de tous les membres du cluster de serveurs d'applications qui exécutent le bean enterprise BeenThere. Le segment de code suivant illustre comment obtenir une instance de l'interface AdminClient :


// Obtention de WebSphere AdminService.
AdminService adminService = AdminServiceFactory.getAdminService();

// Obtention de l'instance AdminClient pour le gestionnaire de déploiement.
adminClient = adminService.getDeploymentManagerAdminClient();

ConfigService

Cette interface permet de lire le document de configuration cell.xml de WebSphere Application Server pour déterminer si l'application BeenThere est exécutée dans un environnement WebSphere Application Server Base Edition ou Network Deployment Edition. Le segment de code suivant illustre comment déterminer l'environnement dans lequel une application est exécutée :


// Création d'une session de gestion WebSphere.
Session session = new Session();

// Obtention de l'instance WebSphere ConfigService
// pour le serveur d'applications qui exécute ce servlet.
ConfigService configService = ConfigServiceFactory.getConfigService();
if (configService != null)
{
  // Lecture du document cell.xml.
  ObjectName cellObj = ConfigServiceHelper.createObjectName(null, "Cellule");
  ObjectName[] cellObjs = configService.queryConfigObjects(session, null, cellObj, null);

  if (cellObjs.length != 0)
  {
    cellObj = cellObjs[0];
    String cellName = (String) configService.getAttribute(session, cellObj, "nom");
    String cellType = (String) configService.getAttribute(session, cellObj, "typeCellule");
    if (cellType.equals("DISTRIBUTED"))
    {
      websphereND = true;
    }
  }

  // Libération de la session.
  configService.discard(session);

Si un environnement Network Deployment est détecté, l'option Display bean cluster member weights est activée et affichée car elle est valide uniquement dans ce type d'environnement. Dans le cas contraire, cette option ne peut pas être sélectionnée.