Bei der Migration der Produktkonfiguration werden diverse Konfigurationen einander zugeordnet.
Es sind zahlreiche Migrationsszenarios möglich. Die Migrationstools ordnen Objekte und Attribute der zu migrierenden Version den entsprechenden Objekten und Attributen in der Umgebung der neuen Version zu.
Die Migrationstools konvertieren geeignete Befehlszeilenparameter in die entsprechenden JVM-Einstellungen (JVM = Java™ Virtual Machine) in der Serverprozessdefinition. Die meisten Einstellungen werden direkt zugeordnet. Einige Einstellungen können nicht migriert werden, weil ihre Aufgabenbereiche in der Konfiguration von WebSphere ESB Version 6.2 nicht existieren oder andere Bedeutungen oder Geltungsbereiche besitzen.
Informationen zum Ändern der Einstellungen von Prozessdefinitionen finden Sie unter Einstellungen für Prozessdefinitionen im WebSphere Application Server Network Deployment, Version 6.1 Information Center. Informationen zum Ändern der Java Virtual Machine-Einstellungen finden Sie in dem Abschnitt für Java Virtual Machine-Einstellungen im Information Center von WebSphere Application Server Network Deployment, Version 6.1.
Bei der Migration der EAR-Dateien von WebSphere ESB mit dem Tool wsadmin auf Version 6.2 verwendet das Tool WBIPostUpgrade die standardmäßige maximale Java-Heapspeichergröße von 64 MB, um die EAR-Dateien zu installieren.
java.lang.OutOfMemoryError JVMXE006:OutOfMemoryError
Erhöhen Sie die maximale Java-Heapgröße, und verwenden Sie das nachfolgende Beispiel, um die Anwendung zu installieren.
Beispiel für die Installation einer Anwendung auf WebSphere ESB Version 6.2
wsadmin -conntype NONE -javaoption -Xmx###m -c "$AdminApp install C:\\WebSphere\\ProcServer <EAR_dateiname> {-nodeployejb -appname anwendungsname -cluster clustername}"
Sie können einen WebSphere ESB Version 6.0.x oder 6.1.x-Knoten, der zu einer Zelle gehört, auf WebSphere ESB Version 6.2 migrieren, ohne den Knoten aus der Zelle entfernen zu müssen.
Migrieren Sie zunächst den Deployment Manager, bevor Sie andere Basisknoten in der Zelle migrieren.
Verwenden Sie bei der Migration von Version 6.0.x oder 6.1.x auf Version 6.2 denselben Zellennamen. Wenn Sie einen anderen Zellennamen verwenden, können eingebundene Knoten nicht erfolgreich in die Zelle der WebSphere ESB Version 6.2 migriert werden.
Wenn Sie einen Basisknoten von WebSphere ESB, der sich in einer Zelle befindet, auf Version 6.2 migrieren, wird der Knotenagent ebenfalls auf Version 6.2 migriert.
Bei der Migration werden Dateien aus Verzeichnissen der früheren Version in die Konfiguration von WebSphere ESB Version 6.2 kopiert.
WebSphere migriert alle Merkmaldateien, die mit Version 6.0.x oder 6.1.x installiert werden, indem es die Einstellungen in den Merkmaldateien der Version 6.2 zusammenführt.
Bei der Migration werden keine Merkmaldateien überschrieben.
RAR- und JAR-Dateien, die von J2C-Ressourcen referenziert werden, werden folgendermaßen migriert:
Ressourcen auf Clusterebene migrieren
<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172" name="ims" archivePath="${WAS-INSTALLATIONSSTAMMVERZEICHNIS}\installedConnectors\x2.rar"> ... </resources.j2c:J2CResourceAdapter>
Wenn Sie eine Ressource auf Clusterebene besitzen, muss sich diese auf allen Cluster-Membern (Knoten) im gleichen Verzeichnis befinden. Im obigen Beispiel muss sich die RAR-Datei demzufolge auf allen Cluster-Membern im folgenden Verzeichnis befinden: ${WAS-INSTALLATIONSSTAMMVERZEICHNIS}\installedConnectors\x2.rar. Die Variable ${WAS-INSTALLATIONSSTAMMVERZEICHNIS} wird auf den einzelnen Cluster-Membern in das jeweils zutreffende Verzeichnis aufgelöst.
Bei der Migration eines Deployment Managers migrieren die Tools die Clusterdateien auf dem Deployment Manager; dies beinhaltet auch die Dateien 'resourcexxx.xml'.
Wenn Sie einen Pfad zu einer RAR-Datei in Version 6.0.x oder 6.1.x fest codiert haben (z. B. archivePath="C:/WAS/installedConnectors/x2.rar") können die Migrationstools der Version 6.2 das Attribut archivePath nicht entsprechend ändern, da hierdurch alle Cluster-Member ungültig würden, die nicht migriert wurden.
Bei der Migration eines eigenständigen Profils werden keine WebSphere ESB-Beispiele migriert. Für alle Beispiele der Version 6.2 stehen der Version 6.2 funktional entsprechende Beispiele zur Verfügung.
Wenn Sie die Sicherheit in WebSphere ESB Version 6.2 aktivieren, wird standardmäßig die Java 2-Sicherheit aktiviert. Die Java 2-Sicherheit erfordert das explizite Erteilen von Sicherheitsberechtigungen.
Es gibt mehrere Verfahren, um unterschiedliche Java 2-Sicherheitsebenen in Version 6.2 zu definieren. Das eine Verfahren besteht darin, eine Datei was.policy innerhalb der Anwendung zu erstellen, um alle Sicherheitsberechtigungen zu aktivieren. Die Migrationstools rufen den Befehl wsadmin auf, um eine bestehende Datei was.policy im Verzeichnis properties von Version 6.2 zu Enterprise-Anwendungen, die gerade migriert werden, hinzuzufügen.
Hierbei handelt es sich um die Standardeinstellung.
Zum Bespiel wurden vorhandene Schlüsseldateien und Trust-Dateien aus dem SSLConfig-Repertoire entfernt und neue Keystore- und Truststore-Objekte erstellt.
Damit die Sicherheitseinstellungen beibehalten werden können, müssen Sie die Sicherheitseinstellungen von WebSphere Application Server migrieren, die für Version 6.0.2.x festgelegt wurden. Informationen zur Migration von Sicherheitskonfigurationen auf Version 6.2 finden Sie unter Migration, Koexistenz und Interoperabilität - Sicherheitsaspekte im WebSphere Application Server Network Deployment, Version 6.1 Information Center.
Diese Verzeichnisse befinden sich normalerweise unterhalb des Installationsverzeichnisses einer früheren Version. Das Standardverzeichnis für stdin, stdout und stderr ist das Verzeichnis logs des Installationsstammverzeichnisses von WebSphere ESB Version 6.2.
Die Migrationstools versuchen, vorhandene Auslagerungs- und Arbeitsverzeichnisse zu migrieren. Andernfalls werden geeignete Standardwerte für Version 6.2 verwendet.
Weitere Informationen zu Auslagerungsverzeichnissen finden Sie unter Einstellungen für EJB-Container. Weitere Informationen zu Arbeitsverzeichnissen enthält der Artikel Einstellungen für Prozessdefinitionen.
In einem Koexistenzszenario kann die gemeinsame Verwendung von Verzeichnissen für verschiedene Versionen zu Problemen führen.
Die Migrationstools migrieren sämtliche Ports. Die Tools protokollieren eine Warnung, wenn ein Portkonflikt auftritt, weil ein Port in der Konfiguration bereits definiert ist. Sie müssen alle Portkonflikte auflösen, bevor mehrere Server zur gleichen Zeit ausgeführt werden können.
Bei Angabe des Parameters -portBlock im Befehl WBIPostUpgrade wird jedem migrierten Transport ein neuer Wert zugewiesen.
Weitere Informationen zum Befehl WBIPostUpgrade finden Sie in Befehlszeilendienstprogramm 'WBIPostUpgrade'.
Weitere Informationen zu Transportketten und Kanälen finden Sie im Artikel Transportketten konfigurieren.
Aliasnamenseinträge für virtuelle Hosts müssen Sie für jeden Port manuell hinzufügen. Weitere Informationen finden Sie im Artikel Virtuelle Hosts konfigurieren.
Für die in WebSphere ESB Version 6.0.x oder 6.1.x implementierte J2EE-Spezifikationsstufe (J2EE = Java 2 Platform, Enterprise Edition) musste das Verhalten des Web-Containers in Bezug auf die Festlegung des Inhaltstyps geändert werden. Wenn ein standardmäßiger Servlet-Writer den Inhaltstyp nicht festlegt, wird dieser nicht mehr als Standardwert für den Web-Container verwendet und der Web-Container gibt den Aufruf als "null" zurück. Diese Situation kann in einigen Browsern dazu führen, dass nachfolgende Web-Container-Tags nicht ordnungsgemäß angezeigt werden. Um dieses Problem zu vermeiden, wird bei der Migration von Enterprise-Anwendungen die IBM® Erweiterung autoResponseEncoding für Webmodule auf "true" festgelegt.