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
- 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..
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.
- 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.
- 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
Nächste Schritte
- 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.