Configuration des applications WebSphere Application Server pour démarrer automatiquement les serveurs de conteneur

Les serveurs de conteneur dans un environnement WebSphere Application Server démarrent automatiquement quand un module contenant les fichiers XML eXtreme Scale démarre.

Avant de commencer

WebSphere Application Server et WebSphere eXtreme Scale doivent être installés, et vous devez être capable d'accéder à la console d'administration de WebSphere Application Server.

Pourquoi et quand exécuter cette tâche

Les applications Java Platform, Enterprise Edition ont des règles de chargeur de classe complexes qui compliquent grandement le chargement des classes lors de l'utilisation d'une grille de données partagée dans un serveur Java EE. Une application Java EE correspond généralement à un seul fichier EAR (Enterprise Archive). Le fichier EAR contient un ou plusieurs modules EJB (Enterprise JavaBeans) ou modules WAR (Web archive) déployés.

WebSphere eXtreme Scale surveille le démarrage de chaque module et recherche des fichiers XML eXtreme Scale. Si le service de catalogue détecte qu'un module démarre avec les fichiers XML, le serveur d'applications est enregistré en tant que conteneur de serveur machine virtuelle Java (JVM). En enregistrant les serveurs de conteneur dans le service de catalogue, une même application peut être déployée dans des grilles de données différents, mais utilisée comme une grille de données unique par le service de catalogue. Le service de catalogue n'est pas concerné par les cellules, les grilles, ou les grilles dynamiques. Une grille de données unique peut couvrir plusieurs cellules, si nécessaire.

Procédure

  1. Modularisez le fichier EAR pour disposer de modules incluant les fichiers XML eXtreme Scale dans le dossier META-INF. WebSphere eXtreme Scale détecte la présence des fichiers objectGrid.xml et objectGridDeployment.xml dans le dossier META-INF des modules EJB et WEB lorsqu'ils démarrent. Si un seul fichier objectGrid.xml est détecté, la machine JVM est supposée être un client. Sinon, la machine virtuelle Java est supposée faire office de grille de données définie dans le fichier objectGridDeployment.xml.

    Vous devez utiliser les noms corrects pour ces fichiers XML. Les noms de fichier sont sensibles à la casse. Si les fichiers sont absents, le conteneur ne démarre pas. Vous pouvez vérifier si le fichier systemout.log contient des messages indiquant que des fragments sont placés. Un module EJB ou d'archive Web utilisant eXtreme Scale doit avoir des fichiers XML eXtreme Scale dans son répertoire META-INF.

    Les fichiers XML eXtreme Scale incluent : L'environnement d'exécution détecte ces fichiers, puis contacte le service de catalogue pour l'informer qu'un autre conteneur est disponible pour héberger les fragments pour ce eXtreme Scale.
    Conseil : Si votre application comporte des entités et que vous prévoyez d'utiliser un serveur un conteneur, affectez la valeur minSyncReplicas ) 0 dans le fichier XML du descripteur de déploiement. Sinon, vous risquez de voir l'un des messages suivants dans le fichier SystemOut.log car le positionnement ne pourra se produire tant qu'un autre serveur n'a pas démarré pour satisfaire à la règle minSyncReplica :
    CWPRJ1005E: Erreur lors de la résolution de l'association d'entités. Entité=nom_entité, 
    association=nom_association.
    CWOBJ3013E: Le référentiel EntityMetadata n'est pas disponible.  Le seuil du délai d'attente a été atteint lors de la tentative d'inscription de l'entité : nom_entité.
  2. Déployez et démarrez votre application.

    Le conteneur démarre automatiquement quand le module est démarré. Le service de catalogue commence à placer les serveurs principaux et secondaires de partition (fragments) dès que possible. Ce placement a lieu immédiatement, à moins que vous ne définissiez l'environnement pour le retarder. Pour plus d'informations, voir Contrôle du placement.

Que faire ensuite

Les applications dans la même cellule que les conteneurs, peuvent se connecter à ces grilles de données à l'aide d'une méthode ObjectGridManager.connect(null, null), puis appeler la méthode getObjectGrid(ccc, "object grid name"). La méthode connect ou getObjectGrid peut être bloquée jusqu'à ce que les conteneurs aient placés les fragments, mais ce blocage représente un problème uniquement quand la grille de données démarre.

Chargeurs de classe

Tout plug-in ou objet stocké dans un eXtreme Scale est chargé sur un certain chargeur de classe. Deux modules EJB dans un même fichier d'archive d'entreprise peuvent inclure ces objets. Ces objets sont les identiques, mais ils sont chargés avec différents chargeurs de classe. Si l'application A stocke un objet Personne dans une mappe qui est locale pour le serveur, l'application B reçoit une exception ClassCastException si elle essaie de lire cet objet. Cette exception se produit car l'application B a chargé l'objet Personne sur un chargeur de classe différent.

Une manière de résoudre ce problème consiste à faire en sorte qu'un module racine contienne les plug-in et les objets nécessaires qui sont stockés dans le eXtreme Scale. Chaque module utilisant eXtreme Scale doit référencer ce module pour ses classes. Une autre solution consiste à placer ces objets partagés dans un fichier JAR d'utilitaire qui se trouve dans un chargeur de classe commun partagé par les modules et les applications. Les objets peuvent également être placés dans des classes WebSphere ou le répertoire lib/ext, mais cet placement complique le déploiement.

Les modules EJB dans un fichier d'archive d'entreprise partagent généralement le même ClassLoader et ne sont pas affectés par ce problème. Chaque module de fichier d'archive Web possède son propre ClassLoader et est affecté par ce problème.

Connexion à un client de grille de données uniquement

Si la propriété catalog.services.cluster est définie dans les propriétés personnalisées d'une cellule, d'un noeud ou d'un serveur, un module dans le fichier EAR peut appeler la méthode ObjectGridManager.connect (ServerFactory.getServerProperties().getCatalogServiceBootstrap(), null, null) pour obtenir un ClientClusterContext. Le module peut également appeler la méthode ObjectGridManager.getObjectGrid(ccc, "grid name") pour obtenir une référence à la grille de données. Si des objets d'application sont stockés dans des mappes, vérifiez que ces objets sont présents dans un chargeur de classe commun.

Les clients Java ou les clients en dehors de la cellule peuvent se connecter au port IIOP d'amorçage du service de catalogue. Dans WebSphere Application Server, le gestionnaire de déploiement héberge le service de catalogue par défaut. Le client peut alors obtenir un ClientClusterContext et la grille de données nommée.

Gestionnaire d'entités

Avec le gestionnaire d'entités, les blocs de données sont stockés dans les mappes et non pas les objets d'application, ce qui réduit les problèmes de chargeur de classe. Les plug-in, en revanche, peuvent présenter un problème. Notez également qu'un fichier XML de descripteur ObjectGrid de remplacement client est toujours nécessaire lorsqu'une grille de données a des entités définies : ObjectGridManager.connect("host:port[,host:port], null, objectGridOverride) or ObjectGridManager.connect(null, objectGridOverride).