IBM WebSphere WebSphere Integration Developer Version 6.1

Migrationshandbuch

Version 6 Release 1

Hinweis

Vor Verwendung dieser Informationen und des darin beschriebenen Produkts sollten die Informationen unter Bemerkungen gelesen werden.

Diese Ausgabe gilt für Version 6 Release 1 von WebSphere Integration Developer.

Copyright International Business Machines Corporation 2005, 2007. Alle Rechte vorbehalten.

Inhaltsverzeichnis

Kapitel 1. Migration nach WebSphere Integration Developer
Kapitel 2. Frühere Versionen von WebSphere Integration Developer migrieren
Überlegungen für den Migrationsprozess von einer Version auf die nächste
Entwicklung und Implementierungsversionsstände
Kapitel 3. Migration von WebSphere InterChange Server nach WebSphere Process Server
Unterstützte Migrationspfade für WebSphere InterChange Server
Vorbereitung für die Migration von WebSphere InterChange Server
Überlegungen für den WebSphere InterChange-Migrationsprozess
Überlegungen: Allgemeine Entwicklung
Überlegungen: Dienstprogramme für allgemeinen Code
Überlegungen: Datenbankverbindungspools
Überlegungen: Geschäftsobjekte
Überlegungen: Collaboration-Schablonen
Überlegungen: Zuordnungen
Überlegungen: Beziehungen
Überlegungen: Zugriffs-Framework-Clients
Überlegungen: Datenbankkonflikte verhindern
Überlegungen: Nach der Migration
Migration von WebSphere InterChange Server unter Verwendung des Migrationsassistenten
WebSphere InterChange Server-Migration überprüfen
Migrationsfehler von WebSphere InterChange Server beheben
Durch Migrationstools verarbeitete WebSphere InterChange Server-Artefakte
Unterstützte WebSphere InterChange Server-APIs
WebSphere Process Server-DataObject aus WebSphere InterChange Server-XML zuordnen
Kapitel 4. Migration von WebSphere MQ Workflow nach WebSphere Integration Developer
Vorbereitung für die Migration von WebSphere MQ Workflow
Migration von WebSphere MQ Workflow unter Verwendung des Migrationsassistenten
WebSphere MQ Workflow Migration überprüfen
Einschränkungen des Migrationsprozesses (von WebSphere MQ Workflow)
Kapitel 5. Migration von Quellenartefakten zu WebSphere Integration Developer von WebSphere Studio Application Developer Integration Edition
Unterstützte Migrationspfade für die Migration von Quellenartefakten
Quellenartefakte für die Migration vorbereiten
Überlegungen zum Migrationsprozess für das Quellenartefakt
Serviceprojekte mit dem WebSphere Integration Developer-Migrationsassistenten migrieren
Serviceprojekte mit WSADIEServiceProjectMigration migrieren
Anwendung migrieren
SCA-Komponenten und SCA-Importe für die Anwendungsservices zur Neuvernetzung erstellen
Migration eines Java-Service
Migration eines EJB-Service
Migration eines Geschäftsprozesses zum Geschäftsprozess-Serviceaufruf
Migration eines Web-Service (SOAP/JMS)
Migration eines Web-Service (SOAP/HTTP)
Migration eines JMS-Service
Migration eines J2C-IMS-Service
Migration eines J2C-CICS ECI-Service
Migration eines J2C-CICS EPI-Service
Migration eines J2C-HOD-Service
Migration eines Umsetzungs-Serviceprojekts
Auslastungsszenario für Servicemigration
SCA-Exporte für den Zugriff auf den migrierten Service erstellen
Migration von EJB und EJB-Prozessbindings
Migration von JMS und JMS-Prozessbindings
Migration des IBM Web-Service-Binding (SOAP/JMS)
Migration des IBM Web-Service-Binding (SOAP/HTTP)
Migration des Apache Web-Service-Binding (SOAP/HTTP)
Migration zum SCA-Programmiermodell
Migration von WSIFMessage API-Aufrufen zu SDO APIs
Migration des WebSphere Business Integration Server Foundation Client-Codes
Migration von WebSphere Business Integration Server Foundation BPEL Java-Snippets
Interaktionen mit WebSphere Business Integration-Adaptern migrieren
Migration von WSDL-Schnittstellen, die über SOAP-verschlüsselte Feldgruppentypen verfügen
Migration des WebSphere Business Integration EJB-Projekts
5.1-WSIF-Definitionen manuell löschen
Die Migration der Quellenartefakte überprüfen
Mit Migrationsfehlern von Quellenartefakten arbeiten
Einschränkungen des Migrationsprozesses (für Quellenartefaktmigration)
Bemerkungen
Rechtliche Hinweise

Kapitel 1. Migration nach WebSphere Integration Developer

WebSphere Integration Developer Version 6.1 bietet die für die Migration Ihrer vorhandenen Umgebung notwendigen Tools.

Anmerkung: WebSphere Integration Developer 6.0.2- und 6.1-Projekte können in WebSphere Integration Developer 6.0.1 nicht verwendet werden. Wenn Sie ein Upgrade auf WebSphere Integration Developer 6.0.2 oder 6.1 durchführen, können Projekte nicht in WebSphere Integration Developer 6.0.1.x zurückversetzt werden. Für Benutzer von Version 6.0.2 oder 6.1, die Code in ein Repository einchecken oder Projekte exportieren und diese dann mit einem Benutzer von WebSphere Integration Developer 6.0.1 gemeinsam nutzen, steht ebenfalls keine Unterstützung zur Verfügung.

Die folgenden Themen enthalten Konzepte, Referenzinformationen und schrittweise Anleitungen für die Migration nach WebSphere Integration Developer:

Kapitel 2. Frühere Versionen von WebSphere Integration Developer migrieren

Die Migration von früheren Versionen von WebSphere Integration Developer zu WebSphere Integration Developer 6.1 wird unterstützt. Dies wird als Migration von einer Version auf die nächste bezeichnet.

Bei der Migration nach WebSphere Integration Developer 6.1 wird die Basisstruktur der vorhandenen Anwendung mit einer geringfügigen erforderlichen Rekonfiguration beibehalten. Beachten Sie, dass die Migration von einer Version auf die nächste keinen zugeordneten Assistenten aufweist.

Die folgenden Themen enthalten eine weitere Anleitung für den Migrationsprozess von WebSphere Integration Developer von einer Versoin auf die nächste:

Überlegungen für den Migrationsprozess von einer Version auf die nächste

Der größte Teil der Migration von einer früheren Version von WebSphere Integration Developer nach Version 6.1 wird automatisch ausgeführt. Sie müssen jedoch mehrere Aspekte beachten, die möglicherweise eine weitere manuelle Konfiguration erfordern.

Die folgenden Überlegungen sollen Sie beim Migrationsprozess von einer Version auf die nächste unterstützen:

Adapter
Anwendungen, die eine frühere Adapterversion verwenden, können mit einem Dienstprogramm schnell auf die aktuelle Version migriert werden. Weitere Informationen hierzu finden weiter unten unter dem zugehörigen Link zum Abschnitt "Anwendungen mit früheren Adapterversionen migrieren".

CEI-Ereignisse
Die Überwachungsmodelle von WebSphere Integration Developer 6.0.2 können nicht neu erstellt werden, sie können jedoch in WebSphere Integration Developer 6.1 verwendet werden, wenn Sie bereits erstellt wurden.

Editor für Ereignisdefinitionen
Dieser Editor wird in WebSphere Integration Developer 6.1 nicht weiter unterstützt.

XSD Federation
XSD Federation (d. h. die Generierung von XSD-Einschlüssen) wurde in WebSphere Integration Developer 6.1 entfernt. Daher müssen alle alten PIs über alle benötigten XSD-Einschlüsse verfügen, die in der PI eingeschlossen sind. Dies wird automatisch für PIs ausgeführt, die nach WebSphere Integration Developer 6.0.2.x exportiert wurden. Zum Export von PIs aus Version 6.0.1.2 müssen Sie jedoch beim Export explizit das Kontrollkästchen Abgeleitete Dateien einschließen aktivieren.

Primitive 'XSL-Transformation'
In WebSphere Integration Developer 6.1 verfügt das Primitive 'XSL-Transformation' über einen neuen XML-Zuordnungseditor. XML-Zuordnungen, die in einer früheren Version erstellt wurden, müssen auf das neue Format migriert werden, bevor Sie diese bearbeiten können. Weitere Informationen hierzu finden weiter unten unter dem zugehörigen Link zum Abschnitt "Primitive 'XSL-Transformation' migrieren".

Entwicklung und Implementierungsversionsstände

Ihre Entscheidung darüber, welche Versionsstände Sie in Ihrer Umgebung benötigen, hängt von den Versionständen ab, mit denen Ihre Anwendungen entwickelt wurden.

WebSphere Process Server 6.1 und WebSphere Integration Developer 6.1 sind mit früheren Releases wie folgt kompatibel:

Anmerkung: Für i5/OS-Systeme gibt es keine früheren installierten Versionen.

Kapitel 3. Migration von WebSphere InterChange Server nach WebSphere Process Server

Die Migration von WebSphere InterChange Server zu WebSphere Process Server wird durch die folgenden Funktionen in WebSphere Integration Developer unterstützt:

Anmerkung: Angaben zu Einschränkungen, die in diesem Release von WebSphere Process Server mit der Migration verbunden sind, finden Sie in den Release-Informationen.

Die Migration von Quellenartefakten wird zwar unterstützt, aber es empfiehlt sich, zunächst durch intensive Analysen und Tests zu ermitteln, ob die resultierenden Anwendungen in WebSphere Process Server erwartungsgemäß funktionieren oder aber nach der Migration überarbeitet werden müssen. Diese Empfehlung hängt mit den folgenden Einschränkungen hinsichtlich der funktionalen Parität zwischen WebSphere InterChange Server und der vorliegenden Version von WebSphere Process zusammen. In dieser Version von WebSphere Process Server gibt es für die folgenden Funktionen von WebSphere InterChange Server keine äquivalente Unterstützung:

Unterstützte Migrationspfade für WebSphere InterChange Server

WebSphere Process Server-Migrationstools unterstützen die Migration von WebSphere InterChange Server ab Version 4.2.2.

Jedes WebSphere InterChange Server-Release vor Version 4.2.2 muss vor der Migration WebSphere Process Server nach Version 4.2.2 oder 4.3 migriert werden.

Vorbereitung für die Migration von WebSphere InterChange Server

Stellen Sie vor der Migration von WebSphere InterChange Server nach WebSphere Process Server zunächst sicher, dass Sie Ihre Umgebung ordnungsgemäß vorbereitet haben. WebSphere Process Server bietet die für die Migration von WebSphere InterChange Server erforderlichen Tools.

Diese Migrationstools können folgendermaßen aufgerufen werden:

Die Eingabe für die Migrationstools besteht aus einer Repository-JAR-Datei, die aus WebSphere InterChange Server exportiert wurde. Daher müssen Sie vor dem Zugriff auf die Migrationstools mit einer dieser Optionen zunächst Folgendes ausführen:

  1. Stellen Sie sicher, dass Sie eine Version von WebSphere InterChange Server ausführen, die nach WebSphere Process Server migriert werden kann. Siehe das Thema "Unterstützte Migrationspfade für WebSphere InterChange Server".
  2. Exportieren Sie Ihre Quellenartefakte aus WebSphere InterChange Server in eine Repository-Jar-Datei mit dem WebSphere InterChange Server repos_copy-Befehl, wie in der Dokumentation für WebSphere InterChange Server beschrieben. Der Assistent benötigt als Eingabe eine Repository-JAR-Datei von WebSphere InterChange Server. Diese JAR-Datei muss im Bezug auf die Anwendungen, die migriert werden, eigenständig sein. Dies bedeutet, dass alle Artefakte, auf die ein beliebiges Artefakt in der JAR-Datei verweist, ebenfalls in der JAR-Datei enthalten sein müssen. Damit sichergestellt ist, dass die generierte Repository-JAR-Datei eigenständig ist, führen Sie den Befehl repos_copy mit der Option -vr aus, bevor Sie das Server-Repository exportieren. (Dadurch wird das Repository überprüft.). Wenn das Repository gültig ist, schreibt repos_copy die folgende Ausgabe in die Konsole: Validation Succeeded. All Dependencies Resolved. Wenn das Repository ungültig ist, gibt repos_copy eine Liste der Abhängigkeiten aus, die aufgelöst werden müssen. Lösen Sie die Abhängigkeiten auf, bevor Sie das Repository exportieren. Exportieren Sie die Repository-Artefakte, und erstellen Sie die Repository-JAR-Datei, indem Sie den WebSphere InterChange Server-Befehl repos_copy mit der Option -o verwenden. Weitere Informationen zum Export einzelner Komponenten finden Sie in der Dokumentation zu WebSphere InterChange Server 4.3.

Überlegungen für den WebSphere InterChange-Migrationsprozess

Die folgenden Überlegungen sind dazu gedacht, die Entwicklung von Integrationsartefakten für WebSphere InterChange Server zu unterstützen. Wenn Sie anhand dieser Richtlinien vorgehen, können Sie die Migration von Artefakten aus WebSphere InterChange Server zu WebSphere Process Server vereinfachen.

Diese Empfehlungen sollen nur eine Orientierung sein. Es gibt Fälle, in denen es erforderlich ist, von diesen Richtlinien abzuweichen. In solchen Fällen sollten Sie sich so wenig wie möglich von den Richtlinien entfernen, um die zur Migration der Artefakte erforderlichen Nacharbeiten möglichst gering zu halten. Beachten Sie, dass die hier beschriebenen Richtlinien keine allgemeinen Empfehlungen für die Entwicklung von WebSphere InterChange Server-Artefakten sind. Sie beschränken sich vielmehr auf diejenigen Empfehlungen, die eine künftige Migration von Artefakten vereinfachen könnten.

Überlegungen: Allgemeine Entwicklung

Es gibt verschiedene Überlegungen, die für so gut wie die meisten Integrationsartefakte zutreffend sind. Im Allgemeinen werden die Artefakte, die das Funktionsspektrum der Tools nutzen und den durch die Tools umgesetzten Metadatenmodellen entsprechen, problemlos migriert. Artefakte mit deutlichen Erweiterungen und externen Abhängigkeiten hingegen erfordern bei der Migration wahrscheinlich größere manuelle Eingriffe.

Die folgende Liste fasst die Überlegungen für die allgemeine Entwicklung von auf WebSphere InterChange Server basierenden Lösungen zusammen, die die künftige Migration vereinfachen:

Die Integrationslösungen müssen sich unbedingt an das Programmiermodell und an die Architektur halten, die durch WebSphere InterChange Server bereitgestellt werden. Die einzelnen Integrationskomponenten in WebSphere InterChange Server haben in der Architektur klar strukturierte Aufgaben. Deutliche Abweichungen von diesem Modell erschweren die Migration von Inhalt in die entsprechenden Artefakte unter WebSphere Process Server.

Ein weiteres allgemeines Verfahren, das den Erfolg künftiger Migrationsprojekte vergrößert, ist die Dokumentierung des Systementwurfs. Achten Sie darauf, Integrationsarchitektur und -entwurf zu erfassen, einschließlich des funktionalen Entwurfs und der Anforderungen an die Servicequalität (Quality of Service), der gegenseitigen Abhängigkeiten von projektübergreifend genutzten Artefakten und auch der Entwurfsentscheidungen, die während der Implementierung getroffen wurden. Dies vereinfacht die Systemanalyse während der Migration und reduziert gegebenenfalls erforderliche Nacharbeiten.

Bei der Erstellung, Konfiguration und Änderung von Artefaktdefinitionen dürfen nur die bereitgestellten Entwicklungstools verwendet werden. Vermeiden Sie eine manuelle Bearbeitung von Artefaktmetadaten (z. B. die direkte Bearbeitung von XML-Dateien), denn dies kann das Artefakt für die Migration beschädigen.

Befolgen Sie bei der Entwicklung von Java-Code innerhalb von Collaboration-Schablonen, Zuordnungen, Dienstprogrammen für allgemeinen Code und anderen Komponenten die folgenden Richtlinien:

Verwenden Sie für die Artefakte nur die in der Dokumentation veröffentlichten APIs von WebSphere InterChange Server. Diese APIs sind in den Entwicklungshandbüchern zu WebSphere InterChange Server ausführlich beschrieben. Kompatibilitäts-APIs werden in WebSphere Process Server für veröffentlichte WebSphere InterChange Server-APIs bereitgestellt. Obwohl WebSphere InterChange Server über viele interne Schnittstellen verfügt, die Sie verwenden können, wird dieses Verfahren nicht empfohlen, da die künftige Unterstützung dieser Schnittstellen nicht garantiert werden kann.

Vermeiden beim Entwurf von Geschäftslogik und von Umsetzungsregeln in Zuordnungen und in Collaboration-Schablonen nach Möglichkeit Dienstprogrammbibliotheken für allgemeinen Code, die über Felder entwickelt wurden und die als JAR-Datei (Java Archive) in den Klassenpfad von WebSphere InterChange Server aufgenommen werden, da diese manuell migriert werden müssen.

Verwenden Sie den Aktivitätseditor in möglichst großem Umfang. Dies stellt sicher, dass die Logik durch Metadaten beschrieben wird, die einfacher in die neuen Artefakte migriert werden können. Für Operationen, die Sie in den Tools wiederverwenden wollen, sollten Sie möglichst immer die Funktion für die eigenen Objektgruppen verwenden.

In jedem zu entwickelnden Java-Code-Snippet, dessen Entwicklung erforderlich ist, sollte der Code so einfach und so atomar wie möglich sein. Die Qualität des Java-Codes sollte in der Scripterstellung, der Einbeziehung von Basisauswertungen, Operationen und Berechnungen, der Datenformatierung, der Typkonvertierung usw. zum Ausdruck kommen. Wenn eine erweiterte und komplexere Anwendungslogik benötigt wird, sollte die Kapselung der Logik in EJBs erwogen werden, deren Ausführung in WebSphere Application Server erfolgt, und der Aufruf der Logik sollte aus WebSphere InterChange Server heraus über Web-Service-Aufrufe vorgenommen werden. Verwenden Sie JDK-Standardbibliotheken anstelle von Fremdanbieter- oder externen Bibliotheken, die möglicherweise separat migriert werden müssen. Fassen Sie außerdem zusammengehörige Logik in einem einzigen Code-Snippet zusammen, und vermeiden Sie die Verwendung von Logik, wenn sich Verbindungs- und Transaktionskontexte über mehrere Code-Snippets hinweg erstrecken können. Beispielsweise sollte sich bei Datenbankoperationen der Code, der mit dem Anfordern einer Verbindung, dem Starten und Beenden einer Transaktion und dem Freigeben der Verbindung zusammenhängt, in einem einzigen Snippet befinden.

Allgemein muss gewährleistet sein, dass Code, der eine Schnittstelle mit einem unternehmensweiten Informationssystem (Enterprise Information System - EIS) bilden soll, in Adapter und nicht in Zuordnungen oder Collaboration-Schablonen gestellt wird. Dies ist ein empfohlenes Verfahren für den Architekturentwurf. Außerdem werden so Voraussetzungen für Fremdanbieterbibliotheken und zugehörige Überlegungen im Code verringert, beispielsweise die Verbindungsverwaltung und mögliche JNI-Implementierungen (Java Native Interface).

Machen Sie den Code durch Verwendung der passenden Ausnahmebedingungsbehandlung so sicher wie möglich. Achten Sie auch darauf, dass der Code für die Ausführung in einer J2EE-Anwendungsserverumgebung kompatibel ist, auch wenn er gegenwärtig in einer J2SE-Umgebung ausgeführt wird. Halten Sie sich an die J2EE-Entwicklungsverfahren wie z. B. die Vermeidung statischer Variablen, des Startens von Threads und der Platten-E/A. Diese Verfahren sind nicht nur allgemein gut geeignet, sondern sie können die Portierbarkeit verbessern.

Überlegungen: Dienstprogramme für allgemeinen Code

Die Entwicklung von Dienstprogrammbibliotheken für allgemeinen Code sollte zur übergreifenden Nutzung in Integrationsartefakten in der WebSphere InterChange Server-Umgebung nach Möglichkeit vermieden werden. In Situationen, in denen die Wiederverwendung von Code über Integrationsartefakte hinweg erforderlich ist, empfiehlt sich die Nutzung der Funktion für die eigenen Objektgruppen im Aktivitätseditor. In Betracht zu ziehen ist außerdem die Kapselung der Logik in EJBs, deren Ausführung in WebSphere Application Server erfolgt, und der Aufruf der Logik aus WebSphere InterChange Server heraus über Web-Service-Aufrufe.

Es ist zwar möglich, dass einige Dienstprogrammbibliotheken für allgemeinen Code unter WebSphere Process Server einwandfrei ausgeführt werden, für die Migration der angepassten Dienstprogramme sind jedoch Sie zuständig.

Überlegungen: Datenbankverbindungspools

Ein Datenbankverbindungspool von WebSphere InterChange Server innerhalb einer Zuordnung oder einer Collaboration-Schablone wird in WebSphere Process Server als Standard-JDBC-Ressource wiedergegeben. Die Art und Weise, wie Verbindungen und Transaktionen verwaltet werden, kann sich jedoch zwischen WebSphere InterChange Server und WebSphere Process Server unterscheiden. Vermeiden Sie daher, Datenbanktransaktionen über mehrere Java-Snippets hinweg aktiv zu halten.

Benutzerdefinierte Datenbankverbindungspools sind in Zuordnungen und Collaboration-Schablonen zur einfachen Datensuche und auch im Hinblick auf eine ausgereifte prozessinstanzübergreifende Statusverwaltung nützlich. Ein Datenbankverbindungspool in WebSphere InterChange Server wird in WebSphere Process Server als JDBC-Standardressource wiedergegeben, und die grundlegende Funktion ist identisch. Die Art und Weise, wie Verbindungen und Transaktionen verwaltet werden, kann sich jedoch unterscheiden.

Um eine künftige Portierbarkeit zu maximieren, sollten Datenbanktransaktionen über Java-Snippet-Knoten hinweg in einer Collaboration-Schablone oder Zuordnung nicht aktiv bleiben. Beispielsweise sollte sich der Code, der mit dem Anfordern einer Verbindung, dem Starten und Beenden einer Transaktion und dem Freigeben der Verbindung zusammenhängt, in einem einzigen Code-Snippet befinden.

Überlegungen: Geschäftsobjekte

Verwenden Sie für die Entwicklung von Geschäftsobjekten nur die Tools, die zur Konfiguration von Artefakten bereitgestellt werden, verwenden Sie explizite Datentypen sowie Längen für Datenattribute, und verwenden Sie nur die dokumentierten APIs.

Geschäftsobjekte in WebSphere Process Server basieren auf SDOs (Service Data Object - Servicedatenobjekt). SDOs verwenden Datenattribute, die stark typisiert sind. Bei Geschäftsobjekten in WebSphere InterChange Server und Adaptern sind die Datenattribute nicht stark typisiert, und Benutzer geben manchmal Zeichenfolgedatentypen für Datenattribute an, die nicht aus Zeichenfolgen bestehen. Um Probleme bei WebSphere Process Server zu vermeiden, müssen Sie Datentypen explizit angeben.

Da Geschäftsobjekte in WebSphere Process Server möglicherweise zur Laufzeit serialisiert werden, wenn sie zwischen Komponenten übergeben werden, ist es wichtig, die erforderlichen Längen für Datenattribute explizit anzugeben, um die Auslastung der Systemressourcen so gering wie möglich zu halten. Aus diesem Grund sollte beispielsweise für ein Zeichenfolgenattribut nicht die maximale Länge von 255 Zeichen verwendet werden. Auch die Angabe von Attributen ohne Länge, was derzeit einem Standardwert von 255 Zeichen entspricht, ist zu vermeiden. Geben Sie stattdessen die erforderliche Länge für Attribute präzise an.

Für die Namen von Geschäftsobjektattributen gelten in WebSphere Process Server die XSD-NCName-Regeln. Verwenden Sie daher in Namen von Geschäftsobjektattributen keine Leerzeichen oder Doppelpunkte (":"). Namen von Geschäftsobjektattributen, die Leerzeichen oder Doppelpunkte enthalten, sind in WebSphere Process Server ungültig. Benennen Sie Geschäftsobjektattribute vor der Migration um.

Wenn Sie in einem Geschäftsobjekt eine Feldgruppe verwenden, können Sie sich bei der Indexierung der Feldgruppe in Zuordnungen und/oder Beziehungen nicht auf die Reihenfolge der Feldgruppe verlassen. Die Anweisung, die Feldgruppen in WebSphere Process Server migriert, kann die Indexreihenfolge besonders bei gelöschten Einträgen nicht garantieren.

Es ist wichtig, Geschäftsobjektdefinitionen ausschließlich mit dem Entwurfstool für Geschäftsobjekte zu bearbeiten und nur die veröffentlichten APIs für Geschäftsobjekte in Integrationsartefakten zu verwenden.

Überlegungen: Collaboration-Schablonen

Viele der oben beschriebenen Richtlinien, gelten für die Entwicklung von Collaboration-Schablonen.

Um sicherzustellen, dass Prozesse korrekt mit Metadaten beschrieben werden, verwenden Sie zur Erstellung und Änderung von Collaboration-Schablonen immer das Tool 'Process Designer', und vermeiden Sie es, die Metadatendateien manuell zu bearbeiten. Verwenden Sie nach Möglichkeit immer den Aktivitätseditor, um den Einsatz von Metadaten bei der Beschreibung der erforderlichen Logik zu maximieren.

Verwenden Sie in den Collaboration-Schablonen nur die dokumentierten APIs, denn dies hält die bei der Migration möglicherweise erforderliche manuelle Nacharbeit gering. Verwenden Sie keine statischen Variablen. Verwenden Sie stattdessen nicht statische Variablen und Collaboration-Eigenschaften, um die Anforderungen der Geschäftslogik umzusetzen. Vermeiden Sie den Einsatz der Java-Qualifikationsmerkmale 'final', 'transient' und 'native' in Java-Snippets. Diese Qualifikationsmerkmale können in den BPEL-Java-Snippets, die bei der Migration der Collaboration-Schablonen entstehen, nicht umgesetzt werden.

Um die künftige Portierbarkeit zu maximieren, verwenden Sie nach Möglichkeit keine expliziten Aufrufe für die Verbindungsfreigabe und keine expliziten Transaktionsangaben (d. h. explizite COMMIT-Operationen und explizite ROLLBACK-Operationen) für benutzerdefinierte Datenbankverbindungspools. Nutzen Sie stattdessen die containergesteuerte implizite Verbindungsbereinigung und die implizite Transaktionsangabe. Vermeiden Sie des Weiteren Systemverbindungen und Transaktionen, die in einer Collaboration-Schablone über Java-Snippet-Knoten hinweg aktiv sind. Dies gilt für alle Verbindungen zu einem externen System und auch für die benutzerdefinierten Datenbankverbindungspools. Operationen mit einem externen EIS-System sollten innerhalb eines Adapters verwaltet werden, und der Code für Datenbankoperationen sollte in einem einzigen Code-Snippet enthalten sein. Dies kann in einer Collaboration erforderlich sein, die bei der Wiedergabe als BPEL-Geschäftsprozesskomponente möglicherweise als unterbrechbarer Ablauf selektiv implementiert wird. In diesem Fall kann der Prozess aus mehreren separaten Transaktionen zusammengesetzt sein, wobei nur Informationen zum Status und zu globalen Variablen zwischen den Aktivitäten übergeben werden. Der Kontext für alle Systemverbindungen zu zugehörigen Transaktionen, die sich über diese Prozesstransaktionen erstrecken, würde verloren gehen.

Benennen Sie Eigenschaftsnamen von Collaboration-Schablonen entsprechend den W3C-XML-Namenskonventionen für NCName. WebSphere Process Server akzeptiert Namen, die diesen Konventionen entsprechen. In BPEL-Eigenschaftsnamen sind alle unzulässigen Zeichen ungültig, die in Eigenschaftsnamen migriert werden. Benennen Sie vor der Migration Eigenschaften um, damit alle unzulässige Zeichen aus den Namen entfernt werden, um Syntaxfehler in der durch die Migration generierten BPEL zu verhindern.

Verweisen Sie nicht mit 'this' auf Variablen. Verwenden Sie beispielsweise anstelle von 'this.inputBusObj' lediglich 'inputBusObj'.

Verwenden Sie für Variablen die Gültigkeit auf Klassenebene anstelle des Gültigkeitsbereichs für Szenarien. Der Gültigkeitsbereich für Szenarien wird während der Migration nicht weitergeleitet.

Initialisieren Sie alle Variablen, die in Java-Snippets mit einem Standardwert deklariert werden: z. B. mit "Object myObject = null;". Achten Sie darauf, dass vor der Migration alle Variablen während der Deklaration initialisiert werden.

Vergewissern Sie sich, dass die Abschnitte der Collaboration-Schablone, die vom Benutzer geändert werden können, keine Java-Importanweisungen enthalten. Verwenden Sie in der Definition der Collaboration-Schablone die Importfelder, um die zu importierenden Java-Pakete anzugeben.

Legen Sie nicht fest, dass eingehende Geschäftsobjektwerte in der Variablen triggeringBusObj gespeichert werden sollen. In WebSphere InterChange Server ist triggeringBusObj schreibgeschützt, und die zugehörigen Werte können nicht überschrieben werden. Dadurch werden keine Werte eingehender Geschäftsobjekte gespeichert. Wenn als Empfangsvariable für ein eingehendes Geschäftsobjekt bei einem internen Serviceaufruf die Variable triggeringBusObj verwendet wird, ändert sich nach der Migration das Verhalten des internen Serviceaufrufs wie folgt: Innerhalb des BPEL-Prozesses überschreibt der vom internen Serviceaufruf eingehende Wert den Wert, der in triggeringBusObj gespeichert ist.

Überlegungen: Zuordnungen

Viele der für Collaboration-Schablonen bereits beschriebenen Richtlinien gelten auch für Zuordnungen.

Um sicherzustellen, dass Zuordnungen korrekt mit Metadaten beschrieben werden, verwenden Sie zur Erstellung und Änderung von Zuordnungen immer das Zuordnungsentwurfstool, und vermeiden Sie es, die Metadatendateien manuell zu bearbeiten. Verwenden Sie nach Möglichkeit immer den Aktivitätseditor, um den Einsatz von Metadaten bei der Beschreibung der erforderlichen Logik zu maximieren.

Wenn Sie in einer Zuordnung auf untergeordnete Geschäftsobjekte verweisen, verwenden Sie für das untergeordnete Geschäftsobjekt eine untergeordnete Zuordnung.

Vermeiden Sie die Verwendung von Java-Code als 'Wert' in SET, da dies in WebSphere Process Server ungültig ist. Verwenden Sie stattdessen Konstanten. Falls der SET-Wert 'xml version=' + '1.0' + ' encoding=' + 'UTF-8' lautet, wird dies in WebSphere Process Server nicht ausgewertet. Ändern Sie diese Angabe in 'xml version=1.0 encoding=UTF-8', bevor Sie die Migration ausführen.

Verwenden Sie in den Zuordnungen nur die dokumentierten APIs, denn dies hält die bei der Migration möglicherweise erforderliche manuelle Nacharbeit gering. Verwenden Sie keine statischen Variablen. Verwenden Sie stattdessen nichtstatische Variablen. Vermeiden Sie die Verwendung der Java-Qualifikationsmerkmale 'final', 'transient' und 'native' in angepassten Code für Zuordnungen.

Wenn Sie in einem Geschäftsobjekt eine Feldgruppe verwenden, sollten Sie sich bei der Indexierung der Feldgruppe in Zuordnungen nicht auf die Reihenfolge der Feldgruppe verlassen. Die Anweisung, die Feldgruppen in WebSphere Process Server migriert, kann die Indexreihenfolge besonders bei gelöschten Einträgen nicht garantieren.

Um die künftige Portierbarkeit zu maximieren, verwenden Sie nach Möglichkeit keine expliziten Aufrufe für die Verbindungsfreigabe und keine expliziten Transaktionsangaben (d. h. explizite COMMIT-Operationen und explizite ROLLBACK-Operationen) für benutzerdefinierte Datenbankverbindungspools. Nutzen Sie stattdessen die containergesteuerte implizite Verbindungsbereinigung und die implizite Transaktionsangabe. Vermeiden Sie außerdem Systemverbindungen und Transaktionen, die über die Grenzen von Transaktionsknoten hinweg in angepassten Zuordnungsschritten aktiv sind. Dies gilt für alle Verbindungen zu einem externen System und auch für die benutzerdefinierten Datenbankverbindungspools. Operationen mit einem externen EIS-System sollten innerhalb eines Adapters verwaltet werden, und der Code für Datenbankoperationen sollte in einem einzigen angepassten Schritt enthalten sein.

