Eine Web-Service-Gateway-Konfiguration der Version 5.1 migrieren

In WebSphere Application Server Version 5.1 ist das Web-Service-Gateway eine gesonderte Komponente mit einer eigenen Schnittstelle. In höheren Produktversionen ist das Gateway in die SIB-fähigen Web-Services integriert und wieder als Mechanismus für die Erweiterung und Verbindung von Services für eingehende und abgehende Daten implementiert. Sie verwenden ein wsadmin-Befehlsscript, um eine vorhandene Gatewaykonfiguration aus einem Anwendungsserver der Version 5.1 in einen Anwendungsserver oder Cluster einer höheren Version zu migrieren.

Vorbereitende Schritte

Stellen Sie fest, ob Sie die vorhandenen Gateways migrieren müssen:
  • WebSphere Application Server Version 5.0 wird nicht mehr unterstützt. Deshalb sollten Sie alle vorhandenen Gateways, die in Anwendungsservern der Version 5.0 ausgeführt werden, auf die Ausführung in Anwendungsservern der aktuellen Produktversion migrieren.
  • Web-Service-Gateways, die in WebSphere Application Server Version 5.1 ausgeführt werden, können mit bestimmten Einschränkungen mit Gateway-Instanzen koexistieren, die in Anwendungsservern der Version 7.0 oder höher ausgeführt werden..
  • Eine Zelle der Version 7.0 oder höher kann Anwendungsserver der Version 5.1, Version 6 und Version 7.0 oder höher enthalten..
Weitere Informationen finden Sie im Artikel Koexistenz: Ein Gateway der Version 5.1 beibehalten oder migrieren.

Sie können ein Gateway der Version 5.1 in Produktionsumgebungen migrieren, ohne das Gateway zu stoppen. Requester-Anwendungen können dann die neue Gatewaykonfiguration verwenden, während das vorhandene Gateway der Version 5.1 weiterhin ausgeführt wird.

Informationen zu diesem Vorgang

Beim Migrationsprozess wird eine Gatewayanwendung der Version 5.1, deren Konfiguration in eine XML-Datei exportiert wurde, und anschließend diese exportierte XML-Datei verwendet, um dieselbe Gatewayfunktionalität in einem Anwendungsserver oder Cluster der höheren Version zu konfigurieren. Hierfür exportieren Sie die Gatewaykonfiguration der Version 5.1 und führen anschließend ein Script aus, um die exportierte Konfiguration in eine neue Gatewayinstanz in einem vorhandenen Anwendungsserver oder Cluster der höheren Version zu migrieren.

Die Konfiguration der Version 5.1 wird wie folgt migriert:
  • Während der Migration wird automatisch eine Gatewayinstanz erstellt.
  • Gateway-Services, Zielservices und UDDI-Referenzen werden direkt migriert.
  • Die Definitionen im Gateway von JAX-RPC-Handlern und -Handlerlisten werden ebenfalls migriert. Sie müssen sicherstellen, dass die zugrundeliegenden Handlerklassen zur Laufzeit verfügbar sind.
  • Zuordnungen von Gateway-Services zu spezifischen Kanälen werden durch entsprechende Zuordnungen zu spezifischen Paaren aus eingehendem Port und Endpunktlistener ersetzt (weil in höheren Versionen der Funktionen eines Kanals von einem Endpunktlistener und einem Port für eingehende Daten gemeinsam bereitgestellt werden). Alle Apache-SOAP-Kanäle werden auf eine Kombination aus Endpunktlistener und Port für eingehende Daten für SOAP over HTTP migriert.
  • Vorhandene Filter werden nicht migriert. Die Verwendung von Filtern ist seit Version 5.1.1 veraltet, und die Unterstützung für Filter wurde in Version 7 nicht weiter bereitgestellt. Die Rolle, die die Filter früher hatten, wird jetzt von JAX-RPC-Handlern und SIB-Mediations übernommen.
  • Web-Service-Clients, die aus der WSDL für den Zielservice und nicht aus der des Gateway-Service generiert werden, werden in höheren Versionen standardmäßig als fehlerhaft gekennzeichnet.
  • Wenn Sie die WSDL des Gateway-Service der Version 5.1 verwendet haben, um Ihre Web-Service-Clients zu generieren, und Ihre WSDL-Bindung und die Codierungsdarstellung nicht "document-literal" ist, müssen Sie nach der Migration auf eine höhere Version die Client-Stubs mit der WSDL des neuen Gateway-Service erneut generieren.
  • WS-Security-Bindungen werden als Bindungen migriert, die der Spezifikation WS-Security Draft 13 entsprechen. Beachten Sie jedoch Folgendes:
    • Die letzte Version (1.0) der WS-Security-Spezifikation (die in WebSphere Application Server Version 6 implementiert ist) ist mit der Version Draft 13 nicht kompatibel, und deshalb wurde die Verwendung von WS-Security Draft 13 in WebSphere Application Server Version 6 als veraltet gekennzeichnet. Da die Spezifikation WS-Notification Draft 13 jedoch veraltet ist, sollten Sie sie nur verwenden, um die fortgesetzte Nutzung einer vorhandenen Web-Service-Clientanwendung zuzulassen, die auf der Basis der Spezifikation WS-Notification Draft 13 geschrieben wurde.
    • Die WS-Security-Bindungsobjekte werden nur migriert, wenn der Migrationsprozess auf der Maschine ausgeführt wird, auf der der Zielserver ausgeführt wird (bei eigenständigen Servern), bzw. auf der Maschine, auf der der Deployment Manager ausgeführt wird (in einer Network-Deployment-Konfiguration).
    • Es werden nur WS-Security-Bindungsobjekte, die in einem Gateway-Service oder in einer WS-Security-Zielservicekonfiguration verwendet werden, migriert. Alle Bindungsobjekte, die Sie erstellen, aber nicht verwenden, werden nicht migriert. Beispiel: Wenn Sie eine WS-Security-Konfiguration haben, die auf ein Objekt für Signaturdaten verweist, und das Objekt für Signaturdaten auf einen Trust-Anchor verweist, werden das Objekt für Signaturdaten und das Trust-Anchor-Objekt zusammen mit der WS-Security-Konfiguration, in der auf diese Objekte verwiesen wird, migriert.
