Containerinteroperabilität
"Containerinteroperabilität" beschreibt die Fähigkeit von Clients und Servern des Produkts verschiedener Versionen, die Unterstützung der verschiedenen nativen EJB-Finder-Methoden und die Konformität mit Java EE erfolgreich zu vereinbaren.
Interoperabilität der Handle-Formate in WebSphere Application Server Version 5 und Version 5.0.1
Anwendungen, die versuchen, Handles für Enterprise-Beans und EJBHome persistent zu speichern, müssen die Klasse "ObjectInputStream" von WebSphere Application Server Version 5 ableiten. Diese Aktion ist erforderlich, damit die Unterklasse ObjectInputStream den Kontextklassenlader verwenden kann, um die Klassen für Enterprise-Beans und EJBHome-Stubs aufzulösen.
Außerdem funktionieren Handles, die in WebSphere Application Server Version 5 erstellt und persistent gespeichert werden, nur für Objekte mit unveränderter ferner Schnittstelle. Wenn die ferne Schnittstelle geändert wird, ist das Handle nicht mehr gültig, weil der Stub im Handle serialisiert ist und sich dessen serielle Versions-UID ändert, sobald sich die ferne Schnittstelle ändert.
In diesem Release wird ein neues Verfahren für Handle-Persistenz eingeführt, dass die Nachteile bei der Implementierung in früheren Versionen nicht mehr aufweist. Wenn Sie in dieser Version von WebSphere Application Server Handles verwenden, müssen Sie Folgendes beim Anwenden dieser Aktualisierung, zukünftigen Fixpacks für WebSphere Application Server und kumulative EJB-Container-Fixes für WebSphere Application Server Version 5 beachten.
Wird auf einem System mit WebSphere Application Server Version 5.0.1 ein persistentes Handle oder Home-Handle der WebSphere Application Server Version 5 gefunden, kann dieses gelesen und verwendet werden. Außerdem wird das Handle in das Format von WebSphere Application Server Version 5.0.1 konvertiert, falls es erneut persistent gespeichert wird. Das Format von WebSphere Application Server Version 5.0.1 kann von einem WebSphere Application Server Version 5 nur dann gelesen werden, wenn PQ72184 angewendet wurde.
Es treten Probleme auf, wenn Handles persistent gespeichert und systemübergreifend verwendet werden, die nicht aus WebSphere Application Server Version 5.0.1 oder später stammen. Ein System der Version 5 kann jedoch ein Handle der Version 5.0.1 über einen Aufruf von einem fernen System empfangen, um ein Handle für eine Enterprise-Bean oder ein getHomeHandle für ein EJBHome zu erhalten. Der ferne Aufruf funktioniert, aber jeder Versuch, das Handle in einem System der Version 5 persistent zu speichern, unterliegt denselben Einschränkungen bezüglich der Verwendung von ObjectInputStream und Änderungen der fernen Schnittstelle, die das persistente Handle ungültig machen.
Wenn Ihre Anwendung Handles persistent speichert und diese Persistenz mit mehreren Clients oder Anwendungsservern teilt, wenden Sie WebSphere Application Server Version 5.0.1 oder PQ72184 gleichzeitig auf die Client- und die Serversysteme an. Sollten Sie dies nicht tun, sind diese Systeme möglicherweise nicht mehr in der Lage, die Handle-Daten zu lesen, die von den aktualisierten Systemen gespeichert wurden. Außerdem können von WebSphere Application Server Version 5 gespeicherte Handles die Anwendungen des aktualisierten Systems dazu zwingen, die Klasse ObjectInputStream weiterhin abzuleiten. Anwendungen, die den Scheduler und den Process Choreographer von WebSphere Application Server Enterprise Version 5 verwenden, sind von diesen Änderungen betroffen. Benutzer dieser Anwendungen müssen ihre Systeme der Version 5 gleichzeitig mit Version 5.0.1 oder PQ72184 aktualisieren.
Wenn die Anwendungen Handles im Sitzungskontext oder lokal in einer Datei auf demselben System speichern, auf die andere Anwendungen auf anderen Systemen nicht zugreifen können, können die Benutzer dieser Anwendungen ihre Systeme unter Umständen einzeln aktualisieren. Wenn Client-Container- und Thin-Client-Anwendungen persistente Handle-Daten nicht gemeinsam nutzen, können diese bei Bedarf ebenfalls aktualisiert werden. Handles, die in WebSphere Application Server Version 5, Version 4.0.3 und höher (mit gesetztem property-Flag) oder Version 3.5.7 und höher (mit gesetztem property-Flag) erstellt und persistent gespeichert wurden, sind jedoch nicht verwendbar, wenn Änderungen an der Home- oder der fernen Schnittstelle vorgenommen wurden.
Wenn in einem WebSphere Application Server Version 3.5.7 oder Version 4.0.3 und höher die Systemeigenschaft "com.ibm.websphere.container.portable" auf true gesetzt ist, gelten für alle Objekt-Handles in diesem Server dieselben Interoperabilitätseinschränkungen. Falls Anwendungen der WebSphere Application Server Version 3.5.7 und höher oder Version 4.0.3 ein Handle speichern, das sie von einem WebSphere Application Server Version 5 oder Version 5.0.1 erhalten haben, gelten dieselben Einschränkungen bezüglich der abgeleiteten Klasse "ObjectInputStream" und der Verwendbarkeit von Handles nach Änderung der fernen Schnittstelle.
Replikation von HTTP-Sitzungen und Handles
Diese Anmerkung gilt nur für Sie, wenn Sie Handles in den Home-Schnittstellen oder EJB- und EJBHome-Referenzen in der HTTP-Sitzung Ihrer Anwendung speichern und mit Replikation von HTTP-Sitzungen arbeiten. Wenn Sie eine Umgebung replizieren möchten, in der Maschinen mit Version 5.0.0 und Version 5.0.1 oder 5.0.2 enthalten sind, müssen Sie zuerst den aktuellen kumulativen Container-E-Fix für Version 5.0.0 auf die Maschinen mit der Version 5.0.0 anwenden, bevor Sie Server der Version 5.0.1 oder 5.0.2 in der Topologie zulassen. Der Grund hierfür ist, dass Server der Version 5.0.0 das Format persistent gespeicherter Handles von Servern der Version 5.0.1 und der Version 5.0.2 nicht interpretieren können. Das ist ähnlich wie bei Systemen der Version 5.0.0 und der Version 5.0.1 oder 5.0.2, die versuchen, eine gemeinsame Datenbank zu verwenden. In diesem Fall wird die Persistenz jedoch vom HttpSession-Objekt und nicht von der Datenbank unterstützt.
Top-down-Zuordnung für die Implementierung
Die Handle-Objekte sind aufgrund des installierten Fix für die Unterstützung von Serialisierung und Entserialisierung ohne die zuvor erforderliche Ableitung der Klasse ObjectInputStream usw. größer geworden. Beim Top-down-Deployment eines Objekts, das EJB- und EJBHome-Referenzen enthält, wird eine DDL-Datei für eine Datenbanktabelle erstellt, die ein Feld (1000 Bytes VARCHAR für BITDATA) enthält, in dem das Handle gespeichert wird. Es kann passieren, dass das Handle Ihres Objekts nicht in das Standardfeld mit einer Größe von 1000 Bytes passt. In diesem Fall müssen Sie das Feld vergrößern. Sie können das Feld in Inkrementen von 250 Bytes, d. h. 1250, 1500 usw. vergrößern.