Verwenden Sie in Ihren Zuordnungen keine untergeordneten Klassen. Der Migrationsbefehl (reposMigrate) migriert keine untergeordneten Klassen, und Sie erhalten Fehler, wenn die Zuordnungen solche enthalten. In einem WebSphere InterChange Server-Repository konnte eine untergeordnete Klasse in einem Knoten definiert und von anderen Knoten innerhalb derselben Collaboration-Schablone referenziert werden. In WebSphere Process Server kann eine untergeordnete Klasse, die in einer BPEL-Komponente definiert ist, von keiner anderen Komponente verwendet werden. Auf Grund dieser Einschränkung werden untergeordnete Klassen nicht übersetzt und müssen manuell bearbeitet werden. Die empfohlenen Änderungen umfassen Folgendes: Der Code der untergeordneten Klasse wird als externe Klasse in ein Paket gestellt, oder die Deklaration für untergeordnete Klasse wird entfernt. Dadurch werden etwaige Fehler behoben, und der Code wird nach Bedarf über die gesamte BPEL hinweg platziert.

Überlegungen: Beziehungen

Denken Sie bei Beziehungen daran, dass Beziehungsdefinitionen zwar für die Verwendung in WebSphere Process Server migriert werden können, das Beziehungstabellenschema und die Instanzdaten jedoch möglicherweise von WebSphere Process Server wiederverwendet und außerdem von WebSphere InterChange Server und WebSphere Process Server gleichzeitig gemeinsam genutzt werden können.

Verwenden Sie für Beziehungen nur die Tools, die zur Konfiguration der zusammengehörigen Komponenten bereitgestellt werden, und verwenden Sie für Beziehungen innerhalb von Integrationsartefakten nur veröffentlichte APIs.

Verwenden Sie zur Bearbeitung von Beziehungsdefinitionen nur das Tool 'Relationship Designer'. Außerdem sollte nur WebSphere InterChange Server die Konfiguration des Beziehungsschemas ermöglicht werden, das bei der Implementierung von Beziehungsdefinitionen automatisch generiert wird. Ändern Sie das Beziehungstabellenschema nicht direkt mit Datenbanktools oder SQL-Prozeduren.

Falls Sie Beziehungsinstanzdaten im Beziehungstabellenschema ändern müssen, achten Sie außerdem darauf, die von Beziehungsmanager bereitgestellten Funktionen zu verwenden.

Verwenden Sie für Beziehungen innerhalb von Integrationsartefakten nur die veröffentlichten APIs.

Überlegungen: Zugriffs-Framework-Clients

Entwickeln Sie keine neuen Clients, die die APIs der CORBA-IDL-Schnittstelle übernehmen. Dies wird in WebSphere Process Server nicht unterstützt.

Überlegungen: Datenbankkonflikte verhindern

Sie können Datenbankkonflikte verhindern, indem Sie Ereignisse so planen, dass sie mit mindestens zwei Sekunden Abstand auftreten.

Wenn eine migrierte Anwendung verursacht, dass bei WebSphere Business Integration-Komponenten gleichzeitig mehrere Ereignisse auftreten, können Datenbankkonflikte oder Deadlocks auftreten. Diese treten auf, wenn WebSphere Process Server Application Scheduler (AppScheduler) plant, mehrere Ereignisse genau gleichzeitig auszuführen. Bei Auftreten eines Deadlocks wird für das Ereignis, das diesen verursacht, ein Rollback ausgeführt, und das Ereignis wird sobald wie möglich wiederholt. Dieser zyklische Vorgang wird fortgesetzt, bis die einzelnen Threads, die auf die Datenbank zuzugreifen versuchen, die Datenbank erfolgreich aktualisiert haben.

Beispiel:

AppScheduler E com.ibm.wbiserver.scheduler.AppSchedulerMB process CWLWS0021E: 
The AppSchedulerMB.process method has generated an exception.
WSRdbXaResour E DSRA0304E: XAException occurred. XAException contents and details are:
The DB2 Error message is : Error executing a XAResource.end(), Server returned
XA_RBDEADLOCK The DB2 Error code is : -4203
The DB2 SQLState is : null  

Sie können dies vermeiden, indem Sie die Ereignisse so planen, dass diese in ausreichend großem Abstand voneinander auftreten, so dass keine Deadlocks auftreten. Planen Sie die Ereignisse in mindestens zwei Sekunden Abstand. Die erforderliche Zeitspanne variiert jedoch in Abhängigkeit von weiteren Bedingungen in Ihrer Umgebung, die sich auf die Leistung auswirken, z. B. der Datenbankgröße, der Hardware, der Übertragungsgeschwindigkeit und sonstigen Einflussgrößen.

Überlegungen: Nach der Migration

Wenn Anwendungen von WebSphere InterChange Server nach WebSphere Integration Developer oder nach WebSphere Process Server migriert wurden, müssen Sie in einigen Bereichen mehr Aufmerksamkeit darauf verwenden, dass migrierte Anwendungen in WebSphere Integration Developer und in WebSphere Process Server konsistent mit der zugehörigen gewünschten Funktion arbeiten, da Unterschiede bei der Architektur für WebSphere InterChange Server bestehen.

Weitere Informationen zu Überlegungen nach der Migration finden Sie im Abschnitt Überlegungen nach der Migration.

Migration von WebSphere InterChange Server unter Verwendung des Migrationsassistenten

Verwenden Sie den WebSphere Integration Developer-Migrationsassistenten zur Migration Ihrer vorhandenen WebSphere InterChange Server-Artefakte.

Führen Sie die folgenden Schritte aus, um den Migrationsassistenten für die Migration Ihrer WebSphere InterChange Server-Artefakte zu verwenden:

  1. Wählen Sie die Optionen Datei -> Importieren -> Geschäftsintegration -> WebSphere InterChange Server - JAR-Datei aus, und klicken Sie auf Weiter, um den Assistenten aufzurufen:
    Importauswahl für WebSphere InterChange Server-JAR-Datei
    Sie können den Migrationsassistenten auch auf der Begrüßungsseite öffnen, indem Sie auf das Symbol Benutzer von Vorversionen Benutzer von Vorversionen klicken, um die Seite Benutzer von Vorversionen zu öffnen. (Sie können jederzeit zur Begrüßungsseite zurückkehren, indem Sie auf die Optionen Hilfe -> Willkommen klicken.)
    Seite 'Benutzer von Vorversionen'
    Klicken Sie auf der linken Seite der Seite 'Benutzer von Vorversionen' auf Migration, um die Seite Migration zu öffnen. Wählen Sie auf der Seite Migration die Option Ein WebSphere ICS-Repository migrieren. Seite 'Migration' mit ausgewählter Option 'Ein WebSphere ICS-Repository migrieren'
  2. Der Migrationsassistent wird geöffnet. Geben Sie den Namen der Quellendatei im Feld Quellenauswahl durch Klicken auf die Schaltfläche Durchsuchen und Navigieren zur Datei ein. Geben Sie den Bibliotheksnamen in das entsprechende Feld ein. Wenn die gemeinsam genutzte Bibliothek derzeit im Arbeitsbereich nicht vorhanden ist, muss Sie durch Klicken auf Neu... erstellt werden. Klicken Sie auf Weiter:
    ICS-Migrationsassistent
  3. Das Migrationsoptionenfenster wird geöffnet. Darin können Sie die Standardeinstellungen für die Migration akzeptieren oder die Option ändern, indem Sie ein Kontrollkästchen auswählen:
    Migrationsoptionen
    In der folgenden Tabelle sind die verfügbaren Migrationsoptionen aufgeführt:
    Option Bezeichnung
    Bei Java-Parsing-Fehlern Warnung ausgeben (Optional) Standardmäßig schlägt die Migration eines einzelnen Artefakts fehl, falls ein Java-Konvertierungfehler gefunden wird. Wenn diese Option festgelegt ist, werden alle Java-Konvertierungfehler nur als Warnungen behandelt, und das Artefakt wird so gut es möglich ist konvertiert.
    Migration bei erstem Fehler stoppen (Optional) Standardmäßig setzt der Migrationsassistent die Verarbeitung der verbleibenden Artefakte in der JAR-Datei fort, falls während der Verarbeitung eines bestimmten Artefakts ein Fehler gefunden wird. Wenn diese Option festgelegt ist, wird die Verarbeitung gestoppt, sobald ein Fehler erkannt wird. Das Artefakt mit dem Fehler und alle darauf folgenden Artefakte werden nicht verarbeitet.
    Schleifenauflösung für Collaboration-Schablone verwenden (Optional) Fordert an, dass alle Schleifen in der Collaboration-Schablone beibehalten werden sollen. Wenn diese Option nicht vorhanden ist, wird für die Migration als Standardeinstellung die Schleifenauflösung verwendet.
    Ereignisfolgenerstellung aktivieren (Optional) Fordert die Aktivierung der Ereignisfolgenerstellung für alle Asynchronous WSDL-Methoden an. Wenn diese Option nicht vorhanden ist, wird gemäß Standardeinstellung für die Migration die Ereignisfolgenerstellung für WSDL-Methoden nicht nicht aktiviert.
    Standardschablone verwenden (Optional) Fordert an, dass alle Assembly-Editor-Schablonen im angegebenen Verzeichnis geladen und für die Konvertierung von XML in Java verwendet werden sollen. Gemäß Standardeinstellung für diese Eigenschaft wir nur die Standardschablone für den Assembly-Editor Version 4.3.3 für die Konvertierung von XML in Java verwendet.
  4. Klicken Sie auf Fertig stellen.

Ein Fortschrittsanzeiger unten im Migrationsdialog zeigt den Fortschritt der Migration an. Nach Beendigung des Migrationsprozesses wird der Migrationsdialog nicht mehr angezeigt, und das Fenster Migrationsergebnisse wird geöffnet.

WebSphere InterChange Server-Migration überprüfen

Wenn während der Migration der WebSphere InterChange Server-Jar-Datei keine Fehler angezeigt werden, war die Migration der Artefakte erfolgreich. Wenn die Migration nicht erfolgreich abgeschlossen wurde, wird eine Liste mit Fehlernachrichten, Warnungen und/oder Informationsnachrichten angezeigt. Sie können diese Nachrichten zur Überprüfung der WebSphere InterChange Server-Migration verwenden.

Anmerkung: Durch die Komplexität der Migration von WebSphere InterChange Server zu WebSphere Process Server wird Ihnen dringend empfohlen, extensive Tests der resultierenden Anwendungen, die in WebSphere Process Server ausgeführt werden, durchzuführen, bevor sie in Produktion gegeben werden, um die erwartete Funktionsweise sicherzustellen.

Die folgende Seite wird angezeigt, wenn während des Migrationsprozesses Migrationsnachrichten generiert wurden:

Fenster 'Migrationsergebnisse'

Im Fenster Migrationsergebnisse wird eine Liste mit den Migrationsnachrichten angezeigt, die während des Migrationsprozesses generiert wurden. Wenn Sie eine Nachricht in der oberen Nachrichtenliste auswählen, werden im unteren Nachrichtenbeschreibungsfenster weitere Informationen zu dieser Nachricht angezeigt.

Sollen sämtliche Nachrichten zu Referenzzwecken gespeichert werden, klicken Sie auf die Schaltfläche ToDo's generieren, um eine Liste unerledigter Aufgaben in der Ansicht für Tasks zu erstellen. Sie können auch Speichern als... auswählen, um die Nachrichten in einer Textdatei im Dateisystem zu speichern. Zur Anzeige der generierten Aufgabenliste klicken Sie auf die Optionen Fenster -> Ansicht anzeigen -> Andere -> Allgemein -> Tasks und auf OK. Die Ansicht Tasks wird geöffnet. Darin sehen Sie die aus dem Migrationsprozess generierte Aufgabenliste.

Migrationsfehler von WebSphere InterChange Server beheben

Wenn Ihre Migration vonWebSphere InterChange Server fehlschlägt, gibt es zwei Möglichkeiten, mit diesen Fehlschlägen umzugehen.

Anmerkung: Möglicherweise ziehen Sie die erste Option vor, da Sie sich anfangs mit WebSphere InterChange Server besser auskennen. Wenn Sie jedoch mehr Erfahrungen mit WebSphere Process Server und seinen neuen Artefakten sammeln, möchten Sie die migrierten Artefakte in WebSphere Integration Developer möglicherweise reparieren.
  1. Wenn die Art des Fehlers es erlaubt, können Sie die WebSphere InterChange Server-Artefakte mit dem WebSphere InterChange Server-Toolset anpassen, die jar-Datei erneut exportieren und die Migration erneut versuchen.
  2. Sie können alle Fehler in den resultierenden WebSphere Process Server-Artefakten durch Bearbeiten der Artefakte in WebSphere Integration Developer korrigieren.

Durch Migrationstools verarbeitete WebSphere InterChange Server-Artefakte

Die Migrationstools können einige der Artefakte von WebSphere InterChange Server automatisch migrieren.

Die Migration ist bei den folgenden Artefakten möglich:

Die Migrationstools erstellen ein Jython-Script, das zusammen mit dem Befehlszeilentool wsadmin zum automatischen Konfigurieren von Ressourcen in WebSphere Process Server für die folgenden WebSphere InterChange Server-Artefakte/Ressourcen verwendet werden kann:

Die folgenden WebSphere InterChange Server-Artefakte werden von den Migrationstools nicht verarbeitet:

Unterstützte WebSphere InterChange Server-APIs

Neben den Migrationstools für WebSphere InterChange Server-Quellenartefakte, die in WebSphere Process Server und WebSphere Integration Developer bereitgestellt werden, gibt es eine Unterstützung für viele APIs, die in WebSphere InterChange Server zur Verfügung standen. Die Migrationstools arbeiten mit diesen WebSphere InterChange Server-APIs zusammen, indem sie den angepassten Snippet-Code bei der Migration so weit wie möglich erhalten.

Anmerkung: Diese APIs werden nur zur Unterstützung von migrierten WebSphere InterChange Server-Anwendungen bereitgestellt, bis diese für die Verwendung der neuen Process Server-APIs geändert werden können.

Die unterstützten WebSphere InterChange Server-APIs in Process Server sind in Folgenden aufgelistet. Diese APIs bieten in WebSphere Process Server Funktionen, die den Funktionen ähneln, die sie in WebSphere InterChange Server bereitstellen. Funktionsbeschreibungen dieser APIs finden Sie in der Dokumentation von WebSphere InterChange Server.

CwBiDiEngine
AppSide_Connector/

JavaConnectorUtil
AppSide_Connector/

JavaConnectorUtilDH
datahandler/
wbi/
ibm/
com/

BusObj
Collaboration/

BusObjArray
Collaboration/

BaseDLM
DLM/

CwDBConnection
CwDBConnection/
CxCommon/

CwDBConstants
CwDBConnection/
CxCommon/

CwDBStoredProcedureParam
CwDBConnection/
CxCommon/

DataHandler (Abstract Class)
DataHandlers/
crossworlds/
com/

NameHandler (Abstract Class)
DataHandlers/
crossworlds/
com/

ConfigurationException (extends java.lang.Exception)
Exceptions/
DataHandlers/
crossworlds/
com/

MalformedDataException (extends java.lang.Exception)
Exceptions/
DataHandlers/
crossworlds/
com/

NotImplementedException (extends java.lang.Exception)
Exceptions/
DataHandlers/
crossworlds/
com/

BusinessObjectInterface
CxCommon/

CxObjectAttr
CxCommon/

CxObjectContainerInterface
CxCommon/

DtpConnection
Dtp/
CxCommon/

DtpDataConversion
Dtp/
CxCommon/

DtpDate
Dtp/
CxCommon/

DtpMapService
Dtp/
CxCommon/

DtpSplitString
Dtp/
CxCommon/

DtpUtils
Dtp/
CxCommon/

BusObjInvalidVerbException (extends InterchangeExceptions)
Exceptions/
CxCommon/

IdentityRelationship
relationship/
utilities/
crossworlds/
com/

MapExeContext
Dtp/
CxCommon/

Participant
RelationshipServices/
Server/

Relationship
RelationshipServices/
Server/

UserStoredProcedureParam
Dtp/
CxCommon/

BaseCollaboration
Collaboration/

CxExecutionContext
CxCommon/

CollaborationException
Collaboration/

Filter
crossworlds/
com/

Globals
crossworlds/
com/

SmartCollabService
crossworlds/
com/

StateManagement
crossworlds/
com/

EventKeyAttrDef
EventManagement/
CxCommon/

EventQueryDef
EventManagement/
CxCommon/

FailedEventInfo
EventManagement/
CxCommon/

WebSphere Process Server-DataObject aus WebSphere InterChange Server-XML zuordnen

Falls Sie die Verbindung zu WebSphere Process Server mit den traditionellen Adaptern herstellen, können Sie anhand des folgenden Algorithmus genauer nachvollziehen, wie das WebSphere Process Server-DataObject aus der WebSphere InterChange Server-XML erstellt wurde. Diese Informationen erläutern, wo die Datenwerte platziert wurden und welche Datenwerte als Ersatz für die in WebSphere InterChange Server verwendeten Datenwerte gewählt wurden.

Allgemeine Informationen

Ladevorgänge

Beim Laden wird eine Laufzeit-XML von WebSphere InterChange Server in eine BusinessGraph AfterImage-Instanz von WebSphere Business Integration geladen.

Speichervorgänge

Beim Speichern wird eine BusinessGraph AfterImage-Instanz von WebSphere Business Integration in einer Laufzeit-XML von WebSphere InterChange Server gespeichert. Falls das eingegebene BusinessGraph kein AfterImage ist, wird eine Ausnahmebedingung ausgelöst.

Attributverarbeitung

Kapitel 4. Migration von WebSphere MQ Workflow nach WebSphere Integration Developer

WebSphere Integration Developer bietet die für die Migration von WebSphere MQ Workflow notwendigen Tools.

Der Migrationsassistent ermöglicht Ihnen die Konvertierung von FDL-Definitionen von Geschäftsprozessen, die Sie aus der Buildtime-Komponente von WebSphere MQ Workflow in entsprechende Artefakte in WebSphere Integration Developer exportiert haben. Die generierten Artefakte enthalten XML-Schema-Definitionen für Geschäftsobjekte, WSDL-Definitionen, BPEL, Import- und Komponentendefinitionen sowie TEL-Definitionen.

Das Konvertierungstool erfordert eine semantisch komplette FDL-Definition eines Prozessmodells, das Sie aus WebSphere MQ Workflow Buildtime mit der Option tief exportieren exportieren. Diese Option stellt sicher, dass alle notwendigen Daten, Programme und Unterprozess-Spezifikationen enthalten sind. Stellen Sie außerdem sicher, dass alle benutzerdefinierten Prozessausführungs-Serverdefinitionen (UPES), auf die in Ihrem WebSphere MQ Workflow-Prozessmodell verwiesen wird, auch ausgewählt werden, wenn Sie FDL aus WebSphere MQ Workflow Buildtime exportieren.

Anmerkung: Der Migrationsassistent beinhaltet nicht die Migration von:

Weitere Informationen zur Migration unter Verwendung des FDL2BPEL-Konvertierungstools finden Sie auf der WebSphere MQ Workflow-Unterstützungssite.

Vorbereitung für die Migration von WebSphere MQ Workflow

Vor der Migration von WebSphere MQ Workflow nach WebSphere Integration Developer, stellen Sie sicher, dass Sie Ihre Umgebung ordnungsgemäß vorbereitet haben.

Der Geltungsbereich und die Vollständigkeit der Zuordnung hängt davon ab, wie genau Sie den folgenden Migrationsrichtlinien folgen:

Der Migrationsassistent erstellt syntaktisch korrekte Geschäftsprozesseditoranweisungen, selbst für WebSphere MQ Workflow-Anweisungen, die nicht migriert werden können (PEA- oder PES-Programmaktivitäten, bestimmte dynamische Mitarbeiterzuordnungen usw.), die manuell an ausführbare Geschäftsprozesseditorartefakte angepasst werden müssen.

In der folgenden Tabelle werden die angewendeten Zuordnungsregeln aufgelistet:

Tabelle 2. Zuordnungsregeln
WebSphere MQ Workflow WebSphere Integration Developer
Prozess Process with execution mode: longRunning; Partner links für eingehende und ausgehende Schnittstellen des Prozesses
Quelle und Datensenke Variables für Prozesseingabe und Prozessausgabe; Receive und Reply-Aktivität
Program-Aktivität Invoke-Aktivität
Process-Aktivität Invoke-Aktivität
Leervorgang FMCINTERNALNOOP-Aktivität
Block Geltungsbereich mit eingebetteten BPEL-Aktivitäten
Exit-Bedingung von Aktivität While-Aktivität (unter Einschluss der aktuellen Aktivität)
Startbedingung der Aktivität Verknüpfungsbedingung der Aktivität
Mitarbeiterzuordnung der Aktivität Human Task-Aktivität
Eingabecontainer und Ausgabecontainer der Aktivität Variables zur Angabe der Ein-/Ausgabe der invoke-Aktivität
Steuerungsstecker; Übergangsbedingung Link; Übergangsbedingung
Datenstecker Assign-Aktivität
Globaler Datencontainer Variable
Anmerkung: Sie sollten den Migrationsprozess wenn möglich zunächst mit kleinen Projekten beginnen. Der Migrationsassistent vereinfacht die Konvertierung Ihrer WebSphere MQ Workflow-Prozessmodelle in Geschäftsprozesseditor-Prozessmodelle, bedenken Sie jedoch, dass die Prozesse nicht eins-zu-eins zugeordnet werden können, da Sie ein neues Programmiermodell erstellen. Die semantischen Geltungsbereiche der zugrundeliegenden Prozess-Spezifikationssprachen (FDL und BPEL) haben einen gemeinsamen Schnittpunkt, überschneiden sich jedoch nicht vollständig. Ansonsten hätte der Geschäftsprozesseditor keine neuen Vorteile zu bieten. Web-Services stellen eine vielversprechende neue Technologie dar, die den Ersatz veralteter Lösungen mit neuen anbieten.

Sie sollten die generierten Artefakte generell immer überprüfen und wenn nötig modifizieren. Möglicherweise sind zusätzliche Anstrengungen nötig, eine erfolgreiche Migration entweder zu ermöglichen oder die Migrationstask abzuschließen.

Migration von WebSphere MQ Workflow unter Verwendung des Migrationsassistenten

Der Migrationsassistent ermöglicht Ihnen die Konvertierung von FDL-Definitionen von Geschäftsprozessen, die Sie aus der Buildtime-Komponente von WebSphere MQ Workflow in entsprechende Artefakte in WebSphere Integration Developer exportiert haben. Die generierten Artefakte enthalten XML-Schema-Definitionen für Geschäftsobjekte, WSDL-Definitionen, BPEL, Import- und Komponentendefinitionen sowie TEL-Definitionen.

Anmerkung: Der Migrationsassistent beinhaltet nicht die Migration von:

Führen Sie die folgenden Schritte aus, um den Migrationsassistenten für die Migration Ihrer WebSphere MQ Workflow-Artefakte zu verwenden:

  1. Wählen Sie die Optionen Datei -> Importieren -> Geschäftsintegration -> WebSphere MQ Workflow - FDL-Datei aus, und klicken Sie auf Weiter, um den Assistenten aufzurufen:
    Importauswahl für WebSphere MQ Workflow - FDL-Datei
    Sie können den Migrationsassistenten auch auf der Begrüßungsseite öffnen, indem Sie auf das Symbol Benutzer von Vorversionen Benutzer von Vorversionen klicken, um die Seite Benutzer von Vorversionen zu öffnen. Sie können jederzeit zur Begrüßungsseite zurückkehren, indem Sie auf die Optionen Hilfe -> Willkommen klicken.)
    Seite 'Benutzer von Vorversionen'
    Klicken Sie auf der linken Seite der Seite 'Benutzer von Vorversionen' auf Migration, um die Seite Migration zu öffnen. Wählen Sie auf der Seite Migration die Option Einen WebSphere MQ Workflow-Prozess migrieren. Seite 'Migration' mit ausgewählte Option 'Einen WebSphere MQ Workflow-Prozess migrieren'
  2. Der Migrationsassistent wird geöffnet. Geben Sie den absoluten Pfad und den Namen der FDL-Datei in das Feld 'Quellenauswahl' ein, oder klicken Sie auf die Schaltfläche Durchsuchen, um zu dieser Datei zu navigieren. Geben Sie den Modulnamen in das entsprechende Feld ein (die Eingabe eines Modulnamens ist erforderlich, um den Vorgang fortsetzen zu können). Klicken Sie auf Weiter:
    FDL-Migrationsassistent
  3. Die Seite mit den Migrationsoptionen wird geöffnet. Hier können Sie die Migrationsstandardeinstellungen akzeptieren oder ein Kontrollkästchen zum Ändern der Option auswählen. Durch Auswahl des Kontrollkästchens Namensunverträglichkeiten als Fehler behandeln können Sie das automatische Hinzufügen von Suffixen verhindern, was zu Interoperabilitätsfehlern führen könnte. Das Kontrollkästchen Vordefinierte Datenmember initialisieren fügt zusätzliche Knoten zum Prozess hinzu, um die vordefinierten Datenmember zu initialisieren:
    Seite 'WebSphere MQ Workflow - Migrationsoptionen'
  4. Klicken Sie auf Fertig stellen.

Ein Fortschrittsanzeiger unten im Migrationsdialog zeigt den Fortschritt der Migration an. Nach Beendigung des Migrationsprozesses wird der Migrationsdialog nicht mehr angezeigt, und das Fenster Migrationsergebnisse wird geöffnet:

Seite für WebSphere MQ Workflow-Migrationsergebnisse

WebSphere MQ Workflow Migration überprüfen

Wenn bei der Durchführung der Migration eine Liste mit Fehlernachrichten, Warnungen und/oder Informationsnachrichten generiert wurde, wird diese Liste im Fenster mit den Migrationsergebnissen angezeigt. Andernfalls wird das Fenster mit dem Assistenten geschlossen, falls die Migration ausgeführt wurde.

Die folgende Seite wird angezeigt, wenn während des Migrationsprozesses Migrationsnachrichten generiert wurden:

Fenster 'Migrationsergebnisse'

Im Fenster Migrationsergebnisse wird eine Liste mit Migrationsnachrichten angezeigt, die während des Migrationsprozesses generiert wurden. Wenn Sie eine Nachricht in der oberen Nachrichtenliste auswählen, werden im unteren Nachrichtenbeschreibungsfenster weitere Informationen zu dieser Nachricht angezeigt.

Sollen sämtliche Nachrichten zu Referenzzwecken gespeichert werden, klicken Sie auf die Schaltfläche ToDo's generieren, um eine Liste unerledigter Aufgaben in der Ansicht für Tasks zu erstellen. Sie können auch Speichern als... auswählen, um die Nachrichten in einer Textdatei im Dateisystem zu speichern. Zur Anzeige der generierten Aufgabenliste klicken Sie auf die Optionen Fenster -> Ansicht anzeigen -> Andere -> Allgemein -> Tasks und auf OK. Die Ansicht Tasks wird geöffnet. Darin sehen Sie die aus dem Migrationsprozess generierte Aufgabenliste.

Einschränkungen des Migrationsprozesses (von WebSphere MQ Workflow)

Es gibt bestimmte Einschränkungen für den WebSphere MQ Workflow-Migrationsprozess.

Kapitel 5. Migration von Quellenartefakten zu WebSphere Integration Developer von WebSphere Studio Application Developer Integration Edition

Quellenartefakte können von WebSphere Studio Application Developer Integration Edition zu WebSphere Integration Developer migriert werden. Die Migration von Quellenartefakten in eine Anwendung erfordert eine Migration zum neuen WebSphere Integration Developer-Programmiermodell, so dass neue Funktionalitäten und Funktionen verwendet werden können. Die Anwendung kann daraufhin in WebSphere Process Server neu implementiert und installiert werden.

Viele der in WebSphere Business Integration Server Foundation 5.1 verfügbaren Funktionen sind nach unten auf den WebSphere-Basisanwendungsserver 6.x verschoben worden. Tipps zur Migration dieser Funktionen finden Sie in folgendem Abschnitt: Tips for migrating programming model extensions (Tipps für die Migration von Programmiermodellerweiterungen).

Zur kompletten Migration eines WebSphere Studio Application Developer Integration Edition-Serviceprojekts müssen drei wichtige Tasks erfüllt werden:

  1. Quellenartefakte für die Migration vorbereiten. Diese Aktionen müssen möglicherweise in WebSphere Studio Application Developer Integration Edition ausgeführt werden.
  2. Verwenden Sie den Migrationsassistenten oder dass Befehlszeilenscript WSADIEServiceProjectMigration zur automatischen Migration dieser Artefakte nach dem Geschäftsintegrations-Modulprojekt.
  3. Verwenden Sie den WebSphere Integration Developer für den manuellen Abschluss dieser Migration. Dies schließt das Korrigieren von Java-Code ein, der nicht automatisch migriert werden konnte, sowie das Prüfen der Neuvernetzung von Artefakten.

Anmerkung: Die Laufzeitmigration (Upgradepfad) wird in WebSphere Process Server 6.x nicht zur Verfügung gestellt; daher ist dieser Quellenartefakt-Migrationspfad die einzige Option für die Migration der WebSphere Studio Integration Edition-Serviceprojekte in 6.x.

Unterstützte Migrationspfade für die Migration von Quellenartefakten

Vor Beginn der Migration von Quellenartefakten von WebSphere Studio Application Developer Integration Edition, überprüfen Sie die unterstützten Migrationspfade, die von WebSphere Integration Developer unterstützt werden.

Der Migrationsassistent bietet die Möglichkeit der Migration eines WebSphere Studio Application Developer Integration Edition Version 5.1 (oder höher) -Serviceprojekts zur Zeit. Es wird kein kompletter Arbeitsbereich migriert.

Der Migrationsassistent migriert keine Anwendungs-Binaries - er migriert nur Quellenartefakte, die in einem WebSphere Studio Application Developer Integration Edition-Serviceprojekt enthalten sind.

Quellenartefakte für die Migration vorbereiten

Stellen Sie vor der Migration von Quellenartefakten zu WebSphere Integration Developer von WebSphere Studio Application Developer Integration Edition sicher, dass Sie Ihre Umgebung ordnungsgemäß vorbereitet haben.