Anmerkung:
  • Die Migration setzt voraus, dass die externen Webadressen für die migrierten Services unverändert bleiben. Diese Voraussetzung basiert auf der Erwartung, dass diese Adressen einem Web-Server und nicht der Maschine mit dem Gateway zugeordnet sind und der Hostname und die Portnummer für diese Adressen deshalb nicht betroffen sind. Wenn die externen Webadressen in Ihrer Konfiguration auf die Gatewaymaschine verweisen, nach Abschluss des Migrationsprozesses.
  • In WebSphere Application Server Network Deployment können Sie die Migration auf einen Einzelserver jedes Konfigurationsprofils (eigenständiger Server oder Deployment Manager) durchführen. Es wird jedoch empfohlen, als Ziel für die Migration einen Einzelserver zu verwenden, der unter einem Deployment-Manager-Profil ausgeführt wird. Wenn Sie die Migration auf ein Einzelserverprofil durchführen, können Sie danach die Gatewaykonfiguration nicht mit der Administrationskonsole ändern.
  • SIB-fähige Web-Services validieren Web-Service-Nachrichten gründlicher, als es in WebSphere Application Server Version 5.1 der Fall ist. Deshalb werden einige Clientanwendungen, die falsch formatierte Anforderungen oder Antworten verwenden (in denen die Nachrichtenabschnitte falsch benannt sind) und in Version 5.1 funktionieren, jetzt als falsch formatiert identifiziert. Die Schritte, die zur Behebung dieses Problems ausgeführt werden müssen, sind im Artikel Busfähige Web-Services: Bekannte Einschränkungen beschrieben.

Zum Migrieren einer vorhandenen Gatewaykonfiguration von einem Anwendungsserver der Version 5.1 auf die Gatewayfunktionalität in einem Anwendungsserver oder Cluster einer höheren Version führen Sie die folgenden Schritte aus:

