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.
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.
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).