In den folgenden Schritten wird beschrieben, wie Sie Ihre Umgebung vor der Migration von Quellenartefakten zu WebSphere Integration Developer von WebSphere Studio Application Developer Integration Edition vorbereiten:

  1. Stellen Sie vor der Migration sicher, dass Sie über eine Sicherungskopie des gesamten 5.1 Arbeitsbereichs verfügen.
  2. Die beste Möglichkeit für die Migration der nicht-WBI-spezifischen Projekte in Ihren Arbeitsbereich können Sie anhand der Informationen bestimmen, die Sie im Abschnitt zur Migration im Rational Application Developer Information Center finden: Migrating from WebSphere Studio V5.1, 5.1.1, or 5.1.2 (Migration von WebSphere Studio V5.1, 5.1.1 oder 5.1.2 durchführen).
  3. Hintergrundinformationen zur Web-Service-Funktionalität in Rational Application Developer finden Sie im Abschnitt zu den Web-Services im Rational Application Developer Information Center unter Developing Web services (Web-Services entwickeln)
  4. Stellen Sie sicher, dass alle geeigneten WebSphere Integration Developer-Funktionen aktiviert sind. Wenn diese Funktionen bei Ihnen nicht aktiviert sind, können Sie möglicherweise nicht alle Menüoptionen sehen, die unten beschrieben werden. So aktivieren Sie die wichtigen Funktionen:
  5. Verwenden Sie ein neues Arbeitsbereichsverzeichnis für WebSphere Integration Developer. Es wird abgeraten, WebSphere Integration Developer in einem alten WebSphere Studio Application Developer Integration Edition-Arbeitsbereich zu öffnen, der Serviceprojekte enthält, da diese Projekte zunächst in ein Format migriert werden müssen, das von WebSphere Integration Developer gelesen werden kann. Die empfohlenen Schritte für diese Vorgehensweise sind Folgende:
    1. Kopieren Sie alle Nicht-Serviceprojekte aus dem alten in den neuen Arbeitsbereich. Kopieren Sie nicht die mit 5.1 erstellten EJB-, Web- und EAR-Projekte, wenn Implementierungscode für ein 5.1-Serviceprojekt erstellt wurde. Der neue 6.x-Implementierungscode wird automatisch neu generiert, wenn das BI-Modul erstellt wird.
    2. Öffnen Sie WebSphere Integration Developer im leeren Arbeitsbereich, und importieren Sie alle Nicht-Serviceprojekte durch Klicken auf Datei -> Importieren -> Allgemein -> Vorhandenes Projekt in Arbeitsbereich. Wählen Sie die Projekte, die Sie in den neuen Arbeitsbereich kopiert haben.
      • Wenn es sich beim Projekt um ein J2EE-Projekt handelt, sollten Sie es durch Verwendung des Rational Application Developer-Migrationsassistenten auf die Ebene von 1.4 migrieren:
        1. Klicken Sie mit der rechten Maustaste auf das Projekt, und wählen Sie die Option Migration -> J2EE-Migrationsassistent....
        2. Überprüfen Sie die Warnmeldungen auf der ersten Seite, und klicken Sie auf Weiter, sofern nichts anderes angegeben ist.
        3. Stellen Sie sicher, dass das J2EE-Projekt in der Projektliste markiert ist. Lassen Sie Projektstruktur migrieren und J2EE-Spezifikationsebene markiert. Wählen Sie J2EE-Version 1.4 und Zielserver WebSphere Process Server v6.1 aus.
        4. Wählen Sie alle sonstigen Optionen, die für Ihr J2EE-Projekt geeignet sind, und klicken Sie auf Fertig stellen. Wenn dieser Schritt erfolgreich abgeschlossen wird, wird folgende Nachricht angezeigt Migration erfolgreich abgeschlossen.
        5. Wenn nach der Migration Fehler im J2EE-Projekt vorhanden sind, entfernen Sie alle Klassenpfadeinträge, die auf V5 .jar-Dateien oder Bibliotheken verweisen und fügen Sie stattdessen die JRE-Systembibliothek und die WPS-Serverziel-Bibliotheken zum Klassenpfad hinzu (unten beschrieben). Dadurch sollten die meisten bzw. alle Fehler gelöst werden.
      • Bei WebSphere Business Integration EJB-Projekten mit erweiterter Nachrichtenübertragung (CMM) oder Container Managed Persistence over Anything (CMP/A) müssen die IBM EJB-Deskriptordateien mit der Erweiterung JAR migriert werden, nachdem das 5.1 Projekt in den Arbeitsbereich 6.x importiert wurde. Weitere Informationen finden Sie in "Migration vonWebSphere-Geschäftsintegrations-EJB-Projekten".
      • Fixieren Sie den Klassenpfad für jedes in den Arbeitsbereich importierte Nicht-Serviceprojekt. Um die Bibliotheken von JRE und WebSphere Process Server zum Klassenpfad hinzuzufügen, klicken Sie mit der rechten Maustaste auf das importierte Projekt und wählen Eigenschaften aus. Gehen Sie zum Eintrag Java-Erstellungspfad und wählen Sie die Registerkarte Bibliotheken. Gehen Sie danach folgendermaßen vor:
        1. Wählen Sie die Optionen Bibliothek hinzufügen -> JRE-Systembibliothek -> Alternative JRE - WPS-Server V6.1 JRE -> Fertig stellen.
        2. Wählen Sie daraufhin Bibliothek hinzufügen -> Ziel des WPS-Servers -> Klassenpfad des WPS-Servers konfigurieren' -> Fertig stellen.
  6. WebSphere Integration Developer generiert den Implementierungscode standardmäßig bei der Erstellung.
  7. Um die .bpel-Dateien innerhalb eines Serviceprojekts vollständig zu migrieren, stellen Sie sicher, dass alle .wsdl- und .xsd-Dateien, auf die von den .bpel-Dateien verwiesen wird, in einem Geschäftsintegrationsprojekt im neuen Arbeitsbereich aufgelöst werden können:

Nun können Sie mit dem Migrationsprozess beginnen.

Überlegungen zum Migrationsprozess für das Quellenartefakt

Es gibt eine Reihe von Überlegungen für den Quellenartefakt-Migrationsprozess von WebSphere Studio Application Developer Integration Edition.

Die folgenden Verfahren illustrieren das Design von WebSphere Studio Application Developer Integration Edition Services, um deren erfolgreiche Migration zum neuen Programmiermodell sicherzustellen:

Serviceprojekte mit dem WebSphere Integration Developer-Migrationsassistenten migrieren

Der WebSphere Integration Developer-Migrationsassistent ermöglicht die Migration von Serviceprojekten.

Anmerkung:

Der Migrationsassistent führt die folgenden Schritte aus:

  1. Erstellung eines neuen Geschäftsintegrationsmoduls (der Modulname wird von Ihnen definiert)
  2. Migration der Serviceprojekt-Klassenpfadeinträge zum neuen Modul
  3. Kopieren aller WebSphere Business Integration Server Foundation-Quellenartefakte aus dem ausgewählten Quellenprojekt in dieses Modul
  4. Migration der BPEL-Erweiterungen zu WSDL-Dateien
  5. Migration der Geschäftsprozesse (.bpel-Dateien) von der BPEL4WS-Version 1.1 zur neuen von WebSphere Process Server unterstützten Ebene, die auf BPEL4WS Version 1.1 mit wichtigen Funktionalitäten der zukünftigen WS-BPEL Version 2.0-Spezifikation aufbaut
  6. Erstellung einer SCA-Komponente für jeden .bpel-Prozess
  7. Erstellung einer Überwachungsdatei (.mon) für jeden BPEL-Prozess, um das Standardüberwachungsverhalten von WebSphere Studio Application Developer Integration Edition (wenn nötig) beizubehalten
  8. Erstellung von Importen und Exporten in Abhängigkeit von den in WebSphere Studio Application Developer Integration Edition ausgewählten Implementierungsoptionen
  9. Erstellung einer Verbindung zwischen der BPEL-Komponente und den zugehörigen Partnerlinks (Importe, Exporte und Java-Komponenten)

Führen Sie die folgenden Schritte aus, um Serviceprojekte mit dem WebSphere Integration Developer-Migrationsassistenten zu migrieren:

  1. Wählen Sie die Optionen Datei -> Importieren -> Geschäftsintegration -> WebSphere Studio Application Developer Integration Edition - Serviceprojekt aus, und klicken Sie auf Weiter, um den Assistenten aufzurufen:
    Importauswahl für Migration des Quellenartefakts
    Sie können den Migrationsassistenten auch auf der Begrüßungsseite öffnen, indem Sie auf das Symbol Benutzer von Vorversionen Benutzer von Vorversionen klicken, um die Seite Benutzer von Vorversionen zu öffnen. (Sie können jederzeit zur Begrüßungsseite zurückkehren, indem Sie auf die Optionen Hilfe -> Willkommen klicken.)
    Seite 'Benutzer von Vorversionen'
    Klicken Sie auf der linken Seite der Seite Benutzer von Vorversionen auf Migration, um die Seite Migration zu öffnen. Wählen Sie auf der Seite Migration die Option Ein Integration Edition 5.1 Serviceprojekt migrieren. Seite 'Migration' mit ausgewählte Option 'Ein Integration Edition 5.1 Serviceprojekt migrieren'
  2. Der Migrationsassistent wird geöffnet. Geben Sie den Pfad für die Quellenauswahl ein oder klicken Sie auf die Schaltfläche Durchsuchen, um sie zu suchen. Geben Sie außerdem den Modulnamen für die Position des zu migrierenden Serviceprojekts von WebSphere Studio Application Developer Integration Edition ein:
    Migrationsassistent für Quellenartefakte
    Hinweis: Es wird empfohlen, dass Sie den Namen des Serviceprojekts als Modulnamen auswählen, denn wenn sich andere Projekte im WebSphere Studio Application Developer Integration Edition-Arbeitsbereich befinden, die von diesem Projekt abhängen, müssen Sie die Klassenpfade des untergeordneten Projekts nach deren Import in WebSphere Integration Developer nicht aktualisieren.
  3. Wählen Sie in den Migrationsoptionen 'Ursprüngliche BPEL Java-Snippets beibehalten' im Kontrollkästchen für Kommentare aus:
    Migrationsoptionen
    Klicken Sie auf Fertig stellen.
  4. Wenn der Migrationsprozess abgeschlossen ist, wird das Fenster Migrationsergebnisse geöffnet:
    Fenster 'Migrationsergebnisse'
    Es wird automatisch eine diese Migrationsnachrichten enthaltende Protokolldatei im .metadata-Ordner des 6.x-Arbeitsbereichs generiert. Die Protokolldatei erhält den Namen ".log".

Wenn der Migrationsassistent abgeschlossen ist, bauen Sie das erstellte Geschäftsintgrationsmodul auf und versuchen Sie, alle Aufbaufehler zu beheben. Überprüfen Sie alle migrierten .bpel-Dateien: stellen Sie sicher, dass diese vollständig migriert wurden und im WebSphere Integration Developer BPEL Editor geöffnet werden können. Es gibt bestimmte BPEL Java Snippets, die nicht automatisch migriert werden können. Wenn Sie Fehler in den BPEL Java-Snippets feststellen, finden Sie Informationen zur Behebung dieser Fehler in "Migration zum SCA-Programmiermodell". Wenn Sie den Migrationsassistenten außerdem für die Migration eines Serviceprojekts zu einem BI-Modul verwendet haben, öffnen Sie den Modulabhängigkeitseditor, um sicherzustellen, dass die Abhängigkeiten korrekt eingestellt sind. Dazu wechseln Sie in die Geschäftsintegrationsperspektive und klicken doppelt auf das Modulprojekt für Geschäftsintegration. Hier können Sie Abhängigkeiten von Projekten für Geschäftsintegrationsbibliotheken, Java-Projekten und J2EE-Projekten hinzufügen.

Serviceprojekte mit WSADIEServiceProjectMigration migrieren

Mit dem Befehl WSADIEServiceProjectMigration können Sie Serviceprojekte migrieren.

Der Migrationsbefehl führt Folgendes aus:

Anmerkung: Die Serviceprojekte müssen in der Reihenfolge ihrer Abhängigkeit migriert werden. Wenn eine BPEL in Serviceprojekt A beispielsweise einen Prozess-zu-Prozess-Aufruf zu einer BPEL in Serviceprojekt B durchführt, muss Serviceprojekt B vor Serviceprojekt A migriert werden. Andernfalls kann der Prozess-zu-Prozess-Aufruf nicht ordnungsgemäß konfiguriert werden.

Führen Sie das Script WSADIEServiceProjectMigration wie folgt aus:

  1. Lokalisieren Sie das Script, indem Sie den gemeinsam genutzten Ordner öffnen, der bei der Installation von WebSphere Integration Developer angegeben wurde. Das Script befindet sich z. B. unter: SHARED_FOLDER_HOME/plugins/com.ibm.wbit.migration.wsadie_6.1.0
  2. Rufen Sie das Script wie folgt auf: WSADIEServiceProjectMigration -e eclipse-verz -s quellenprojektverz -d arbeitsbereich [-t zielprojektname] [-preserveSnippets true|false] [-debug]

    Parameterdefinitionen:

    -e eclipse-verz
    Die Position des Eclipse-Ordners (Eclipse-Laufzeit).
    -s quellenprojektverz
    Der vollständige Pfad zum WebSphere Studio Application Developer Integration Edition 5.1-Serviceprojekt.
    -d arbeitsbereich
    Der Arbeitsbereich, in dem das neue Geschäftsintegrationsmodul erstellt werden soll.
    -t zielprojektname
    Der Name des neuen, zu erstellenden Geschäftsintegrationsmoduls. Die Standardeinstellung entspricht der Einstellung für das migrierte WebSphere Studio Application Developer Integration Edition 5.1-Projekt.
    -preserveSnippets flag
    Aktiviert oder inaktiviert die Beibehaltung von vorhandenen BPEL-Java-Snippets in auskommentierter Form. Der Standardwert ist 'true'.
    -debug flag
    Aktiviert die Debugausgabe.

    Beispiel:

    WSADIEServiceProjectMigration -e WID_HOME\eclipse" -d "\myWIDworkspace" -s "\\MyServiceProject" -t "MyBIModuleName" -preserveSnippets false -debug
  3. Starten Sie nach der Ausführung des Befehls den neuen Arbeitsbereich in WebSphere Integration Developer.
  4. Generieren Sie das erstellte Geschäftsintgrationsmodul, und versuchen Sie, alle Generierungsfehler zu beheben. Überprüfen Sie alle migrierten .bpel-Dateien: stellen Sie sicher, dass diese vollständig migriert wurden und im WebSphere Integration Developer BPEL Editor geöffnet werden können. Es gibt bestimmte BPEL Java Snippets, die nicht automatisch migriert werden können. Wenn Sie Fehler in den BPEL Java-Snippets feststellen, finden Sie Informationen zur Behebung dieser Fehler in "Migration zum SCA-Programmiermodell".
  5. Öffnen Sie den Modulabhängigkeitseditor, um sicherzustellen, dass die Abhängigkeiten korrekt eingestellt sind. Wechseln Sie dazu in die Geschäftsintegrationsperspektive, und klicken Sie doppelt auf das Modulprojekt für Geschäftsintegration. Hier können Sie Abhängigkeiten von Projekten für Geschäftsintegrationsbibliotheken, Java-Projekten und J2EE-Projekten hinzufügen.

Anwendung migrieren

Wenn der Migrationsassistent die Artefakte erfolgreich in das neue Geschäftsintegrationsmodul migriert hat, müssen die Artefakte zur Erstellung einer Anwendung, die sich nach dem SCA-Modell richtet, miteinander verbunden werden. Der Migrationsassistent versucht zwar, die Artefakte erfolgreich zu migrieren; dennoch empfiehlt sich eine zusätzliche manuelle Prüfung. Anhand der Informationen in diesem Abschnitt können Sie feststellen, ob die Migration korrekt ausgeführt wurde.

  1. Öffnen Sie WebSphere Integration Developer und wechseln Sie zur Geschäftsintegrationsperspektive. Nun sollten die Module angezeigt werden, die vom Migrationsassistenten erstellt wurden (ein Modul für jedes migrierte Serviceprojekt). Beim ersten Artefakt, das unter dem Modulprojekt aufgelistet ist, handelt es sich um die Assembly-Datei des Moduls (es verfügt über den gleichen Namen wie das Modul).
  2. Doppelklicken Sie auf die Assembly-Datei, um sie im Assembly-Editor zu öffnen, in dem SCA-Komponenten erstellt und miteinander verbunden werden können, um eine ähnliche Funktionalität wie die der Version 5.1-Anwendung zu erhalten. Wenn im WebSphere Studio Application Developer Integration Edition-Serviceprojekt BPEL-Prozesse vorhanden waren, wurden Standard SCA-Komponenten vom Migrationsassistenten für jeden dieser Prozesse erstellt, die sich daraufhin im Assembly-Editor befinden.
  3. Wählen Sie eine Komponente aus und gehen Sie zur Sicht 'Eigenschaften', in der die Beschreibung, Informationen und Implementierungseigenschaften angezeigt werden und bearbeitet werden können.

Einige Projekte erfordern möglicherweise eine Neuvernetzung nach der Migration, um die Services wie in 5.1 neu zu verbinden. Die folgenden Informationen enthalten weitere Hinweise dazu, wie die Anwendung manuell mit den in WebSphere Integration Developer zur Verfügung gestellten Tools neu verbunden werden kann:

SCA-Komponenten und SCA-Importe für die Anwendungsservices zur Neuvernetzung erstellen

Alle migrierten Geschäftsprozesse müssen mit den zugehörigen Geschäftspartnern vernetzt werden. Es muss eine SCA-Komponente oder ein Import für alle anderen Servicetypen erstellt werden. Für WebSphere Studio Application Developer Integration Edition-Serviceprojekte, die mit projektexternen Systemen oder Entitäten interagieren, kann ein SCA-Import erstellt werden, damit das migrierte Projekt auf diese Entitäten als Services gemäß dem SCA-Modell zugreifen kann.

Anmerkung: Das Migrationsprogramm versucht eine automatische Ausführung. Sie können jedoch die Arbeitsschritte des Tools anhand der folgenden Informationen nachvollziehen.

Für WebSphere Studio Application Developer Integration Edition-Serviceprojekte, die mit Entitäten innerhalb des Projekts interagieren (beispielsweise ein Geschäftsprozess, ein Umsetzungsservice oder eine Java-Klasse), kann ein SCA-Import erstellt werden, damit das migrierte Projekt auf diese Entitäten als Services gemäß dem SCA-Modell zugreifen kann.

Die folgenden Abschnitte enthalten detaillierte Informationen über den zu erstellenden SCA-Import oder die SCA-Komponenten basierend auf dem Servicetyp, der migriert werden muss:

Migration eines Java-Service

Sie können einen Java-Service zu einer SCA Java-Komponente migrieren.

Wenn das WebSphere Studio Application Developer Integration Edition-Serviceprojekt von anderen Java-Projekten abhängig war, kopieren Sie die vorhandenen Projekte in das neue Arbeitsbereichsverzeichnis, und importieren Sie sie in WebSphere Integration Developer unter Verwendung des Assistenten unter Datei -> Importieren -> Allgemein -> Vorhandene Projekte in Arbeitsbereich.

In WebSphere Studio Application Developer Integration Edition standen beim Generieren eines neuen Java Service aus einer vorhandenen Java-Klasse die folgenden Optionen zur Verfügung:

Es gibt zahlreiche neue Komponenten, die neue Funktionen wie Datenzuordnung, Schnittstellenmediation, Geschäftsstatusmaschinen, Selektoren, Geschäftsregeln und vieles mehr bieten. Zunächst sollten Sie bestimmen, ob einer dieser neuen Komponententypen die benutzerdefinierte Java-Komponente ersetzen kann. Wenn dies nicht möglich ist, folgen Sie dem unten beschriebenen Migrationspfad.

Importieren Sie das Serviceprojekt mit dem Migrationsassistenten. Dies resultiert in der Erstellung eines Geschäftsintegrationsmoduls mit den WSDL-Nachrichten, PortTypes, Bindings und Services, die in WebSphere Studio Application Developer Integration Edition generiert werden.

Erweitern Sie in der Geschäftsintegrationsperspektive das Modul, um seinen Inhalt anzuzeigen. Öffnen Sie den Assembly-Editor durch Doppelklicken auf das erste Element unterhalb des Modulprojekts (es verfügt über denselben Namen wie das Projekt).

Es stehen die folgenden Optionen zur Verfügung:

Die benutzerdefinierte Java-Komponente erstellen: Option 1

Die empfohlene Migrationstechnik ist die Verwendung des WebSphere Integration Developer Java-Komponententyps, mit dem Sie den Java-Service als eine SCA-Komponente darstellen können. Während der Migration muss benutzerdefinierter Java-Code geschrieben werden, um zwischen dem SCA Java-Schnittstellenstil und dem vorhandenen Schnittstellenstil der Java-Komponente zu unterscheiden.

Führen Sie die folgenden Schritte aus, um die benutzerdefinierte Java-Komponente zu erstellen:

  1. Erweitern Sie im Modulprojekt die Option Schnittstellen und wählen Sie die WSDL-Schnittstelle, die für diese Java-Klasse in WebSphere Studio Application Developer Integration generiert wurde.
  2. Ziehen und übergeben Sie diese Schnittstelle an den Assembly-Editor. Es wird ein Dialog angezeigt, der Sie nach dem zu erstellenden Komponententyp fragt. Wählen Sie Komponente mit keinem Implementierungstyp und klicken Sie auf OK.
  3. Eine generische Komponente wird im Assembly-Diagramm angezeigt. Markieren Sie sie und gehen Sie zur Sicht Eigenschaften.
  4. Sie können den Namen und Anzeigenamen der Komponente in einen beschreibenden Namen in der Registerkarte Beschreibung ändern.
  5. Auf der Registerkarte Details können Sie sehen, dass diese Komponente über eine Schnittstelle verfügt, nämlich die, die Sie zum Assembly-Editor gezogen und an diesen übergeben haben.
  6. Stellen Sie sicher, dass sich die Java-Klasse, auf die Sie zugreifen möchten, im Klassenpfad des Serviceprojekts befindet, wenn sie nicht im Projekt selbst enthalten ist.
  7. Klicken Sie mit der rechten Maustaste auf das Modulprojekt und wählen Sie Editor für Abhängigkeiten öffnen.... Stellen Sie sicher, dass das Projekt, das die alte Java-Klasse enthält, im Abschnitt Java aufgelistet ist. Wenn dies nicht der Fall ist, fügen Sie sie durch Klicken auf Hinzufügen... hinzu.
  8. Klicken Sie im Assembly-Editor mit der rechten Maustaste auf die Komponente, die Sie soeben erstellt haben, und wählen Sie Implementierung generieren... -> Java. Wählen Sie daraufhin das Paket, in dem die Java-Implementierung generiert wird. Dadurch wird ein Java-Gerüstservice erstellt, der sich an die WSDL-Schnittstelle gemäß dem SCA-Programmiermodell hält, in dem komplexe Typen durch ein commonj.sdo.DataObject-Objekt dargestellt werden und einfache Typen durch ihre funktional entsprechenden Java-Objekte.

Die folgenden Code-Beispiele zeigen:

  1. Relevante Definitionen aus der 5.1 WSDL-Schnittstelle
  2. Die WebSphere Studio Application Developer Integration Edition 5.1 Java-Methoden, die der WSDL entsprechen
  3. Die WebSphere Integration Developer 6.x-Java-Methoden für die gleiche WSDL

Der folgenden Code zeigt die relevanten Definitionen aus der 5.1 WSDL-Schnittstelle:

<types>
	<schema xmlns="http://www.w3.org/2001/XMLSchema" 
    			attributeFormDefault="qualified" 
    			elementFormDefault="unqualified"    
    			targetNamespace="http://migr.practice.ibm.com/" 
    			xmlns:xsd1="http://migr.practice.ibm.com/">

			<complexType name="StockInfo">
				<all>
					<element name="index" type="int"/>
					<element name="price" type="double"/>
					<element name="symbol" nillable="true" 
							    type="string"/>

				</all>
			</complexType>
	</schema>
</types>

<message name="getStockInfoRequest">
	<part name="symbol" type="xsd:string"/>
</message>
<message name="getStockInfoResponse">
	<part name="result" type="xsd1:StockInfo"/>
</message>

	<operation name="getStockInfo" parameterOrder="symbol">
			<input message="tns:getStockInfoRequest" 
							name="getStockInfoRequest"/>
			<output message="tns:getStockInfoResponse" 
 			 				name="getStockInfoResponse"/>
        </operation>

Der folgende Code zeigt die WebSphere Studio Application Developer Integration Edition 5.1 Java-Methoden, die der WSDL entsprechen:

public StockInfo getStockInfo(String symbol)
	{
		return new StockInfo();
	}

	public void setStockPrice(String symbol, float newPrice)
	{
		// set some things
	}

Der folgende Code zeigt die WebSphere Integration Developer 6.x-Java-Methoden für dieselbe WSDL:

public DataObject getStockInfo(String aString) {
		//TODO Needs to be implemented.
		return null;
	}

	public void setStockPrice(String symbol, Float newPrice) {
		//TODO Needs to be implemented.
	}

Sie müssen nun Code dort eingeben, wo die "//TODO"-Tags in der generierten Java-Implementierungsklasse angezeigt werden. Es gibt zwei Optionen:

  1. Verschieben Sie die Logik von der ursprünglichen Java-Klasse in diese Klasse und passen Sie sie für die Verwendung von DataObject an.
  2. Erstellen Sie eine private Instanz der alten Java-Klasse in dieser generierten Java-Klasse und schreiben Sie Code, um Folgendes zu tun:
    1. Konvertieren aller Parameter der generierten Java-Implementierungsklasse in Parameter, die die alte Java-Klasse erwartet
    2. Aufrufen der privaten Instanz der alten Java-Klasse mit den konvertierten Parametern
    3. Konvertieren des Rückgabewerts der alten Java-Klasse in den Rückgabewerttyp, der von der generierten Java-Implementierungsmethode deklariert wird
    4. Diese Option wird für Auslastungsszenarios empfohlen, in denen die WSIF-Service-Proxys von neuen Java-Komponenten im Stil von 6.x verbraucht werden.

Wenn Sie eine der obenstehenden Optionen abgeschlossen haben, müssen Sie den Java-Service neu verbinden. Es sollten keine "Verweise" vorhanden sein, daher müssen Sie die Schnittstelle der Java-Komponente neu verbinden:

Einen Java-Web-Service erstellen: Option 2

Eine alternative zu berücksichtigende Option sind die Rational Application Developer Web-Servicetools, mit denen Sie einen Web-Service um eine Java-Klasse herum erstellen können.

Anmerkung: Weitere Informationen finden Sie auf der folgenden Site, bevor Sie eine Migration mit der folgenden Methode versuchen: Creating a Web service from a Java bean (Einen Web-Service aus einer Java-Bean erstellen).
Anmerkung: Diese Option erfordert die Konfiguration einer Web-Service-Laufzeit über WebSphere Integration Developer, bevor der Web-Service-Assistent aufgerufen wird.

Wenn Sie eine Bottom-up-Methode in WebSphere Studio Application Developer Integration Edition verwendet haben, um WSDL um die Java-Klasse herum zu generieren, führen Sie die folgenden Schritte aus:

  1. Erstellen Sie ein neues Web-Projekt und kopieren Sie die Java-Klasse, um die Sie den Service erstellen möchten, in den Java-Quellenordner dieses Web-Projekts.
  2. Klicken Sie mit der rechten Maustaste auf das Unternehmensanwendungsprojekt, das den Container für die Java-Klasse darstellt, um die herum Sie einen Service erstellen.
  3. Wählen Sie Eigenschaften, gehen Sie zu den Eigenschaften Server und stellen Sie sicher, dass die Ziellaufzeit auf WebSphere Process Server v6.1 und Standardserver auf den installierten WebSphere Process Server v6.1 eingestellt ist.
  4. Starten Sie den Testserver, implementieren Sie diese Anwendung für den Server und stellen Sie sicher, dass er erfolgreich startet.
  5. Klicken Sie als nächstes mit der rechten Maustaste auf die Java-Klasse, um die herum Sie einen Service erstellen möchten, und wählen Sie Web-Services -> Web-Service erstellen aus.
  6. Wählen Sie für Web-Service-Typ die Option Java-Bean-Web-Service und heben Sie die Markierung für Web-Service im Webprojekt starten auf, es sei denn, Sie möchten den Web-Service sofort implementieren. Optional haben Sie auch die Möglichkeit, ein Client-Proxy zu generieren. Klicken Sie auf Weiter.
  7. Die Java-Klasse, auf die Sie mit der rechten Maustaste geklickt haben, wird angezeigt. Klicken Sie auf Weiter.
  8. Sie müssen nun Ihre Service-Implementierungsoptionen konfigurieren. Klicken Sie auf Bearbeiten. Als Servertyp wählen Sie WPS-Server V6.1 und als Web-Service-Laufzeit wählen Sie IBM WebSphere und J2EE Version 1.4. Wenn Sie dadurch keine gültige Kombination auswählen können, finden Sie weitere Informationen zur Migration von J2EE-Projekten zur V1.4-Ebene im Abschnitt "Vorbereitung für die Migration". Klicken Sie auf OK.
  9. Geben Sie den Namen des Webprojekts für das Serviceprojekt ein. Wählen Sie außerdem das entsprechende EAR-Projekt. Klicken Sie auf Weiter. Beachten Sie, dass Sie möglicherweise mehrere Minuten warten müssen.
  10. Wählen Sie im Java-Bean-Identitätsfenster des Web-Service die WSDL-Datei, die die die WSDL-Definitionen enthalten wird. Wählen Sie die Methoden, die für den Web-Service zugänglich gemacht werden sollen, und wählen Sie den entsprechenden Stil/die Verschlüsselung (Dokument/Literal, RPC/Literal oder RPC/verschlüsselt). Wählen Sie die Option für die angepasste Zuordnung für Paket zu Namensbereich, und wählen Sie einen Namensbereich, der für die migrierte Java-Klasse für alle Java-Pakete eindeutig ist, die von der Schnittstelle dieser Java-Klasse verwendet werden. (Der Standardnamensbereich ist für den Paketnamen eindeutig, was zu Konflikten führen kann, falls Sie einen weiteren Web-Service erstellen, der dieselben Java-Klassen verwendet). Geben Sie ggfs. weitere Parameter an.
  11. Klicken Sie auf Weiter. Klicken Sie in der Anzeige Zuordnung von Web-Service-Paket zu Namensbereich auf Hinzufügen, und geben Sie in der erstellten Zeile den Namen des Pakets der Java-Bean ein. Fügen Sie dann den angepassten Namensbereich hinzu, der diese Java-Klasse eindeutig kennzeichnet. Fügen Sie weiter Zuordnungen für alle Java-Pakete hinzu, die von der Java-Bean-Schnittstelle verwendet werden.
  12. Klicken Sie auf Weiter. Beachten Sie, dass Sie möglicherweise mehrere Minuten warten müssen.
  13. Klicken Sie auf Fertig stellen. Wenn Sie die Arbeit mit dem Assistenten abgeschlossen haben, kopieren Sie die den Java-Service beschreibende generierte WSDL-Datei in das Geschäftsintegrations-Modulprojekt, wenn es sich beim Serviceprojekt um einen Verbraucher des Java-Service handelte. Sie befindet sich im generierten Router-Web-Projekt im Ordner WebContent/WEB-INF/wsdl. Aktualisieren/erstellen Sie das Geschäftsintegrations-Modulprojekt erneut.
  14. Wechseln Sie zur Geschäftsintegrationsperspektive und erweitern Sie erst das Modul und daraufhin die logische Kategorie Web-Service-Ports.
  15. Wählen Sie den in den zuvor durchgeführten Schritten erstellten Port, ziehen und übergeben Sie ihn an den Assembly-Editor und markieren Sie ihn, um einen Import mit Web-Service-Binding zu erstellen. Wenn Sie dazu aufgefordert werden, wählen Sie die WSDL-Schnittstelle der Java-Klasse. Die SCA-Komponente, die die Java-Klasse in 5.1 verbraucht hat, kann nun mit diesem Import verbunden werden, um die Migrationsschritte für die manuelle Neuvernetzung abzuschließen.

Beachten Sie, dass die Schnittstelle sich leicht von der 5.1 Schnittstelle unterscheiden kann, und Sie möglicherweise eine Schnittstellenmediationskomponente zwischen dem 5.1 Verbraucher und dem neuen Import einfügen müssen. Klicken Sie dazu auf das Tool Verbinden im Assembly-Editor und verbinden Sie die SCA-Quellenkomponente mit diesem neuen Import mit Web-Service-Binding. Da die Schnittstellen sich unterscheiden, wird die folgende Meldung angezeigt: Der Quell- und Zielknoten haben keine übereinstimmenden Schnittstellen. Wählen Sie zwischen dem Quell- und dem Zielknoten eine Schnittstellenzuordnung erstellen. Doppelklicken Sie auf die Zuordnungskomponente, die im Assembly-Editor erstellt wurde. Dadurch wird der Zuordnungseditor geöffnet. Anweisungen zur Erstellung einer Schnittstellenzuordnung finden Sie im Information Center.

Wenn Sie eine Top-down-Methode in WebSphere Studio Application Developer Integration Edition mit der Erstellung von Java-Klassen aus einer WSDL-Definition gewählt hatten, führen Sie die folgenden Schritte durch:

  1. Erstellen Sie ein neues Webprojekt und kopieren Sie die WSDL-Datei, aus der Sie das Java-Gerüst generieren möchten, in den Quellenordner dieses Webprojekts.
  2. Klicken Sie mit der rechten Maustaste auf die WSDL-Datei, die den PortType enthält, aus dem Sie das Java-Gerüst generieren möchten, und wählen Sie Web Services -> Java-Bean-Gerüst generieren.
  3. Wählen Sie den Web-Servicetyp Skeleton-Java-Bean-Web-Service und beenden Sie den Assistenten.

Nach Beenden des Assistenten sollten Sie über Java-Klassen verfügen, die die Serviceschnittstelle implementieren und nicht von WSIF-APIs abhängen.

Vor- und Nachteile für jede der Neuvernetzungsoptionen des Java-Service

Es gibt Vor- und Nachteile für jede der Neuvernetzungsoptionen des Java-Service.

Die folgende Liste beschreibt beide Optionen mit den jeweiligen Vor- und Nachteilen:

Migration eines EJB-Service

Sie können einen EJB-Service zu einem SCA-Import mit Binding für Session-Bean ohne Status migrieren.

Wenn das WebSphere Studio Application Developer Integration Edition-Serviceprojekt von einer anderen EJB, einem EJB-Client oder Java-Projekt abhängig war, importieren Sie diese vorhandenen Projekte unter Verwendung des Assistenten unter Datei -> Importieren -> Allgemein -> Vorhandene Projekte in Arbeitsbereich. Dies war normalerweise der Fall, wenn auf eine EJB von einem Serviceprojekt verwiesen wurde. Wenn WSDL- oder XSD-Dateien, auf die vom Serviceprojekt verwiesen wird, in einem anderen Projekttyp vorhanden sind, erstellen Sie eine neue Geschäftsintegrationsbibliothek mit demselben Namen wie der des alten Nicht-Service-Projekts, und kopieren Sie alle Artefakte in die Bibliothek.