Vorgehensweise

  1. Optional: Entfernen Sie alle Filter aus Ihrem Gateway der Version 5.1.
    Sie können ein Gateway, das Filter enthält, migrieren. Filter funktionieren jedoch nicht in höheren Versionen. Deshalb sollten Sie sie wie folgt aus der Konfiguration entfernen, bevor Sie die folgenden Schritte ausführen:
    1. Prüfen Sie, ob Ihr Gateway der Version 5.1 Filter verwendet. Weitere Informationen finden Sie im Artikel 'Über das Gateway implementierte Filter auflisten und verwalten' im Information Center von WebSphere Application Server Version 5.1 .
    2. Entfernen Sie alle Filter. Weitere Informationen finden Sie im Artikel 'Filter aus dem Web-Service-Gateway entfernen' im Information Center von WebSphere Application Server Version 5.1.
    Nach der Migration können Sie Ihre Filterfunktionen durch eine Kombination von JAX-RPC-Handlern und SIB-Mediations erneut erstellen. Wenn Sie ein Web-Service-Gateway migrieren, das einen Routing-Filter enthält, können Sie die Filterfunktionen neu erstellen.
  2. Wählen Sie einen Zielserver oder -cluster aus, der ein Einzelserver bzw. Cluster der höheren Version ist und zu einer Network-Deployment-Zelle gehört.
  3. Konfigurieren Sie den Zielserver bzw. -cluster als Member eines Service Integration Bus.
  4. Konfigurieren Sie ein SDO-Repository (Service Data Objects) auf Zellenebene für den Zielserver bzw. -cluster.
  5. Wenn Sie EJB-Bindungen migrieren und diese weiterhin eine Bindung des Typs "RPC-encoded" oder eine andere Bindung als "document/literal" verwenden sollen, fügen Sie eine Bindung des korrekten Typs in der WSDL für die EJB-Bindungen hinzu. Dieser Schritt ist erforderlich, weil die Standardbindung für Gateways der Version 5.1 den Typ RPC-encoded hat, in höheren Versionen für die Standardbindung aber der Typ document literal verwendet wird.
  6. Vergewissern Sie sich, dass der Quellenanwendungsserver (Version 5.1) aktiv ist, und verwenden Sie anschließend die Benutzerschnittstelle für das Gateway der Version 5.1, um die Gatewaykonfiguration im Anwendungsserver der Version 5.1 als private Konfiguration zu sichern. Weitere Informationen finden Sie im Artikel zu WebSphere Application Server Version 5.1: Gatewaykonfiguration sichern.
  7. Optional: Stoppen Sie den Anwendungsserver der Version 5.1.
    Anmerkung: Wenn Sie ein Gateway verwenden, das in einer Produktionsumgebung eingesetzt wird, lassen Sie das Gateway der Version 5.1 so lange aktiv, bis die Gatewaykonfiguration der höheren Version vollständig ist. Stellen Sie anschließend die anfordernden Anwendungen auf die neue Gatewaykonfiguration um, während das vorhandene Gateway der Version 5.1 weiterhin ausgeführt wird. Es dürfen jedoch nicht beide Versionen des Gateway gleichzeitig ausgeführt werden. Möglicherweise müssen Sie den Server der Version 5.1 stoppen, bevor Sie den Server oder Cluster der höheren Version starten (z. B., wenn Sie den Server oder Cluster der höheren Version als direkten Ersatz für den Server der Version 5.1 auf derselben Maschine und mit denselben Portnummern installieren).
  8. Starten Sie den Zielanwendungsserver oder im Zielcluster der höheren Version und, bei einem Einzelserver oder Cluster in einer verwalteten Zelle, den Deployment Manager für die Zielzelle.
  9. Stellen Sie sicher, dass alle WSDL-Dokumente, die für die Definition der Zielservices im Anwendungsserver der Version 5.1 verwendet wurden, an den angegebenen Positionen verfügbar sind. Wenn die WSDL-Position eine UDDI-Referenz ist, stellen Sie sicher, dass die referenzierte UDDI-Registry verfügbar ist.
  10. Optional: Wenn das migrierte Gateway JAX-RPC-Handler und -Handlerlisten verwendet, müssen Sie sicherstellen, dass die zugrundeliegenden Handlerklassen zur Laufzeit verfügbar sind.
  11. Führen Sie die folgenden Schritte aus, um die exportierte Konfiguration in eine neue Gatewayinstanz im Anwendungsserver oder Cluster der höheren Version zu migrieren:
    1. Öffnen Sie eine Eingabeaufforderung, und wechseln Sie in das Verzeichnis Stammverzeichnis_des_Anwendungsservers/util.
    2. Führen Sie den folgenden Befehl aus:
      [IBM i]Anmerkung: [IBM i]Der Scripting-Client wsadmin wird über die Qshell ausgeführt. [IBM i]Weitere Informationen finden Sie unter Qshell für die Ausführung von WebSphere-Scripts mit wsadmin-Scripting konfigurieren.
      migratewsgw[AIX Solaris HP-UX Linux Windows][z/OS].ext -C=Zellenname [-S=Servername -N=Knotenname]
                          [-X=Clustername] -B=Busname
                           -G=Name_der_v5-Gatewaykonfigurationsdatei
                          [-H=Name_des_Verwaltungshosts] [-A=Verwaltungsport]
                          [-U=Name_der_Gatewayinstanz] [-P=Objektpräfix]
                          [-username=WAS-Benutzer-ID -password=WAS-Kennwort]
      Für diese Angaben gilt Folgendes:
      • [AIX Solaris HP-UX Linux Windows][z/OS].ext steht für die Dateierweiterung .bat auf Windows-Systemen bzw. .sh auf UNIX- und Linux-Systemen.
      • Eckige Klammern ("[ ]") zeigen an, dass ein Parameter bzw. eine Gruppe von Parametern unter bestimmten Umständen optional sind.
      • Servername und Knotenname (für einen einzelnen Server) bzw. Clustername (für einen Cluster) definieren den Server bzw. Cluster, in den die Gatewaykonfiguration migriert wird.
      • Zellenname, Servername und Knotenname (oder Clustername), Name_des_Verwaltungshosts und Verwaltungsport definieren gemeinsam die Verbindung zum Anwendungsserver (bzw. Cluster) der höheren Version. Servername bzw. Clustername gibt den Namen des Zielanwendungsservers bzw. Zielclusters an, in dem Endpunktlistener und Portziele für abgehende Daten erstellt werden. Wenn Sie eine Migration auf einen Server oder Cluster durchführen, der zu einer verwalteten Zelle gehört, definieren Name_des_Verwaltungshosts und Verwaltungsport den Hostnamen und die Nummer des SOAP-Verwaltungsports des Deployment Manager. Wenn Sie eine Migration auf einen Server durchführen, der nicht zu einer verwalteten Zelle gehört, definieren Name_des_Verwaltungshosts und Verwaltungsport den Hostnamen und die Portnummer des eigenständigen Servers und sind optional. Fehlen diese Angaben, geht der Befehl davon aus, dass die beabsichtigten Werte localhost:8880 sind (d. h. die Standardwerte von WebSphere Application Server für einen eigenständigen Server).
        [IBM i]Anmerkung: Name_des_Verwaltungshosts steht obligatorisch für die Plattform IBM i.
      • Name_der_v5-Gatewaykonfigurationsdatei steht für den vollständigen Pfad- und Dateinamen der exportierten XML-Konfigurationsdatei für das private Gateway der Version 5.1.
      • Busname und Name_der_Gatewayinstanz definieren zusammen die Gatewayinstanz, die Sie im Bus erstellen. Der Name_der_Gatewayinstanz ist nur erforderlich, wenn Sie mehrere Gatewayinstanzen in diesem Bus erstellen möchten. Wenn Sie diesen optionalen Parameter nicht angeben, wird ein Standardname zugeordnet.
      • Objektpräfix steht für eine Zeichenfolge, die den Namen der vom Migrationsprozess definierten Objekte vorangestellt wird. Wenn Sie kein Objektpräfix angeben, wird der Namespace-URI (Standardwert urn:ibmwsgw) für die migrierten Services verwendet.
      • WAS-Benutzer-ID und WAS-Kennwort müssen angegeben werden, wenn der Zielanwendungsserver bzw. Cluster kennwortgeschützt ist.
  12. Optional: Wenn die externen Webadressen für die migrierten Services vom Migrationsprozess geändert werden, müssen Sie diese neuen Adressen in der Endpunktlistenerkonfiguration angeben. Sie müssen diese Änderung vornehmen, wenn die externen Webadressen auf die Gatewaymaschine und nicht auf einen Web-Server zeigen und Sie das Gateway auf eine andere Maschine oder an einen anderen Port auf derselben Maschine migriert haben.

Nächste Schritte

Anmerkung:
  • Wenn in Ihrem Gateway der Version 5.1 Filter verwendet wurden, erstellen Sie die Filterfunktionen unter Verwendung einer Kombination von JAX-RPC-Handlern und SIB-Mediations erneut.
  • Falls die Gatewaykonfiguration Gateway-Services mit mehreren Zielservices enthält, wurde in der Konfiguration der Version 5.1 möglicherweise ein Routing-Filter verwendet, um einen bestimmten Zielservice auszuwählen. In diesem Fall müssen Sie das migrierte Gateway weiter konfigurieren, um einen Zielservice und einen Port über eine Routing-Mediation auszuwählen.
  • Ein Web-Service-Gateway der höheren Version verwendet mehr Hauptspeicher für die Verarbeitung einer Nachricht, so dass Fehler aufgrund abnormaler Speicherbedingungen in der Java Virtual Machine auftreten können, wenn ein großer Anhang über den migrierten Gateway übergeben wird. Wenn dieser Fehler auftritt, müssen Sie den Wert für die Größe des JVM-Heapspeichers erhöhen.

Symbol, das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twsg_coex_migrate
Dateiname:twsg_coex_migrate.html