Configuración de aplicaciones WebSphere Application Server para el inicio automático de servidores de contenedor

Los servidores de contenedor de un entorno de WebSphere Application Server se inician automáticamente cuando se inicia un módulo que tiene incluidos los archivos XML de eXtreme Scale.

Antes de empezar

WebSphere Application Server y WebSphere eXtreme Scale deben estar instalados y debe poder acceder a la consola administrativa de WebSphere Application Server.

Acerca de esta tarea

Las aplicaciones Java Platform, Enterprise Edition tienen reglas de cargador de clases complejas que complican considerablemente la carga de clases cuando se utiliza una cuadrícula de datos compartida en un servidor Java EE. Una aplicación Java EE normalmente es un único archivo EAR (Enterprise Archive). El archivo EAR contiene uno o más módulos EJB Enterprise JavaBeans (EJB) o de archivado web (WAR).

WebSphere eXtreme Scale observa con atención que cada módulo se inicie y busca los archivos XML de eXtreme Scale. Si el servicio de catálogo detecta que un módulo se inicia con los archivos XML, el servidor de aplicaciones se registra como una Máquina virtual Java (JVM ) de servidor de contenedor. Registrando los servidores de contenedor con el servicio de catálogo, la misma aplicación se puede desplegar en distintas cuadrículas de datos, pero es utilizada como una única cuadrícula de datos por el servicio de catálogo. El servicio de catálogo no se ocupa de células, cuadrículas o cuadrículas dinámicas. Una única cuadrícula de datos puede distribuirse en varias células, si es necesario.

Procedimiento

  1. Empaquete el archivo EAR para que tenga varios módulos que incluyan los archivos XML de eXtreme Scale en la carpeta META-INF. WebSphere eXtreme Scale detecta la presencia de los archivos objectGrid.xml y objectGridDeployment.xml en la carpeta META-INF de los módulos EJB y WEB cuando se inician. Si solo se encuentra un archivo objectGrid.xml, se asume que la JVM es cliente. De lo contrario, se asume que esta JVM actúa como un contenedor para la cuadrícula de datos definida en el archivo objectGridDeployment.xml.

    Debe utilizar los nombres correctos para estos archivos XML. Los nombres de archivo son sensibles a las mayúsculas y minúsculas. Si los archivos no existen, el contenedor no se inicia. Puede comprobar el archivo systemout.log para obtener mensajes que indican que se han colocado los fragmentos. Un módulo EJB o módulo WAR que utiliza eXtreme Scale debe tener archivos XML de eXtreme Scale en su directorio META-INF.

    Los archivos XML de eXtreme Scale incluyen: El tiempo de ejecución detecta estos archivos y, a continuación, contacta con el servicio de catálogo para informarle de que otro contenedor está disponible para alojar fragmentos para ese eXtreme Scale.
    Consejo: Si la aplicación tiene entidades y está planificando utilizar un servidor de contenedor, establezca el valor minSyncReplicas en 0 en el archivo XML de descriptor de despliegue. De lo contrario, podría aparecer uno de estos mensajes en el archivo SystemOut.log debido a que no se puede producir la colocación hasta que otro servidor empieza a cumplir la política minSyncReplica:
    CWPRJ1005E: Se ha producido un error al resolver la asociación de entidad.
    Entity=nombre_entidad, association=nombre_asociación.
    CWOBJ3013E: El depósito de EntityMetadata no está disponible. Se ha alcanzado
    el umbral del tiempo de espera excedido al intentar registrar la entidad:
    nombre_entidad.
  2. Despliegue e inicie la aplicación,

    El contenedor se inicia automáticamente cuando se inicia el módulo. El servicio de catálogo empieza a colocar primarios y réplicas (fragmentos) de particiones lo antes posible. Esta colocación se produce inmediatamente a menos que se configure el entorno para retardar la colocación. Para obtener más información, consulte Control de la colocación.

Qué hacer a continuación

Las aplicaciones de la misma célula que los contenedores pueden conectarse a estas cuadrículas de datos utilizando un método ObjectGridManager.connect(null, null) y a continuación llamar al método getObjectGrid(ccc, "nombre de cuadrícula de objetos"). Los métodos connect o getObjectGrid podrían bloquearse hasta que los contenedores hayan colocado los fragmentos, pero este bloqueo es solo un problema cuando se inicia la cuadrícula de datos.

Cargadores de clases

Todos los plug-ins u objetos almacenados en un eXtreme Scale se cargan en un cargador de clases determinado. Dos módulos EJB en el mismo archivo EAR pueden incluir estos objetos. Los objetos son los mismos pero se cargan con distintos cargadores de clases. Si la aplicación A almacena un objeto Person en una correlación que es local al servidor, la aplicación B recibe una ClassCastException si intenta leer ese objeto. Esta excepción se produce porque la aplicación B ha cargado el objeto Person en un cargador de clases distinto.

Un método para resolver este problema es hacer que un módulo root contenga los plug-ins y objetos necesarios que están almacenados en el eXtreme Scale. Cada módulo que utiliza eXtreme Scale debe hacer referencia a dicho módulo para sus clases. Otra resolución es colocar estos objetos compartidos en un archivo JAR de programa de utilidad que se encuentra en un cargador de clases común compartido por módulos y aplicaciones. Los objetos también se pueden colocar en las clases WebSphere o en el directorio lib/ext. Sin embargo, esta colocación complica el despliegue.

Los módulos EJB en un archivo EAR normalmente comparten el mismo ClassLoader y no se ven afectados por este problema. Cada módulo WAR tiene su propio ClassLoader y se ve afectado por este problema.

Conexión a una cuadrícula de datos de solo cliente

Si la propiedad catalog.services.cluster se define en las propiedades de célula, nodo o servidor, cualquier módulo del archivo EAR puede llamar al método ObjectGridManager.connect (ServerFactory.getServerProperties().getCatalogServiceBootstrap(), null, null) para obtener un ClientClusterContext. El módulo también puede llamar al método ObjectGridManager.getObjectGrid(ccc, "nombre de cuadrícula") para obtener una referencia a la cuadrícula de datos. Si los objetos de aplicación se almacenan en correlaciones, verifique que estos objetos estén presentes en un cargador de clases común.

Los clientes Java o clientes externos a la célula se pueden conectar al puerto IIOP de programa de arranque del servicio de catálogo. En WebSphere Application Server, el gestor de despliegue aloja el servicio de catálogo de forma predeterminada. A continuación, el cliente puede obtener un ClientClusterContext y la cuadrícula de datos con nombre.

Gestor de entidades

Con el gestor de entidades, los tuples se almacenan en las correlaciones en lugar de hacerlo en los objetos de aplicación, lo que genera menos problemas de cargador de clases. Sin embargo, los plug-ins pueden ser un problema. Además, tenga en cuenta que el archivo XML de descriptor de ObjectGrid de sustitución de cliente siempre es necesario al conectar a una cuadrícula de datos que tenga entidades definidas: ObjectGridManager.connect("host:puerto[,host:puerto], null, objectGridOverride) o ObjectGridManager.connect(null, objectGridOverride).