Importieren Sie das Serviceprojekt mit dem Migrationsassistenten. Dies resultiert in der Erstellung eines Geschäftsintegrationsmoduls mit den WSDL-Nachrichten, PortTypes, Bindings und Services, die in WebSphere Studio Application Developer Integration Edition generiert werden.

Erweitern Sie in der Geschäftsintegrationsperspektive das Modul, um seinen Inhalt anzuzeigen. Öffnen Sie den Assembly-Editor durch Doppelklicken auf das erste Element unterhalb des Modulprojekts (es verfügt über denselben Namen wie das Projekt).

Es stehen die folgenden Optionen zur Verfügung:

Die benutzerdefinierte EJB-Komponente erstellen: Option 1

Die empfohlene Migrationstechnik ist die Verwendung des WebSphere Integration Developer-Imports mit einem Session-Bindingtyp ohne Status, mit dem Sie eine Session-EJB ohne Status als SCA-Komponente aufrufen können. Während der Migration muss benutzerdefinierter Java-Code geschrieben werden, um zwischen dem SCA Java-Schnittstellenstil und dem vorhandenen EJB-Schnittstellenstil zu konvertieren.

Anmerkung: Obwohl das Migrationstool diese Schritte automatisch ausführt, sind für alle Änderungen, die nach der Migration an den zur EJB-Schnittstelle gehörenden Schnittstellen und Datentypen (Geschäftsobjekte) vorgenommen werden, manuelle Aktualisierungen für den genannten Konvertierungscode erforderlich. Je nach Änderung werden in WebSphere Integration Developer möglicherweise Fehler angezeigt.

So erstellen Sie die benutzerdefinierte EJB-Komponente:

  1. Erweitern Sie im Modulprojekt die Option Schnittstellen und wählen Sie die WSDL-Schnittstelle, die für diese EJB in WebSphere Studio Application Developer Integration generiert wurde.
  2. Ziehen und übergeben Sie diese Schnittstelle an den Assembly-Editor. Es wird ein Dialog angezeigt, der Sie nach dem zu erstellenden Komponententyp fragt. Wählen Sie Komponente mit keinem Implementierungstyp und klicken Sie auf OK.
  3. Eine generische Komponente wird im Assemblydiagramm angezeigt. Markieren Sie sie und gehen Sie zur Ansicht Eigenschaften.
  4. Sie können den Namen und Anzeigenamen der Komponente in einen beschreibenden Namen in der Registerkarte Beschreibung ändern. Wählen Sie einen Namen wie Ihren EJB-Namen, fügen Sie jedoch eine Erweiterung wie "JavaMed" hinzu, da es sich hierbei um eine Java-Komponente handeln wird, die zwischen der WSDL -Schnittstelle, die für EJB in WebSphere Studio Application Developer Integration generiert wurde, und der Java-Schnittstelle des EJB vermittelt.
  5. Auf der Registerkarte Details können Sie sehen, dass diese Komponente über eine Schnittstelle verfügt, nämlich die, die Sie zum Assembly-Editor gezogen und an diesen übergeben haben.
  6. Klicken Sie im Assembly-Editor mit der rechten Maustaste auf die Komponente, die Sie soeben erstellt haben, und wählen Sie Implementierung generieren... -> Java. Wählen Sie daraufhin das Paket, in dem die Java-Implementierung generiert wird. Dadurch wird ein Java-Gerüstservice erstellt, der sich an die WSDL-Schnittstelle gemäß dem SCA-Programmiermodell hält, in dem komplexe Typen durch ein commonj.sdo.DataObject-Objekt dargestellt werden und einfache Typen durch ihre funktional entsprechenden Java-Objekte.

Die folgenden Code-Beispiele zeigen:

  1. Relevante Definitionen aus der 5.1 WSDL-Schnittstelle
  2. Die WebSphere Studio Application Developer Integration Edition 5.1 Java-Methoden, die der WSDL entsprechen
  3. Die WebSphere Integration Developer 6.x-Java-Methoden für die gleiche WSDL

Der folgenden Code zeigt die relevanten Definitionen aus der 5.1 WSDL-Schnittstelle:

<types>
	<schema xmlns="http://www.w3.org/2001/XMLSchema" 
    			attributeFormDefault="qualified" 
    			elementFormDefault="unqualified"    
    			targetNamespace="http://migr.practice.ibm.com/" 
    			xmlns:xsd1="http://migr.practice.ibm.com/">

			<complexType name="StockInfo">
				<all>
					<element name="index" type="int"/>
					<element name="price" type="double"/>
					<element name="symbol" nillable="true" 
							    type="string"/>

				</all>
			</complexType>
	</schema>
</types>

<message name="getStockInfoRequest">
	<part name="symbol" type="xsd:string"/>
</message>
<message name="getStockInfoResponse">
	<part name="result" type="xsd1:StockInfo"/>
</message>

	<operation name="getStockInfo" parameterOrder="symbol">
			<input message="tns:getStockInfoRequest" 
							name="getStockInfoRequest"/>
			<output message="tns:getStockInfoResponse" 
 			 				name="getStockInfoResponse"/>
        </operation>

Der folgende Code zeigt die WebSphere Studio Application Developer Integration Edition 5.1 Java-Methoden, die der WSDL entsprechen:

public StockInfo getStockInfo(String symbol)
	{
		return new StockInfo();
	}

	public void setStockPrice(String symbol, float newPrice)
	{
		// set some things
	}

Der folgende Code zeigt die WebSphere Integration Developer 6.x-Java-Methoden für dieselbe WSDL:

public DataObject getStockInfo(String aString) {
		//TODO Needs to be implemented.
		return null;
	}

	public void setStockPrice(String symbol, Float newPrice) {
		//TODO Needs to be implemented.
	}

Sie müssen nun echten Code dort eingeben, wo die "//TODO"-Tags in der generierten Java-Implementierungsklasse angezeigt werden. Zunächst müssen Sie einen Verweis von dieser Java-Komponente zur aktuellen EJB erstellen, so dass sie auf die EJB gemäß dem SCA-Programmiermodell zugreifen kann:

  1. Lassen Sie den Assembly-Editor geöffnet und wechseln Sie in die J2EE-Perspektive. Suchen Sie das EJB-Projekt, das die EJB enthält, für die Sie einen Service erstellen.
  2. Erweitern Sie das Element Implementierungsdeskriptor: <project-name>, und suchen Sie die EJB. Ziehen und übergeben Sie sie an den Assembly-Editor. Wenn Sie über Projektabhängigkeiten gewarnt werden, die aktualisiert werden müssen, wählen Sie das Kontrollkästchen Den Editor für Modulabhängigkeiten öffnen... aus. Klicken Sie dann auf OK.
  3. Stellen Sie sicher, dass das EJB-Projekt im J2EE-Abschnitt aufgelistet ist, und wenn dies nicht der Fall ist, fügen Sie es durch Klicken auf die Schaltfläche Hinzufügen hinzu.
  4. Speichern Sie die Modulabhängigkeiten und schließen Sie den Editor. Sie werden sehen, dass ein neuer Import im Assembly-Editor erstellt wurde. Markieren Sie ihn und gehen Sie zur Sicht 'Eigenschaften' in der Registerkarte 'Beschreibung', um den Namen und Anzeigenamen des Imports in einen aussagekräftigeren Namen zu ändern. Auf der Registerkarte 'Binding' können Sie sehen, dass der Importtyp normalerweise auf Binding für Session-Bean ohne Status gesetzt ist und der JNDI-Name der EJB bereits ordnungsgemäß eingerichtet ist.
  5. Wählen Sie das Verbindungstool aus der Palette im Assembly-Editor.
  6. Klicken Sie auf die Java-Komponente und lassen Sie die Maustaste los.
  7. Klicken Sie als nächstes auf den EJB-Import und lassen Sie die Maustaste los.
  8. Wenn Sie gefragt werden Am Quellenknoten wird ein übereinstimmender Verweis erstellt. Möchten Sie fortfahren? Klicken Sie auf OK. Dadurch wird eine Verbindung zwischen den zwei Komponenten hergestellt.
  9. Wählen Sie die Java-Komponente im Assembly-Editor und erweitern Sie in der Sicht 'Eigenschaften' in der Registerkarte 'Details' die Option 'Verweise', und wählen Sie den Verweis zur EJB, die gerade erstellt wurde. Sie können den Namen des Verweises aktualisieren, wenn der generierte Name nicht sehr aussagekräftig oder geeignet ist. Notieren Sie den Namen dieses Verweises für die zukünftige Verwendung.
  10. Speichern Sie das Assembly-Diagramm.

