Anwendungen von WebSphere Application Server für den automatischen Start von Container-Servern konfigurieren

Container-Server in einer Umgebung mit WebSphere Application Server werden automatisch gestartet, wenn ein Modul gestartet wird, in dem die XML-Dateien von eXtreme Scale enthalten sind.

Vorbereitende Schritte

WebSphere Application Server und WebSphere eXtreme Scale müssen installiert und in der Lage sein, auf die Administrationskonsole von WebSphere Application Server zuzugreifen.

Informationen zu diesem Vorgang

Java-EE-Anwendungen haben komplexe Klassenladerregeln, die das Laden von Klassen erheblich komplizieren, wenn ein Datengrid mit Shards in einem Java-EE-Server verwendet wird. Eine Java-EE-Anwendung ist gewöhnlich eine einzige EAR-Datei. Die EAR-Datei enthält ein oder mehrere EJB- oder WAR-Module.

WebSphere eXtreme Scale überwacht den Start jedes Moduls und sucht nach XML-Dateien von eXtreme Scale. Wenn der Katalogservice erkennt, dass ein Modul mithilfe von XML-Dateien gestartet wird, wird der Anwendungsserver als Container-Server-JVM (Java Virtual Machine) registriert. Durch die Registrierung der Container-Server beim Katalogservice kann dieselbe Anwendung in mehreren Datengrids implementiert und trotzdem vom Katalogservice als einzelnes Datengrid behandelt werden. Der Katalogservice kümmert sich nicht um Zellen, Grids oder dynamische Grids. Ein einziges Datengrid kann, sofern erforderlich, mehrere Zellen umspannen.

Vorgehensweise

  1. Packen Sie in Ihre EAR-Datei Module, die die XML-Dateien von eXtreme Scale im Ordner META-INF enthalten. WebSphere eXtreme Scale erkennt das Vorhandensein der Dateien objectGrid.xml und objectGridDeployment.xml im Ordner META-INF von EJB- und WEB-Modulen, wenn diese gestartet werden. Wenn nur eine Datei objectGrid.xml gefunden wird, wird davon ausgegangen, dass die JVM ein Client ist. Sind beide Dateien vorhanden. wird davon ausgegangen, dass diese JVM als Container für das Datengrid agiert, das in der Datei objectGridDeployment.xml definiert ist.

    Sie müssen die richtigen Namen für diese XML-Dateien verwenden. Bei den Dateinamen muss die Groß-/Kleinschreibung beachtet werden. Wenn die Dateien nicht vorhanden sind, wird der Container nicht gestartet. Sie können in der Datei systemout.log nach Nachrichten suchen, die darauf hinweisen, dass Shards verteilt werden. Ein EJB-Modul oder WAR-Modul, das eXtreme Scale verwendet, muss XML-Dateien von eXtreme Scale in seinem Verzeichnis META-INF enthalten.

    Die XML-Dateien von eXtreme Scale enthalten Folgendes: Die Laufzeitumgebung erkennt diese Dateien und stellt dann eine Verbindung zum Katalogservice her, um ihn darüber zu informieren, dass ein weiterer Container verfügbar ist, der Shards für diese Instanz von eXtreme Scale aufnehmen kann.
    Tipp: Wenn Ihre Anwendung Entitäten hat und Sie einen Container-Server verwenden möchten, setzen Sie minSyncReplicas in der XML-Implementierungsdeskriptordatei auf den Wert 0. Andernfalls können Sie eine der folgenden Nachrichten in der Datei SystemOut.log sehen, weil keine Verteilung stattfinden kann, bis ein anderer Server der minSyncReplica-Richtlinie entspricht:
    CWPRJ1005E: Fehler beim Auflösen der Entitätsassoziation. Entity=entity_name, 
    association=association_name.
    CWOBJ3013E: Das EntityMetadata-Repository ist nicht verfügbar. Beim Versuch, die Entität
    zu registrieren, wurde das zulässige Zeitlimit erreicht: Entitätsname
  2. Implementieren und starten Sie Ihre Anwendung.

    Der Container wird automatisch gestartet, wenn das Modul gestartet wird. Der Katalogservice beginnt sobald wie möglich mit der Verteilung der primären und Replikat-Shards der Partition. Diese Verteilung findet unverzüglich statt, sofern Sie keine Verzögerung der Verteilung in der Umgebung konfigurieren. Weitere Informationen finden Sie unter Verteilung steuern.