Sie müssen das SCA-Programmiermodell verwenden, um die EJB aus der generierten Java-Klasse aufzurufen. Öffnen Sie die generierte Java-Klasse und befolgen Sie diese Schritte, um den Code für den Aufruf des EJB-Service zu schreiben. Für die generierte Java-Implementierungsklasse:

  1. Erstellen Sie eine private Variable (deren Typ der Ihrer remote angeschlossenen EJB-Schnittstelle entspricht):
    private YourEJBInterface ejbService = null;
  2. Wenn komplexe Typen in Ihrer EJB-Schnittstelle vorhanden sind, erstellen Sie außerdem eine private Variable für die BOFactory:
    private BOFactory boFactory = (BOFactory) 
    	ServiceManager.INSTANCE.locateService("com/ibm/websphere/bo
    	/BOFactory");
  3. Verwenden Sie die SCA APIs im Konstruktor der Java-Implementierungsklasse, um den EJB-Verweis aufzulösen (denken Sie daran, den Namen des EJB-Verweises, den Sie ein paar Schritte zuvor notiert haben, einzugeben), und stellen Sie die private Variable gemäß diesem Verweis ein:
    // Locate the EJB service
    	this.ejbService = (YourEJBInterface) 
    	ServiceManager.INSTANCE.locateService("name-of-your-ejb-reference");

Für jedes "//TODO" in der generierten Java-Implementierungsklasse:

  1. Konvertieren Sie alle Parameter in die Parametertypen, die die EJB erwartet.
  2. Rufen Sie die entsprechende Methode im EJB-Verweis unter Verwendung des SCA-Programmiermodells auf, und senden Sie die konvertierten Parameter.
  3. Konvertieren Sie den Rückgabewert der EJB in den Rückgabewerttyp, der von der generierten Java-Implementierungsmethode deklariert wird
/**
	 * Method generated to support the implementing WSDL port type named
	 * "interface.MyBean".
	 */
	public DataObject getStockInfo(String aString) {
		DataObject boImpl = null;

		try {

			// invoke the EJB method
			StockInfo stockInfo = this.ejbService.getStockInfo(aString);

			// formulate the SCA data object to return.
			boImpl = (DataObject) 
					this.boFactory.createByClass(StockInfo.class);

			// manually convert all data from the EJB return type into the 
			// SCA data object to return
			boImpl.setInt("index", stockInfo.getIndex());
			boImpl.setString("symbol", stockInfo.getSymbol());
			boImpl.setDouble("price", stockInfo.getPrice());
		} catch (RemoteException e) {
			e.printStackTrace();
		}
		return boImpl;
	}

	/**
	 * Method generated to support the implementing WSDL port type named
	 * "interface.MyBean".
	 */
	public void setStockPrice(String symbol, Float newPrice) {
		try {
			this.ejbService.setStockPrice(symbol, newPrice.floatValue());
		} catch (RemoteException e) {
			e.printStackTrace();
		}

	}
Einen EJB-Web-Service erstellen: Option 2

Eine alternative zu berücksichtigende Option sind die Rational Application Developer Web-Servicetools, mit denen Sie einen Web-Service um eine EJB herum erstellen können.

Anmerkung: Weitere Informationen finden Sie auf der folgenden Site, bevor Sie eine Migration mit der folgenden Methode versuchen: Creating a Web service from an enterprise bean (EJB) using the WebSphere run-time environment (Einen Web-Service aus einer Enterprise-Bean (EJB) unter Verwendung der WebSphere-Laufzeitumgebung erstellen).
Anmerkung: Diese Option erfordert die Konfiguration einer Web-Service-Laufzeit über WebSphere Integration Developer, bevor der Web-Service-Assistent aufgerufen wird.

Befolgen Sie die folgenden Schritte, um einen Web-Service um eine EJB herum zu erstellen:

  1. Klicken Sie mit der rechten Maustaste auf das Unternehmensanwendungsprojekt, das den Container für die EJB darstellt, um die herum Sie einen Service erstellen.
  2. Wählen Sie Eigenschaften, gehen Sie zu den Eigenschaften Server und stellen Sie sicher, dass die Ziellaufzeit auf WebSphere Process Server v6.1 und Standardserver auf den installierten WebSphere Process Server v6.1 eingestellt ist.
  3. Starten Sie den Testserver, implementieren Sie diese Anwendung für den Server und stellen Sie sicher, dass er erfolgreich startet.
  4. Erweitern Sie in der J2EE-Perspektive das EJB-Projekt in der Sicht 'Projektexplorer'. Erweitern Sie den Implementierungsdeskriptor und die Kategorie Session-Beans. Wählen Sie die Bean, um die der Web-Service herum erstellt werden soll.
  5. Klicken Sie mit der rechten Maustaste und wählen Sie Web-Services -> Web-Services erstellen.
  6. Wählen Sie für Web-Service-Typ die Option EJB-Web-Service aus und heben Sie die Markierung für Web-Service im Webprojekt starten auf, es sei denn, Sie möchten den Web-Service sofort implementieren. Klicken Sie auf Weiter.
  7. Stellen Sie sicher, dass die EJB, auf die Sie mit der rechten Maustaste geklickt haben, hier ausgewählt ist, und klicken Sie auf Weiter.
  8. Sie müssen nun Ihre Service-Implementierungsoptionen konfigurieren. Klicken Sie auf Bearbeiten. Als Servertyp wählen Sie WPS-Server V6.1 und als Web-Service-Laufzeit wählen Sie IBM WebSphere und J2EE Version 1.4. Wenn Sie dadurch keine gültige Kombination auswählen können, finden Sie weitere Informationen zur Migration von J2EE-Projekten zur V1.4 Ebene im Abschnitt "Vorbereitung für die Migration". Klicken Sie auf OK.
  9. Für das Serviceprojekt geben Sie den Namen des EJB-Projekts ein, das die EJB enthält. Wählen Sie außerdem das entsprechende EAR-Projekt aus. Klicken Sie auf Weiter. Beachten Sie, dass Sie möglicherweise mehrere Minuten warten müssen.
  10. Wählen Sie im Fenster für die Web-Service-EJB-Konfiguration das zu verwendende Router-Projekt aus (wählen Sie den Namen des zu erstellenden Router-Web-Projekts aus, und dieses Projekt wird zu der gleichen Unternehmensanwendung wie die ursprüngliche EJB hinzugefügt). Wählen Sie den gewünschten Transport (SOAP über HTTP oder SOAP über JMS). Klicken Sie auf Weiter.
  11. Wählen Sie die WSDL-Datei, die die WSDL-Definitionen enthalten wird. Wählen Sie die Methoden, die für den Web-Service zugänglich gemacht werden sollen, und wählen Sie den entsprechenden Stil/die Verschlüsselung (Dokument/Literal, RPC/Literal oder RPC/verschlüsselt). Wählen Sie die Option für die angepasste Zuordnung für Paket zu Namensbereich und einen Namensbereich, der für die migrierte EJB für alle Java-Pakete eindeutig ist, die von der EJB verwendet werden. (Der Standardnamensbereich ist für den Paketnamen eindeutig, was zu Konflikten führen kann, falls Sie einen weiteren Web-Service erstellen, der dieselben Java-Klassen verwendet). Geben Sie ggfs. weitere Parameter an. Es gibt für jede Kombination aus Stil/Verschlüsselung Einschränkungen. Weitere Informationen finden Sie in den Einschränkungen für Web-Services unter: Limitations of Web services.
  12. Klicken Sie auf Weiter. Klicken Sie in der Anzeige für die Zuordnung von Web-Service-Paket zu Namensbereich auf Hinzufügen, und geben Sie in der erstellten Zeile den Namen des Pakets der EJB ein. Fügen Sie dann den angepassten Namensbereich hinzu, der diese EJB eindeutig kennzeichnet. Fügen Sie weiter Zuordnungen für alle Java-Pakete hinzu, die von der EJB-Schnittstelle verwendet werden.
  13. Klicken Sie auf Weiter. Beachten Sie, dass Sie möglicherweise mehrere Minuten warten müssen.
  14. Klicken Sie auf Fertig stellen. Wenn Sie die Arbeit mit dem Assistenten abgeschlossen haben, kopieren Sie die den EJB-Service beschreibende generierte WSDL-Datei in das Geschäftsintegrations-Modulprojekt, wenn es sich bei dem Serviceprojekt um einen Verbraucher des EJB-Service handelte. Sie befindet sich im generierten Router-Web-Projekt im Ordner WebContent/WEB-INF/wsdl. Aktualisieren/erstellen Sie das Geschäftsintegrations-Modulprojekt erneut.
  15. Wechseln Sie zur Geschäftsintegrationsperspektive und erweitern Sie erst das migrierte Modul und daraufhin die logische Kategorie Web-Service-Ports.
  16. Wählen Sie den in den zuvor durchgeführten Schritten erstellten Port, ziehen und übergeben Sie ihn an den Assembly-Editor und markieren Sie ihn, um einen Import mit Web-Service-Binding zu erstellen. Wenn Sie dazu aufgefordert werden, wählen Sie die WSDL-Schnittstelle der EJB. Die SCA-Komponente, die die EJB in 5.1 verbraucht hat, kann nun mit diesem Import verbunden werden, um die Migrationsschritte für die manuelle Neuvernetzung abzuschließen.

Wenn Sie eine Top-down-Methode in WebSphere Studio Application Developer Integration Edition mit der Erstellung eines EJB-Gerüsts aus einer WSDL-Definition gewählt hatten, führen Sie die folgenden Schritte durch:

  1. Erstellen Sie ein neues Webprojekt und kopieren Sie die WSDL-Datei, aus der Sie das EJB-Gerüst generieren möchten, in den Quellenordner dieses Web-Projekts.
  2. Klicken Sie mit der rechten Maustaste auf die WSDL-Datei, die den PortType enthält, aus dem Sie das EJB-Gerüst generieren möchten, und wählen Sie Web Services -> Java-Bean-Gerüst generieren.
  3. Wählen Sie den Web-Servicetyp Skeleton-EJB-Web-Service und beenden Sie den Assistenten.

Nach Beenden des Assistenten sollten Sie über eine EJB verfügen, die die Serviceschnittstelle implementiert und nicht von WSIF-APIs abhängt.

Beachten Sie, dass die Schnittstelle sich leicht von der 5.1 Schnittstelle unterscheiden kann, und Sie möglicherweise eine Schnittstellenmediationskomponente zwischen dem 5.1 Verbraucher und dem neuen Import einfügen müssen. Klicken Sie dazu auf das Tool Verbinden im Assembly-Editor und verbinden Sie die SCA-Quellenkomponente mit diesem neuen Import mit Web-Service-Binding. Da die Schnittstellen sich unterscheiden, wird die folgende Meldung angezeigt: Der Quell- und Zielknoten haben keine übereinstimmenden Schnittstellen. Wählen Sie zwischen dem Quell- und dem Zielknoten eine Schnittstellenzuordnung erstellen. Doppelklicken Sie auf die Zuordnungskomponente, die im Assembly-Editor erstellt wurde. Dadurch wird der Zuordnungseditor geöffnet. Anweisungen zur Erstellung einer Schnittstellenzuordnung finden Sie im Information Center.

Wenn Sie diesen Vorgang abgeschlossen haben, müssen Sie den EJB-Service neu verbinden. Es sollten keine "Verweise" vorhanden sein, daher müssen Sie die Schnittstelle der Java-Komponente neu verbinden:

Vor- und Nachteile der einzelnen Neuvernetzungsoptionen für EJB-Service

Die einzelnen Neuvernetzungsoptionen für EJB-Service weisen Vor- und Nachteile auf.

Die folgende Liste beschreibt beide Optionen mit den jeweiligen Vor- und Nachteilen:

Migration eines Geschäftsprozesses zum Geschäftsprozess-Serviceaufruf

Dieses Szenario ist auf einen Geschäftsprozess anwendbar, der einen anderen Geschäftsprozess aufruft, wobei der zweite Geschäftsprozess über ein WSIF-Prozessbinding aufgerufen wird. Dieser Abschnitt beschreibt die Migration von BPEL zu einem BPEL-Serviceaufruf mit Hilfe einer Verbindung oder eines Imports/Exports mit SCA-Binding.

Für die Migration eines Prozessbinding-Serviceprojekts (BPEL) führen Sie die folgenden Schritte durch:

  1. Erweitern Sie in der Geschäftsintegrationsperspektive das Modul, um seinen Inhalt anzuzeigen. Öffnen Sie den Assembly-Editor durch Doppelklicken auf das erste Element unterhalb des Modulprojekts (es verfügt über denselben Namen wie das Projekt).
  2. Es gibt mehrere Szenarien, in denen ein BPEL-Prozess einen anderen BPEL-Prozess aufrufen kann. Suchen Sie unten nach dem Szenario, das Ihre Anwendung betrifft:

Migration eines Web-Service (SOAP/JMS)

Sie können einen Web-Service (SOAP/JMS) zu einem SCA-Import mit Web-Service-Binding migrieren.

Führen Sie die folgenden Schritte durch, um ein SOAP/JMS-Serviceprojekt für eine ausgehende Servicemigration zu migrieren:

  1. Zunächst müssen Sie das Serviceprojekt unter Verwendung des Migrationsassistenten importieren. Dies resultiert in der Erstellung eines Geschäftsintegrationsmoduls mit den WSDL-Nachrichten, PortTypes, Bindings und Services, die in WebSphere Studio Application Developer Integration Edition generiert werden. Beachten Sie, dass wenn es sich bei dem IBM Web-Service (SOAP/JMS), der von dieser Anwendung aufgerufen wird, außerdem um einen WebSphere Studio Application Developer Integration Edition Web-Service handelt, der migriert wird, es möglicherweise Aktualisierungen für diesen Web-Service während der Migration gab. Wenn dies der Fall ist, verwenden Sie die migrierten WSDL-Dateien dieses Web-Service an dieser Stelle.
  2. Erweitern Sie in der Geschäftsintegrationsperspektive das Modul, sodass Sie seinen Inhalt anzeigen können. Öffnen Sie den Assembly-Editor durch Doppelklicken auf das erste Element unterhalb des Modulprojekts (es verfügt über denselben Namen wie das Projekt).
  3. Als nächstes fügen Sie einen Import hinzu, der der Anwendung ermöglicht, mit dem IBM Web Service (via SOAP/JMS) gemäß dem SCA-Programmiermodell zu interagieren. Stellen Sie sicher, dass die WSDL-Schnittstelle, Binding und Servicedefinitionen im migrierten Modul oder in einer Bibliothek, von der das Modul abhängt, vorhanden sind.
  4. Erweitern Sie in der Geschäftsintegrationsperspektive das migrierte Modul und öffnen Sie das Assembly-Diagramm im Assembly-Editor.
  5. Erweitern Sie die logische Kategorie des Web-Service-Ports und ziehen und übergeben Sie den Port, der dem aufzurufenden Service entspricht, an den Assembly-Editor.
  6. Wählen Sie die Erstellung eines Imports mit Web-Service-Binding.
  7. Nach Erstellung des Imports wählen Sie ihn im Assembly-Editor aus und gehen zur Sicht 'Eigenschaften'. In der Registerkarte 'Binding' wird der Port und Service angezeigt, an die der Import gebunden ist.
  8. Speichern Sie das Assembly-Diagramm.

Wenn Sie diesen Vorgang abgeschlossen haben, müssen Sie den Service neu verbinden:

Migration eines Web-Service (SOAP/HTTP)

Sie können einen Web-Service (SOAP/HTTP) zu einem SCA-Import mit Web-Service-Binding migrieren.

Führen Sie die folgenden Schritte durch, um ein SOAP/HTTP-Serviceprojekt für eine ausgehende Servicemigration zu migrieren:

  1. Zunächst müssen Sie das Serviceprojekt unter Verwendung des Migrationsassistenten importieren. Dies resultiert in der Erstellung eines Geschäftsintegrationsmoduls mit den WSDL-Nachrichten, PortTypes, Bindings und Services, die in WebSphere Studio Application Developer Integration Edition generiert werden. Beachten Sie, dass wenn es sich bei dem IBM Web-Service (SOAP/HTTP), der von dieser Anwendung aufgerufen wird, außerdem um einen WebSphere Studio Application Developer Integration Edition Web-Service handelt, der migriert wird, es möglicherweise Aktualisierungen für diesen Web-Service während der Migration gab. Wenn dies der Fall ist, verwenden Sie die migrierten WSDL-Dateien dieses Web-Service an dieser Stelle.
  2. Erweitern Sie in der Geschäftsintegrationsperspektive das Modul, sodass Sie seinen Inhalt anzeigen können. Öffnen Sie den Assembly-Editor durch Doppelklicken auf das erste Element unterhalb des Modulprojekts (es verfügt über denselben Namen wie das Projekt).
  3. Als nächstes fügen Sie einen Import hinzu, der der Anwendung ermöglicht, mit dem IBM Web Service (via SOAP/HTTP) gemäß dem SCA-Programmiermodell zu interagieren. Stellen Sie sicher, dass die WSDL-Schnittstelle, Binding und Servicedefinitionen im migrierten Modul oder in einer Bibliothek, von der das Modul abhängt, vorhanden sind.
  4. Erweitern Sie in der Geschäftsintegrationsperspektive das migrierte Modul und öffnen Sie das Assembly-Diagramm im Assembly-Editor.
  5. Erweitern Sie die logische Kategorie des Web-Service-Ports und ziehen und übergeben Sie den Port, der dem aufzurufenden Service entspricht, an den Assembly-Editor.
  6. Wählen Sie die Erstellung eines Imports mit Web-Service-Binding.
  7. Nach Erstellung des Imports wählen Sie ihn im Assembly-Editor aus und gehen zur Sicht 'Eigenschaften'. In der Registerkarte 'Binding' wird der Port und Service angezeigt, an die der Import gebunden ist.
  8. Speichern Sie das Assembly-Diagramm.

Wenn Sie diesen Vorgang abgeschlossen haben, müssen Sie den Service neu verbinden:

Migration eines JMS-Service

Sie können einen JMS-Service zu einem SCA-Import mit JMS-Binding migrieren.

Anmerkung: Wenn die JMS-Nachricht an einen Adapter von WebSphere Business Integration gesendet wird, finden Sie weitere Informationen im Abschnitt "Interaktionen mit WebSphere Business Integration-Adaptern migrieren", den Sie über den unten stehenden Link aufrufen können.

Führen Sie die folgenden Schritte durch, um ein JMS-Serviceprojekt für eine ausgehende Servicemigration zu migrieren:

  1. Zunächst müssen Sie das Serviceprojekt unter Verwendung des Migrationsassistenten importieren. Dies resultiert in der Erstellung eines Geschäftsintegrationsmoduls mit den WSDL-Nachrichten, PortTypes, Bindings und Services, die in WebSphere Studio Application Developer Integration Edition generiert werden.
  2. Erweitern Sie in der Geschäftsintegrationsperspektive das Modul, sodass Sie seinen Inhalt anzeigen können. Öffnen Sie den Assembly-Editor durch Doppelklicken auf das erste Element unterhalb des Modulprojekts (es verfügt über denselben Namen wie das Projekt).
  3. Als nächstes fügen Sie einen Import hinzu, der der Anwendung ermöglicht, mit einer JMS-Warteschlange gemäß dem SCA-Programmiermodell zu interagieren.
  4. Erweitern Sie das migrierte Modulprojekt im Assembly-Editor, erweitern Sie die Kategorie Schnittstellen und suchen Sie den WSDL PortType, der den von der Anwendung aufgerufenen Web-Service beschreibt. Ziehen und übergeben Sie sie an den Assembly-Editor.
  5. Ein Dialog namens Erstellung von Komponenten ermöglicht Ihnen die Auswahl des zu erstellenden Komponententyps. Wählen Sie Ohne Binding importieren.
  6. Sie werden sehen, dass ein neuer Import im Assembly-Editor erstellt wurde. Wenn Sie diesen markieren und zur Sicht 'Eigenschaften' gehen, können Sie den Namen und Anzeigenamen des Imports in der Registerkarte 'Beschreibung' in einen aussagekräftigeren Namen ändern.
  7. Details zum migrierten JMS-Service finden Sie in den WSDL-Bindingdateien und -Servicedateien aus 5.1. Diese Details können Sie verwenden, um die Details für den Import mit JMS-Binding in 6.x anzugeben. Suchen Sie im 5.1-Serviceprojekt nach den WSDL-Dateien für 5.1-JMS-Binding und -Service (diese Dateien heißen normalerweise '*JMSBinding.wsdl' und '*JMSService.wsdl'). Untersuchen Sie die dort erfassten Binding- und Serviceinformationen. Anhand des Bindings können Sie ermitteln, ob Text- oder Objektnachrichten verwendet wurden und ob angepasste Datenformatbindings zum Einsatz kamen. In diesem Fall ist es sinnvoll, auch für den Import mit JMS-Binding von 6.x ein angepasstes Datenbinding zu schreiben. Anhand des Service können Sie die Ausgangskontextfactory, den Namen der JNDI-Verbindungsfactory, den JNDI-Zieladressnamen und den Zieladressstil (Warteschlange) ermitteln.
  8. Klicken Sie mit der rechten Maustaste auf den Import, und wählen Sie Binding generieren und JMS-Binding aus. Sie werden aufgefordert, die folgenden Parameter einzugeben:
    Wählen Sie die JMS-Nachrichtendomäne aus:
    • Point-to-Point
    • Publish-Subscribe
    • Domain-Independent
    Wählen Sie aus, wie Daten zwischen Geschäftsobjekt und JMS-Nachricht serialisiert werden:
    • Text
    • Objekt
    • Benutzerdefiniert
    Wenn 'Benutzerdefiniert' ausgewählt ist, gehen Sie folgendermaßen vor:
    Geben Sie den vollständig qualifizierten Namen der com.ibm.websphere.sca.jms.data.JMSDataBinding-Implementierungsklasse an. Sie sollten ein benutzerdefiniertes Datenbinding angeben, wenn Ihre Anwendung JMS-Headereigenschaften festlegen muss, die normalerweise im JMS-Importbinding nicht verfügbar sind. In diesem Fall können Sie eine Klasse für das angepasste Datenbinding erstellen, die das JMS-Standarddatenbinding 'com.ibm.websphere.sca.jms.data.JMSDataBinding' erweitert, und angepassten Code für den direkten Zugriff auf 'JMSMessage' hinzufügen. Weitere Informationen finden Sie in den JMS-Beispielen des Abschnitts 'Bindings für Import- und Exportkomponenten erstellen und ändern', die Sie über den unten stehenden Link aufrufen können.
    Konnektivität ankommender Daten verwendet die JMS-Standardfunktions-Selektorklasse:
    <ausgewählt> oder <abgewählt>
  9. Wählen Sie den soeben erstellten Export. Gehen Sie in der Sicht 'Eigenschaften' zur Registerkarte 'Binding'. Sie können alle hier angezeigte Binding-Information manuell mit all den Werten eingeben, die Sie zuvor in WebSphere Studio Application Developer Integration Edition angegeben haben. Die Binding-Information, die Sie angeben können, lautet folgendermaßen:

Wenn Sie diesen Vorgang abgeschlossen haben, müssen Sie den Service neu verbinden:

Migration eines J2C-IMS-Service

Sie können einen J2C-IMS-Service zu einem SCA-Import mit EIS-Binding oder einem SCA-Import mit Web-Service-Binding migrieren.

Verwenden Sie keine der WebSphere Studio Application Developer Integration Edition-Artefakte, die für diesen IMS-Service generiert wurden. Sie müssen den Service mit den Assistenten in WebSphere Integration Developer erneut erstellen und die Anwendung manuell neu verbinden.

Anmerkung: Schalten Sie automatische Erstellung ein oder erstellen Sie das Modul manuell.

Es stehen die folgenden Optionen zur Verfügung:

Anmerkung: Beachten Sie bei beiden Optionen, dass wenn ein BPEL-Service diesen IMS-Service aufruft, die BPEL leicht verändert werden muss, da die über den EIS-Service zugänglich gemachte Schnittstelle sich von der alten 5.1 Schnittstelle leicht unterscheidet. Um dies zu tun, öffnen Sie den BPEL-Editor, passen Sie den Partnerlink, der dem EIS-Service entspricht, an, und verwenden Sie die neue in den obenstehenden Schritten generierte Schnittstelle (WSDL-Datei). Nehmen Sie alle erforderlichen Änderungen an den BPEL-Aktivitäten für die neue WSDL-Schnittstelle des EIS-Service vor.

SCA-Import zum Aufruf des IMS-Service: Option 1 erstellen

Sie können einen SCA-Import mit EIS-Binding erstellen, der DataObjects zur Speicherung der Nachrichten/Daten für die Kommunikation mit dem IMS-System verwendet.

Führen Sie die folgenden Schritte durch, um einen SCA-Import zum Aufrufen des IMS-Service zu erstellen:

  1. Erstellen Sie ein neues Geschäftsintegrations-Modulprojekt, um diesen neuen IMS-Service zu speichern.
  2. Rufen Sie zur Neuerstellung des EIS-Service die Optionen Datei -> Neu -> Sonstige -> Geschäftsintegration -> Externer Service auf.
  3. Mit diesem Assistenten können Sie einen Service aus einem EIS-System importieren. Er ähnelt dem WebSphere Studio Application Developer Integration Edition-Assistenten, der den WSIF-basierten EIS-Service in 5.1 erstellt hat. Sie können den neuen J2C IMS-Ressourcenadapter mit diesem Assistenten importieren. Durchsuchen Sie das Verzeichnis, in dem WebSphere Integration Developer installiert ist, und führen Sie eine Detailabfrage/-analyse unter Ressourcenadapter -> ims15 -> imsico9102.rar durch.
    Anmerkung: Weitere Informationen zum Abschluss der Eigenschaften für Speichern und Fenster für Operationen finden Sie im Information Center. Bei der Ausführung des Assistenten 'Externer Service' können Sie während des Hinzufügens einer Operation Geschäftsobjekte für den Eingabe- oder Ausgabedatentyp der Operation erstellen. Dazu müssen Sie über die C- oder COBOL-Quellendatei verfügen, die Sie im WebSphere Studio Application Developer Integration Edition-Assistenten verwendet haben. Diese Dateien hätten in das alte Serviceprojekt kopiert werden sollen, so dass Sie dort auf die Quellendateien verweisen können. Sie können die Geschäftsobjekte auch mit dem separaten Assistenten unter Datei -> Neu -> Sonstige -> Geschäftsintegration -> Externe Daten importieren.
  4. Wenn Sie den Assistenten beendet haben, öffnen Sie die Geschäftsintegrationsperspektive und erweitern Sie das Modul, so dass Sie ihren Inhalt anzeigen können. In den Datentypen des Moduls sollten neue Geschäftsobjekte und in den Schnittstellen neue Schnittstellen aufgelistet sein.
  5. Öffnen Sie den Assembly-Editor durch Doppelklicken auf das erste Element unterhalb des Modulprojekts (es verfügt über denselben Namen wie das Projekt). Im Erstellungsbereich sollte ein Import vorhanden sein, der über EIS-Binding verfügt und den soeben von Ihnen erstellten Service darstellt.

Anweisungen dazu, wie Sie diesen Service für Verbraucher zugänglich machen, finden Sie im Abschnitt "SCA-Exporte für den Zugriff auf den migrierten Service erstellen".

Web-Service um den J2C-Service herum erstellen: Option 2

Sie können einen J2C Web-Service erstellen, und wenn es sich beim Verbraucher des Service um eine SCA-Komponente handelt, können Sie den Service als einen IBM Web-Service (SOAP/HTTP oder SOAP/JMS) auslasten.

Führen Sie die folgenden Schritte durch, um einen Web-Service um den J2C-Service herum zu erstellen:

  1. Erstellen Sie die J2C Java-Bean durch Klicken auf Datei -> Neu -> J2C -> J2C-JavaBean
  2. Wählen Sie die 1.5 Version des IMS-Connector für Java und klicken Sie auf Weiter.
  3. Markieren Sie Verwaltete Verbindung und geben Sie den JNDI Lookup-Namen ein. Klicken Sie auf Weiter.
  4. Geben Sie das Projekt, das Paket und den Namen für die neue Java-Bean an. Die Bean setzt sich aus einer Schnittstelle und einer Implementierungsklasse zusammen. Klicken Sie auf Weiter.
  5. Fügen Sie eine Java-Methode für jede Funktion oder jeden Service hinzu, auf den Sie vom EIS zugreifen möchten. Zusätzliche Methoden können zu einem späteren Zeitpunkt im Java-Quelleneditor über die Sicht 'Snippets' hinzugefügt werden. Klicken Sie auf die Schaltfläche Hinzufügen..., wählen Sie den Namen für die Methode aus, und klicken Sie auf Weiter.
  6. Wählen Sie nun Durchsuchen... aus, um vorhandene Typen wiederzuverwenden, oder Neu..., um den CICS/IMS Java-Datenbinding-Assistenten (in dem Sie auf eine COBOL- oder C-Quellendatei verweisen können) für die Eingabe- und Ausgabedatentypen zu starten.
  7. Wenn Sie die Erstellung von Java-Methoden abgeschlossen haben, klicken Sie auf Weiter.
  8. Schließen Sie die verbleibenden Schritte in diesem Assistenten ab, um Ihre J2C Java-Bean zu erstellen.
  9. Erstellen Sie den Web-Service durch Klicken auf Datei -> Neu -> J2C -> Webseite, Web-Service oder EJB aus J2C-JavaBean, um den Service um Ihre J2C Java-Bean herum zu erstellen.
  10. Beenden Sie den Assistenten.

Die Verbraucher dieses Service können nun den WSDL-Service verwenden, der mit diesem Assistenten generiert wird, um den IMS-Service aufzurufen.

Vor- und Nachteile der einzelnen Neuvernetzungsoptionen für J2C-IMS-Service

Die einzelnen Neuvernetzungsoptionen für J2C-IMS-Service weisen Vor- und Nachteile auf.

Die folgende Liste beschreibt beide Optionen mit den jeweiligen Vor- und Nachteilen:

Migration eines J2C-CICS ECI-Service

Sie können einen J2C-CICS ECI-Service zu einem SCA-Import mit EIS-Binding oder einem SCA-Import mit Web-Service-Binding migrieren.

Befolgen Sie die Anweisungen im Thema "Migration eines J2C-IMS-Service"; stellen Sie dabei jedoch sicher, dass die folgende RAR-Datei anstelle der IMS RAR-Datei importiert wird:

Wenn Sie die zweite Option wählen, um einen J2C Web-Service zu erstellen, wählen Sie den V1.5 ECIResourceAdapter im zweiten Fenster des J2C-Assistenten für die Erstellung von Java-Beans.

Weitere Informationen finden Sie auch im Thema "Migration eines J2C-IMS-Service".

Migration eines J2C-CICS EPI-Service

Es gibt keine direkte Unterstützung für den J2C-CICS EPI-Service in WebSphere Integration Developer. Um auf diesen Service von einem SCA-Modul aus zuzugreifen, müssen Sie unter Verwendung des Auslastungsszenarios migrieren.

Anweisungen zur Migration dieses Servicetyps zu WebSphere Integration Developer finden Sie im Thema "Auslastungsszenario für Servicemigration".

Migration eines J2C-HOD-Service

Es gibt keine direkte Unterstützung für den J2C-HOD-Service in WebSphere Integration Developer. Um auf diesen Service von einem SCA-Modul aus zuzugreifen, müssen Sie unter Verwendung des Auslastungsszenarios migrieren.

Anweisungen zur Migration dieses Servicetyps zu WebSphere Integration Developer finden Sie im Thema "Auslastungsszenario für Servicemigration".

Migration eines Umsetzungs-Serviceprojekts

Sie können einen Umsetzungsservice wenn möglich zu einer SCA-Datenzuordnung und Schnittstellenzuordnung migrieren. Sie können auch das Auslastungsszenario für den Zugriff auf diesen Service von einem SCA-Modul aus verwenden.

Die Datenzuordnungs- und Schnittstellenzuordnungskomponenten sind neu in Version 6.0. Sie bieten ähnliche Funktionen wie der Umsetzungsservice in 5.1, verfügen jedoch nicht über die vollständige XSL-Umsetzungsfunktionalität. Wenn Sie Ihren Umsetzungsservice nicht mit einer dieser Komponenten ersetzen können, müssen Sie unter Verwendung des Auslastungsszenarios migrieren, da es keine direkte Unterstützung für den Umsetzungsservice in WebSphere Integration Developer gibt. Führen Sie die Schritte aus, die im Abschnitt "Auslastungsszenario für Servicemigration" dokumentiert sind, um auf diesen Service von einem SCA-Modul aus zuzugreifen.

Auslastungsszenario für Servicemigration

Für die Fälle, in denen es keine direkte Entsprechung für einen WebSphere Studio Application Developer Integration Edition-Servicetyp gibt, wird ein Auslastungsszenario benötigt, um den alten WebSphere Studio Application Developer Integration Edition-Service ohne Wartung (auf AS-IS-Basis) beim Neuentwurf der Anwendung in WebSphere Integration Developer auszulasten.

Im Folgenden finden Sie die Schritte, die in WebSphere Studio Application Developer Integration Edition vor dem Aufruf des Migrationsassistenten durchgeführt werden müssen:

  1. Erstellen Sie ein neues Java-Projekt, das diesen Client-Proxy-Code enthalten soll. Fügen Sie diesen Client-Proxy-Code nicht in das Serviceprojekt ein, da die generierten Nachrichten im 5.1-Stil und Java Bean-Klassen vom automatischen Migrationsassistenten übersprungen werden, der die Serviceprojekte migriert.
  2. Öffnen Sie WebSphere Studio Application Developer Integration Edition und klicken Sie mit der rechten Maustaste auf die WSDL-Datei, die das Umsetzungsbinding und den Service enthält und wählen Sie Unternehmensservices -> Service-Proxy generieren. Sie werden gefragt, welchen Proxy-Typ Sie erstellen möchten, es ist jedoch nur Web Services Invocation Framework (WSIF) verfügbar. Klicken Sie auf Weiter.
  3. Sie können nun das Paket und den Namen der zu erstellenden Service-Proxy Java-Klasse angeben (Sie erstellen den Proxy im aktuellen Serviceprojekt). Klicken Sie auf Weiter.
  4. Geben Sie nun den Proxy-Stil an, wählen Sie Client Stub und die gewünschten in den Proxy einzuschließenden Operationen, und klicken Sie auf Fertig stellen. Dadurch wird eine Java-Klasse erstellt, die dieselben Methoden wie der WebSphere Studio Application Developer Integration Edition-Service zugänglich macht, wobei die Argumente zu den Java-Methoden einen Abschnitt der WSDL-Quellennachricht darstellen.

Nun können Sie zu WebSphere Integration Developer migrieren:

  1. Kopieren Sie das Client-Proxy-Java-Projekt in den neuen Arbeitsbereich und importieren Sie es durch Klicken auf Datei -> Importieren -> Vorhandenes Projekt in Arbeitsbereich.
  2. Importieren Sie das Serviceprojekt mit dem Migrationsassistenten. Dies resultiert in der Erstellung eines Geschäftsintegrationsmoduls mit den WSDL-Nachrichten, PortTypes, Bindings und Services, die in WebSphere Studio Application Developer Integration Edition generiert werden.
  3. Erweitern Sie in der Geschäftsintegrationsperspektive das Modul, sodass Sie seinen Inhalt anzeigen können. Öffnen Sie den Assembly-Editor durch Doppelklicken auf das erste Element unterhalb des Modulprojekts (es verfügt über denselben Namen wie das Projekt).
  4. Zur Erstellung der benutzerdefinierten Java-Komponente erweitern Sie Schnittstellen unter dem Modulprojekt und wählen Sie die WSDL-Schnittstelle, die für diesen Umsetzungsservice in WebSphere Studio Application Developer Integration Edition generiert wurde.
  5. Ziehen und übergeben (Drag-and-drop) Sie diese Schnittstelle an den Assembly-Editor. Es wird ein Dialog angezeigt, der Sie nach dem zu erstellenden Komponententyp fragt. Wählen Sie Komponente mit keinem Implementierungstyp und klicken Sie auf OK.
  6. Eine generische Komponente wird im Assembly-Diagramm angezeigt. Markieren Sie sie und gehen Sie zur Sicht Eigenschaften.
  7. In der Registerkarte Beschreibung können Sie den Namen und Anzeigenamen der Komponente in einen aussagekräftigeren Namen ändern (wählen Sie in diesem Fall etwas Ähnliches wie Ihren EJB-Namen, fügen Sie jedoch eine Erweiterung wie beispielsweise "JavaMed" hinzu, da es sich hierbei um eine Java-Komponente handeln wird, die zwischen der WSDL-Schnittstelle, die für den Umsetzungsservice in WebSphere Studio Application Developer Integration Edition generiert wurde, und der Java-Schnittstelle des Umsetzungs-Client-Proxy vermittelt).
  8. Auf der Registerkarte Details können Sie sehen, dass diese Komponente über eine Schnittstelle verfügt, nämlich die, die Sie zum Assembly-Editor gezogen und an diesen übergeben haben.
  9. Klicken Sie im Assembly-Editor mit der rechten Maustaste auf die Komponente, die Sie soeben erstellt haben, und wählen Sie Implementierung generieren... -> Java. Wählen Sie daraufhin das Paket aus, in dem die Java-Implementierung generiert wird. Dadurch wird ein Java-Gerüstservice erstellt, der sich an die WSDL-Schnittstelle gemäß dem SCA-Programmiermodell hält, in dem komplexe Typen durch ein commonj.sdo.DataObject-Objekt dargestellt werden und einfache Typen durch ihre funktional entsprechenden Java-Objekte.

Sie müssen nun Code dort eingeben, wo die "//TODO"-Tags in der generierten Java-Implementierungsklasse angezeigt werden. Es gibt zwei Optionen:

  1. Verschieben Sie die Logik von der ursprünglichen Java-Klasse in diese Klasse und passen Sie sie an die neue Datenstruktur an.
  2. Erstellen Sie eine private Instanz der alten Java-Klasse in dieser generierten Java-Klasse und schreiben Sie Code, um Folgendes zu tun:
    1. Konvertieren aller Parameter der generierten Java-Implementierungsklasse in Parameter, die die alte Java-Klasse erwartet
    2. Aufrufen der privaten Instanz der alten Java-Klasse mit den konvertierten Parametern
    3. Konvertieren des Rückgabewerts der alten Java-Klasse in den Rückgabewerttyp, der von der generierten Java-Implementierungsmethode deklariert wird

Wenn Sie die obenstehenden Optionen abgeschlossen haben, müssen Sie den Client-Proxy neu verbinden. Es sollten keine"Verweise" vorhanden sein, daher müssen Sie die Schnittstelle derJava-Komponente neu verbinden:

SCA-Exporte für den Zugriff auf den migrierten Service erstellen

Ein SCA-Export muss erstellt werden, um den migrierten Service für externe Verbraucher gemäß dem SCA-Modell für alle Services verfügbar zu machen, für die im WebSphere Studio Application Developer Integration Edition-Serviceprojekt Implementierungscode generiert wurde. Dies schließt alle Services ein, die durch anwendungsexterne Clients aufgerufen werden. Hinweis: Das Migrationsprogramm versucht eine automatische Ausführung; Sie können jedoch die Arbeitsschritte des Tools anhand der folgenden Informationen nachvollziehen.

Wenn Sie in WebSphere Studio Application Developer Integration Edition mit der rechten Maustaste auf den BPEL-Prozess oder sonstige Service WSDL geklickt haben und Unternehmensservices -> Implementierungscode generieren ausgewählt haben, müssen Sie die folgenden manuellen Migrationsschritte ausführen. Beachten Sie, dass sich WebSphere Integration Developer von WebSphere Studio Application Developer Integration Edition insofern unterscheidet, als dass es alle Implementierungsoptionen speichert. Bei der Erstellung des Projekts wird der Implementierungscode automatisch in der generierten EJB und den Web-Projekten aktualisiert, daher gibt es die Option zum manuellen Erstellen des Implementierungscodes nicht mehr.

Es wurden fünf Bindingoptionen im Abschnitt 'Schnittstellen für Partner' des Assistenten zur Generierung von BPEL-Implementiercode zur Verfügung gestellt. Die folgende eingehende BPEL Service-Migrationsinformation bietet Einzelheiten zum Exporttyp und den Eigenschaften, die basierend auf den Implementier-Bindingtypen, die in WebSphere Studio Application Developer Integration Edition ausgewählt wurden, zu erstellen sind:

Migration von EJB und EJB-Prozessbindings

EJB und EJB-Prozessbindings können zur empfohlenen SCA-Anweisung migriert werden.

In WebSphere Studio Application Developer Integration Edition hat dieser Bindingtyp Clients die Kommunikation mit einem BPEL-Prozess oder anderen Servicetyp durch Aufruf eines EJB ermöglicht. Beachten Sie, dass dieser Bindingtyp für Mikroprozesse nicht optional war - er wurde immer ausgewählt, wenn das generierte EJB intern von den anderen Bindingtypen verwendet wurde.

Der JNDI-Name des generierten EJB wurde automatisch als eine Kombination aus BPEL-Name, Zielnamensbereich sowie 'Gültig ab'-Zeitmarke generiert. Die folgenden Attribute können beispielsweise durch Überprüfung der BPEL-Prozesseigenschaften im BPEL Editor auf den Registerkarten 'Beschreibung' und 'Serverinhalt' gefunden werden:

Tabelle 3. Generierter Namensbereich
Prozessname MyService
Zielnamensbereich http://www.example.com/process87787141/
Gültig ab Jan 01 2003 02:03:04

Der generierte Namensbereich für dieses Beispiel lautet daraufhin com/example/www/process87787141/MyService20030101T020304.

In WebSphere Studio Application Developer Integration Edition gab es keine Optionen zur Auswahl, wenn EJB-Binding als Implementierungstyp ausgewählt wurde.

Es gibt vier Optionen für die Migration des WebSphere Studio Application Developer Integration Edition-Prozessbinding. Die Clienttypen, die auf den Service zugreifen, bestimmen, welche der unten aufgelisteten Migrationsoptionen durchgeführt werden:

Anmerkung: Wenn die manuellen Migrationsschritte abgeschlossen sind, muss der Client ebenso zum neuen Programmiermodell migriert werden. Weitere Informationen finden Sie im entsprechenden Thema für die folgenden Client-Typen:

Tabelle 4. Weitere Informationen zur Migration von Clients
Clienttyp Weitere Informationen finden Sie in
EJB Client, der die generierte Session-Bean aufruft. Ein solcher Client ruft eine EJB-Methode auf, die der aufzurufenden BPEL-Operation entspricht "Migration des EJB Client"
WSIF Client, der das EJB Prozessbinding verwendet "Migration des EJB-Prozessbinding-Client"
Generischer Geschäftsprozess-Choreographer EJB API "Migration des generischen Geschäftsprozess-Choreographer EJB API Client"
Generische Geschäftsprozess-Choreographer-Nachrichtenübertragungs-API "Migration des generischen Geschäftsprozess-Choreographer Messaging API Client"
Ein weiterer BPEL-Prozess im gleichen Modul N/V: BPEL-Komponenten unter Verwendung des Assembly-Editors verbinden
Ein weiterer BPEL-Prozess in einem anderen Modul N/V: Einen Import mit SCA-Binding im Referenzmodul erstellen, und dessen Binding mit dem Verweis auf Export mit SCA-Binding, das Sie weiter unten in Option 1 erstellt haben, konfigurieren

Migrationsoption 1 für EJB und EJP-Prozessbinding

Die erste Migrationsoption für das WebSphere Studio Application Developer Integration Edition EJB-Prozessbinding ist die Ermöglichung des Zugriffs auf Geschäftsprozesse durch eine andere Komponente in demselben Modul.

Verbinden Sie diese andere Komponente mit der BPEL-Komponente im Assembly-Editor wie folgt:

  1. Wählen Sie das Element Verbinden in der Symbolleiste.
  2. Klicken Sie auf die andere Komponente, um sie als Quelle der Verbindung auszuwählen.
  3. Klicken Sie auf die Komponente BPEL SCA, um sie als Ziel für die Verbindung auszuwählen.
  4. Speichern Sie das Assembly-Diagramm.
Migrationsoption 2 für EJB und EJP-Prozessbinding

Die zweite Migrationsoption für das WebSphere Studio Application Developer Integration Edition EJB-Prozessbinding ist die Ermöglichung des Zugriffs auf Geschäftsprozesse durch sonstige SCA-Module und Clients.

Anmerkung: Diese Schritte sind verbindlich, wenn die generischen Geschäftsprozess-Choreographer-APIs für den Aufruf des Geschäftsprozesses verwendet werden.

Der Export mit SCA-Binding ermöglicht den Zugriff auf eine SCA-Komponente durch andere SCA-Module. Führen Sie die folgenden Schritte aus, um einen Export mit SCA-Binding zu erstellen:

  1. Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
  2. Erstellen Sie einen Export mit SCA-Binding für jede BPEL-Prozessschnittstelle, für die ein EJB-Binding in WebSphere Studio Application Developer Integration Edition generiert wurde:
    1. Klicken Sie mit der rechten Maustaste auf die BPEL-Komponente im Assembly-Editor.
    2. Wählen Sie Exportieren....
    3. Wählen Sie SCA-Binding.
    4. Wenn es mehrere Schnittstellen für den Prozess gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
    5. Wählen Sie nach Erstellung des SCA-Exports den Export im Assembly-Editor aus, und wählen Sie in der Sicht 'Eigenschaften' das Inhaltsteilfenster Beschreibung aus. Der Name und die Beschreibung des Exports werden aufgelistet und können auf Wunsch geändert werden.
    6. Speichern Sie das Assembly-Diagramm.
Migrationsoption 3 für EJB und EJP-Prozessbinding

Die dritte Migrationsoption für das WebSphere Studio Application Developer Integration Edition EJB-Prozessbinding ist es, Module durch eine nicht-SCA-Entität (beispielsweise eine JSP oder einenJava-Client) zugänglich zu machen.

Die Standalone Reference macht eine SCA-Komponente durch einen beliebigen externen Client zugänglich. Führen Sie die folgenden Schritte aus, um eine Standalone Reference zu erstellen:

  1. Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
  2. Erstellen Sie eine Standalone Reference für jede BPEL-Prozessschnittstelle, für die ein EJB-Binding in WebSphere Studio Application Developer Integration Edition generiert wurde:
    1. Wählen Sie das Element Standalone References in der Symbolleiste aus.
    2. Klicken Sie auf den Erstellungsbereich des Assembly-Editors, um eine Standalone References SCA-Entität zu erstellen.
    3. Wählen Sie das Element Verbinden in der Symbolleiste.
    4. Klicken Sie auf die Entität Standalone References, um sie als Quelle für die Verbindung auszuwählen.
    5. Klicken Sie auf die Komponente BPEL SCA, um sie als Ziel für die Verbindung auszuwählen.
    6. Es erscheint die Warnung Am Quellenknoten wird ein übereinstimmender Verweis erstellt. Möchten Sie fortfahren?. Klicken Sie auf OK.
    7. Wählen Sie die Entität Standalone References aus, die soeben erstellt wurde. Wählen Sie dann in der Sicht 'Eigenschaften' das Inhaltsteilfenster Beschreibung aus.
    8. Erweitern Sie den Link Verweise und wählen Sie die soeben erstellte Referenz. Der Name und die Beschreibung der Referenz werden aufgelistet und können auf Wunsch geändert werden.
    9. Wenn es mehrere Schnittstellen für den Prozess gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
    10. Speichern Sie das Assembly-Diagramm.
Migrationsoption 4 für EJB und EJP-Prozessbinding

Die vierte Migrationsoption für das WebSphere Studio Application Developer Integration Edition EJB-Prozessbinding ist die Ermöglichung des Zugriffs auf Geschäftsprozesse durch einen Web-Services-Client.

Der Export mit Web-Service-Binding ermöglicht den Zugriff auf eine SCA-Komponente über einen externen Web-Services-Client. Führen Sie die folgenden Schritte aus, um einen Export mit Web-Service-Binding zu erstellen:

  1. Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
  2. Erstellen Sie einen Export mit SCA-Binding für jede BPEL-Prozessschnittstelle, für die ein EJB-Binding in WebSphere Studio Application Developer Integration Edition generiert wurde:
    1. Klicken Sie mit der rechten Maustaste auf die BPEL-Komponente im Assembly-Editor.
    2. Wählen Sie Exportieren... .
    3. Wählen Sie Web-Service-Binding.
    4. Wenn es mehrere Schnittstellen für den Prozess gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
    5. Wählen Sie den Transport: soap/http oder soap/jms.
    6. Wählen Sie nach Erstellung des Web-Services-Exports den Export im Assembly-Editor aus. Wählen Sie dann in der Sicht 'Eigenschaften' das Inhaltsteilfenster Beschreibung aus. Der Name und die Beschreibung des Exports werden aufgelistet und können auf Wunsch geändert werden.
    7. Speichern Sie das Assembly-Diagramm.

Migration von JMS und JMS-Prozessbindings

JMS und JMS-Prozessbindings können zur empfohlenen SCA-Anweisung migriert werden.

In WebSphere Studio Application Developer Integration Edition hat dieser Bindingtyp Clients die Kommunikation mit einem BPEL-Prozess oder anderen Servicetyp durch Senden einer Nachricht an ein MDB ermöglicht. Beachten Sie, dass dieser Bindingtyp für Prozesse mit langer Laufzeit nicht optional war und immer ausgewählt war. Tatsächlich war dieser Bindingtyp der einzige Bindingtyp, der für Request-Response-Schnittstellen von Prozessen mit langer Laufzeit zulässig war. Bei andere Servicetypen würde eine MDB generiert werden, die den entsprechenden Service aufruft.

Der vom JMS Binding verwendete JNDI-Name war eine Kombination aus BPEL-Name, Zielnamensbereich sowie 'Gültig an'-Zeitmarke.

In WebSphere Studio Application Developer Integration Edition gab es die folgenden Optionen zur Auswahl, wenn JMS Binding als Implementiertyp für einen BPEL-Prozess ausgewählt wurde:

Es gibt fünf Optionen für die Migration des WebSphere Studio Application Developer Integration Edition JMS-Prozessbinding. Die Clienttypen, die auf den Service zugreifen, bestimmen, welche der unten aufgelisteten Migrationsoptionen durchgeführt werden:

Anmerkung: Wenn die manuellen Migrationsschritte abgeschlossen sind, muss der Client ebenso zum neuen Programmiermodell migriert werden. Weitere Informationen finden Sie im entsprechenden Thema für die folgenden Client-Typen:

Tabelle 5. Weitere Informationen für die Migration von Clients
Clienttyp Weitere Informationen finden Sie in
WSIF Client, der JMS-Prozess-Binding verwendet "Migration des generischen Geschäftsprozess-Choreographer Messaging API Client und des JMS-Prozessbinding-Client"
Generischer Geschäftsprozess-Choreographer EJB API "Migration des generischen Geschäftsprozess-Choreographer EJB API Client"
Migration des Unternehmens durch generische Geschäftsprozess-Choreographer-Nachrichtenübertragungs-API "Migration des generischen Geschäftsprozess-Choreographer Messaging API Client"
Ein weiterer BPEL-Prozess im gleichen Modul N/V: BPEL-Komponenten unter Verwendung des Assembly-Editors verbinden
Ein weiterer BPEL-Prozess in einem anderen Modul N/V: Einen Import mit SCA-Binding im Referenzmodul erstellen, und dessen Binding mit dem Verweis auf Export mit SCA-Binding, das Sie weiter unten in Option 1 erstellt haben, konfigurieren.

Migrationsoption 1 für JMS und JMS-Prozessbinding

Die erste Migrationsoption für das WebSphere Studio Application Developer Integration Edition JMS-Prozessbinding ist die Ermöglichung des Zugriffs auf Geschäftsprozesse durch eine andere Komponente in demselben Modul.

Verbinden Sie diese andere Komponente mit der BPEL-Komponente im Assembly-Editor wie folgt:

  1. Wählen Sie das Element Verbinden in der Symbolleiste.
  2. Klicken Sie auf die andere Komponente, um sie als Quelle der Verbindung auszuwählen.
  3. Klicken Sie auf die Komponente BPEL SCA, um sie als Ziel für die Verbindung auszuwählen.
  4. Speichern Sie das Assembly-Diagramm.
Migrationsoption 2 für JMS und JMS-Prozessbinding

Die zweite Migrationsoption für das WebSphere Studio Application Developer Integration Edition JMS-Prozessbinding ist die Ermöglichung des Zugriffs auf Geschäftsprozesse durch sonstige SCA-Module und Clients.

Der Export mit SCA-Binding ermöglicht den Zugriff auf eine SCA-Komponente durch andere SCA-Module. Führen Sie die folgenden Schritte aus, um einen Export mit SCA-Binding zu erstellen:

  1. Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
  2. Erstellen Sie einen Export mit SCA-Binding für jede BPEL-Prozessschnittstelle, für die ein JMS-Binding in WebSphere Studio Application Developer Integration Edition generiert wurde:
    1. Klicken Sie mit der rechten Maustaste auf die BPEL-Komponente im Assembly-Editor.
    2. Wählen Sie Exportieren....
    3. Wählen Sie SCA-Binding.
    4. Wenn es mehrere Schnittstellen für den Prozess gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
    5. Wählen Sie nach der Erstellung des SCA-Exports den Export im Assembly-Editor aus. Wählen Sie dann in der Sicht 'Eigenschaften' das Inhaltsteilfenster Beschreibung aus. Der Name und die Beschreibung des Exports werden aufgelistet und können auf Wunsch geändert werden.
    6. Speichern Sie das Assembly-Diagramm.
Migrationsoption 3 für JMS und JMS-Prozessbinding

Die dritte Migrationsoption für das WebSphere Studio Application Developer Integration Edition JMS-Prozessbinding ist es, Geschäftsprozesse durch eine nicht-SCA-Entität (beispielsweise eine JSP oder einenJava-Client) zugänglich zu machen.

Die Standalone Reference macht eine SCA-Komponente durch einen beliebigen externen Client zugänglich. Führen Sie die folgenden Schritte aus, um eine Standalone Reference zu erstellen:

  1. Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
  2. Erstellen Sie eine Standalone Reference für jede BPEL-Prozessschnittstelle, für die ein JMS-Binding in WebSphere Studio Application Developer Integration Edition generiert wurde:
    1. Wählen Sie das Element Standalone References in der Symbolleiste aus.
    2. Klicken Sie auf den Erstellungsbereich des Assembly-Editors, um eine Standalone References SCA-Entität zu erstellen.
    3. Wählen Sie das Element Verbinden in der Symbolleiste.
    4. Klicken Sie auf die Entität Standalone References, um sie als Quelle für die Verbindung auszuwählen.
    5. Klicken Sie auf die Komponente BPEL SCA, um sie als Ziel für die Verbindung auszuwählen.
    6. Es erscheint die Warnung Am Quellenknoten wird ein übereinstimmender Verweis erstellt. Möchten Sie fortfahren?. Klicken Sie auf OK.
    7. Wählen Sie die Entität Standalone References aus, die soeben erstellt wurde. Wählen Sie dann in der Sicht 'Eigenschaften' das Inhaltsteilfenster Beschreibung aus.
    8. Erweitern Sie den Link Verweise und wählen Sie die soeben erstellte Referenz. Der Name und die Beschreibung der Referenz werden aufgelistet und können auf Wunsch geändert werden.
    9. Wenn es mehrere Schnittstellen für den Prozess gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
    10. Speichern Sie das Assembly-Diagramm.
Migrationsoption 4 für JMS und JMS-Prozessbinding

Die vierte Migrationsoption für das WebSphere Studio Application Developer Integration Edition JMS-Prozessbinding ist die Ermöglichung des Zugriffs auf Geschäftsprozesse durch einen Web-Services-Client.

Der Export mit Web-Service-Binding ermöglicht den Zugriff auf eine SCA-Komponente über einen externen Web-Services-Client. Führen Sie die folgenden Schritte aus, um einen Export mit Web-Service-Binding zu erstellen:

  1. Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
  2. Erstellen Sie einen Export mit SCA-Binding für jede BPEL-Prozessschnittstelle, für die ein JMS-Binding in WebSphere Studio Application Developer Integration Edition generiert wurde:
    1. Klicken Sie mit der rechten Maustaste auf die BPEL-Komponente im Assembly-Editor.
    2. Wählen Sie Exportieren... .
    3. Wählen Sie Web-Service-Binding.
    4. Wenn es mehrere Schnittstellen für den Prozess gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
    5. Wählen Sie den Transport: soap/http oder soap/jms.
    6. Wählen Sie nach Erstellung des Web-Services-Exports den Export im Assembly-Editor aus. Wählen Sie dann in der Sicht 'Eigenschaften' das Inhaltsteilfenster Beschreibung aus. Der Name und die Beschreibung des Exports werden aufgelistet und können auf Wunsch geändert werden.
    7. Speichern Sie das Assembly-Diagramm.
Migrationsoption 5 für JMS und JMS-Prozessbinding

Die fünfte Migrationsoption für das WebSphere Studio Application Developer Integration Edition JMS-Prozessbinding ist die Ermöglichung des Zugriffs auf Geschäftsprozesse durch einen JMS-Client.

Der Export mit JMS-Binding ermöglicht den Zugriff auf eine SCA-Komponente über einen externen JMS-Client. Führen Sie die folgenden Schritte aus, um einen Export mit JMS-Binding zu erstellen:

  1. Sie müssen für BPEL-Services neue Warteschlangenressourcen erstellen und auf diese Ressourcen verweisen, da das 5.1-JMS-Prozessbinding deutlich vom 5.1-JMS-Standardbinding abwich. Bei anderen Servicetypen können Sie die Werte, die Sie für den JMS-Implementierungscode in WebSphere Studio Application Developer Integration Edition 5.1 ausgewählt haben, ermitteln, indem Sie nach der WSDL-Datei namens JMSBinding.wsdl und JMSService.wsdl im entsprechenden Paket unterhalb des Ordners ejbModule/META-INF für das generierte EJB-Projekt suchen und die dort erfassten Binding- und Serviceinformationen untersuchen. Anhand des Bindings können Sie ermitteln, ob Text- oder Objektnachrichten verwendet wurden und ob angepasste Datenformatbindings zum Einsatz kamen. In diesem Fall ist es sinnvoll, auch für den Export mit JMS-Binding von 6.x ein angepasstes Datenbinding zu schreiben. Anhand des Service können Sie die Ausgangskontextfactory, den Namen der JNDI-Verbindungsfactory, den JNDI-Zieladressnamen und den Zieladressstil (Warteschlange) ermitteln.
  2. Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
  3. Erstellen Sie einen Export mit JMS-Binding für jede BPEL-Prozessschnittstelle, für die ein JMS-Binding in WebSphere Studio Application Developer Integration Edition generiert wurde, durch Klicken mit der rechten Maustaste auf die BPEL-Komponente im Assembly-Editor.
  4. Wählen Sie Exportieren... .
  5. Wählen Sie JMS-Binding.
  6. Wenn es mehrere Schnittstellen für den Prozess gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
  7. Wählen Sie in der nächsten Anzeige (JMS-Exportbindingattribute) die Option JMS-Nachrichtendomäne. Definieren Sie dieses Attribut als Punkt-zu-Punkt.
  8. Wählen Sie aus, wie Daten zwischen dem Geschäftsobjekt und der JMS-Nachricht serialisiert werden, und geben Sie die folgenden Werte ein (es empfiehlt sich, die Option Text anstelle von Objekt auszuwählen, weil der (normalerweise in XML stehende) Text von der Laufzeit unabhängig ist und die Serviceintegration zwischen unterschiedlichen und voneinander unabhängigen Systemen ermöglicht):
    1. Für Text, wählen Sie die Verwendung des JMS-Standardfunktionsselektors oder geben Sie den vollständig qualifizierten Namen der FunctionSelector-Implementierungsklasse ein.
    2. Für Objekt, wählen Sie die Verwendung des JMS-Standardfunktionsselektors oder geben Sie den vollständig qualifizierten Namen der FunctionSelector-Implementierungsklasse ein.
    3. Für Vom Benutzer bereitgestellt geben Sie den vollständig qualifizierten Namen der JMSDataBinding-Implementierungsklasse ein. Die Auswahl von Vom Benutzer bereitgestellt ist erforderlich, wenn Ihre Anwendung auf JMS-Headereigenschaften zugreifen muss, die im JMS-Importbinding nicht verfügbar sind. In diesem Fall müssen Sie dann eine Klasse für das angepasste Datenbinding erstellen, die das JMS-Standarddatenbinding com.ibm.websphere.sca.jms.data.JMSDataBinding erweitert, und angepassten Code für den direkten Zugriff auf 'JMSMessage' hinzufügen. Danach geben Sie den Namen der angepassten Klasse für dieses Feld an. Weitere Informationen finden Sie in den JMS-Beispielen des Abschnitts 'Bindings für Import- und Exportkomponenten erstellen und ändern', die Sie über den unten stehenden Link aufrufen können.
    4. Für Vom Benutzer bereitgestellt, wählen Sie die Verwendung des JMS-Standardfunktionsselektors oder geben Sie den vollständig qualifizierten Namen der FunctionSelector-Implementierungsklasse ein.
  9. Wählen Sie nach der Erstellung des Exports mit JMS-Binding den Export im Assembly-Editor aus. Wählen Sie dann in der Sicht 'Eigenschaften' das Inhaltsteilfenster Beschreibung aus. Der Name und die Beschreibung des Exports werden aufgelistet und können auf Wunsch geändert werden.
  10. Wählen Sie das Inhaltsteilfenster 'Binding', um weitere Optionen anzuzeigen.
  11. Speichern Sie das Assembly-Diagramm.

Migration des IBM Web-Service-Binding (SOAP/JMS)

Das IBM Web-Service-Binding (SOAP/JMS) für einen BPEL-Prozess oder einen anderen Servicetyp kann zur empfohlenen SCA-Anweisung migriert werden.

In WebSphere Studio Application Developer Integration Edition, gab dieser Bindingtyp Clients die Möglichkeit, mit einem BPEL-Prozess oder einem anderen Servicetyp durch Aufruf des IBM Web Service zu kommunizieren, wobei es sich beim Übertragungsprotokoll um JMS handelte und die Nachricht die SOAP-Codierregeln befolgte.

Das folgende Beispiel veranschaulicht die Konventionen, die bei der Generierung eines IBM Web-Service (SOAP/JMS) für einen 5.1-BPEL-Service zu Anwendung kommen. Der JNDI-Name des generierten IBM Web Service war eine Kombination aus BPEL-Name, Zielnamensbereich und 'Gültig-ab'-Zeitmarke, sowie dem Namen der Schnittstelle (WSDL-Porttyp, für den der Implementiercode generiert wurde). Die folgenden Attribute können beispielsweise durch Überprüfung der BPEL-Prozesseigenschaften im BPEL-Editor auf den Registerkarten 'Beschreibung' und 'Serverinhalt' gefunden werden:

Tabelle 6. Generierter Namensbereich
Prozessname MyService
Zielnamensbereich http://www.example.com/process87787141/
Gültig ab Jan 01 2003 02:03:04
Schnittstelle ProcessPortType

Der generierte Namensbereich für dieses Beispiel lautet daraufhin com/example/www/process87787141/MyService20030101T020304_ProcessPortTypePT.

In WebSphere Studio Application Developer Integration Edition gab es die folgenden Optionen zur Auswahl, wenn das IBM Web-Service-Binding (SOAP/JMS) als Implementiertyp für einen BPEL-Prozess oder einen anderen Servicetyp ausgewählt wurde:

Eine WSDL-Datei, die das IBM Web Service SOAP/JMS-Binding und den Service angibt, wird im generierten EJB-Projekt, jedoch nicht im Serviceprojekt selbst erstellt. Das bedeutet, dass Sie die Datei manuell suchen und in Ihr Geschäftsintegrations-Modulprojekt kopieren müssen, wenn der IBM Web-Service-Client-Code nicht geändert werden darf. Standardmäßig wurde diese WSDL-Datei im EJB-Projekt unter ejbModule/META-INF/wsdl/<Geschäftsprozessname>_ <Geschäftsprozessschnittstellen-Porttypname>_JMS.wsdl erstellt.

Der WSDL PortType und Nachrichten der Geschäftsprozessschnittstelle werden ebenso in diese WSDL-Datei kopiert, statt auf den vorhandenen WSDL PortType und Nachrichten, die im Serviceprojekt definiert sind, zu verweisen.

Wenn der IBM Web-Service-Client-Code nach der Migration unverändert sein soll, wird die Information in dieser Datei für die unten aufgeführten manuellen Migrationsschritte benötigt.

Es gibt zwei Optionen für die Migration des WebSphere Studio Application Developer Integration Edition SOAP/JMS-Prozessbinding. Es muss entschieden werden, ob der Client zum SCA-Programmiermodell migriert wird oder ob er als Web-Services-Client belassen wird:

Anmerkung: Wenn die manuellen Migrationsschritte abgeschlossen sind, muss der Client ebenso zum neuen Programmiermodell migriert werden. Weitere Informationen finden Sie im entsprechenden Thema für die folgenden Client-Typen:

Tabelle 7. Weitere Informationen für die Migration von Clients
Clienttyp Weitere Informationen finden Sie in
IBM Web-Service-Client "Migration des IBM Web Service (SOAP/JMS) Client"

Migrationsoption 1 für das IBM Web-Service-Binding (SOAP/JMS)

Die erste Migrationsoption für das WebSphere Studio Application Developer Integration Edition SOAP/JMS-Binding ermöglicht einem Web-Services-Client den Zugriff auf den Service.

Der Export mit Web-Service-Binding ermöglicht den Zugriff auf eine SCA-Komponente über einen externen Web-Services-Client. Führen Sie die folgenden Schritte aus, um einen Export mit Web-Service-Binding zu erstellen:

  1. Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
  2. Erstellen Sie einen Export mit SCA-Binding für jede Serviceschnittstelle, für die ein IBM Web Service (SOAP/JMS)-Binding inWebSphere Studio Application Developer Integration Edition generiert wurde:
    1. Klicken Sie mit der rechten Maustaste auf die SCA-Komponente im Assembly-Editor.
    2. Wählen Sie Exportieren....
    3. Wählen Sie Web-Service-Binding.
    4. Wenn es mehrere Schnittstellen für die Komponente gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
    5. Wählen Sie die Transport-soap/jms.
  3. Nach Erstellung des Web-Services-Exports wählen Sie den Export im Assembly-Editor aus. Wählen Sie dann in der Sicht 'Eigenschaften' das Inhaltsteilfenster Beschreibung aus. Der Name und die Beschreibung des Exports werden aufgelistet und können auf Wunsch geändert werden.
  4. Speichern Sie das Assembly-Diagramm.
  5. Wählen Sie das Inhaltsteilfenster 'Binding', in dem Sie sehen können, dass ein IBM Web Service WSDL-Binding und Service direkt im Projektordner des Moduls erstellt wurde. Es erhält den Namen component-that-was-exportedExportWSDL PortType name Jms_Service.wsdl. Wenn Sie diese Datei untersuchen, werden Sie feststellen, dass das eingeschlossene Dokument/Literal-Binding standardmäßig verwendet wird, da dies der bevorzugte Stil in 6.x ist. Dies ist die WSDL, die von IBM Web-Service-Clients für den Aufruf des Service verwendet werden wird.
  6. Führen Sie diese Schritte durch, um ein neues Web-Service-Binding und einen Service zu generieren, wenn das Beibehalten des Client-Codes gewünscht ist:
    1. Kopieren Sie die 5.1 WSDL-Datei aus dem generierten 5.1 EJB-Projekt unter ejbModule/META-INF/wsdl/Geschäftsprozessname/Geschäftsprozessschnittstellen-PorttypnameJMS.wsdl in das Geschäftsintegrations-Modulprojekt.
    2. Nach dem Kopieren der Datei und der Neuerstellung des Moduls werden möglicherweise Fehlermeldungen angezeigt, da die vom Web-Service verwendeten XML-Schematypen, WSDL-Nachrichten und WSDL-Porttypen in der WSDL-Datei desIBM Web-Services in 5.1 doppelt vorhanden sind. Um dies zu beheben, löschen Sie diese doppelt vorhandenen Definitionen aus der Binding/Service-WSDL des IBM Web-Service und fügen Sie an deren Stelle einen WSDL-Import für die echte Schnittstellen-WSDL hinzu. Hinweis: Beachten Sie, dass die Schemendefinitionen in bestimmten Fällen geändert wurden, als der IBM Web-Service-Implementierungscode von WebSphere Studio Application Developer Integration Edition generiert wurde. Dies führt unter Umständen zu Inkonsistenzen für vorhandene Clients, die die IBM Web-Service-WSDL verwenden. Das Schemaattribut "elementFormDefault" beispielsweise wurde in dem Inline-Schema, das in der IBM Web-Service-WSDL generiert wurde, auf "qualifiziert" gesetzt, auch wenn die ursprüngliche Schemadefinition nicht qualifiziert war. Dadurch wurde der folgende Fehler während der Laufzeit generiert: WSWS3047E: Fehler: Element kann nicht entserealisiert werden.
    3. Klicken Sie mit der rechten Maustaste auf diese WSDL-Datei, die Sie soeben in das Geschäftsintegrationsmodul kopiert haben, und wählen Sie Öffnen mit und WSDL-Editor.
    4. Gehen Sie zur Registerkarte 'Quelle'. Löschen Sie alle in dieser Datei definierten WSDL PortTypes und Nachrichten.
    5. Daraufhin wird folgender Fehler angezeigt: Der für das '<binding>' Binding angegebene '<portType>' Porttyp ist nicht definiert. Um dies zu beheben, klicken Sie im WSDL-Editor in der Diagrammsicht mit der rechten Maustaste auf den Importabschnitt und wählen Sie Import hinzufügen.
    6. Klicken Sie in der Sicht 'Eigenschaften' in der Registerkarte 'Allgemein' auf die Schaltfläche ... rechts neben dem Feld für die Speicherposition. Blättern Sie zur Schnittstellen-WSDL, in der sich die WSDL-Nachricht und die Porttypdefinitionen befinden und klicken Sie auf OK, um die Schnittstellen-WSDL in die Service/Binding-WSDL zu kopieren.
    7. Speichern Sie die WSDL-Datei.
    8. Aktualisieren/erstellen Sie das Projekt neu. Wechseln Sie in die Geschäftsintegrationsperspektive. Öffnen Sie das Assembly-Diagramm des Moduls im Assembly-Editor.
    9. Erweitern Sie das zu migrierende Modul in der Sicht 'Projektexplorer', und erweitern Sie die logische Kategorie Web-Service-Ports. Der in der Binding/Service-WSDL vorhandene Port sollte nun angezeigt werden. Ziehen und übergeben Sie ihn an den Assembly-Editor.
    10. Wählen Sie die Erstellung eines Exports mit Web-Service-Binding und wählen Sie den entsprechenden Portnamen. Dadurch wird der Export erstellt, der das alte Binding/Service verwendet, sodass vorhandene Web-Service-Clients nicht geändert werden müssen. Wenn Sie den Export auswählen, den Sie soeben im Assembly-Editor erstellt haben und zur Sicht 'Eigenschaften' gehen, wird in der Registerkarte 'Binding' angezeigt, dass die 5.1 Port- und Servicenamen für Sie eingetragen wurden.
    11. Speichern Sie alle Änderungen.
    12. Kurz vor der Implementierung der Anwendung können Sie die Konfiguration des generierten Web-Projekts ändern, so dass Sie der 5.1 Serviceadresse entspricht (Sie müssen diese Änderungen jedes Mal durchführen, wenn Sie Änderungen am SCA-Modul vornehmen, durch die diese Datei erneut generiert wird). Wenn Sie die Servicedefinition der aus 5.1 wiederverwendeten IBM Web-Service-WSDL aufrufen, wird die Serviceadresse angezeigt, für die der 5.1-Client codiert ist: <wsdlsoap:address location="http://localhost:9080/MyServiceWeb/services/MyServicePort"/>
    13. Damit die generierten 6.x-Webprojekt-Artefakte mit dieser alten Serviceadresse übereinstimmen, müssen Sie den generierten Implementierungsdeskriptor des Webprojekts ändern. Öffnen Sie den Implementierungsdeskriptor in WebSphere Integration Developer und fügen Sie in der Registerkarte 'Servlets' eine zusätzliche URL-Zuordnung hinzu, die der vorhandenen URL-Zuordnung für diesen Export ähnelt, mit dem gleichen Servlet-Namen aber einem anderen URL-Muster.
    14. Wenn Sie außerdem das Kontextstammverzeichnis dieses Web-Projekts ändern müssen, so dass es dem Kontextstammverzeichnis in der ursprünglichen Serviceadresse entspricht (in diesem Beispiel ist das Kontextstammverzeichnis 'MyServiceWeb'), öffnen Sie den Implementierungsdeskriptor für die J2EE-Unternehmensanwendung, in dem sich dieses Webprojekt befindet, und ändern Sie das Kontextstammverzeichnis dieses Webmoduls, so dass es dem Kontextstammverzeichnis der alten Serviceadresse entspricht. Möglicherweise wird der folgende Fehler angezeigt, den Sie ignorieren können: CHKJ3017E: Webprojekt: <WEB PROJ NAME> ist einem ungültigen Kontextstammverzeichnis zugeordnet: <NEW CONTEXT ROOT> in EAR-Projekt: <APP NAME>.
Migrationsoption 2 für das IBM Web-Service-Binding (SOAP/JMS)

Die zweite Migrationsoption für das WebSphere Studio Application Developer Integration Edition SOAP/JMS-Prozessbinding ist es, Geschäftsprozesse für eine nicht-SCA-Entität (beispielsweise eine JSP oder einen Java-Client) zugänglich zu machen.

Die Standalone Reference macht eine SCA-Komponente durch einen beliebigen externen Client zugänglich. Führen Sie die folgenden Schritte aus, um eine Standalone Reference zu erstellen:

  1. Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
  2. Erstellen Sie eine Standalone Reference für jede BPEL-Prozessschnittstelle, für die ein IBM Web Service (SOAP/JMS)-Binding in WebSphere Studio Application Developer Integration Edition generiert wurde:
    1. Wählen Sie das Element Standalone References in der Symbolleiste aus.
    2. Klicken Sie auf den Erstellungsbereich des Assembly-Editors, um eine Standalone References SCA-Entität zu erstellen.
    3. Wählen Sie das Element Verbinden in der Symbolleiste.
    4. Klicken Sie auf die Entität Standalone References, um sie als Quelle für die Verbindung auszuwählen.
    5. Klicken Sie auf die Komponente BPEL SCA, um sie als Ziel für die Verbindung auszuwählen.
    6. Es erscheint die Warnung Am Quellenknoten wird ein übereinstimmender Verweis erstellt. Möchten Sie fortfahren?. Klicken Sie auf OK.
    7. Wählen Sie die Entität Standalone References aus, die soeben erstellt wurde. Wählen Sie dann in der Sicht 'Eigenschaften' das Inhaltsteilfenster Beschreibung aus.
    8. Erweitern Sie den Link Verweise und wählen Sie die soeben erstellte Referenz. Der Name und die Beschreibung der Referenz werden aufgelistet und können auf Wunsch geändert werden.
    9. Wenn es mehrere Schnittstellen für den Prozess gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
    10. Speichern Sie das Assembly-Diagramm.

Migration des IBM Web-Service-Binding (SOAP/HTTP)

Das IBM Web-Service-Binding (SOAP/HTTP) für einen BPEL-Prozess oder einen anderen Servicetyp kann zur empfohlenen SCA-Anweisung migriert werden.

In WebSphere Studio Application Developer Integration Edition, gab dieser Bindingtyp Clients die Möglichkeit, mit einem BPEL-Prozess oder einem anderen Servicetyp durch Aufruf des IBM Web Service zu kommunizieren, wobei es sich beim Übertragungsprotokoll um HTTP handelte und die Nachricht die SOAP-Codierregeln befolgte.

Das folgende Beispiel veranschaulicht die Konventionen, die bei der Generierung eines IBM Web-Service (SOAP/HTTP) für einen 5.1-BPEL-Service zu Anwendung kommen. Der JNDI-Name des generierten IBM Web Service war eine Kombination aus BPEL-Name, Zielnamensbereich und 'Gültig-ab'-Zeitmarke, sowie dem Namen der Schnittstelle (WSDL-Porttyp, für den der Implementiercode generiert wurde). Die folgenden Attribute können beispielsweise durch Überprüfung der BPEL-Prozesseigenschaften im BPEL-Editor auf den Registerkarten 'Beschreibung' und 'Serverinhalt' gefunden werden:

Tabelle 8. Generierter Namensbereich
Prozessname MyService
Zielnamensbereich http://www.example.com/process87787141/
Gültig ab Jan 01 2003 02:03:04
Schnittstelle ProcessPortType

Der generierte Namensbereich für dieses Beispiel lautet daraufhin com/example/www/process87787141/MyService20030101T020304_ProcessPortTypePT.

In WebSphere Studio Application Developer Integration Edition gab es die folgenden Optionen zur Auswahl, wenn das IBM Web-Service-Binding (SOAP/HTTP) als Implementiertyp für einen BPEL-Prozess oder einen anderen Servicetyp ausgewählt wurde:

Eine WSDL-Datei, die das IBM Web Service SOAP/HTTP-Binding und den Service angibt, wird in den generierten Web- und EJB-Projekten, jedoch nicht im Serviceprojekt selbst erstellt. Das bedeutet, dass Sie die Datei manuell suchen und in Ihr Geschäftsintegrations-Modulprojekt kopieren müssen, wenn der IBM Web-Service-Client-Code nicht geändert werden darf. Standardmäßig wurde diese WSDL-Datei im Webprojekt unter WebContent/WEB-INF/wsdl/<Geschäftsprozessname>_<Geschäftsprozessschnittstellen-Porttypname>_HTTP.wsdl erstellt.

Der WSDL PortType und Nachrichten der Geschäftsprozessschnittstelle werden ebenso in diese WSDL-Datei kopiert, statt auf den vorhandenen WSDL PortType und Nachrichten, die im Serviceprojekt definiert sind, zu verweisen.

Wenn der IBM Web-Service-Client-Code nach der Migration unverändert sein soll, wird die Information in dieser Datei für die unten aufgeführten manuellen Migrationsschritte benötigt.

Es gibt zwei Optionen für die Migration des WebSphere Studio Application Developer Integration Edition SOAP/HTTP-Prozessbinding. Es muss entschieden werden, ob der Client zum SCA-Programmiermodell migriert wird oder ob er als Web-Services-Client belassen wird:

Anmerkung: Wenn die manuellen Migrationsschritte abgeschlossen sind, muss der Client ebenso zum neuen Programmiermodell migriert werden. Weitere Informationen finden Sie im entsprechenden Thema für die folgenden Client-Typen:

Tabelle 9. Weitere Informationen für die Migration von Clients
Clienttyp Weitere Informationen finden Sie in
IBM Web-Service-Client "Migration des IBM Web Service (SOAP/HTTP) Client"

Migrationsoption 1 für das IBM Web-Service-Binding (SOAP/HTTP)

Die erste Migrationsoption für das WebSphere Studio Application Developer Integration Edition SOAP/HTTP-Prozessbinding ist die Ermöglichung des Zugriffs auf Geschäftsprozesse durch einen Web-Services-Client.

Der Export mit Web-Service-Binding ermöglicht den Zugriff auf eine SCA-Komponente über einen externen Web-Services-Client. Führen Sie die folgenden Schritte aus, um einen Export mit Web-Service-Binding zu erstellen:

  1. Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
  2. Erstellen Sie einen Export mit SCA-Binding für jede BPEL-Prozessschnittstelle, für die ein IBM Web-Service-Binding (SOAP/HTTP) in WebSphere Studio Application Developer Integration Edition generiert wurde, durch Klicken mit der rechten Maustaste auf die BPEL-Komponente im Assembly-Editor.
  3. Wählen Sie Exportieren....
  4. Wählen Sie Web-Service-Binding.
  5. Wenn es mehrere Schnittstellen für die Komponente gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
  6. Wählen Sie die Transport-soap/http.
  7. Nach Erstellung des Web-Services-Exports wählen Sie den Export im Assembly-Editor aus. Wählen Sie dann in der Sicht 'Eigenschaften' das Inhaltsteilfenster Beschreibung aus. Der Name und die Beschreibung des Exports werden aufgelistet und können auf Wunsch geändert werden.
  8. Speichern Sie das Assembly-Diagramm.
  9. Führen Sie diese Schritte durch, um ein neues Web-Service-Binding und einen Service zu generieren, wenn das Beibehalten des Client-Codes gewünscht ist:
    1. Kopieren Sie die 5.1 WSDL-Datei aus dem generierten 5.1 EJB-Projekt unter ejbModule/META-INF/wsdl/Geschäftsprozessname/Geschäftsprozessschnittstellen-Porttypname_HTTP.wsdl in das Geschäftsintegrations-Modulprojekt.
    2. Nach dem Kopieren der Datei und der Neuerstellung des Moduls werden möglicherweise Fehlermeldungen angezeigt, da die vom Web-Service verwendeten XML-Schematypen, WSDL-Nachrichten und WSDL-Porttypen in der WSDL-Datei des IBM Web-Service in 5.1 doppelt vorhanden sind. Um dies zu beheben, löschen Sie diese doppelt vorhandenen Definitionen aus der Binding/Service-WSDL des IBM Web-Service und fügen Sie an deren Stelle einen WSDL-Import für die echte Schnittstellen-WSDL hinzu. Hinweis: Beachten Sie, dass die Schemendefinitionen in bestimmten Fällen geändert wurden, als der IBM Web-Service-Implementierungscode von WebSphere Studio Application Developer Integration Edition generiert wurde. Dies führt unter Umständen zu Inkonsistenzen für vorhandene Clients, die die IBM Web-Service- WSDL verwenden. Das Schemaattribut "elementFormDefault" beispielsweise wurde in dem Inline-Schema, das in der IBM Web-Service-WSDL generiert wurde, auf "qualifiziert" gesetzt, auch wenn die ursprüngliche Schemadefinition nicht qualifiziert war. Dadurch wurde der folgende Fehler während der Laufzeit generiert: WSWS3047E: Fehler: Element kann nicht entserealisiert werden.
    3. Klicken Sie mit der rechten Maustaste auf diese WSDL-Datei, die Sie soeben in das Geschäftsintegrationsmodul kopiert haben, und wählen Sie Öffnen mit und WSDL-Editor.
    4. Gehen Sie zur Registerkarte 'Quelle'. Löschen Sie alle in dieser Datei definierten WSDL PortTypes und Nachrichten.
    5. Daraufhin wird folgender Fehler angezeigt: Der für das Binding '<binding>' angegebene Porttyp '<portType>' ist nicht definiert. Um dies zu beheben, klicken Sie im WSDL-Editor in der Diagrammsicht mit der rechten Maustaste auf den Importabschnitt und wählen Sie Import hinzufügen.
    6. Klicken Sie in der Sicht 'Eigenschaften' in der Registerkarte 'Allgemein' auf die Schaltfläche ... rechts neben dem Feld für die Speicherposition. Blättern Sie zur Schnittstellen-WSDL, in der sich die WSDL-Nachricht und die Porttypdefinitionen befinden und klicken Sie auf OK, um die Schnittstellen-WSDL in die Service/Binding-WSDL zu kopieren.
    7. Speichern Sie die WSDL-Datei.
    8. Aktualisieren/erstellen Sie das Projekt neu. Wechseln Sie in die Geschäftsintegrationsperspektive. Öffnen Sie das Assembly-Diagramm des Moduls im Assembly-Editor.
    9. Erweitern Sie das zu migrierende Modul in der Sicht 'Projektexplorer', und erweitern Sie die logische Kategorie Web-Service-Ports. Der in der Binding/Service-WSDL vorhandene Port sollte nun angezeigt werden. Ziehen und übergeben Sie ihn an den Assembly-Editor.
    10. Wählen Sie die Erstellung eines Exports mit Web-Service-Binding und wählen Sie den entsprechenden Portnamen. Dadurch wird der Export erstellt, der das alte Binding/Service verwendet, sodass vorhandene Web-Service-Clients nicht geändert werden müssen. Wenn Sie den Export auswählen, den Sie soeben im Assembly-Editor erstellt haben und zur Sicht 'Eigenschaften' gehen, wird in der Registerkarte 'Binding' angezeigt, dass die 5.1 Port- und Servicenamen für Sie eingetragen wurden.
    11. Speichern Sie alle Änderungen.
    12. Kurz vor der Implementierung der Anwendung können Sie die Konfiguration des generierten Web-Projekts ändern, so dass Sie der 5.1 Serviceadresse entspricht (Sie müssen diese Änderungen jedes Mal durchführen, wenn Sie Änderungen am SCA-Modul vornehmen, durch die diese Datei erneut generiert wird). Wenn Sie die Servicedefinition der aus 5.1 wiederverwendeten IBM Web-Service-WSDL aufrufen, wird die Serviceadresse angezeigt, für die der 5.1-Client codiert ist: <wsdlsoap:address location="http://localhost:9080/MyServiceWeb/services/MyServicePort"/>
    13. Damit die generierten 6.x-Webprojekt-Artefakte mit dieser alten Serviceadresse übereinstimmen, müssen Sie den generierten Implementierungsdeskriptor des Webprojekts ändern. Öffnen Sie den Implementierungsdeskriptor in WebSphere Integration Developer und fügen Sie in der Registerkarte 'Servlets' eine zusätzliche URL-Zuordnung hinzu, die der vorhandenen URL-Zuordnung für diesen Export ähnelt, mit dem gleichen Servlet-Namen aber einem anderen URL-Muster.
    14. Wenn Sie außerdem das Kontextstammverzeichnis dieses Web-Projekts ändern müssen, so dass es dem Kontextstammverzeichnis in der ursprünglichen Serviceadresse entspricht (in diesem Beispiel ist das Kontextstammverzeichnis 'MyServiceWeb'), öffnen Sie den Implementierungsdeskriptor für die J2EE-Unternehmensanwendung, in dem sich dieses Webprojekt befindet, und ändern Sie das Kontextstammverzeichnis dieses Webmoduls, so dass es dem Kontextstammverzeichnis der alten Serviceadresse entspricht. Möglicherweise wird der folgende Fehler angezeigt, den Sie ignorieren können: CHKJ3017E: Webprojekt: <WEB PROJ NAME> ist einem ungültigen Kontextstammverzeichnis zugeordnet: <NEW CONTEXT ROOT> in EAR-Projekt: <APP NAME>.
Migrationsoption 2 für das IBM Web-Service-Binding (SOAP/HTTP)

Die zweite Migrationsoption für das WebSphere Studio Application Developer Integration Edition SOAP/HTTP-Prozessbinding ist es, Geschäftsprozesse für eine nicht-SCA-Entität (beispielsweise eine JSP oder einen Java-Client) zugänglich zu machen.

Die Standalone Reference macht eine SCA-Komponente durch einen beliebigen externen Client zugänglich. Führen Sie die folgenden Schritte aus, um eine Standalone Reference zu erstellen:

  1. Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
  2. Erstellen Sie eine Standalone Reference für jede Schnittstelle, für die ein IBM Web Service (SOAP/HTTP)-Binding in WebSphere Studio Application Developer Integration Edition generiert wurde:
    1. Wählen Sie das Element Standalone References in der Symbolleiste aus.
    2. Klicken Sie auf den Erstellungsbereich des Assembly-Editors, um eine Standalone References SCA-Entität zu erstellen.
    3. Wählen Sie das Element Verbinden in der Symbolleiste.
    4. Klicken Sie auf die Entität Standalone References, um sie als Quelle für die Verbindung auszuwählen.
    5. Klicken Sie auf die Komponente SCA, um sie als Ziel für die Verbindung auszuwählen.
    6. Es erscheint die Warnung Am Quellenknoten wird ein übereinstimmender Verweis erstellt. Möchten Sie fortfahren?. Klicken Sie auf OK.
    7. Wählen Sie die Entität Standalone References, die soeben erstellt wurde, und wählen Sie in der Sicht 'Eigenschaften' das Inhaltsteilfenster Beschreibung.
    8. Erweitern Sie den Link Verweise und wählen Sie die soeben erstellte Referenz. Der Name und die Beschreibung der Referenz werden aufgelistet und können auf Wunsch geändert werden.
    9. Wenn es mehrere Schnittstellen für den Prozess gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
    10. Speichern Sie das Assembly-Diagramm.

Migration des Apache Web-Service-Binding (SOAP/HTTP)

Das Apache Web-Service-Binding (SOAP/HTTP) für einen BPEL-Prozess oder einen anderen Servicetyp kann zur empfohlenen SCA-Anweisung migriert werden.

In WebSphere Studio Application Developer Integration Edition hat dieser Bindingtyp Clients die Kommunikation mit einem BPEL-Prozess oder einem anderen Servicetyp durch Aufruf eines Apache Web-Service ermöglicht.

In WebSphere Studio Application Developer Integration Edition gab es die folgenden Optionen zur Auswahl, wenn das Apache Web-Service-Binding als Implementiertyp für einen BPEL-Prozess oder einen anderen Servicetyp ausgewählt wurde:

Eine WSDL-Datei, die das Apache SOAP-Binding und den Service angibt, wird im Serviceprojekt erstellt. Standardmäßig wird sie in demselben Verzeichnis wie der Service erstellt, der mit dem Namen <Geschäftsprozessname>_<Geschäftsprozessschnittstellen-Porttypname>_SOAP.wsdl eingeschlossen wird. Der WSDL PortType und Nachrichten der Geschäftsprozessschnittstelle werden direkt von diesem Binding und Service verwendet. Nach der Migration sollten Sie diese WSDL für nichts anderes außer möglicherweise für denselben Namensbereich, Port und Servicenamen in der neuen WSDL verwenden, die für Sie in Version 6.x generiert wird.

Es gibt zwei Optionen für die Migration des WebSphere Studio Application Developer Integration Edition Web Service-Prozessbinding. Es muss entschieden werden, ob der Client zum SCA-Programmiermodell migriert wird oder ob er als IBM Web-Services-Programmiermodell belassen wird. Es gibt kein Binding mehr, das dem Apache Web Service (SOAP/HTTP) -Bindingtyp im 6 SCA-Programmiermodell entspricht.

Migrieren Sie diesen Apache Web Service zur Verwendung der IBM Web-Service-Engine. Weitere Informationen zur Durchführung dieser Migration und Erstellung eines IBM Web-Service (SOAP/HTTP) finden Sie im Thema "Migration des IBM Web-Service-Binding (SOAP/HTTP)".

Migration zum SCA-Programmiermodell

Dieser Abschnitt bezieht sich auf jeden unformatierten Java-Code, der mit einem WebSphere Studio Application Developer Integration Edition-Service im Dialog steht, und veranschaulicht die Migration vom WSIF-Programmiermodell zum neuen SCA-Programmiermodell, wobei der Datenfluss durch die Anwendung in Eclipse Service Data Objects (SDOs) gespeichert wird. Dieser Abschnitt beschreibt außerdem, wie Sie die gängigsten Client-Typen manuell zum neuen Programmiermodell migrieren.

Im Falle von BPEL Prozessen, die Java Snippets enthalten, veranschaulicht dieser Abschnitt die Migration von der alten Java Snippet API zur neuen Java Snippet API, wobei der Datenfluss durch die Anwendung in Eclipse Service Data Objects (SDOs) gespeichert wird. Wenn möglich, werden die Snippets automatisch durch den Migrationsassistenten migriert, es gibt jedoch Snippets, die vom Migrationsassistenten nicht vollständig migriert werden können, was bedeutet, dass manuelle Schritte für den Abschluss der Migration erforderlich sind.

Im Folgenden finden Sie eine Zusammenfassung der Änderungen des Programmiermodells:

Version 5.1 - Programmiermodell
  1. WSIF- und WSDL-basiert
  2. Generierte Proxys für Services
  3. Beans und Formatsteuerroutinen für Typen
Version 6.x - Programmiermodell (Java-zentrierter)
  1. SCA-Services basierend auf SDOs mit Doclet-Tags
  2. Schnittstellenbindings für Services
  3. SDOs und Datenbindings für Typen

Migration von WSIFMessage API-Aufrufen zu SDO APIs

In dem folgenden Abschnitt wird die Migration vom alten WebSphere Business Integration Server Foundation-Programmiermodell, in dem der Datenfluss durch die Anwendung als WSIFMessage-Objekte mit einer generierten Schnittstelle, die stark typisiert war, dargestellt wird, zum neuen Programmiermodell von WebSphere Process Server Version 6.0 beschrieben, in dem die Daten als Service Data Objects (SDOs) dargestellt werden und keine stark typisierte Schnittstelle generiert wird.

Tabelle 10. Änderungen und Lösungen der Migration von WSIFMessage API-Aufrufen zu SDO APIs
Änderung Lösung
WSIFMessage-basierte Wrapper-Klassen werden nicht mehr für WSDL-Nachrichtentypen generiert, und auch die Java-Bean Helper-Klassen werden nicht mehr für komplexe Schementypen generiert. Beim Schreiben von Code, der mit SCA-Services interagiert, müssen die generischen SDO APIs für die Manipulation der commonj.sdo.DataObject-Nachrichten verwendet werden, die die durch die Anwendung fließenden Daten enthalten.

WSDL-Nachrichtendefinitionen, die über einen einzelnen einfach typisierten Abschnitt verfügen, werden nun durch einen einfachen Java-Typ dargestellt, der den Abschnitt direkt darstellt , statt die tatsächlichen Daten ein einen Wrapper einzuschließen. Wenn es sich beim einzelnen Nachrichtenabschnitt um einen komplexen Typ handelt, werden die Daten als ein DataObject dargestellt, das die komplexe Typdefinition befolgt.

WSDL-Nachrichtendefinitionen, die über mehrere Abschnitte verfügen, entsprechen nun einem DataObject, das über Eigenschaften für alle Nachrichtenabschnitte verfügt, wobei complexTypes als "Referenztyp"-Eigenschaften des übergeordneten DataObject dargestellt werden, auf die über getDataObject- und setDataObject-Methoden zugegriffen werden kann.

Stark typisierte Getter-Methoden für WSIFMessage-Abschnitte und generierte Java-Beans sollten nicht verwendet werden. Schwach typisierte SDO APIs sollten für den Abruf von DataObject-Eigenschaften verwendet werden.
Stark typisierte Setter-Methoden für Nachrichtenabschnitte von BPEL-Variablen sind nicht mehr verfügbar. Schwach typisierte SDO APIs müssen für die Einrichtung der DataObject-Eigenschaften verwendet werden.
Schwach typisierte Getter-Methoden für WSIFMessage-Eigenschaften sollten nicht mehr verwendet werden. Schwach typisierte SDO APIs müssen für die Einrichtung der DataObject-Eigenschaften verwendet werden.
Schwach typisierte Setter-Methoden für WSIFMessage-Eigenschaften sollten nicht mehr verwendet werden. Schwach typisierte SDO APIs müssen für die Einrichtung der DataObject-Eigenschaften verwendet werden.
Alle WSIFMessage API-Aufrufe sollten wenn möglich zur SDO API migriert werden. Migrieren Sie den Aufruf wenn möglich zu einem äquivalenten SDO API-Aufruf. Überarbeiten Sie die Logik, wenn dies nicht möglich ist.

Migration des WebSphere Business Integration Server Foundation Client-Codes

Dieser Abschnitt beschreibt die Migration verschiedener Client-Typen, die für die WebSphere Business Integration Server Foundation 5.1-Servicetypen möglich waren.

Migration des EJB Client

Dieses Thema erläutert die Migration von Clients, die eine EJB-Schnittstelle verwenden, um einen Service aufzurufen.

  1. Ziehen und übergeben Sie den Export (mit Drag and Drop) mit SCA Binding vom migrierten Modell zum Assembly-Editor dieses neuen Moduls. Dadurch wird ein Import mit SCA Binding erstellt. Damit ein Client einen Verweis zu diesem Import abrufen kann, muss ein Standalone-Verweis erstellt werden.
  2. Wählen Sie auf der Palette den Standalone-Verweis. Klicken Sie einmal auf den Assembly Editor-Erstellungsbereich, um einen Standalone-Verweis für dieses neue Modul zu erstellen.
  3. Wählen Sie das Verbindungstool, klicken Sie auf den Serviceverweis und daraufhin auf Importieren.
  4. Klicken Sie auf OK, wenn Sie gewarnt werden, dass ein übereinstimmender Verweis am Quellenknoten erstellt wird.
  5. Sie werden gefragt: Es ist für einen Java-Client einfacher, eine Java-Schnittstelle mit diesem Verweis zu verwenden - möchten Sie den WSDL-Verweis in einen kompatiblen Java-Verweis umwandeln?:
    1. Beantworten Sie diese Frage mit Ja, wenn dieser Client diesen Service abrufen soll und ihn als Java-Klasse umsetzen soll, um ihn mit einer Java-Schnittstelle aufzurufen. Diese neue Java-Schnittstelle übernimmt ihren Namen vom WSDL PortType, wobei das Paket der Schnittstelle vom Namensbereich des WSDL PortType hergeleitet wird. Für jede auf dem WSDL PortType definierte Operation gibt es eine definierte Methode, und jeder WSDL-Nachrichtenabschnitt wird als Argument zu den Schnittstellenmethoden dargestellt.
    2. Beantworten Sie diese Frage mit Nein, wenn der Client diesen Service abrufen und die generische com.ibm.websphere.sca.Service-Schnittstelle verwenden soll, um ihn mit der Aufrufoperation als einen generischen SCA-Service aufzurufen.
  6. Benennen Sie den Standalone-Verweis gegebenenfalls in einen aussagekräftigeren Namen um, indem Sie die Standalone-Verweiskomponente im Assembly-Editor auswählen. Wählen Sie in der Sicht 'Eigenschaften' die Registerkarte 'Details', suchen Sie den Verweis, der soeben erstellt wurde, und ändern Sie den Namen. Notieren Sie sich den gewählten Namen für diesen Verweis, da der Client diesen Namen für den Aufruf der locateService-Methode der com.ibm.websphere.sca.ServiceManager-Instanz verwenden muss.
  7. Klicken Sie auf Speichern, um das Assembly-Diagramm zu speichern.

Dieses neue Modul muss auf dem lokalen Klassenpfad des Clients vorhanden sein, damit er auf das migrierte EJB-Modul, das auf dem Server ausgeführt wird, zugreifen kann.

Im folgenden finden Sie ein Beispiel eines Client-Codes für einen Service des Typs 'CustomerInfo':

// Create a new ServiceManager
ServiceManager serviceManager = ServiceManager.INSTANCE;

// Locate the CustomerInfo service
CustomerInfo customerInfoService = (CustomerInfo) serviceManager.locateService 
("<name-of-standalone-reference-from-previous-step");

	// Invoke the CustomerInfo service
	System.out.println("	[getMyValue] getting customer info...");
	DataObject customer = customerInfoService.getCustomerInfo(customerID);

Der Client muss die Konstruktion der Nachricht ändern. Die Nachrichten basierten zuvor auf der WSIFMessage-Klasse, sollten nun jedoch auf der commonj.sdo.DataObject-Klasse basieren.

Migration des EJB-Prozessbinding-Client

Dieses Thema erläutert die Migration von Clients, die das WSIF-EJB-Prozessbinding verwenden, um auf einen BPEL-Service zuzugreifen.

Clients, die das EJB-Prozessbinding für den Aufruf eines Geschäftsprozesses verwendet haben, sollten nun entweder die SCA API für den Aufruf des Service (der migrierte Geschäftsprozess muss über einen Export mit SCA-Binding verfügen) oder die IBM Web Service Client API verwenden, um den Service aufzurufen (der migrierte Geschäftsprozess muss über einen Export mit Web-Service-Binding verfügen).

Weitere Informationen zur Generierung solcher Clients finden Sie in den Themen "Migration des EJB Client", "Migration des IBM Web Service (SOAP/JMS) Client" und "Migration des IBM Web Service (SOAP/HTTP) Client".

Migration des IBM Web Service (SOAP/JMS) Client

Dieses Thema erläutert die Migration von Clients, die Web-Service-APIs (SOAP/JMS) verwenden, um einen Service aufzurufen.

Für vorhandene Clients ist während der Migration keine Migration erforderlich. Beachten Sie, dass Sie das generierte Webprojekt manuell ändern müssen (erstellen Sie eine neue Servlet-Zuordnung) und manchmal das Kontextstammverzeichnis des Webprojekts im Implementierungsdeskriptor der Unternehmensanwendung, um den Service mit der gleichen Adresse zu veröffentlichen, unter der er in WebSphere Business Integration Server Foundation veröffentlicht war. Weitere Informationen enthält das Thema "Migration des IBM Web-Service-Binding (SOAP/JMS)".

Beachten Sie, dass im Vergleich zu 5.1, in der ein WSIF- oder RPC-Client generiert werden konnte, die Tools in 6.x nur RPC Client-Erzeugung unterstützen, da RPC die bevorzugte API in 6.x gegenüber der WSIF-API ist.

Hinweis: Zur Erzeugung einer neuen Client Proxy aus WebSphere Integration Developer muss WebSphere Process Server oder WebSphere Application Server installiert sein.

  1. Vergewissern Sie sich, dass WebSphere Process Server oder WebSphere Application Server installiert ist.
  2. Suchen Sie in der Perspektive 'Ressourcen' oder Java nach der WSDL-Datei, die dem Export mit Web-Service-Binding entspricht, klicken Sie mit der rechten Maustaste und wählen Sie Web Services -> Client generieren (Beachten Sie, dass dieser Assistent dem Assistenten in 5.1 sehr ähnlich ist).
  3. Wählen Sie für den Client-Proxytyp Java-Proxy und klicken Sie auf Weiter.
  4. Die Position der WSDL sollte angegeben sein. Klicken Sie auf Weiter.
  5. Als nächstes müssen Sie die entsprechenden Optionen auswählen, um die Konfiguration Ihrer Client-Umgebung anzugeben, einschließlich der Laufzeit des Web-Service, Server, J2EE Version, Client-Typ (Java, EJB, Web, Anwendungs-Client). Klicken Sie auf Weiter.
  6. Führen Sie die verbleibenden Schritte durch, um den Client-Proxy zu generieren.
Migration des IBM Web Service (SOAP/HTTP) Client

Dieses Thema erläutert die Migration von Clients, die Web-Service-APIs (SOAP/HTTP) verwenden, um einen Service aufzurufen.

Für vorhandene Clients ist während der Migration keine Migration erforderlich. Beachten Sie, dass Sie das generierte Webprojekt manuell ändern müssen (erstellen Sie eine neue Servlet-Zuordnung) und manchmal das Kontextstammverzeichnis des Webprojekts im Implementierungsdeskriptor der Unternehmensanwendung, um den Service mit der gleichen Adresse zu veröffentlichen, unter der er in WebSphere Business Integration Server Foundation veröffentlicht war. Weitere Informationen enthält das Thema "Migration des IBM Web-Service-Binding (SOAP/HTTP)".

Wenn Änderungen von Konstruktionen aufgetreten sind und Sie einen neuen Client-Proxy generieren möchten, befolgen Sie die folgenden Schritte. Beachten Sie, dass im Vergleich zu 5.1, in der ein WSIF- oder RPC-Client generiert werden konnte, die Tools in 6.x nur RPC Client-Erzeugung unterstützen, da RPC die bevorzugte API in 6.x gegenüber der WSIF-API ist.

Hinweis: Zur Erzeugung einer neuen Client Proxy aus WebSphere Integration Developer muss WebSphere Process Server oder WebSphere Application Server installiert sein.

  1. Vergewissern Sie sich, dass WebSphere Process Server oder WebSphere Application Server installiert ist.
  2. Wählen Sie die WSDL-Datei, die dem Export mit Web-Service-Binding entspricht, klicken Sie mit der rechten Maustaste und wählen Sie Web Services -> Client generieren (Beachten Sie, dass dieser Assistent dem Assistenten in 5.1 sehr ähnlich ist).
  3. Wählen Sie für den Client-Proxytyp Java-Proxy und klicken Sie auf Weiter.
  4. Die Position der WSDL sollte angegeben sein. Klicken Sie auf Weiter.
  5. Als nächstes müssen Sie die entsprechenden Optionen auswählen, um die Konfiguration Ihrer Client-Umgebung anzugeben, einschließlich der Laufzeit des Web-Service, Server, J2EE Version, Client-Typ (Java, EJB, Web, Anwendungs-Client). Klicken Sie auf Weiter.
  6. Führen Sie die verbleibenden Schritte durch, um den Client-Proxy zu generieren.

Migration des Apache Web Service (SOAP/HTTP) Client

Die Apache Web Service Client APIs sind nicht für den Aufruf eines WebSphere Integration Developer Service geeignet. Client-Code muss für die Verwendung der IBM Web Service (SOAP/HTTP) Client APIs migriert werden.

Weitere Informationen enthält das Thema "Migration des IBM Web Service (SOAP/HTTP) Client".

Wenn ein Client-Proxy in 5.1 automatisch generiert wurde, hat dieser Proxy zur Interaktion mit dem Service WSIF-APIs verwendet. In 6.x unterstützen die Tools nur RPC Client- Erzeugung, da RPC die bevorzugte API in 6.x gegenüber der WSIF-API ist.

Hinweis: Zur Erzeugung einer neuen Client Proxy aus WebSphere Integration Developer muss WebSphere Process Server oder WebSphere Application Server installiert sein.

  1. Vergewissern Sie sich, dass WebSphere Process Server oder WebSphere Application Server installiert ist.
  2. Wählen Sie die WSDL-Datei, die dem Export mit Web-Service-Binding entspricht, klicken Sie mit der rechten Maustaste und wählen Sie Web Services -> Client generieren (Beachten Sie, dass dieser Assistent dem Assistenten in 5.1 sehr ähnlich ist).
  3. Wählen Sie für den Client-Proxytyp Java-Proxy und klicken Sie auf Weiter.
  4. Die Position der WSDL sollte angegeben sein. Klicken Sie auf Weiter.
  5. Als nächstes müssen Sie die entsprechenden Optionen auswählen, um die Konfiguration Ihrer Client-Umgebung anzugeben, einschließlich der Laufzeit des Web-Services, Server,J2EE Version, Client-Typ (Java, EJB, Web, Anwendungs-Client). Klicken Sie auf Weiter.
  6. Führen Sie die verbleibenden Schritte durch, um den Client-Proxy zu generieren.

Migration des JMS Client

Clients, die mit einem 5.1-Service über die JMS-API (durch das Senden einer JMS-Nachricht an eine Warteschlange) kommunizieren, müssen unter Umständen manuell migriert werden. Dieses Thema erläutert die Migration von Clients, die JMS-APIs verwenden (eine JMS-Nachricht an eine Warteschlange senden), um einen Service aufzurufen.

Sie müssen sicherstellen, dass der in einem früheren Schritt erstellte Export mit JMS-Binding diese Text- oder Objektnachricht unverändert akzeptieren kann. Möglicherweise müssen Sie zu diesem Zweck ein angepasstes Datenbinding schreiben. Weitere Informationen hierzu finden Sie unter "Migration von JMS und JMS-Prozessbindings".

Der Client muss die Konstruktion der Nachricht ändern. Die Nachrichten basierten zuvor auf der WSIFMessage-Klasse, sollten nun jedoch auf der commonj.sdo.DataObject-Klasse basieren. Weitere Informationen zur Durchführung dieser manuellen Migration finden Sie im Abschnitt "Migration von WSIFMessage API-Aufrufen zu SDO APIs".

Migration des generischen Geschäftsprozess-Choreographer EJB API Client

Dieses Thema erläutert die Migration von Clients, die die generische EJB-API des Geschäftsprozess-Choreographers der Version 5.1 verwenden, um einen BPEL-Service aufzurufen.

Es gibt eine neue Version der generischen EJB API, die DataObjects als Nachrichtenformat verwendet. Der Client muss die Konstruktion der Nachricht ändern. Die Nachrichten basierten zuvor auf der WSIFMessage-Klasse, sollten nun jedoch auf der commonj.sdo.DataObject-Klasse basieren. Beachten Sie, dass die generische EJB API sich nicht erheblich geändert hat, da ClientObjectWrapper nach wie vor eine Nachrichtenumlaufprogramm für das entsprechende Nachrichtenformat bereitstellt.

Ex: DataObject dobj = myClientObjectWrapper.getObject();
String result = dobj.getInt("resultInt");

Der JNDI-Name der alten generischen EJB, die WSIFMessage-Objekte akzeptiert, ist:

GenericProcessChoreographerEJB
JNDI Name: com/ibm/bpe/api/BusinessProcessHome
Interface: com.ibm.bpe.api.BusinessProcess

Es gibt zwei generische EJBs in 6.0, da die Human Task-Operationen nun als separate EJB verfügbar sind. Die 6.0 JNDI-Namen dieser generischen EJBs lauten:

GenericBusinessFlowManagerEJB
JNDI Name: com/ibm/bpe/api/BusinessFlowManagerHome
Interface: com.ibm.bpe.api.BusinessFlowManager

HumanTaskManagerEJB
JNDI Name: com/ibm/task/api/TaskManagerHome
Interface: com.ibm.task.api.TaskManager
Migration des generischen Geschäftsprozess-Choreographer Messaging API Client und des JMS-Prozessbinding-Client

In WebSphere Process Server gibt es keine generische Nachrichtenübertragungs-API. Anhand der Informationen unter "Migration von JMS und JMS-Prozessbindings" können Sie eine andere Methode auswählen, um den Geschäftsprozess für Kunden zugänglich zu machen und den Client gemäß dem ausgewählten Binding erneut zu schreiben.

Migration des Geschäftsprozess-Choreographer-Web-Client

Dieses Thema erläutert, wie Sie die Web-Client-Einstellungen und angepassten JSPs des Prozess-Choreographers aus Version 5.1 migrieren.

Der Migrationsassistent behält die Web-Client-Einstellungen aus 5.1 bei. Diese Einstellungen können im Human Task-Editor nicht bearbeitet werden. Sie sollten mit WebSphere Integration Developer 6.x neue Web-Client-Einstellungen und JSPs erstellen.

Migration von Web-Client-Änderungen
In 5.1 konnten Sie Darstellung und Funktionsweise des Struts-basierten Web-Clients durch Änderung seiner JSP-Datei Header.jsp und des Style-Sheets dwc.css ändern.

Da der 6.x-Web-Client (umbenannt in Business Process Choreographer Explorer) auf Java Server Faces (JSF) anstelle von Struts basiert, ist die automatische Migration von Web-Client-Änderungen nicht möglich. Detaillierte Informationen zur Anpassung der Version 6.x dieser Anwendung finden Sie in der "Business Process Choreographer Explorer"-Dokumentation.

Benutzerdefinierte JSPs können für Geschäftsprozesse und Mitarbeiteraktivitäten definiert werden. Der Web-Client verwendet diese JSPs zur Anzeige von Eingabe- und Ausgabenachrichten für den Prozess und Aktivitäten.

Diese JSPs sind insbesondere in folgenden Fällen hilfreich:

  1. Nachrichten verfügen über nicht-primitive Abschnitte, um die Benutzerfreundlichkeit der Datenstruktur der Nachrichten zu verbessern.
  2. Sie möchten die Funktionalität des Web-Clients erweitern.

Es stehen mehrere unterschiedliche Optionen für die Angabe von Web-Client-Einstellungen für einen 6.x-Prozess zur Verfügung, daher müssen Sie WebSphere Integration Developer verwenden, um die Web-Client-Einstellungen für migrierte Prozesse und Aktivitäten zu überarbeiten:

  1. Wählen Sie den Prozesserstellungsbereich oder eine Aktivität im Prozess.
  2. Wählen Sie in der Sicht 'Eigenschaften' die Registerkarte Client, um die Web-Client-Einstellungen zu überarbeiten.
  3. Migrieren Sie alle benutzerdefinierten JSPs manuell:
    1. Weitere Informationen zu Programmiermodelländerungen finden Sie im Abschnitt "Migration zum SCA-Programmiermodell".
    2. Der Web-Client verwendet die generischen APIs für die Interaktion mit Geschäftsprozessen. In diesen Abschnitten finden Sie Informationen zur Migration von Aufrufen zu diesen generischen APIs.
  4. Geben Sie den Namen der neuen JSP in den 6.x-Web-Client-Einstellungen für den Prozess an.
Anmerkung: Die Zuordnung von JSPs ist mit der Version 6.x von Business Process Choreographer Explorer nicht notwendig, da DataObjects keine benutzerdefinierte Zuordnung erfordern.

Migration von WebSphere Business Integration Server Foundation BPEL Java-Snippets

Im Falle von BPEL Prozessen, die Java Snippets enthalten, veranschaulicht dieser Abschnitt die Migration von der alten Java Snippet API zur neuen Java Snippet API, wobei der Datenfluss durch die Anwendung als Eclipse Service Data Objects (SDOs) gespeichert wird.

Informationen zur Durchführung von Migrationsschritten, die spezifisch sind für den Übergang von WSIFMessage zu SDO finden Sie im Abschnitt "Migration von WSIFMessage API-Aufrufen zu SDO APIs".

Wenn möglich, werden die Snippets automatisch vom Migrationsassistenten migriert, es gibt jedoch Snippets, die vom Migrationsassistenten nicht vollständig migriert werden können. Hierfür werden zusätzliche manuelle Schritte für den Abschluss des Migrationsvorgangs benötigt. Informationen zu den Java-Snippet-Typen, die manuell migriert werden müssen, finden Sie im Thema 'Einschränkungen'. Wann immer eines dieser Snippets angetroffen wird, gibt der Migrationsassistent eine Erklärung dazu ab, weshalb es nicht automatisch migriert werden kann und gibt eine Warnung oder Fehlermeldung aus.

In der folgenden Tabelle werden die Änderungen des BPEL Java-Snippet-Programmiermodells und der API von Process Choreographer Version 5.1 zu 6.x aufgelistet:

Tabelle 11. Änderungen und Lösungen für die Migration von WebSphere Business Integration Server Foundation BPEL Java-Snippets
Änderung Lösung
WSIFMessage-basierte Wrapper-Klassen werden nicht mehr für WSDL-Nachrichtentypen generiert, und auch die Java-Bean Helper-Klassen werden nicht mehr für komplexe Schementypen generiert. Auf BPEL-Variablen kann direkt über den Namen zugegriffen werden. Beachten Sie, dass BPEL-Variablen, deren WSDL-Nachrichtendefinition über einen einzelnen Abschnitt verfügt, diesen Abschnitt nun direkt darstellen, statt mit den tatsächlichen Daten in einen Wrapper eingeschlossen. Bei Variablen, deren Nachrichtentyp über mehrere Abschnitte verfügt, sind die Abschnitte in einen DataObject-Wrapper eingeschlossen (während es sich beim Wrapper in WebSphere Application Developer Integration Edition um eine WSIFMessage gehandelt hat).

Da BPEL-Variablen direkt in 6.x-Snippets verwendet werden können, besteht weniger Bedarf an lokalen Variablen als in 5.1.

Die stark typisierten Getter für die BPEL-Variablen haben den Einschluss der Nachrichtenabschnitte mit dem Wrapper-Objekt implizit initialisiert. Es gibt kein 'Wrapper'-Objekt für BPEL-Variablen, deren WSDL-Nachrichtendefinition nur über einen einzelnen Abschnitt verfügt: in diesem Fall stellen die BPEL-Variablen den Abschnitt direkt dar (In dem Fall, in dem es sich beim einzelnen Abschnitt um einen einfachen XSD-Typ handelt, wird die BPEL-Variable als Java-Objekt-Wrappertyp wie beispielsweise java.lang.String, java.lang.Integer, etc. dargestellt). BPEL-Variablen mit WSDL-Nachrichtendefinitionen mit mehreren Abschnitten werden anders gehandhabt: die Abschnitte sind nach wie vor in einen Wrapper eingeschlossen und dieser DataObject-Wrapper muss explizit im 6.x-Java-Snippet-Code initialisiert werden, wenn er noch nicht durch eine vorherige Operation eingerichtet wurde.

Wenn irgendwelche der lokalen Variablen aus den 5.1-Snippets über denselben Namen wie die BPEL-Variable verfügen, kann es zu Konflikten kommen, versuchen Sie daher, diese Situation wenn möglich zu lösen.

WSIFMessage-Objekte werden nicht mehr für die Darstellung von BPEL-Variablen verwendet. Wenn irgendwelche der benutzerdefinierten Java-Klassen, die aus den Java-Snippets aufgerufen werden, über einen WSIFMessage-Parameter verfügen, muss dieser migriert werden, so dass er ein DataObject akzeptiert/ablehnt.
Stark typisierte Getter-Methoden für BPEL-Variablen sind nicht mehr verfügbar. Auf die Variablen kann direkt über den Namen zugegriffen werden. Beachten Sie, dass BPEL-Variablen, deren WSDL-Nachrichtendefinition über einen einzelnen Abschnitt verfügt, diesen Abschnitt nun direkt darstellen, statt mit den tatsächlichen Daten in einen Wrapper eingeschlossen. Bei Variablen, deren Nachrichtentyp über mehrere Abschnitte verfügt, sind die Abschnitte in einen DataObject-Wrapper eingeschlossen (während es sich beim Wrapper in WebSphere Application Developer Integration Edition um eine WSIFMessage gehandelt hat).
Stark typisierte Setter-Methoden für BPEL-Variablen sind nicht mehr verfügbar. Auf die Variablen kann direkt über den Namen zugegriffen werden. Beachten Sie, dass BPEL-Variablen, deren WSDL-Nachrichtendefinition über einen einzelnen Abschnitt verfügt, diesen Abschnitt nun direkt darstellen, statt mit den tatsächlichen Daten in einen Wrapper eingeschlossen. Bei Variablen, deren Nachrichtentyp über mehrere Abschnitte verfügt, sind die Abschnitte in einen DataObject-Wrapper eingeschlossen (während es sich beim Wrapper in WebSphere Application Developer Integration Edition um eine WSIFMessage gehandelt hat).
Schwach typisierte Getter-Methoden für BPEL-Variablen, die eine WSIFMessage zurückgeben, sind nicht mehr verfügbar. Auf die Variablen kann direkt über den Namen zugegriffen werden. Beachten Sie, dass BPEL-Variablen, deren WSDL-Nachrichtendefinition über einen einzelnen Abschnitt verfügt, diesen Abschnitt nun direkt darstellen, statt mit den tatsächlichen Daten in einen Wrapper eingeschlossen. Bei Variablen, deren Nachrichtentyp über mehrere Abschnitte verfügt, sind die Abschnitte in einen DataObject-Wrapper eingeschlossen (während es sich beim Wrapper in WebSphere Application Developer Integration Edition um eine WSIFMessage gehandelt hat).

Beachten Sie, dass es zwei Variationen der getVariableAsWSIFMessage-Methode gab:

getVariableAsWSIFMessage(String variableName)
getVariableAsWSIFMessage(String variableName, boolean forUpdate)

Der Standardzugriff auf eine Java-Snippet-Aktivität ist der Schreib-/Lesezugriff. Diese Standardeinstellung können Sie in einen Lesezugriff ändern, indem Sie @bpe.readOnlyVariables mit der Liste der Variablennamen in einem Kommentar im Snippet angeben. Beispiel: Eine Festlegung der Variablen B und D als Lesezugriff könnte folgendermaßen aussehen:

variableB.setString("/x/y/z", variableA.getString("/a/b/c")); 
// @bpe.readOnlyVariables names="variableA"
variableD.setInt("/x/y/z", variableC.getInt("/a/b/c")); 
// @bpe.readOnlyVariables names="variableC"

Falls Sie ein Java-Snippet in einer Bedingung verwenden, sind Variablen standardmäßig schreibgeschützt. Sie können dies jedoch in einen Schreib-/Lesezugriff ändern, indem Sie @bpe.readWriteVariables... angeben.

Schwach typisierte Setter-Methoden für BPEL-Variablen sind nicht mehr verfügbar. Auf die Variablen kann direkt über den Namen zugegriffen werden. Beachten Sie, dass BPEL-Variablen, deren WSDL-Nachrichtendefinition über einen einzelnen Abschnitt verfügt, diesen Abschnitt nun direkt darstellen, statt mit den tatsächlichen Daten in einen Wrapper eingeschlossen. Bei Variablen, deren Nachrichtentyp über mehrere Abschnitte verfügt, sind die Abschnitte in einen DataObject-Wrapper eingeschlossen (während es sich beim Wrapper in WebSphere Application Developer Integration Edition um eine WSIFMessage gehandelt hat).
Schwach typisierte Getter-Methoden für Nachrichtenabschnitte von BPEL-Variablen sind nicht geeignet für Nachrichten mit einem einzelnen Abschnitt und haben sich für Nachrichten mit mehreren Abschnitten geändert. Migrieren Sie zu der schwach typisierten Getter-Methode für die Eigenschaften von BPEL- Variablen (DataObjects).

Beachten Sie, dass BPEL-Variablen, deren WSDL-Nachrichtendefinition über einen einzelnen Abschnitt verfügt, diesen Abschnitt direkt darstellen, und auf die Variable sollte direkt ohne Verwendung einer Getter-Methode zugegriffen werden.

Es gab zwei Variationen der getVariablePartAsObject-Methode:

getVariablePartAsObject(String variableName, String partName)
getVariablePartAsObject(String variableName, String partName,boolean 
forUpdate)

Bei Nachrichten mit mehreren Abschnitten wird entsprechende Funktionalität durch diese Methode in 6.x bereitgestellt:

getVariableProperty(String variableName, QName propertyName);  		

In 6.x gibt es keinen Vorgang für die Verwendung einer Variablen für schreibgeschützten Zugriff. (Dies war der Fall für die erste Methode oben sowie die zweite Methode mit forUpdate='false'.) Die Variable wird direkt im 6.x-Snippet verwendet und kann jederzeit aktualisiert werden.

Schwach typisierte Setter-Methoden für Nachrichtenabschnitte von BPEL-Variablen sind nicht geeignet für Nachrichten mit einem einzelnen Abschnitt und haben sich für Nachrichten mit mehreren Abschnitten geändert. Migrieren Sie zu der schwach typisierten Setter-Methode für die Eigenschaften von BPEL- Variablen (DataObjects).

Beachten Sie, dass BPEL-Variablen, deren WSDL-Nachrichtendefinition über einen einzelnen Abschnitt verfügt, diesen Abschnitt direkt darstellen, und auf die Variable sollte direkt ohne Verwendung einer Setter-Methode zugegriffen werden.

Aufrufe der folgenden Methode müssen migriert werden:

setVariableObjectPart(String variableName, String partName, 
Object data)  

Bei Nachrichten mit mehreren Abschnitten wird entsprechende Funktionalität durch diese Methode in 6.x bereitgestellt:

setVariableProperty(String variableName, QName propertyName,
Serializable value);
Stark typisierte Getter-Methoden für BPEL-Partnerverbindungen sind nicht mehr verfügbar. Migrieren Sie zu den schwach typisierten Getter-Methoden für BPEL-Partnerverbindungen.
Stark typisierte Setter-Methoden für BPEL-Partnerverbindungen sind nicht mehr verfügbar. Migrieren Sie zu den schwach typisierten Setter-Methoden für BPEL-Partnerverbindungen.
Stark typisierte Getter-Methoden für BPEL-Korrelationsgruppen sind nicht mehr verfügbar.
V5.1-Snippet:
String corrSetPropStr = 
getCorrelationSetCorrSetAPropertyCustomerName();
int corrSetPropInt = 
getCorrelationSetCorrSetBPropertyCustomerId();
V6.x-Snippet:
String corrSetPropStr = (String) getCorrelationSetProperty
("CorrSetA", new QName("CustomerName"));
int corrSetPropInt = ((Integer) getCorrelationSetProperty 
("CorrSetB", new QName("CustomerId"))).intValue();
Zusätzlicher benötigter Parameter für die schwach typisierten Getter-Methoden für benutzerdefinierte BPEL-Aktivitätseigenschaften.
V5.1-Snippet:
String val = getActivityCustomProperty("propName");
V6.x-Snippet:
String val = getActivityCustomProperty
("name-of-current-activity", "propName");
Zusätzlicher benötigter Parameter für die schwach typisierten Setter-Methoden für benutzerdefinierte BPEL-Aktivitätseigenschaften.
V5.1-Snippet:
String newVal = "new value";
setActivityCustomProperty("propName", newVal); 
V6.x-Snippet:
String newVal = "new value";
setActivityCustomProperty("name-of-current-activity", 
"propName", newVal);
Die Methode raiseFault(QName faultQName, Serializable message) ist nicht mehr vorhanden. Migrieren Sie wenn möglich zu raiseFault(QName faultQName, String variableName); ansonsten migrieren Sie zur Methode raiseFault(QName faultQName) oder erstellen Sie eine neue BPEL-Variable für das serialisierbare Objekt.

Interaktionen mit WebSphere Business Integration-Adaptern migrieren

Wenn es sich beim JMS-Client um einen Adapter von WebSphere Business Integration handelt, müssen Sie die Tools von 'Externer Service' verwenden, um den Import mit JMS-Binding zu erstellen. Dieser Import verwendet ein spezielles Datenbinding zur Serialisierung der SDO in das genaue Format, das vom Adapter von WebSphere Business Integration erwartet wird.

Führen Sie die folgenden Schritte aus, um auf die Tools von 'Externer Service' zuzugreifen:

  1. Rufen Sie die Optionen Datei -> Neu -> Andere -> Geschäftsintegration aus, und wählen Sie Externer Service. Klicken Sie auf Weiter.
  2. Wählen Sie Adapter. Klicken Sie auf Weiter.
  3. Geben Sie den Pfad der Konfigurationsdatei (.cfg)-Datei für den Adapter von WebSphere Business Integration ein und das Verzeichnis, das das XML-Schema des Geschäftsobjekts enthält, das vom Adapter verwendet wird. Klicken Sie auf Weiter.
  4. Überprüfen Sie die für Sie generierte Abfrage, und wenn diese korrekt ist, klicken Sie auf Abfrage ausführen. Wählen Sie in der Liste Nach Abfrage erkannte Objekte die Objekte, die Sie hinzufügen möchten (eins nach dem anderen). Klicken Sie dann auf die Schaltfläche >> Hinzufügen.
  5. Akzeptieren Sie die Konfigurationsparameter für das Geschäftsobjekt und klicken Sie auf OK.
  6. Wiederholen Sie diesen Vorgang für jedes Geschäftsobjekt.
  7. Klicken Sie auf Weiter.
  8. Wählen Sie für das Laufzeitformat für Geschäftsobjekte die Option SDO. Wählen Sie für das Zielprojekt das Modul, das Sie gerade migriert haben. Lassen Sie das Feld Ordner leer.
  9. Klicken Sie auf Fertig stellen.

Dieses Tool migriert die alten XSDs in das Format, das von dem speziellen Datenbinding erwartet wird, entfernen Sie daher die alten XSDs für den Adapter von WebSphere Business Integration aus dem Modul und verwenden Sie die neuen XSDs. Wenn das Modul keine Nachrichten vom Adapter empfängt, löschen Sie die mit diesem Tool generierten Exporte. Wenn das Modul keine Nachrichten an den Adapter sendet, löschen Sie den Import. Weitere Informationen zu dieser Funktion finden Sie im Information Center.

Migration von WSDL-Schnittstellen, die über SOAP-verschlüsselte Feldgruppentypen verfügen

Dieser Abschnitt beschreibt die Migration oder Handhabung von Schemas, die über SOAP-verschlüsselte Feldgruppentypen verfügen.

Soap-verschlüsselte Feldgruppentypen mit RPC-Stil werden als unbegrenzte Sequenzen eines konkreten Typs in 6.x behandelt. Eine Erstellung von XSD-Typen, die in irgendeiner Weise auf die Typen soapend:Array verweisen, wird nicht empfohlen, da das Programmiermodell sich in Richtung des eingeschlossenen Dokument/Literal-Stils anstelle des RPC-Stils bewegt (obwohl sich das ändern könnte).

Es wird Fälle geben, in denen eine SCA-Anwendung einen externen Service aufrufen muss, der den Typ soapend:Array verwendet. Dies kann in einigen Fällen nicht vermieden werden, daher wird im Folgenden beschrieben, wie Sie diese Situation handhaben können:

WSDL-Beispielcode:

		<xsd:complexType name="Vendor">
			<xsd:all>
				<xsd:element name="name" type="xsd:string" />
				<xsd:element name="phoneNumber" type="xsd:string" />
			</xsd:all>
		</xsd:complexType>
	</xsd:schema>

		<xsd:complexType name="Vendors">
			<xsd:complexContent mixed="false">
				<xsd:restriction base="soapenc:Array">
					<xsd:attribute wsdl:arrayType="tns:Vendor[]" ref="soapenc:arrayType" 
					xmlnxsd:wsdl="http://schemas.xmlsoap.org/wsdl/" />
				</xsd:restriction>
		</xsd:complexContent>

		<xsd:complexType name="VendorsForProduct">
			<xsd:all>
				<xsd:element name="productId" type="xsd:string" />
				<xsd:element name="vendorList" type="tns:Vendors" />
			</xsd:all>
		</xsd:complexType>

		<xsd:complexType name="Product">
			<xsd:all>
				<xsd:element name="productId" type="xsd:string" />
				<xsd:element name="productName" type="xsd:string" />
			</xsd:all>
		</xsd:complexType>

	<message name="doFindVendorResponse">
		<part name="returnVal" type="tns:VendorsForProduct" />
	</message>

	<operation name="doFindVendor">
		<input message="tns:doFindVendor" />
		<output message="tns:doFindVendorResponse" />
	</operation>

Beispielcode für einen Client dieses Web-Service:

  // Locate the vendor service and find the doFindVendor operation 

Service findVendor=(Service)ServiceManager.INSTANCE.locateService("vendorSearch");
            OperationType doFindVendorOperationType=findVendor.getReference().getOperationType("doGoogleSearch");
            
            // Create the input DataObject
            DataObject doFindVendor=DataFactory.INSTANCE.create(doFindVendorOperationType.getInputType());
            doFindVendor.setString("productId", "12345");
            doFindVendor.setString("productName", "Refrigerator");

            // Invoke the FindVendor service
			DataObject FindVendorResult = (DataObject)findVendor.invoke(doFindVendorOperationType, doFindVendor);
            
            // Display the results
            int resultProductId=findVendorResult.getString("productId");
            
            DataObject resultElements=findVendorResult.getDataObject("vendorList");
            Sequence results=resultElements.getSequence(0);
            for (int i=0, n=results.size(); i
            for (int i=0, n=results.size(); i

Im Folgenden finden Sie ein weiteres Beispiel, in dem es sich beim Roottyp um ein soapenc:Array handelt. Achten Sie darauf, wie das sampleElements DataObject mit dem zweiten oben aufgelisteten Schema erstellt wird. Zunächst wird der Typ des DataObject ermittelt und anschließend die Eigenschaft für sampleStructElement. Hierbei handelt es sich in Wirklichkeit um eine Platzhaltereigenschaft, und diese wird nur verwendet, um eine gültige Eigenschaft beim Hinzufügen der DataObjects zur Sequenz zu erhalten. In Ihrem Szenario kann das folgende Muster verwendet werden:

WSDL-Beispielcode:

<s:schema elementFormDefault="qualified" targetNamespace="http://soapinterop.org/xsd">
			<s:import namespace="http://schemas.xmlsoap.org/soap/encoding/" />
			<s:import namespace="http://schemas.xmlsoap.org/wsdl/" />
			<s:complexType name="SOAPStruct">
				<s:sequence>
					<s:element minOccurs="1" maxOccurs="1" form="unqualified" name="varInt" type="s:int" />
					<s:element minOccurs="1" maxOccurs="1" form="unqualified" name="varString" type="s:string" />
					<s:element minOccurs="1" maxOccurs="1" form="unqualified" name="varFloat" type="s:float" />
				</s:sequence>
			</s:complexType>

			<s:complexType name="ArrayOfSOAPStruct">
				<s:complexContent mixed="false">
					<s:restriction base="soapenc:Array">
						<s:attribute wsdl:arrayType="s0:SOAPStruct[]" ref="soapenc:arrayType" />
					</s:restriction>
				</s:complexContent>
			</s:complexType>
		</s:schema>

	<wsdl:message name="echoStructArraySoapIn">
		<wsdl:part name="inputStructArray" type="s0:ArrayOfSOAPStruct" />
	</wsdl:message>
	<wsdl:message name="echoStructArraySoapOut">
		<wsdl:part name="return" type="s0:ArrayOfSOAPStruct" />
	</wsdl:message>

		<wsdl:operation name="echoStructArray">
			<wsdl:input message="tns:echoStructArraySoapIn" />
			<wsdl:output message="tns:echoStructArraySoapOut" />
		</wsdl:operation>

	<schema targetNamespace="http://sample/elements"
		xmlns="http://www.w3.org/2001/XMLSchema"
		xmlns:tns="http://sample/elements">

	<element name="sampleStringElement" type="string"/>
	
	<element name="sampleStructElement" type="any"/>

</schema>

Beispielcode für einen Client dieses Web-Service:

// Create the input DataObject and get the SDO sequence for the any 
// element
DataFactory dataFactory=DataFactory.INSTANCE;
DataObject arrayOfStruct = dataFactory.create("http://soapinterop.org/xsd","ArrayOfSOAPStruct");
Sequence sequence=arrayOfStruct.getSequence("any");
            
// Get the SDO property for the sample  element that we want to use 
// here to populate the sequence
// We have defined this element in an XSD file, see SampleElements.xsd
DataObject sampleElements=dataFactory.create("http://sample/elements", 
"DocumentRoot");
Property property = sampleElements.getType().getProperty("sampleStructElement");
            
            // Add the elements to the sequence
DataObject item=dataFactory.create("http://soapinterop.org/xsd", "SOAPStruct");
item.setInt("varInt", 1);
item.setString("varString", "Hello");
item.setFloat("varFloat", 1.0f);
sequence.add(property, item);
item=dataFactory.create("http://soapinterop.org/xsd", "SOAPStruct");
item.setInt("varInt", 2);
item.setString("varString", "World");
item.setFloat("varFloat", 2.0f);
sequence.add(property, item);

// Invoke the echoStructArray operation
System.out.println("[client] invoking echoStructArray operation");
DataObject echoArrayOfStruct = (DataObject)interopTest.invoke("echoStructArray", arrayOfStruct);
            
// Display the results
if (echoArrayOfStruct!=null) {
    sequence=echoArrayOfStruct.getSequence("any");
    for (int i=0, n=sequence.size(); i<n; i++) {
      item=(DataObject)sequence.getValue(i);
      System.out.println("[client] item varInt = "+ 
          item.getInt("varInt")+" 
          varString="+item.getString("varString")+" 
          varFloat="+item.getFloat("varFloat"));

Migration des WebSphere Business Integration EJB-Projekts

In WebSphere Studio Application Developer Integration Edition können EJB-Projekte über spezielle WebSphere-Geschäftsintegrationsfunktionen wie erweiterte Nachrichtenübertragung (Extended Messaging, CMM) und CMP/A komponentenbasierte Persistenz überall (Component-managed persistence anywhere) verfügen. Die Implementierungsdeskriptoren für solche Projekte müssen migriert werden, und dieser Abschnitt beschreibt, wie diese Migration durchgeführt wird.

Führen Sie die folgenden Schritte aus, um diese Migration durchzuführen:

  1. Kopieren Sie das WebSphere Business Integration EJB-Projekt in den neuen Arbeitsbereich, und importieren Sie es aus WebSphere Integration Developer unter Verwendung des Assistenten unter Datei -> Importieren -> Vorhandenes Projekt in Arbeitsbereich. Optional können Sie auch den J2EE-Migrationsassistenten ausführen.
  2. Schließen Sie alle laufenden Instanzen von WebSphere Integration Developer im 6.x-Arbeitsbereich.
  3. Führen Sie das folgende Script aus, das die WebSphere Business Integration-Implementierungsdeskriptoren im EJB-Projekt migriert:
    Unter Windows:
    SHARED_FOLDER_HOME/plugins/com.ibm.wbit.migration.wsadie_6.1.0/WSADIEEJBProjectMigration.bat
    Unter Linux:
    SHARED_FOLDER_HOME/plugins/com.ibm.wbit.migration.wsadie_6.1.0/WSADIEEJBProjectMigration.sh
    Die folgenden Parameter werden unterstützt, wobei der Arbeitsbereich und Projektname verbindlich sind:
    Syntax:      WSADIEEJBProjectMigration.bat
                [-e eclipse-folder] -d workspace -p project
    
    eclipse-folder: Die Speicherposition Ihres Eclipse-Ordners -- normalerweise lautet diese 'eclipse'
                    befindet sich in Ihrem Produktinstallationsordner.
    
    workspace:  Der Arbeitsbereich, der das zu migrierende WSADIE EJB-Projekt enthält.
    
    project:    Der Name des zu migrierenden Projekts.
    Beispielsweise
     WSADIEEJBProjectMigration.bat -e "C:\IBM\WID6\eclipse" -d "d:\my60workspace" -p "MyWBIEJBProject"
  4. Beim Öffnen von WebSphere Integration Developer müssen Sie das EJB-Projekt aktualisieren, um die aktualisierten Dateien zu erhalten.
  5. Suchen Sie nach der Datei ibm-web-ext.xmi im EJB-Projekt. Wenn eine gefunden wurde, vergewissern Sie sich, dass die folgende Zeile in der Datei unter Element enthalten ist:
    <webappext:WebAppExtension>
    element:  
    <webApp href="WEB-INF/web.xml#WebApp"/>
  6. Entfernen Sie den alten Implementierungscode, der in 5.1 erzeugt wurde. Generieren Sie den Implementierungscode neu, indem Sie die WebSphere Application Server-Richtlinien zu diesem Thema befolgen.

5.1-WSIF-Definitionen manuell löschen

Nachdem Sie die Migration der Quellenartefakte abgeschlossen haben, sollten Sie alle WSDL-Definitionen für WSIF-Bindings und -Services (WSIF = Web Services Invocation Framework) der Version 5.1, die nicht mehr verwendet werden, aus Ihren Projekten der Version 6.x löschen. Das Auslastungsszenario für die Servicemigration ist der einzige Fall, bei dem weiterhin ein WSIF-Binding oder -Service verwendet wird.

Die folgenden WSDL-Namensbereiche geben an, dass es sich bei einer Binding- oder Servicedefinition um einen 5.1-WSIF-Service handelt, der gelöscht werden kann, wenn er nicht mehr verwendet wird:

EJB-WSIF-Namensbereich:
http://schemas.xmlsoap.org/wsdl/ejb/
Java-WSIF-Namensbereich:
http://schemas.xmlsoap.org/wsdl/java/
JMS-WSIF-Namensbereich:
http://schemas.xmlsoap.org/soap/jms/
WSIF-Namensbereich für Geschäftsprozess:
http://schemas.xmlsoap.org/wsdl/process/
WSIF-Namensbereich für Umsetzungsprogramm:
http://schemas.xmlsoap.org/wsdl/transformer/
IMS-WSIF-Namensbereich:
http://schemas.xmlsoap.org/wsdl/ims/
CICS-ECI-WSIF-Namensbereich:
http://schemas.xmlsoap.org/wsdl/cicseci/
CICS-EPI-WSIF-Namensbereich:
http://schemas.xmlsoap.org/wsdl/cicsepi/
HOD-WSIF-Namensbereich:
http://schemas.xmlsoap.org/wsdl/hod3270/

Die Migration der Quellenartefakte überprüfen

Wenn bei der Durchführung der Migration eine Liste mit Fehlernachrichten, Warnungen und/oder Informationsnachrichten generiert wurde, wird diese Liste im Fenster mit den Migrationsergebnissen angezeigt. Andernfalls wird das Fenster mit dem Assistenten geschlossen, falls die Migration ausgeführt wurde.

Die folgende Seite wird angezeigt, wenn während des Migrationsprozesses Migrationsnachrichten generiert wurden:

Fenster 'Migrationsergebnisse'

Im Fenster Migrationsergebnisse wird eine Liste mit den Migrationsnachrichten angezeigt, die während des Migrationsprozesses generiert wurden. Wenn Sie eine Nachricht in der oberen Nachrichtenliste auswählen, werden im unteren Nachrichtenbeschreibungsfenster weitere Informationen zu dieser Nachricht angezeigt.

Sollen sämtliche Nachrichten zu Referenzzwecken gespeichert werden, klicken Sie auf die Schaltfläche ToDo's generieren, um eine Liste unerledigter Aufgaben in der Ansicht für Tasks zu erstellen. Sie können auch Speichern als... auswählen, um die Nachrichten in einer Textdatei im Dateisystem zu speichern. Überprüfen Sie jede Nachricht, um festzustellen, ob eventuell sofortige Maßnahmen erforderlich sind, um ein Artefakt, das nicht vollständig migriert werden konnte, zu korrigieren. Zur Anzeige der generierten Aufgabenliste klicken Sie auf die Optionen Fenster -> Ansicht anzeigen -> Andere -> Allgemein -> Tasks und auf OK. Die Ansicht Tasks wird geöffnet. Darin sehen Sie die aus dem Migrationsprozess generierte Aufgabenliste.

Um zu überprüfen, ob ein Teil einer Migration abgeschlossen ist, wechseln Sie zur Geschäftsintegrationsperspektive und stellen Sie sicher, dass alle Prozesse und WSDL-Schnittstellen des alten Serviceprojekts im neuen Modul angezeigt werden. Erstellen Sie das Projekt und korrigieren Sie alle Fehler, die die Erstellung des Projekts verhindern.

Nach Durchführen der manuellen Migrationsschritte, die für den Abschluss der Migration der Geschäftsintegrationsanwendung notwendig sind, exportieren Sie die Anwendung als eine EAR-Datei und installieren Sie sie auf einem WebSphere Process Server, und konfigurieren Sie die entsprechenden Ressourcen.

Führen Sie die manuellen Migrationsschritte aus, die für die Migration des Client-Codes notwendig sind, oder generieren Sie neuen Client-Code mit Hilfe von WebSphere Integration Developer. Stellen Sie sicher, dass der Client auf die Anwendung zugreifen kann und dass die Anwendung sich genauso verhält wie in der vorherigen Laufzeitumgebung.

Mit Migrationsfehlern von Quellenartefakten arbeiten

Wenn Ihre Quellenartefaktmigration von WebSphere Studio Application Developer Integration Edition fehlschlägt, gibt es eine Reihe von Möglichkeiten, mit diesen Fehlschlägen umzugehen.

Im Folgenden werden einige der möglichen Quellenartefakt-Migrationsfehler aufgeführt:

Wenn der Migrationsassistent ohne diese Nachricht beendet wird, wird eine Liste mit Informationen, Warnungen und Fehlernachrichten angezeigt. Diese bedeuten, dass ein Teil des Serviceprojekts nicht automatisch migriert werden konnte, und dass manuelle Änderungen vorgenommen werden müssen, um die Migration abzuschließen.

Einschränkungen des Migrationsprozesses (für Quellenartefaktmigration)

Es gibt bestimmte Einschränkungen für den Quellenartefakt-Migrationsprozess von WebSphere Studio Application Developer Integration Edition.

In den folgenden Listen sind einige der Einschränkungen des Migrationsprozesses für die Quellenartefaktmigration im Detail beschrieben:

Allgemeine Einschränkungen

Einschränkungen für das SCA-Programmiermodell

Technische Einschränkungen für den BPEL-Migrationsprozess

Bemerkungen

Die vorliegenden Informationen wurden für Produkte und Services entwickelt, die auf dem deutschen Markt angeboten werden. Möglicherweise bietet IBM die in dieser Dokumentation beschriebenen Produkte, Services oder Funktionen in anderen Ländern nicht an. Informationen über die gegenwärtig im jeweiligen Land verfügbaren Produkte und Services sind beim zuständigen IBM Ansprechpartner erhältlich. Hinweise auf IBM(R) Lizenzprogramme oder andere IBM Produkte bedeuten nicht, dass nur Programme, Produkte oder Services von IBM verwendet werden können. An Stelle der IBM Produkte, Programme oder Services können auch andere, ihnen äquivalente Produkte, Programme oder Services verwendet werden, solange diese keine gewerblichen oder andere Schutzrechte der IBM verletzen. Die Verantwortung für den Betrieb von Fremdprodukten, Fremdprogrammen und Fremdservices liegt beim Kunden.

Für in diesem Handbuch beschriebene Erzeugnisse und Verfahren kann es IBM Patente oder Patentanmeldungen geben. Mit der Auslieferung dieses Handbuchs ist keine Lizenzierung dieser Patente verbunden. Lizenzanforderungen sind schriftlich an folgende Adresse zu richten (Anfragen an diese Adresse müssen auf Englisch formuliert werden):

IBM Director of Licensing 
IBM Europe, Middle East & Africa
Tour Descartes
2,avenue Gambetta
92066 Paris La Defense 
France

Trotz sorgfältiger Bearbeitung können technische Ungenauigkeiten oder Druckfehler in dieser Veröffentlichung nicht ausgeschlossen werden. Die Angaben in diesem Handbuch werden in regelmäßigen Zeitabständen aktualisiert. Die Änderungen werden in Überarbeitungen oder in Technical News Letters (TNLs) bekannt gegeben. IBM kann ohne weitere Mitteilung jederzeit Verbesserungen und/oder Änderungen an den in diesem Dokument beschriebenen Produkten und/oder Programmen vornehmen.

Verweise in diesen Informationen auf Websites anderer Anbieter dienen lediglich als Benutzerinformationen und stellen keinerlei Billigung des Inhalts dieser Websites dar. Das über diese Websites verfügbare Material ist nicht Bestandteil des Materials für dieses IBM Produkt. Die Verwendung dieser Websites geschieht auf eigene Verantwortung.

Werden an IBM Informationen eingesandt, können diese beliebig verwendet werden, ohne dass eine Verpflichtung gegenüber dem Einsender entsteht.

Lizenznehmer des Programms, die Informationen zu diesem Produkt wünschen mit der Zielsetzung: (i) den Austausch von Informationen zwischen unabhängigen, erstellten Programmen und anderen Programmen (einschließlich des vorliegenden Programms) sowie (ii) die gemeinsame Nutzung der ausgetauschten Informationen zu ermöglichen, wenden sich an folgende Adresse:

Intellectual Property Dept. für WebSphere Integration Developer
IBM Canada Ltd.
8200 Warden Avenue
Markham, Ontario L6G 1C7
Canada

Die Bereitstellung dieser Informationen kann unter Umständen von bestimmten Bedingungen - in einigen Fällen auch von der Zahlung einer Gebühr - abhängig sein.

Die Lieferung des im Handbuch aufgeführten Lizenzprogramms sowie des zugehörigen Lizenzmaterials erfolgt auf der Basis der IBM Rahmenvereinbarung bzw. der Allgemeinen Geschäftsbedingungen von IBM, der IBM Internationalen Nutzungsbedingungen für Programmpakete, der IBM Lizenzvereinbarung für Maschinencode oder einer äquivalenten Vereinbarung.

Alle in diesem Dokument enthaltenen Leistungsdaten stammen aus einer gesteuerten Umgebung. Die Ergebnisse, die in anderen Betriebsumgebungen erzielt werden, können daher erheblich von den hier erzielten Ergebnissen abweichen. Einige Daten stammen möglicherweise von Systemen, deren Entwicklung noch nicht abgeschlossen ist. Eine Gewährleistung, dass diese Daten auch in allgemein verfügbaren Systemen erzielt werden, kann nicht gegeben werden. Darüber hinaus wurden einige Daten unter Umständen durch Extrapolation berechnet. Die tatsächlichen Ergebnisse können abweichen. Benutzer dieses Dokuments sollten die entsprechenden Daten in ihrer spezifischen Umgebung prüfen.

Alle Informationen zu Produkten anderer Anbieter stammen von den Anbietern der aufgeführten Produkte, deren veröffentlichten Ankündigungen oder anderen allgemein verfügbaren Quellen. IBM hat diese Produkte nicht getestet und kann daher keine Aussagen zu Leistung, Kompatibilität oder anderen Merkmalen machen. Fragen zu den Leistungsmerkmalen von Produkten anderer Anbieter sind an den jeweiligen Anbieter zu richten.

Die oben genannten Erklärungen bezüglich der Produktstrategien und Absichtserklärungen von IBM stellen die gegenwärtige Absicht der IBM dar, unterliegen Änderungen oder können zurückgenommen werden, und repräsentieren nur die Ziele der IBM.

Diese Veröffentlichung enthält Beispiele für Daten und Berichte des alltäglichen Geschäftsablaufes. Sie sollen nur die Funktionen des Lizenzprogrammes illustrieren; sie können Namen von Personen, Firmen, Marken oder Produkten enthalten. Alle diese Namen sind frei erfunden; Ähnlichkeiten mit tatsächlichen Namen und Adressen sind rein zufällig.

COPYRIGHTLIZENZ:

Diese Veröffentlichung enthält Musteranwendungsprogramme, die in Quellensprache geschrieben sind. Sie dürfen diese Musterprogramme kostenlos kopieren, ändern und verteilen, wenn dies zu dem Zweck geschieht, Anwendungsprogramme zu entwickeln, verwenden, vermarkten oder zu verteilen, die mit der Anwendungsprogrammierschnittstelle konform sind, für die diese Musterprogramme geschrieben werden. Diese Beispiele wurden nicht unter allen denkbaren Bedingungen getestet. Daher kann IBM die Zuverlässigkeit, Wartungsfreundlichkeit oder Funktion dieser Programme weder zusagen noch gewährleisten. Sie dürfen diese Musterprogramme kostenlos kopieren, ändern und verteilen, wenn dies zu dem Zweck geschieht, Anwendungsprogramme zu entwickeln, verwenden, vermarkten oder zu verteilen, die mit der Anwendungsprogrammierschnittstelle von IBM konform sind.

Kopien oder Teile der Musterprogramme bzw. daraus abgeleiteter Code müssen folgenden Copyrightvermerk beinhalten:

(C) (Name Ihrer Firma) (Jahr). Teile dieses Codes sind von Musterprogrammen der IBM Corp. abgeleitet. (C) Copyright IBM Corp. 2000, 2008. Alle Rechte vorbehalten.

Wird dieses Buch als Softcopy (Book) angezeigt, erscheinen keine Fotografien oder Farbabbildungen.

Informationen zur Programmierschnittstelle

Die Informationen zur Programmierschnittstelle sollen Sie bei der Erstellung von Anwendungssoftware unter Verwendung dieses Programms unterstützen.

Allgemeine Programmierschnittstellen ermöglichen es Ihnen, Anwendungssoftware zu schreiben, die die Services der Tools dieses Programms erhält.

Diese Informationen können ferner Informationen zu Diagnose, Änderung und Optimierung enthalten. Informationen zu Diagnose, Änderung und Optimierung werden zur Verfügung gestellt, um Sie beim Debugging Ihrer Anwendungssoftware zu unterstützen.

Achtung: Verwenden Sie diese Informationen zu Diagnose, Änderung und Optimierung nicht als Programmierschnittstelle, es sie geändert werden können.

Marken und Servicemarken

IBM, IBM Logo, WebSphere, Rational, DB2, Universal Database DB2, Tivoli, Lotus, Passport Advantage, developerWorks, Redbooks, CICS, z/OS und IMS sind Marken oder eingetragene Marken von International Business Machines Corporation in den USA und/oder in anderen Ländern.

UNIX ist eine eingetragene Marke von The Open Group in den USA und/oder in anderen Ländern.

Java und alle auf Java basierenden Marken und Logos sind Marken oder eingetragene Marken von Sun Microsystems, Inc. in den USA und/oder in anderen Ländern.

Microsoft und Windows sind Marken oder eingetragene Marken von Microsoft Corporation in den USA und/oder in anderen Ländern.

Linux ist eine Marke von Linus Torvalds in den USA und/oder in anderen Ländern.

Adobe ist eine eingetragene Marke oder eine Marke von Adobe Systems Incorporated in den USA und/oder in anderen Ländern.

Weitere Unternehmens-, Produkt- oder Servicenamen können Marken anderer Hersteller sein.

Rechtliche Hinweise

Die Berechtigung zur Nutzung der Veröffentlichungen wird Ihnen auf der Basis der folgenden Bedingungen gewährt.

Persönliche Nutzung: Sie dürfen diese Veröffentlichungen für Ihre persönliche, nicht kommerzielle Nutzung unter der Voraussetzung vervielfältigen, dass alle Eigentumsvermerke erhalten bleiben. Sie dürfen diese Veröffentlichungen oder Teile der Veröffentlichungen ohne ausdrückliche Genehmigung von IBM weder weitergeben oder anzeigen noch abgeleitete Werke davon erstellen.

Kommerzielle Nutzung: Sie dürfen diese Veröffentlichungen nur innerhalb Ihres Unternehmens und unter der Voraussetzung, dass alle Eigentumsvermerke erhalten bleiben, vervielfältigen, weitergeben und anzeigen. Sie dürfen diese Veröffentlichungen oder Teile der Veröffentlichungen ohne ausdrückliche Genehmigung von IBM außerhalb Ihres Unternehmens weder vervielfältigen, weitergeben oder anzeigen noch abgeleitete Werke davon erstellen.

Abgesehen von den hier gewährten Berechtigungen erhalten Sie keine weiteren Berechtigungen, Lizenzen oder Rechte (veröffentlicht oder stillschweigend) in Bezug auf die Veröffentlichungen oder darin enthaltene Informationen, Daten, Software oder geistiges Eigentum.

IBM behält sich das Recht vor, die in diesem Dokument gewährten Berechtigungen nach eigenem Ermessen zurückzuziehen, wenn sich die Nutzung der Veröffentlichungen für IBM als nachteilig erweist oder wenn die obigen Nutzungsbestimmungen nicht genau befolgt werden.

Sie dürfen diese Informationen nur in Übereinstimmung mit allen anwendbaren Gesetzen und Vorschriften, einschließlich aller US-amerikanischen Exportgesetze und Verordnungen, herunterladen und exportieren.

IBM ÜBERNIMMT KEINE GEWÄHRLEISTUNG FÜR DEN INHALT DIESER VERÖFFENTLICHUNGEN. DIE VERÖFFENTLICHUNGEN WERDEN OHNE WARTUNG (AUF "AS-IS"-BASIS) UND OHNE JEDE GEWÄHRLEISTUNG FÜR DIE HANDELSÜBLICHKEIT UND DIE VERWENDUNGSFÄHIGKEIT FÜR EINEN BESTIMMTEN ZWECK ZUR VERFÜGUNG GESTELLT.

(C) Copyright IBM Corporation 2005, 2008. Alle Rechte vorbehalten.