Nächste Schritte

Anwendungen, die sich in derselben Zelle wie die Container befinden, können eine Verbindung zu diesen Datengrids über die Methode "ObjectGridManager.connect(null, null) herstellen und anschließend die Methode "getObjectGrid(ccc, "object grid name")" aufrufen. Die Methoden "connect" und "getObjectGrid" können blockiert werden, bis die Container die Shards verteilt haben, aber diese Blockierung tritt nur auf, wenn das Datengrid gestartet wird.

ClassLoaders

Alle Plug-ins oder Objekte, die in eXtreme Scale gespeichert sind, werden in ein bestimmtes Klassenladeprogramm geladen. Zwei EJB-Module in derselben EAR-Datei können diese Objekte enthalten. Die Objekte sind identisch, werden aber von verschiedenen Klassenladeprogrammen geladen. Wenn Anwendung A ein Person-Objekt in einer Map speichert, die eine lokale Map des Servers ist, empfängt Anwendung B eine Ausnahme des Typs ClassCastException, wenn sie versucht, das Objekt zu lesen. Diese Ausnahme tritt ein, weil Anwendung B das Person-Objekt in einem anderen Klassenladeprogramm geladen hat.

Eine Methode zur Behebung dieses Problems ist die Verwendung eines Stammmoduls, das die erforderlichen Plug-ins und Objekte enthält, die in eXtreme Scale gespeichert werden. Jedes Modul, das eXtreme Scale verwendet, muss dieses Modul für seine Klassen referenzieren. Eine andere Lösung ist die Verwaltung dieser gemeinsam genutzten Objekte in einer Dienstprogramm-JAR-Datei, die in einem Klassenladeprogramm enthalten ist, das von Modulen und Anwendungen gemeinsam genutzt wird. Die Objekte können auch in WebSphere-Klassen oder in ein Verzeichnis lib/ext gestellt werden, aber diese Verteilung macht die Implementierung komplexer.

EJB-Module in einer EAR-Datei nutzen gewöhnlich dasselbe Klassenladeprogramm und sind von diesem Problem nicht betroffen. Jedes WAR-Modul hat ein eigenes Klassenladeprogramm und ist von diesem Problem betroffen.

Nur Verbindung zu einem Datengrid-Client herstellen:

Wenn die Eigenschaft catalog.services.cluster in den angepassten Zellen-, Knoten- oder Servereigenschaften definiert ist, kann jedes Modul in der EAR-Datei die Methode ObjectGridManager.connect (ServerFactory.getServerProperties().getCatalogServiceBootstrap(), null, null) aufrufen, um einen ClientClusterContext abzurufen. Das Modul kann auch die Methode ObjectGridManager.getObjectGrid(ccc, "grid name") aufrufen, um eine Referenz auf das Datengrid anzufordern. Wenn Anwendungsobjekte in Maps gespeichert werden, müssen Sie sicherstellen, dass diese Objekte in einem gemeinsamen Klassenladeprogramm vorhanden sind.

Java-Clients und Clients außerhalb der Zelle können eine Verbindung zum Bootstrap-IIOP-port des Katalogservice herstellen. In WebSphere Application Server wird der Katalogservice standardmäßig im Deployment Manager ausgeführt. Der Client kann anschließend einen ClientClusterContext und das benannte Datengrid anfordern.

EntityManager

Mit dem Entitätsmanager werden die Tupel in den Maps und nicht in Anwendungsobjekten gespeichert, was zu weniger Problemen beim Laden von Klassen führt. Plug-ins können jedoch ein Problem sein. Beachten Sie auch, das immer eine ObjectGrid-XML-Deskriptordatei für Clientkorrekturwerte erforderlich ist, wenn eine Verbindung zu einem Datengrid hergestellt wird, in der Entitäten definiert sind: ObjectGridManager.connect("host:port[,host:port], null, objectGridOverride) oder ObjectGridManager.connect(null, objectGridOverride).