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.
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.
- Die Implementierung von WebSphere Integration Developer 6.0.x.x (wobei
6.0.x.x für 6.0.1.x oder für 6.0.2.x steht) auf WebSphere Process
Server 6.1 wird unterstützt.
- Anwendungen, die mit WebSphere Integration Developer 6.0.x.x erstellt wurden,
können auf WebSphere Process
Server 6.1-Servern veröffentlicht werden.
- Anwendungen die in WebSphere Integration
Developer 6.0.x.x erstellt und generiert sowie von dort exportiert wurden, können auf WebSphere Process Server 6.1-Servern installiert werden.
- Die Ausführung von WebSphere Process
Server 6.1-Artefakten auf WebSphere Process Server 6.0.x.x wird nicht unterstützt.
- Anwendungen, die mit WebSphere Integration Developer 6.1
erstellt wurden, können auf Servern mit WebSphere Process Server 6.0.x.x
(und allen früheren Releases) weder veröffentlicht noch installiert werden. Derartiger Inhalt kann unter WebSphere Process
Server 6.0.x.x nicht ordnungsgemäß ausgeführt werden, und Änderungen bei der Codegenerierung bewirken, dass Anwendungen
unter WebSphere Process Server 6.0.x.x nicht ordnungsgemäß ausgeführt werden.
- Anwendungen, die mit WebSphere Integration Developer 6.0.x.x erstellt und
in WebSphere Integration
Developer 6.1 generiert wurden, können auf WebSphere Process Server 6.0.x.x-Servern weder veröffentlicht noch installiert werden.
Änderungen bei der Codegenerierung bewirken, dass die Anwendungen unter
WebSphere Process
Server 6.0.x.x nicht ordnungsgemäß ausgeführt werden.
- Anwendungen, die unter Verwendung von serviceDeploy von einem WebSphere Process
Server 6.1-Server aus generiert wurden, können auf einem WebSphere Process Server 6.0.x.x-Server nicht installiert werden.
Änderungen bei der Codegenerierung bewirken, dass die Anwendungen unter
WebSphere Process
Server 6.0.x.x nicht ordnungsgemäß ausgeführt werden.
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.
- Automatische Migration von Quellenartefakten durch Migrationstools, die folgendermaßen aufgerufen werden können:
- Das Menü unter Datei -> Import -> Business Integration von WebSphere Integration
Developer
- Die Begrüßungsseite von WebSphere Integration Developer
- Das Befehlszeilendienstprogramm reposMigrate
- Native Unterstützung in der Laufzeit vieler APIs von WebSphere InterChange Server
- Unterstützung für die aktuelle Adaptertechnologie von WebSphere Business Integration, damit vorhandene Adapter
mit WebSphere Process Server kompatibel sind
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:
- Gruppenunterstützung
- Sofortige Implementierung/Dynamische Aktualisierung
- Scheduleroperation anhalten
- Sicherheit - Prüfung
- Sicherheit - Differenziertes RBAC
- Sicherheitsdeskriptoren werden nicht migriert
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.
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:
- Das Menü unter Datei -> Import -> Business Integration von WebSphere Integration
Developer
- Die Begrüßungsseite von WebSphere Integration Developer
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:
- 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".
- 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:
- Dokumentierung des System- und Komponentenentwurfs
- Bearbeitung von Integrationsartefakten mit den Entwicklungstools
- Definition von Regeln mit den Tools und Java-Snippets gemäß den Vorschlägen
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 nur die veröffentlichten APIs.
- Verwenden Sie den Aktivitätseditor.
- Verwenden Sie zum EIS-Zugriff Adapter.
- Vermeiden Sie externe Abhängigkeiten im Java-Snippet-Code.
- Halten Sie sich an die J2EE-Entwicklungsverfahren für die Portierbarkeit.
- Starten Sie keine Threads, und verwenden Sie keine Basiselemente der Thread-Synchronisation. Für den Fall, dass der Einsatz dieser Elemente zwingend erforderlich ist, müssen sie bei der Migration konvertiert werden, damit sie asynchrone Beans verwenden.
- Führen Sie keine Platten-E/A unter Verwendung von 'java.io.*' aus. Speichern Sie Daten mit JDBC.
- Führen Sie keine Funktionen aus, die möglicherweise für einen EJB-Container reserviert sind, wie beispielsweise Socket-E/A, Laden von Klassen, Laden von nativen Bibliotheken usw. Sind solche Aktionen zwingend erforderlich, müssen diese Snippets bei der Migration manuell konvertiert werden, damit EJB-Containerfunktionen verwendet werden.
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:
- Wählen Sie die Optionen Datei -> Importieren -> Geschäftsintegration -> WebSphere
InterChange Server - JAR-Datei aus, und klicken Sie auf Weiter, um den Assistenten aufzurufen:
Sie können den Migrationsassistenten auch auf der Begrüßungsseite öffnen, indem Sie auf das Symbol 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.)
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.

- 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:
- 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:

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. |
- 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:
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.
- 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.
- 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:
- Geschäftsobjekte werden zu WebSphere Process Server-Geschäftsobjekten.
- Zuordnungen werden zu WebSphere Process Server-Zuordnungen.
- Beziehungen werden zu WebSphere Process Server-Beziehungen und -Aufgabenbereichen.
- Collaboration-Schablonen werden zu WebSphere Process Server-BPEL und -WSDL.
- Collaboration-Objekte werden zu WebSphere Process Server-Modulen mit
einer SCA-Komponente, die an die BPEL für die Collaboration-Schablone und an die gesamte SCA-Vernetzung
gebunden ist.
- Connectordefinitionen werden zu WebSphere Process Server-Modulen, die
SCA-Importe und -Exporte enthalten, damit die Datenübertragung zu traditionellen Adaptern, zu Legacy
Adapter Administrative Artifacts und zur benötigten SCA-Vernetzung ermöglicht wird.
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:
- Datenbankverbindungspools
- Beziehungen
- Schedulereinträge
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/
- BiDiBOTransformation(BusinessObject, String, String, boolean):BusinessObj
- BiDiBusObjTransformation(BusObj, String, String, boolean):BusObj
- BiDiStringTransformation(String, String, String):String
JavaConnectorUtil
AppSide_Connector/
- INFRASTRUCTURE_MESSAGE_FILE
- CONNECTOR_MESSAGE_FILE
- XRD_WARNING
- XRD_TRACE
- XRD_INFO
- XRD_ERROR
- XRD_FATAL
- LEVEL1
- LEVEL2
- LEVEL3
- LEVEL4
- LEVEL5
- createBusinessObject(String):BusinesObjectInterface
- createBusinessObject(String, Locale):BusinesObjectInterface
- createBusinessObject(String, String):BusinesObjectInterface
- createContainer(String):CxObjectContainerInterface
- generateMsg(int, int, int, int, int, Vector):String
- generateMsg(int, int, int, int, Vector):String
- getBlankValue():String
- getEncoding():String
- getIgnoreValue():String
- getLocale():String
- getSDOFromString(String inputString, String sdoName, String metaObjectName,
String mimeType)
- getStringFromSDO(DataObject sdo, String metaObjectName, String mimeType)
- isBlankValue(Object):boolean
- isIgnoreValue(Object):boolean
- isTraceEnabled(int):boolean
- logMsg(String)
- logMsg(String, int)
- traceWrite(int, String)
JavaConnectorUtilDH
datahandler/
wbi/
ibm/
com/
- getSDOFromString(String inputString, String sdoName, String metaObjectName,
String mimeType)
- getStringFromSDO(DataObject sdo, String metaObjectName, String mimeType)
BusObj
Collaboration/
- BusObj(DataObject)
- BusObj(String)
- BusObj(String, Locale)
- copy(BusObj)
- duplicate():BusObj
- equalKeys(BusObj):boolean
- equals(Object):boolean
- equalsShallow(BusObj):boolean
- exists(String):boolean
- get(int):Object
- get(String):Object
- getBoolean(String):boolean
- getBusObj(String):BusObj
- getBusObjArray(String):BusObjArray
- getCount(String):int
- getDouble(String):double
- getFloat(String):float
- getInt(String):int
- getKeys():String
- getLocale():java.util.Locale
- getLong(String):long
- getLongText(String):String
- getString(String):String
- getType():String
- getValues():String
- getVerb():String
- isBlank(String):boolean
- isKey(String):boolean
- isNull(String):boolean
- isRequired(String):boolean
- keysToString():String
- set(BusObj)
- set(int, Object)
- set(String, boolean)
- set(String, double)
- set(String, float)
- set(String, int)
- set(String, long)
- set(String, Object)
- set(String, String)
- setContent(BusObj)
- setDefaultAttrValues()
- setKeys(BusObj)
- setLocale(java.util.Locale)
- setVerb(String)
- setVerbWithCreate(String, String)
- setWithCreate(String, boolean)
- setWithCreate(String, BusObj)
- setWithCreate(String, BusObjArray)
- setWithCreate(String, double)
- setWithCreate(String, float)
- setWithCreate(String, int)
- setWithCreate(String, long):
- setWithCreate(String, Object)
- setWithCreate(String, String)
- toString():String
- validData(String, boolean):boolean
- validData(String, BusObj):boolean
- validData(String, BusObjArray):boolean
- validData(String, double):boolean
- validData(String, float):boolean
- validData(String, int):boolean
- validData(String, long):boolean
- validData(String, Object):boolean
- validData(String, String):boolean
BusObjArray
Collaboration/
- addElement(BusObj)
- duplicate():BusObjArray
- elementAt(int):BusObj
- equals(BusObjArray):boolean
- getElements():BusObj[]
- getLastIndex():int
- max(String):String
- maxBusObjArray(String):BusObjArray
- maxBusObjs(String):BusObj[]
- min(String):String
- minBusObjArray(String):BusObjArray
- minBusObjs(String):BusObj[]
- removeAllElements()
- removeElement(BusObj)
- removeElementAt(int)
- setElementAt(int, BusObj)
- size():int
- sum(String):double
- swap(int, int)
- toString():String
BaseDLM
DLM/
- BaseDLM(BaseMap)
- getDBConnection(String):CwDBConnection
- getDBConnection(String, boolean):CwDBConnection
- getName():String
- getRelConnection(String):DtpConnection
- implicitDBTransactionBracketing():boolean
- isTraceEnabled(int):boolean
- logError(int)
- logError(int, Object[])
- logError(int, String)
- logError(int, String, String)
- logError(int, String, String, String)
- logError(int, String, String, String, String)
- logError(int, String, String, String, String, String)
- logError(String)
- logInfo(int)
- logInfo(int, Object[])
- logInfo(int, String)
- logInfo(int, String, String)
- logInfo(int, String, String, String)
- logInfo(int, String, String, String, String)
- logInfo(int, String, String, String, String, String)
- logInfo(String)
- logWarning(int)
- logWarning(int, Object[])
- logWarning(int, String)
- logWarning(int, String, String)
- logWarning(int, String, String, String)
- logWarning(int, String, String, String, String)
- logWarning(int, String, String, String, String, String)
- logWarning(String)
- raiseException(RunTimeEntityException)
- raiseException(String, int)
- raiseException(String, int, Object[])
- raiseException(String, int, String)
- raiseException(String, int, String, String)
- raiseException(String, int, String, String, String)
- raiseException(String, int, String, String, String, String)
- raiseException(String, int, String, String, String, String, String)
- raiseException(String, String)
- releaseRelConnection(boolean)
- trace(int, int)
- trace(int, int, Object[])
- trace(int, int, String)
- trace(int, int, String, String)
- trace(int, int, String, String, String)
- trace(int, int, String, String, String, String)
- trace(int, int, String, String, String, String, String)
- trace(int, String)
- trace(String)
CwDBConnection
CwDBConnection/
CxCommon/
- beginTransaction()
- commit()
- executePreparedSQL(String)
- executePreparedSQL(String, Vector)
- executeSQL(String)
- executeSQL(String, Vector)
- executeStoredProcedure(String, Vector)
- getUpdateCount():int
- hasMoreRows():boolean
- inTransaction():boolean
- isActive():boolean
- nextRow():Vector
- release()
- rollback()
CwDBConstants
CwDBConnection/
CxCommon/
- PARAM_IN - 0
- PARAM_INOUT - 1
- PARAM_OUT - 2
CwDBStoredProcedureParam
CwDBConnection/
CxCommon/
- CwDBStoredProcedureParam(int, Array)
- CwDBStoredProcedureParam(int, BigDecimal)
- CwDBStoredProcedureParam(int, boolean)
- CwDBStoredProcedureParam(int, Boolean)
- CwDBStoredProcedureParam(int, byte[])
- CwDBStoredProcedureParam(int, double)
- CwDBStoredProcedureParam(int, Double)
- CwDBStoredProcedureParam(int, float)
- CwDBStoredProcedureParam(int, Float)
- CwDBStoredProcedureParam(int, int)
- CwDBStoredProcedureParam(int, Integer)
- CwDBStoredProcedureParam(int, java.sql.Blob)
- CwDBStoredProcedureParam(int, java.sql.Clob)
- CwDBStoredProcedureParam(int, java.sql.Date)
- CwDBStoredProcedureParam(int, java.sql.Struct)
- CwDBStoredProcedureParam(int, java.sql.Time)
- CwDBStoredProcedureParam(int, java.sql.Timestamp)
- CwDBStoredProcedureParam(int, Long)
- CwDBStoredProcedureParam(int, String)
- CwDBStoredProcedureParam(int, String, Object)
- getParamType():int getValue():Object
DataHandler (Abstract Class)
DataHandlers/
crossworlds/
com/
- createHandler(String, String, String):DataHandler
- getBO(InputStream, Object):BusinessObjectInterface
- getBO(Object, BusinessObjectInterface, Object)
- getBO(Object, Object):BusinessObjectInterface
- getBO(Reader, BusinessObjectInterface, Object) (Abstract Method)
- getBO(Reader, Object):BusinessObjectInterface (Abstract Method)
- getBO(String, Object):BusinessObjectInterface
- getBOName(InputStream):String
- getBOName(Reader):String
- getBOName(String):String
- getBooleanOption(String):boolean
- getEncoding():String
- getLocale():Locale
- getOption(String):String
- getStreamFromBO(BusinessObjectInterface, Object):InputStream (Abstract
Method)
- getStringFromBO(BusinessObjectInterface, Object):String (Abstract Method)
- setConfigMOName(String)
- setEncoding(String)
- setLocale(Locale)
- setOption(String, String)
- traceWrite(String, int)
NameHandler (Abstract Class)
DataHandlers/
crossworlds/
com/
- getBOName(Reader, String):String) (Abstract Method)
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/
- clone():Object
- dump():String
- getAppText():String
- getAttrCount():int
- getAttrDesc(int):CxObjectAttr
- getAttrDesc(String):CxObjectAttr
- getAttribute(String):Object
- getAttributeIndex(String):int
- getAttributeType(int):int
- getAttributeType(String):int
- getAttrName(int):String
- getAttrValue(int):Object
- getAttrValue(String):Object
- getBusinessObjectVersion():String
- getDefaultAttrValue(int):String
- getDefaultAttrValue(String):String
- getLocale():String
- getName():String
- getParentBusinessObject():BusinessObjectInterface
- getVerb():String
- getVerbAppText(String):String
- isBlank(int):boolean
- isBlank(String):boolean
- isIgnore(int):boolean
- isIgnore(String):boolean
- isVerbSupported(String):boolean
- makeNewAttrObject(int):Object
- makeNewAttrObject(String):Object
- setAttributeWithCreate(String, Object)
- setAttrValue(int, Object)
- setAttrValue(String, Object)
- setDefaultAttrValues()
- setLocale(Locale)
- setLocale(String)
- setVerb(String)
CxObjectAttr
CxCommon/
- BOOLEAN
- BOOLSTRING
- DATE
- DATESTRING
- DOUBLE
- DOUBSTRING
- FLOAT
- FLTSTRING
- INTEGER
- INTSTRING
- INVALID_TYPE_NUM
- INVALID_TYPE_STRING
- LONGTEXT
- LONGTEXTSTRING
- MULTIPLECARDSTRING
- OBJECT
- SINGLECARDSTRING
- STRING
- STRSTRING
- equals(Object):boolean
- getAppText():String
- getCardinality():String
- getDefault():String
- getMaxLength():int
- getName():String
- getRelationType():String
- getTypeName():String
- getTypeNum():String
- hasCardinality(String):boolean
- hasName(String):boolean
- hasType(String):boolean
- isForeignKeyAttr():boolean
- isKeyAttr():boolean
- isMultipleCard():boolean
- isObjectType():boolean
- isRequiredAttr():boolean
- isType(Object):boolean
CxObjectContainerInterface
CxCommon/
- getBusinessObject(int):BusinessObjectInterface
- getObjectCount():int
- insertBusinessObject(BusinessObjectInterface)
- removeAllObjects()
- removeBusinessObjectAt(int)
- setBusinessObject(int, BusinessObjectInterface)
DtpConnection
Dtp/
CxCommon/
- beginTran()
- commit()
- executeSQL(String)
- executeSQL(String, Vector)
- executeStoredProcedure(String, Vector)
- getUpdateCount():int
- hasMoreRows():boolean
- inTransaction():boolean
- isActive():boolean
- nextRow():Vector
- rollback()
DtpDataConversion
Dtp/
CxCommon/
- BOOL_TYPE - 4
- CANNOTCONVERT - 2
- DATE_TYPE - 5
- DOUBLE_TYPE - 3
- FLOAT_TYPE - 2
- INTEGER_TYPE - 0
- LONGTEXT_TYPE - 6
- OKTOCONVERT - 0
- POTENTIALDATALOSS - 1
- STRING_TYPE - 1
- UNKNOWN_TYPE - 999
- getType(double):int
- getType(float):int
- getType(int):int
- getType(Object):int
- isOKToConvert(int, int):int
- isOKToConvert(String, String):int
- toBoolean(boolean):Boolean
- toBoolean(Object):Boolean
- toDouble(double):Double
- toDouble(float):Double
- toDouble(int):Double
- toDouble(Object):Double
- toFloat(double):Float
- toFloat(float):Float
- toFloat(int):Float
- toFloat(Object):Float
- toInteger(double):Integer
- toInteger(float):Integer
- toInteger(int):Integer
- toInteger(Object):Integer
- toPrimitiveBoolean(Object):boolean
- toPrimitiveDouble(float):double
- toPrimitiveDouble(int):double
- toPrimitiveDouble(Object):double
- toPrimitiveFloat(double):float
- toPrimitiveFloat(int):float
- toPrimitiveFloat(Object):float
- toPrimitiveInt(double):int
- toPrimitiveInt(float):int
- toPrimitiveInt(Object):int
- toString(double):String
- toString(float):String
- toString(int):String
- toString(Object):String
DtpDate
Dtp/
CxCommon/
- DtpDate()
- DtpDate(long, boolean)
- DtpDate(String, String)
- DtpDate(String, String, String[], String[])
- addDays(int):DtpDate
- addMonths(int):DtpDate
- addWeekdays(int):DtpDate
- addYears(int):DtpDate
- after(DtpDate):boolean
- before(DtpDate):boolean
- calcDays(DtpDate):int
- calcWeekdays(DtpDate):int
- get12MonthNames():String[]
- get12ShortMonthNames():String[]
- get7DayNames():String[]
- getCWDate():String
- getDayOfMonth():String
- getDayOfWeek():String
- getHours():String
- getIntDay():int
- getIntDayOfWeek():int
- getIntHours():int
- getIntMilliSeconds():int
- getIntMinutes():int
- getIntMonth():int
- getIntSeconds():int
- getIntYear():int
- getMaxDate(BusObjArray, String, String):DtpDate
- getMaxDateBO(BusObj[], String, String):BusObj[]
- getMaxDateBO(BusObjArray, String, String):BusObj[]
- getMinDate(BusObjArray, String, String):DtpDate
- getMinDateBO(BusObj[], String, String):BusObj[]
- getMinDateBO(BusObjArray, String, String):BusObj[]
- getMinutes():String
- getMonth():String
- getMSSince1970():long
- getNumericMonth():String
- getSeconds():String
- getShortMonth():String
- getYear():String
- set12MonthNames(String[], boolean)
- set12MonthNamesToDefault()
- set12ShortMonthNames(String[])
- set12ShortMonthNamesToDefault()
- set7DayNames(String[])
- set7DayNamesToDefault()
- toString():String
- toString(String):String
- toString(String, boolean):String
DtpMapService
Dtp/
CxCommon/
- runMap(String, String, BusObj[], CxExecutionContext):BusObj[]
DtpSplitString
Dtp/
CxCommon/
- DtpSplitString(String, String)
- elementAt(int):String
- firstElement():String
- getElementCount():int
- getEnumeration():Enumeration
- lastElement():String
- nextElement():String
- prevElement():String
- reset()
DtpUtils
Dtp/
CxCommon/
- padLeft(String, char, int):String
- padRight(String, char, int):String
- stringReplace(String, String, String):String
- truncate(double):int
- truncate(double, int):double
- truncate(float):int
- truncate(float, int):double
- truncate(Object):int
- truncate(Object, int):double
BusObjInvalidVerbException (extends InterchangeExceptions)
Exceptions/
CxCommon/
IdentityRelationship
relationship/
utilities/
crossworlds/
com/
- addMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- deleteMyChildren(String, String, BusObj, String, CxExecutionContext)
- deleteMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- foreignKeyLookup(String, String, BusObj, String, BusObj, String, CxExecutionContext)
- foreignKeyXref(String, String, String, BusObj, String, BusObj, String,
CxExecutionContext)
- maintainChildVerb(String, String, String, BusObj, String, BusObj, String,
CxExecutionContext, boolean, boolean)
- maintainCompositeRelationship(String, String, BusObj, Object, CxExecutionContext)
- maintainSimpleIdentityRelationship(String, String, BusObj, BusObj, CxExecutionContext)
- updateMyChildren(String, String, BusObj, String, String, String, String,
CxExecutionContext)
MapExeContext
Dtp/
CxCommon/
- ACCESS_REQUEST - "SUBSCRIPTION_DELIVERY"
- ACCESS_RESPONSE - "ACCESS_RETURN_REQUEST"
- EVENT_DELIVERY - "SUBSCRIPTION_DELIVERY"
- SERVICE_CALL_FAILURE - "CONSUME_FAILED"
- SERVICE_CALL_REQUEST - "CONSUME"
- SERVICE_CALL_RESPONSE - "DELIVERBUSOBJ"
- getConnName():String
- getGenericBO():BusObj
- getInitiator():String
- getLocale():java.util.Locale
- getOriginalRequestBO():BusObj
- setConnName(String)
- setInitiator(String)
- setLocale(java.util.Locale)
Participant
RelationshipServices/
Server/
- Participant(String, String, int, BusObj)
- Participant(String, String, int, String)
- Participant(String, String, int, long)
- Participant(String, String, int, int)
- Participant(String, String, int, double)
- Participant(String, String, int, float)
- Participant(String, String, int, boolean)
- Participant(String, String, BusObj)
- Participant(String, String, String)
- Participant(String, String, long)
- Participant(String, String, int)
- Participant(String, String, double)
- Participant(String, String, float)
- Participant(String, String, boolean)
- getBoolean():boolean
- getBusObj():BusObj
- getDouble():double
- getFloat():float
- getInstanceId():int
- getInt():int
- getLong():long
- getParticipantDefinition():String
- getRelationshipDefinition():String
- getString():String INVALID_INSTANCE_ID
- set(boolean)
- set(BusObj)
- set(double)
- set(float)
- set(int)
- set(long)
- set(String)
- setInstanceId(int)
- setParticipantDefinition(String)
- setRelationshipDefinition(String)
- setParticipantDefinition(String)
- setRelationshipDefinition(String)
Relationship
RelationshipServices/
Server/
- addMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- addParticipant(Participant):int
- addParticipant(String, String, boolean):int
- addParticipant(String, String, BusObj):int
- addParticipant(String, String, double):int
- addParticipant(String, String, float):int
- addParticipant(String, String, int):int
- addParticipant(String, String, int, boolean):int
- addParticipant(String, String, int, BusObj):int
- addParticipant(String, String, int, double):int
- addParticipant(String, String, int, float):int
- addParticipant(String, String, int, int):int
- addParticipant(String, String, int, long):int
- addParticipant(String, String, int, String):int
- addParticipant(String, String, long):int
- addParticipant(String, String, String):int
- create(Participant):int
- create(String, String, boolean):int
- create(String, String, BusObj):int
- create(String, String, double):int
- create(String, String, float):int
- create(String, String, int):int
- create(String, String, long):int
- create(String, String, String):int
- deactivateParticipant(Participant)
- deactivateParticipant(String, String, boolean)
- deactivateParticipant(String, String, BusObj)
- deactivateParticipant(String, String, double)
- deactivateParticipant(String, String, float)
- deactivateParticipant(String, String, int)
- deactivateParticipant(String, String, long)
- deactivateParticipant(String, String, String)
- deactivateParticipantByInstance(String, String, int)
- deactivateParticipantByInstance(String, String, int, boolean)
- deactivateParticipantByInstance(String, String, int, BusObj)
- deactivateParticipantByInstance(String, String, int, double)
- deactivateParticipantByInstance(String, String, int, float)
- deactivateParticipantByInstance(String, String, int, int)
- deactivateParticipantByInstance(String, String, int, long)
- deactivateParticipantByInstance(String, String, int, String)
- deleteMyChildren(String, String, BusObj, String, CxExecutionContext)
- deleteMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- deleteParticipant(Participant)
- deleteParticipant(String, String, boolean)
- deleteParticipant(String, String, BusObj)
- deleteParticipant(String, String, double)
- deleteParticipant(String, String, float)
- deleteParticipant(String, String, int)
- deleteParticipant(String, String, long)
- deleteParticipant(String, String, String)
- deleteParticipantByInstance(String, String, int)
- deleteParticipantByInstance(String, String, int, boolean)
- deleteParticipantByInstance(String, String, int, BusObj)
- deleteParticipantByInstance(String, String, int, double)
- deleteParticipantByInstance(String, String, int, float)
- deleteParticipantByInstance(String, String, int, int)
- deleteParticipantByInstance(String, String, int, long)
- deleteParticipantByInstance(String, String, int, String)
- getNewID(String):int
- maintainCompositeRelationship(String, String, BusObj, Object, CxExecutionContext)
- maintainSimpleIdentityRelationship(String, String, BusObj, BusObj, CxExecutionContext)
- retrieveInstances(String, boolean):int[]
- retrieveInstances(String, BusObj):int[]
- retrieveInstances(String, double):int[]
- retrieveInstances(String, float):int[]
- retrieveInstances(String, int):int[]
- retrieveInstances(String, long):int[]
- retrieveInstances(String, String):int[]
- retrieveInstances(String, String, boolean):int[]
- retrieveInstances(String, String, BusObj):int[]
- retrieveInstances(String, String, double):int[]
- retrieveInstances(String, String, float):int[]
- retrieveInstances(String, String, int):int[]
- retrieveInstances(String, String, long):int[]
- retrieveInstances(String, String, String):int[]
- retrieveInstances(String, String[], boolean):int[]
- retrieveInstances(String, String[], BusObj):int[]
- retrieveInstances(String, String[], double):int[]
- retrieveInstances(String, String[], float):int[]
- retrieveInstances(String, String[], int):int[]
- retrieveInstances(String, String[], long):int[]
- retrieveInstances(String, String[], String):int[]
- retrieveParticipants(String):Participant[]
- retrieveParticipants(String, String):Participant[]
- retrieveParticipants(String, String[]):Participant[]
- retrieveParticipants(String, int):Participant[]
- retrieveParticipants(String, String, int):Participant[]
- retrieveParticipants(String, String[], int):Participant[]
- updateMyChildren(String, String, BusObj, String, String, String, String,
CxExecutionContext)
- updateParticipant(String, String, BusObj)
- updateParticipantByInstance(Participant)
- updateParticipantByInstance(String, String, int)
- updateParticipantByInstance(String, String, int, BusObj)
UserStoredProcedureParam
Dtp/
CxCommon/
- UserStoredProcedureParam(int, String, Object, String, String)
- getParamDataTypeJavaObj():String
- getParamDataTypeJDBC():int
- getParamIndex():int
- getParamIOType():String
- getParamName():String
- getParamValue():Object
- setParamDataTypeJavaObj(String)
- setParamDataTypeJDBC(int)
- setParamIndex(int)
- setParamIOType(String)
- setParamName(String)
- setParamValue(Object)
- PARAM_TYPE_IN - "IN"
- PARAM_TYPE_OUT - "OUT"
- PARAM_TYPE_INOUT - "INOUT"
- DATA_TYPE_STRING - "String"
- DATA_TYPE_INTEGER - "Integer"
- DATA_TYPE_DOUBLE - "Double"
- DATA_TYPE_FLOAT - "Float"
- DATA_TYPE_BOOLEAN - "Boolean"
- DATA_TYPE_TIME - "java.sql.Time"
- DATA_TYPE_DATE - "java.sql.Date"
- DATA_TYPE_TIMESTAMP - "java.sql.Timestamp"
- DATA_TYPE_BIG_DECIMAL - "java.math.BigDecimal"
- DATA_TYPE_LONG_INTEGER - "Long"
- DATA_TYPE_BINARY - "byte[]"
- DATA_TYPE_CLOB - "Clob"
- DATA_TYPE_BLOB - "Blob"
- DATA_TYPE_ARRAY - "Array"
- DATA_TYPE_STRUCT - "Struct"
- DATA_TYPE_REF - "Ref"
BaseCollaboration
Collaboration/
- BaseCollaboration(com.ibm.bpe.api.ProcessInstanceData)
- AnyException - "AnyException"
- AppBusObjDoesNotExist - "BusObjDoesNotExist"
- AppLogOnFailure - "AppLogOnFailure"
- AppMultipleHits - "AppMultipleHits"
- AppRequestNotYetSent - "AppRequestNotYetSent"
- AppRetrieveByContentFailed - "AppRetrieveByContent"
- AppTimeOut - "AppTimeOut"
- AppUnknown - "AppUnknown"
- AttributeException - "AttributeException"
- existsConfigProperty(String):boolean
- getConfigProperty(String):String
- getConfigPropertyArray(String):String[]
- getCurrentLoopIndex():int
- getDBConnection(String):CwDBConnection
- getDBConnection(String, boolean):CwDBConnection getLocale():java.util.Locale
- getMessage(int):String
- getMessage(int, Object[]):String
- getName():String
- implicitDBTransactionBracketing():boolean
- isCallerInRole(String):boolean
- isTraceEnabled(int):boolean
- JavaException - "JavaException"
- logError(int)
- logError(int, Object[])
- logError(int, String)
- logError(int, String, String)
- logError(int, String, String, String)
- logError(int, String, String, String, String)
- logError(int, String, String, String, String, String)
- logError(String)
- logInfo(int)
- logInfo(int, Object[])
- logInfo(int, String)
- logInfo(int, String, String)
- logInfo(int, String, String, String)
- logInfo(int, String, String, String, String)
- logInfo(int, String, String, String, String, String)
- logInfo(String)
- logWarning(int)
- logWarning(int, Object[])
- logWarning(int, String)
- logWarning(int, String, String)
- logWarning(int, String, String, String)
- logWarning(int, String, String, String, String)
- logWarning(int, String, String, String, String, String)
- logWarning(String)
- not(boolean):boolean ObjectException - "ObjectException"
- OperationException - "OperationException"
- raiseException(CollaborationException)
- raiseException(String, int)
- raiseException(String, int, Object[])
- raiseException(String, int, String)
- raiseException(String, int, String, String)
- raiseException(String, int, String, String, String)
- raiseException(String, int, String, String, String, String)
- raiseException(String, int, String, String, String, String, String)
- raiseException(String, String)
- ServiceCallException - "ConsumerException"
- ServiceCallTransportException - "ServiceCallTransportException"
- SystemException - "SystemException"
- trace(int, int)
- trace(int, int, Object[])
- trace(int, int, String)
- trace(int, int, String, String)
- trace(int, int, String, String, String)
- trace(int, int, String, String, String, String)
- trace(int, int, String, String, String, String, String)
- trace(int, String)
- trace(String)
- TransactionException - "TransactionException"
CxExecutionContext
CxCommon/
- CxExecutionContext()
- getContext(String):Object
- MAPCONTEXT - "MAPCONTEXT"
- setContext(String, Object)
CollaborationException
Collaboration/
- getMessage():String
- getMsgNumber():int
- getSubType():String
- getText():String
- getType():String
- toString():String
Filter
crossworlds/
com/
- Filter(BaseCollaboration)
- filterExcludes(String, String):boolean
- filterIncludes(String, String):boolean
- recurseFilter(BusObj, String, boolean, String, String):boolean
- recursePreReqs(String, Vector):int
Globals
crossworlds/
com/
- Globals(BaseCollaboration)
- callMap(String, BusObj):BusObj
SmartCollabService
crossworlds/
com/
- SmartCollabService()
- SmartCollabService(BaseCollaboration)
- doAgg(BusObj, String, String, String):BusObj
- doMergeHash(Vector, String, String):Vector
- doRecursiveAgg(BusObj, String, String, String):BusObj
- doRecursiveSplit(BusObj, String):Vector
- doRecursiveSplit(BusObj, String, boolean):Vector
- getKeyValues(BusObj, String):String
- merge(Vector, String):BusObj
- merge(Vector, String, BusObj):BusObj
- split(BusObj, String):Vector
StateManagement
crossworlds/
com/
- StateManagement()
- beginTransaction()
- commit()
- deleteBO(String, String, String)
- deleteState(String, String, String, int)
- persistBO(String, String, String, String, BusObj)
- recoverBO(String, String, String):BusObj
- releaseDBConnection()
- resetData()
- retrieveState(String, String, String, int):int
- saveState(String, String, String, String, int, int, double)
- setDBConnection(CwDBConnection)
- updateBO(String, String, String, String, BusObj)
- updateState(String, String, String, String, int, int)
EventKeyAttrDef
EventManagement/
CxCommon/
- EventKeyAttrDef()
- EventKeyAttrDef(String, String)
- public String keyName
- public String keyValue
EventQueryDef
EventManagement/
CxCommon/
- EventQueryDef()
- EventQueryDef(String, String, String, String, int)
- public String nameConnector
- public String nameCollaboration
- public String nameBusObj
- public String verb
- public int ownerType
FailedEventInfo
EventManagement/
CxCommon/
- FailedEventInfo()
- FailedEventInfo(String x6, int, EventKeyAttrDef[], int, int, String, String,
int)
- public String nameOwner
- public String nameConnector
- public String nameBusObj
- public String nameVerb
- public String strTime
- public String strMessage
- public int wipIndex
- public EventKeyAttrDef[] strbusObjKeys
- public int nKeys
- public int eventStatus
- public String expirationTime
- public String scenarioName
- public int scenarioState
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
- Um das Verb in 'ChangeSummary' festzulegen, erfolgen alle Einstellungen mit den APIs
markCreate/Update/Delete.
- Um das Verb in 'ChangeSummary/EventSummary' festzulegen, werden die Verben Create, Update und Delete in 'ChangeSummary' festgelegt, während alle anderen Verben in 'EventSummary' festgelegt werden.
- So wird das Verb aus 'ChangeSummary' abgerufen:
- Wenn 'isDelete' den Wert 'true' hat, lautet das Verb Delete.
Anmerkung: Der Wert von
'isCreate' wird ignoriert, wenn 'isDelete' den Wert 'true' hat. Dieser Fall könnte eintreten, wenn die Erstellung markiert wurde, bevor das DataObject am Hub eintraf, wo es gelöscht wurde, oder falls sowohl
die Erstellung als auch die Löschung im Hub stattfanden.
- Wenn 'isDelete' den Wert 'false' und 'isCreate' den Wert 'true' hat, lautet das Verb Create.
- Wenn 'isDelete' den Wert 'false' und 'isCreate' den Wert 'false' hat, lautet das Verb Update.
- Damit ein DataObject anstelle des beabsichtigten Update nicht als
Create identifiziert wird, müssen Sie bei aktivierter Protokollierung Folgendes ausführen:
- Protokollierung während der Erstellung des DataObject aussetzen
- Protokollierung bei der Aktualisierung des DataObject wieder aufnehmen (oder API markUpdated verwenden)
Ladevorgänge
Beim Laden wird eine Laufzeit-XML von WebSphere InterChange
Server in eine BusinessGraph AfterImage-Instanz
von WebSphere Business Integration geladen.
- Eine Instanz des entsprechenden BusinessGraph wird erstellt.
- Die Protokollierung von 'ChangeSummary' wird aktiviert, damit bei einer späteren Aktivierung die Einträge nicht gelöscht werden.
- Die Protokollierung von 'ChangeSummary' wird angehalten, damit keine unerwünschten Informationen in 'ChangeSummary' aufgenommen werden.
- Die Attribute des BusinessObject der höchsten Ebene werden im
DataObject erstellt (siehe Abschnitt 'Attributverarbeitung').
- Falls das BusinessObject der höchsten Ebene untergeordnete BusinessObjects enthält, werden diese rekursiv verarbeitet.
- Die Attribute dieser untergeordneten BusinessObjects werden im
DataObject erstellt (siehe Abschnitt 'Attributverarbeitung').
- Das Verb des BusinessObject der höchsten Ebene wird auf das Verb der höchsten Ebene
des BusinessGraph gesetzt und in den Zusammenfassungen festgelegt.
- Das Verb der untergeordneten BusinessObjects wird in den Zusammenfassungen festgelegt.
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
- Alle Werte, die im Folgenden nicht behandelt werden, werden UNVERÄNDERT geladen/gespeichert.
- ObjectEventId wird aus/in 'EventSummary' geladen/gespeichert.
- Für CxBlank und CxIgnore gilt:
- Auf der Konvertierungsseite des BusinessObject von WebSphere Business Integration werden CxBlank und 'CxIgnore' folgendermaßen festgelegt/angegeben:
- CxIgnore: Ist nicht festgelegt oder mit dem Java-Wert Null festgelegt
- CxBlank: Wert ist typabhängig (siehe Tabelle unten)
- Auf der Konvertierungsseite des XML-Dokuments von WebSphere InterChange Server werden CxBlank und CxIgnore folgendermaßen festgelegt/angegeben:
Tabelle 1. Festlegung von CxBlank und CxIgnore
Typ |
CxIgnore |
CxBlank |
Int |
Integer.MIN_VALUE |
Integer.MAX_VALUE |
Float |
Float.MIN_VALUE |
Float.MAX_VALUE |
Double |
Double.MIN_VALUE |
Double.MAX_VALUE |
String/date/longtext |
"CxIgnore" |
"" |
Untergeordnete BusinessObjects |
(leeres Element) |
nicht verfügbar |
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:
- WebSphere MQ
Workflow-Laufzeitinstanzen
- Programmanwendungen, die von einem WebSphere MQ Workflow-Programmausführungsagenten (PEA) oder WebSphere MQ
Workflow-Prozessausführungsserver (PES für z/OS) aufgerufen werden
Weitere Informationen zur Migration unter Verwendung des FDL2BPEL-Konvertierungstools finden Sie auf der WebSphere MQ Workflow-Unterstützungssite.
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:
- Stellen Sie sicher, dass FDL-Programmaktivitäten einem benutzerdefinierten Prozessausführungsserver(UPES) zugeordnet sind, wenn es sich nicht um reine staff-Aktivitäten handelt.
- Stellen Sie sicher, dass Mitarbeiterzuordnungen für WebSphere MQ Workflow-Programmaktivitäten mit TEL-Standard-Mitarbeiterverben kompatibel sind.
- Verwenden Sie kurze und einfache Namen, um die Lesbarkeit migrierter Prozessmodelle zu verbessern. Beachten Sie, dass es sich bei FDL-Namen um illegale BPEL-Namen handeln kann. Der Migrationsassistent konvertiert FDL-Namen automatisch in gültige BPEL-Namen.
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:
- WebSphere MQ
Workflow-Laufzeitinstanzen
- Programmanwendungen, die von einem WebSphere MQ Workflow-Programmausführungsagenten (PEA) oder WebSphere MQ
Workflow-Prozessausführungsserver (PES für z/OS) aufgerufen werden
Führen Sie die folgenden Schritte aus, um den Migrationsassistenten für die Migration
Ihrer WebSphere MQ
Workflow-Artefakte zu verwenden:
- Wählen Sie die Optionen Datei -> Importieren -> Geschäftsintegration -> WebSphere
MQ Workflow - FDL-Datei aus, und klicken Sie auf Weiter, um den Assistenten aufzurufen:
Sie können den Migrationsassistenten auch auf der
Begrüßungsseite öffnen, indem Sie auf das Symbol 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.)
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.
- 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:
- 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:
- 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 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:
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.
- Die Migration von FDL generiert Aufrufaktivitäten für UPES-Aktivitäten und die entsprechenden WSDLs. Die Laufzeitumgebung unterscheidet sich allerdings erheblich zwischen IBM WebSphere MQ
Workflow und IBM WebSphere Process
Server in Bezug auf die Verfahren, die für die Korrelation von Aufrufnachrichten und deren Antworten verwendet werden.
- Die Laufzeitsteuerkomponenten von IBM WebSphere MQ Workflow und IBM WebSphere Process Server unterscheiden sich in der Handhabung nicht initialisierter Daten. Während es bei IBM WebSphere MQ Workflow zu keinen Fehlern kam, wird in IBM WebSphere Process
Server eine Ausnahmebedingung ausgegeben und die Ausführung des Prozesses gestoppt. Stellen Sie für die korrekte Ausführung migrierter Anwendungen in IBM WebSphere Process Server sicher, dass alle Variablen und Substrukturen initialisiert werden, bevor sie in Verbindung mit Zuordnungs-, Aufruf-, Mitarbeiter- oder Antwortaktivitäten verwenden werden.
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:
- Quellenartefakte für die Migration vorbereiten. Diese Aktionen müssen möglicherweise
in WebSphere Studio
Application Developer Integration Edition ausgeführt werden.
- Verwenden Sie den Migrationsassistenten oder dass Befehlszeilenscript WSADIEServiceProjectMigration zur automatischen Migration dieser Artefakte nach dem Geschäftsintegrations-Modulprojekt.
- 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.
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.
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:
- Stellen Sie vor der Migration sicher, dass Sie über eine Sicherungskopie des gesamten 5.1 Arbeitsbereichs verfügen.
- 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).
- 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)
- 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:
- Gehen Sie im WebSphere Integrationsentwickler zum Menüelement
Fenster und wählen Sie Benutzervorgaben.
- Gehen Sie zum Arbeitsbereich und wählen Sie die Kategorie Leistungsmerkmale.
- Wählen Sie alle Funktionen in den folgenden Kategorien:
- Advanced J2EE
- Enterprise Java
- Integration Developer
- Java Developer
- Web Developer (typisch)
- Web Service Developer
- XML Developer
- Klicken Sie auf OK.
- 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:
- 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.
- Ö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:
- Klicken Sie mit der rechten Maustaste auf
das Projekt, und wählen Sie die Option Migration -> J2EE-Migrationsassistent....
- Überprüfen Sie die Warnmeldungen auf der ersten Seite, und klicken Sie auf Weiter, sofern nichts anderes angegeben ist.
- 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.
- 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.
- 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:
- Wählen Sie die Optionen Bibliothek hinzufügen -> JRE-Systembibliothek -> Alternative JRE - WPS-Server V6.1 JRE -> Fertig stellen.
- Wählen Sie daraufhin Bibliothek hinzufügen -> Ziel des WPS-Servers -> Klassenpfad des WPS-Servers konfigurieren' -> Fertig stellen.
- WebSphere Integration
Developer generiert den Implementierungscode standardmäßig bei der Erstellung.
- 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:
- Wenn sich die .wsdl- und/oder .xsd-Dateien in demselben Serviceprojekt wie die .bpel-Datei befinden, ist keine weitere Aktion erforderlich.
- Wenn sich die .wsdl- und/oder .xsd-Dateien in einem anderen Serviceprojekt als dem befinden, das Sie migrieren, müssen die 5.1-Artefakte mit Hilfe der WebSphere Studio
Application Developer Integration Edition vor der Migration reorganisiert werden. Der Grund hierfür ist, dass Geschäftsintegrations-Modulprojekte keine Artefakte gemeinsam nutzen können.
Im Folgenden sind zwei Optionen für die Reorganisation der 5.1-Artefakte ausgeführt:
- Erstellen Sie ein neues
Java-Projekt in WebSphere Studio
Application Developer Integration Edition, in dem alle allgemeinen Artefakte enthalten sind. Legen Sie alle .wsdl- und .xsd-Dateien, die von mehr als einem Serviceprojekt gemeinsam genutzt werden, in diesem neuen Java-Projekt ab.
Fügen Sie eine Abhängigkeit von diesem neuen Java-Projekt zu allen Serviceprojekten hinzu, die diese allgemeinen Artefakte verwenden. Erstellen Sie ein neues Geschäftsintegrations-Bibliotheksprojekt in WebSphere Integration Developer mit demselben Namen wie das 5.1 gemeinsam genutzteJava-Projekt, bevor Sie eins der Serviceprojekte migrieren. Kopieren Sie die alten .wsdl- und .xsd-Dateien aus dem gemeinsam genutzten Java-Projekt von 5.1 in diesen neuen BI-Bibliotheksprojektordner. Dies muss vor der Migration der BPEL-Serviceprojekte geschehen.
- Eine andere Option besteht darin, eine lokale Kopie dieser gemeinsam genutzten .wsdl- und .xsd-Artefakte in jedem Serviceprojekt zu behalten, so dass es zu keinen Abhängigkeiten zwischen Serviceprojekten kommt.
- Wenn sich die .wsdl- und/oder .xsd-Dateien in einem anderen Projekttyp befinden
(normalerweise andere Java-Projekte), erstellen Sie ein Geschäftsintegrations-Bibliotheksprojekt mit demselben Namen wie der des 5.1- Projekts. Sie sollten außerdem den neuen Klassenpfad des neuen Bibliotheksprojekts einrichten und die Einträge desJava-Projekts aus 5.1 hinzufügen, sofern welche vorhanden sind. Dieser Projekttyp ist nützlich für das Speichern von gemeinsam genutzten Artefakten.
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:
- Versuchen Sie, die Assign-Aktivität so häufig wie möglich zu verwenden
(im Gegensatz zum Umsetzungsservice, der nur benötigt wird, wenn eine erweiterte Umsetzung erforderlich ist. Sie sollten dieses Verfahren verwenden, da temporäre Komponenten erstellt werden müssen, so dass das SCA-Modul einen Umsetzungsservice aufrufen kann. Zusätzlich gibt es keine spezielle Toolunterstützung in WebSphere Integration
Developer für die Umsetzungsservices, die in 5.1 erstellt wurden (Sie müssen den WSDL- oder XML-Editor zur Bearbeitung der in der WSDL-Datei eingebetteten XSLT, wenn Sie das Verhalten des Umsetzungsservice ändern müssen).
- Geben Sie einen Teil pro WSDL-Nachricht an, gemäß der WS-I-Spezifikation (WS-I - Web-Services Interoperability)
und dem bevorzugten 6.x-Stil.
- Verwenden Sie den WSDL doc-literal-Stil, da dies der bevorzugte Stil in 6.x ist.
- Stellen Sie sicher, dass alle komplexen Typen mit einem Namen versehen wurden und dass jeder komplexe Typ anhand seines Zielnamensbereichs und Namens eindeutig erkannt werden kann. Der folgende Code zeigt das empfohlene Verfahren für die Definition von komplexen Typen und von Elementen dieses Typs (Definition des komplexen Typs gefolgt von einer Elementdefinition, die den Typ verwendet):
<schema attributeFormDefault="qualified"
elementFormDefault="unqualified"
targetNamespace="http://util.claimshandling.bpe.samples.websphere.ibm.com"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://util.claimshandling.bpe.samples.websphere.ibm.com">
<complexType name="Duration">
<all>
<element name="hours" type="int"/>
<element name="minutes" type="int"/>
<element name="days" type="int"/>
</all>
</complexType>
<element name="DurationElement" type="tns:Duration"/>
</schema>
Das folgende Beispiel ist ein anonymer komplexer Typ, der vermieden werden sollte, weil er bei der Serialisierung eines SDO in XML Probleme verursachen kann (ein Element enthält eine Definition für einen anonymen komplexen Typ):
<schema attributeFormDefault="qualified"
elementFormDefault="unqualified"
targetNamespace="http://util.claimshandling.bpe.samples.websphere.ibm.com"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://util.claimshandling.bpe.samples.websphere.ibm.com">
<element name="DurationElement">
<complexType>
<all>
<element name="hours" type="int"/>
<element name="minutes" type="int"/>
<element name="days" type="int"/>
</all>
</complexType>
</element>
</schema>
- Wenn Sie einen Service für externe Kunden veröffentlichen, generieren Sie Service-Implementierungscode mit Hilfe von IBM Web-Services (anstelle von Apache SOAP/HTTP), da IBM Web-Services
in 6.x direkt unterstützt werden, Apache Web-Services jedoch nicht.
- Es gibt zwei Arten, auf die Sie WSDL- und XSD-Dateien in 5.1 organisieren können, um den von Ihnen durchzuführenden Reorganisationsaufwand während der Migration zu reduzieren. In 6.x müssen gemeinsam genutzte Artefakte wie WSDL- und XSD-Dateien in BI-Projekten (Geschäftsintegrations-Module und -Bibliotheken) abgelegt sein, damit auf sie von einem BI-Service verwiesen werden kann:
- Speichern Sie alle WSDL-Dateien, die vom mehr als einem Serviceprojekt gemeinsam genutzt werden, in einem Java-Projekt, auf das die Serviceprojekte verweisen können. Während der Migration zu 6.x erstellen Sie eine neue Geschäftsintegrationsbibliothek mit demselben Namen wie für das gemeinsam genutzte 5.1-Java-Projekt.
Kopieren Sie alle Artefakte aus dem gemeinsam genutzten Java-Projekt 5.1. zur Bibliothek, so dass der Migrationsassistent die Artefakte auflösen kann, wenn die Serviceprojekte, die diese Artefakte verwenden, migriert werden.
- Speichern Sie eine lokale Kopie aller WSDL/XSD-Dateien, auf die ein Serviceprojekt verweist, im Serviceprojekt selbst. WebSphere Studio Application Developer
Integration Edition-Serviceprojekte werden in ein Geschäftsintegrationsmodul in WebSphere Integration
Developer migriert und ein Modul kann keine Abhängigkeiten von anderen Modulen haben (ein Serviceprojekt mit Abhängigkeiten von anderen Serviceprojekten für die gemeinsame Nutzung von WSDL- oder XSD-Dateien kann nicht problemlos migriert werden).
- Vermeiden Sie die Verwendung der generischen Nachrichtenübertragungs-API (generische MDBs) des Geschäftsprozess-Choreographer, da diese in 6.x nicht enthalten ist. Eine MDB-Schnittstelle, die ein spätes Binding bietet, steht in 6.x nicht zur Verfügung.
- Verwenden Sie die EJB-API des generischen Geschäftsprozess-Choreographers, statt die generierten Session-Beans aufzurufen, die für eine bestimmte Version eines Prozesses spezifisch sind. Diese Session-Beans werden
in Version 6.x nicht generiert.
- Wenn Sie über einen Geschäftsprozess mit mehreren Antworten für dieselbe Operation verfügen, stellen Sie im Falle von Client-Einstellungen sicher, dass alle Antworten für diese Operation über dieselben Client-Einstellungen verfügen, da in Version 6.x nur ein Satz mit Client-Einstellungen pro Operationsantwort unterstützt wird.
- Entwerfen Sie BPEL Java-Snippets gemäß den folgenden Richtlinien:
- Vermeiden Sie das Senden von WSIFMessage-Parametern zu benutzerdefinierten Java-Klassen
- versuchen Sie, wenn möglich nicht vom WSIFMessage-Datenformat abzuhängen.
- Vermeiden Sie wenn möglich die Verwendung von WSIF-Metadaten-APIs.
- Vermeiden Sie wenn möglich die Erstellung von Top-down EJBs oder Java-Services, da das Java/EJB-Gerüst, das aus den WSDL-Porttypen/Nachrichten generiert wird, von WSIF-Klassen abhängt (z. B. WSIFFormatPartImpl). Erstellen Sie stattdessen die Java/EJB-Schnittstellen zuerst und generieren Sie einen Service um die Java-Klasse/EJB herum
(Bottom-up-Methode).
- Vermeiden Sie die Erstellung oder Verwendung von WSDL-Schnittstellen, die auf den Typ soapenc:Array verweisen, da dieser Schnittstellentyp nicht naturgemäß im SCA-Programmiermodell unterstützt wird
- Vermeiden Sie die Erstellung von Nachrichtentypen, bei deren problemorientierten Nachrichtentypen es sich um einen Feldgruppentyp handelt
(maxOccurs-Attribut ist größer als eins), da dieser Schnittstellentyp nicht naturgemäß im SCA-Programmiermodell unterstützt wird.
- Definieren Sie Ihre WSDL-Schnittstellen genau - vermeiden Sie wenn möglich XSD complexTypes, die auf den Typ xsd:anyType verweisen.
- Achten Sie bei jeder WSDL- und XSD-Definition, die Sie aus einer EJB- oder Java-Bean generieren, darauf,
dass der Zielnamensbereich eindeutig ist (der Java-Klassenname und -Paketname werden durch den Zielnamensbereich dargestellt),
um bei der Migration nach WebSphere Process
Server 6.x Konflikte zu verhindern. In WebSphere Process Server 6.x ist es unzulässig, wenn zwei unterschiedliche
WSDL/XSD-Definitionen denselben Namen und denselben Zielnamensbereich
aufweisen. Diese Situation tritt häufig auf, wenn der Web-Service-Assistent oder der Befehl
'Java2WSDL' ohne explizite Angabe des Zielnamensbereichs verwendet wird (der Zielnamensbereich ist zwar
für den Paketnamen der EJB-
oder Java-Bean eindeutig, nicht jedoch für die Klasse selbst, so dass bei der Generierung
eines Web-Service für zwei oder mehr EJB- oder Java-Beans im gleichen Paket Probleme auftreten). Die Lösung besteht darin, im Web-Service-Assistenten eine angepasste Zuordnung von Paket und Namensbereich anzugeben oder
die Befehlszeilenoption -namespace für den Befehl 'Java2WSDL' zu verwenden, um sicherzustellen, dass der Namensbereich der generierten Dateien für die jeweilige Klasse eindeutig ist.
- Verwenden Sie nach Möglichkeit für jede WSDL-Datei eindeutige Namensbereiche. In der WSDL 1.1-Spezifikation gibt es Einschränkungen hinsichtlich des Imports von zwei unterschiedlichen WSDL-Dateien mit demselben Namensbereich. Diese Einschränkungen werden in WebSphere Integration Developer 6.x
genauestens umgesetzt.
Serviceprojekte mit dem WebSphere Integration Developer-Migrationsassistenten migrieren
Der WebSphere Integration
Developer-Migrationsassistent ermöglicht die Migration von Serviceprojekten.
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 korrekt konfiguriert werden.
- Es ist nicht erforderlich, die Option für automatische Erstellung bei der Migration von
WebSphere Integration Developer 6.0.2 oder höher zu inaktivieren, da diese Option während des Migrationsprozesses automatisch inaktiviert wird.
Der Migrationsassistent führt die folgenden Schritte aus:
- Erstellung eines neuen Geschäftsintegrationsmoduls (der Modulname wird von Ihnen definiert)
- Migration der Serviceprojekt-Klassenpfadeinträge zum neuen Modul
- Kopieren aller WebSphere Business
Integration Server Foundation-Quellenartefakte aus dem ausgewählten Quellenprojekt in dieses Modul
- Migration der BPEL-Erweiterungen zu WSDL-Dateien
- 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
- Erstellung einer SCA-Komponente für jeden .bpel-Prozess
- Erstellung einer Überwachungsdatei (.mon) für jeden BPEL-Prozess, um das Standardüberwachungsverhalten von WebSphere Studio Application Developer
Integration Edition (wenn nötig) beizubehalten
- Erstellung von Importen und Exporten in Abhängigkeit von den in WebSphere Studio
Application Developer Integration Edition ausgewählten Implementierungsoptionen
- 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:
- 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:
Sie können den Migrationsassistenten auch auf der Begrüßungsseite
öffnen, indem Sie auf das Symbol 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.)
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.
- 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:
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.
- Wählen Sie in den Migrationsoptionen 'Ursprüngliche BPEL Java-Snippets beibehalten' im Kontrollkästchen für Kommentare aus:
Klicken Sie auf Fertig stellen.
- Wenn der Migrationsprozess abgeschlossen ist, wird das Fenster Migrationsergebnisse geöffnet:
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:
- Erstellung eines neuen Geschäftsintegrationsmoduls (der Modulname wird von Ihnen definiert)
- Migration der Klassenpfadeinträge des Serviceprojekts in das neue Modul
- Kopieren aller WebSphere Business
Integration Server Foundation-Quellenartefakte aus dem ausgewählten Quellenprojekt in dieses Modul
- Migration der BPEL-Erweiterungen zu WSDL-Dateien
- 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
- Erstellung einer SCA-Komponente für jeden .bpel-Prozess
- Erstellung einer Überwachungsdatei (.mon) für jeden BPEL-Prozess, um das Standardüberwachungsverhalten von WebSphere Studio Application Developer
Integration Edition (wenn nötig) beizubehalten
- Erstellung von Importen und Exporten in Abhängigkeit von den in WebSphere Studio
Application Developer Integration Edition ausgewählten Implementierungsoptionen
- Erstellung einer Verbindung zwischen der BPEL-Komponente und den zugehörigen Partnerlinks (Importe, Exporte und Java-Komponenten)
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:
- 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
- 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
- Starten Sie nach der Ausführung des Befehls den neuen Arbeitsbereich in WebSphere Integration
Developer.
- 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".
- Ö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.
- Ö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).
- 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.
- 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:
- XSD-Schemata für komplexe Datentypen erstellen:
- Innerhalb der Schnittstellen-WSDL-Datei
- Als neue Datei für jeden Datentyp
- Unterstützung der Funktionalität zur Fehlerbehandlung:
- Fehler generieren
- Keinen Fehler generieren
- Sonstige Informationen über den zu generierenden Service, wie beispielsweise Binding und Servicenamen
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:
- 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.
- 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.
- Eine generische Komponente wird im Assembly-Diagramm angezeigt. Markieren Sie sie und gehen Sie zur Sicht Eigenschaften.
- Sie können den Namen und Anzeigenamen der Komponente in einen beschreibenden Namen in der Registerkarte Beschreibung ändern.
- 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.
- 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.
- 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.
- 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:
- Relevante Definitionen aus der 5.1 WSDL-Schnittstelle
- Die WebSphere Studio
Application Developer Integration Edition 5.1 Java-Methoden, die der WSDL entsprechen
- 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:
- Verschieben Sie die Logik von der ursprünglichen Java-Klasse in diese Klasse und passen Sie sie für die Verwendung von DataObject an.
- Hierbei handelt es sich um die empfohlene Option, wenn Sie die Top-down-Methode in WebSphere Studio
Application Developer Integration Edition ausgewählt haben und die Java-Komponente mit DataObject-Parametern arbeiten soll. Diese Nacharbeit ist notwendig, da die aus WSDL-Definitionen in
WebSphere Studio Application Developer
Integration Edition erstellten Java-Klassen über WSIF-Abhängigkeiten verfügen, die eliminiert werden sollten.
- Erstellen Sie eine private Instanz der alten Java-Klasse in dieser generierten Java-Klasse und schreiben Sie Code, um Folgendes zu tun:
- Konvertieren aller Parameter der generierten Java-Implementierungsklasse in Parameter, die die alte Java-Klasse erwartet
- Aufrufen der privaten Instanz der alten Java-Klasse mit den konvertierten Parametern
- Konvertieren des Rückgabewerts der alten Java-Klasse in den Rückgabewerttyp, der von der generierten Java-Implementierungsmethode deklariert wird
- 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:
- Wenn dieser Service durch einen Geschäftsprozess in demselben Modul aufgerufen wird, stellen Sie eine Verbindung vom entsprechenden Geschäftsprozessverweis zur Schnittstelle dieser Java-Komponente her.
- Wenn dieser Service von einem Geschäftsprozess in einem anderen Modul aufgerufen wird, erstellen Sie einen Export mit SCA-Binding und ziehen und über geben Sie diesem Export vom anderen Modul zum Assembly-Editor dieses Moduls, um den entsprechenden Import mit SCA-Binding zu erstellen. Verbinden Sie den entsprechenden Geschäftsprozessverweis mit diesem Import.
- Wenn dieser Service in WebSphere Studio Application Developer
Integration Edition veröffentlicht wurde, um ihn extern zugänglich zu machen, finden Sie Informationen zur Neuveröffentlichung dieses Service im Abschnitt "SCA-Exporte für den Zugriff auf den migrierten Service
erstellen".
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:
- 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.
- 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.
- 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.
- Starten Sie den Testserver, implementieren Sie diese Anwendung für den Server und stellen Sie sicher, dass er erfolgreich startet.
- 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.
- 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.
- Die Java-Klasse, auf die Sie mit der rechten Maustaste geklickt haben, wird angezeigt. Klicken Sie auf
Weiter.
- 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.
- 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.
- 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.
- 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.
- Klicken Sie auf Weiter. Beachten Sie, dass Sie möglicherweise mehrere Minuten warten müssen.
- 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.
- Wechseln Sie zur Geschäftsintegrationsperspektive und erweitern Sie erst das Modul und daraufhin die logische Kategorie Web-Service-Ports.
- 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:
- 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.
- 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.
- 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:
- Die erste Option bietet wahrscheinlich eine bessere Leistung zur Laufzeit, da der Aufruf eines Web-Service langsamer ist als der Aufruf einer Java-Komponente.
- Die erste Option kann Kontext weitergeben, während ein Web-Serviceaufruf Kontext nicht auf die gleiche Weise weitergibt.
- Die zweite Option beinhaltet nicht die Erstellung eines benutzerdefinierten Codes.
- Die zweite Option ist unter Umständen für einige Java-Schnittstellendefinitionen nicht möglich, da die Erzeugung eines Java-Service Einschränkungen unterliegt. Weitere Informationen finden Sie in der Dokumentation
zu Rational Application Developer unter
Limitations of Web services (Einschränkungen für Web-Services).
- Die zweite Option kann zu einer Schnittstellenänderung führen und damit einer Änderung des SCA-Verbrauchers.
- Die zweite Option setzt voraus,
dass ein Server von WebSphere Process Server 6.x installiert und für die Arbeit mit WebSphere Integration Developer konfiguriert ist.
Um die installierten Laufzeiten anzuzeigen, die für die Arbeit mit
WebSphere Integration
Developer konfiguriert wurden, gehen Sie zu Fenster -> Benutzervorgaben -> Server -> Installierte Laufzeiten,
wählen Sie den Eintrag WebSphere Process Server v6.1 aus (falls dieser vorhanden ist), und
stellen Sie sicher, dass er auf die Position verweist, an der das Produkt installiert ist.
Stellen Sie sicher, dass dieser Eintrag markiert ist, wenn der Server vorhanden ist, und nicht markiert, wenn dieser Server nicht installiert ist. Sie können auch auf Hinzufügen klicken,
um einen weiteren Server hinzuzufügen.
- Wenn die Java-Komponente in WebSphere Studio Application Developer
Integration Edition mit der Top-down-Methode erstellt wurde, wobei das Java-Gerüst von einer WSDL erstellt wurde, sind die Parameter in diese und aus dieser Java-Klasse wahrscheinlich eine Unterklasse von WSIFFormatPartImpl. Wenn dies der Fall ist, wählen Sie Option 1 für die Erzeugung eines neuen Java-Gerüsts im SCA-Stil aus den ursprünglichen WSDL/XSDs oder Option 2 für die Erzeugung eines neuen generischen Java-Gerüsts (nicht abhängig von den WSIF- oder DataObject-APIs) aus der ursprünglichen WSDL-Schnittstelle.
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:
- 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.
- 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.
- Eine generische Komponente wird im Assemblydiagramm angezeigt. Markieren Sie sie und gehen Sie zur Ansicht Eigenschaften.
- 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.
- 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.
- 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:
- Relevante Definitionen aus der 5.1 WSDL-Schnittstelle
- Die WebSphere Studio
Application Developer Integration Edition 5.1 Java-Methoden, die der WSDL entsprechen
- 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:
- 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.
- 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.
- 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.
- 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.
- Wählen Sie das Verbindungstool aus der Palette im Assembly-Editor.
- Klicken Sie auf die Java-Komponente und lassen Sie die Maustaste los.
- Klicken Sie als nächstes auf den EJB-Import und lassen Sie die Maustaste los.
- 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.
- 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.
- 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:
- Erstellen Sie eine private Variable (deren Typ der Ihrer remote angeschlossenen EJB-Schnittstelle entspricht):
private YourEJBInterface ejbService = null;
- 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");
- 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:
- Konvertieren Sie alle Parameter in die Parametertypen, die die EJB erwartet.
- Rufen Sie die entsprechende Methode im EJB-Verweis unter Verwendung des SCA-Programmiermodells auf, und senden Sie die konvertierten Parameter.
- 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: 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:
- Klicken Sie mit der rechten Maustaste auf das Unternehmensanwendungsprojekt, das den Container für die EJB darstellt, um die herum Sie einen Service erstellen.
- 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.
- Starten Sie den Testserver, implementieren Sie diese Anwendung für den Server und stellen Sie sicher,
dass er erfolgreich startet.
- 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.
- Klicken Sie mit der rechten Maustaste und wählen Sie Web-Services -> Web-Services erstellen.
- 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.
- Stellen Sie sicher, dass die EJB, auf die Sie mit der rechten Maustaste geklickt haben, hier ausgewählt ist, und klicken Sie auf Weiter.
- 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.
- 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.
- 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.
- 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.
- 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.
- Klicken Sie auf Weiter. Beachten Sie, dass Sie möglicherweise mehrere Minuten warten müssen.
- 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.
- Wechseln Sie zur Geschäftsintegrationsperspektive und erweitern Sie erst das migrierte Modul und daraufhin die logische Kategorie Web-Service-Ports.
- 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:
- 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.
- 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.
- 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:
- Wenn dieser Service durch einen Geschäftsprozess in demselben Modul aufgerufen wird, stellen Sie eine Verbindung vom entsprechenden Geschäftsprozessverweis zu dieser EJB-Komponente her.
- Wenn dieser Service von einem Geschäftsprozess in einem anderen Modul aufgerufen wird, erstellen Sie einen Export mit SCA-Binding und ziehen und über geben Sie diesem Export vom anderen Modul zum Assembly-Editor dieses Moduls, um den entsprechenden Import mit SCA-Binding zu erstellen. Verbinden Sie den entsprechenden Geschäftsprozessverweis mit diesem Import.
- Wenn dieser Service in WebSphere Studio Application Developer
Integration Edition veröffentlicht wurde, um ihn extern zugänglich zu machen, finden Sie Informationen zur Neuveröffentlichung dieses Service im Abschnitt "SCA-Exporte für den Zugriff auf den migrierten Service
erstellen".
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:
- Die erste Option bietet wahrscheinlich eine bessere Leistung zur Laufzeit, da der Aufruf eines Web-Service langsamer ist als der Aufruf eines EJB.
- Die erste Option kann Kontext weitergeben, während ein Web-Serviceaufruf Kontext nicht auf die gleiche Weise weitergibt.
- Die zweite Option beinhaltet nicht die Erstellung eines benutzerdefinierten Codes.
- Die zweite Option ist unter Umständen für einige EJB-Schnittstellendefinitionen nicht möglich, da die Generierung eines EJB-Service Einschränkungen unterliegt. Weitere Informationen finden Sie in der Dokumentation
zu Rational Application Developer unter
Limitations of Web services (Einschränkungen für Web-Services).
- Die zweite Option kann zu einer Schnittstellenänderung führen und damit einer Änderung des SCA-Verbrauchers.
- Die zweite Option setzt voraus,
dass ein Server von WebSphere Process Server 6.x installiert und für die Arbeit mit WebSphere Integration Developer konfiguriert ist.
Um die installierten Laufzeiten anzuzeigen, die für die Arbeit mit
WebSphere Integration
Developer konfiguriert wurden, gehen Sie zu Fenster -> Benutzervorgaben -> Server -> Installierte Laufzeiten,
wählen Sie den Eintrag WebSphere Process Server v6.1 aus (falls dieser vorhanden ist), und
stellen Sie sicher, dass er auf die Position verweist, an der das Produkt installiert ist.
Stellen Sie sicher, dass dieser Eintrag markiert ist, wenn der Server vorhanden ist, und nicht markiert, wenn dieser Server nicht installiert ist. Sie können auch auf Hinzufügen klicken,
um einen weiteren Server hinzuzufügen.
- Wenn die Java-Komponente in WebSphere Studio Application Developer
Integration Edition mit der Top-down-Methode erstellt wurde, wobei das EJB-Gerüst von einer WSDL erstellt wurde, sind die Parameter in diese und aus dieser Java-Klasse wahrscheinlich eine Unterklasse von WSIFFormatPartImpl. Wenn dies der Fall ist, wählen Sie Option 2 für die Erzeugung eines neuen generischen EJB-Gerüsts (nicht abhängig von den WSIF oder DataObject APIs) aus der ursprünglichen WSDL-Schnittstelle.
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:
- 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 gibt mehrere Szenarien, in denen ein BPEL-Prozess einen anderen BPEL-Prozess aufrufen kann. Suchen Sie unten nach dem Szenario, das Ihre Anwendung betrifft:
- Falls sich die aufgerufene BPEL im gleichen Modul befindet, stellen Sie eine Verbindung vom entsprechenden Verweis der ersten BPEL-Komponente zur entsprechenden Schnittstelle der BPEL-Zielkomponente her.
- Falls sich die aufgerufene BPEL in einem anderen Modul befindet (wobei es sich bei dem anderen Modul um ein migriertes Serviceprojekt handelt), gehen Sie folgendermaßen vor:
- Erstellen Sie einen Export mit SCA-Binding für den zweiten Geschäftsprozess in seinem Modul-Assembly-Diagramm.
- Erweitern Sie das Assembly-Symbol des zweiten Moduls im Navigator der Sicht 'Geschäftsintegration'. Der soeben von Ihnen erstellte Export sollte nun angezeigt werden.
- Ziehen und übergeben (Drag und Drop) Sie den Export von der Sicht 'Geschäftsintegration' unterhalb des zweiten Moduls in den geöffneten Assembly-Editor des ersten Moduls. Dadurch wird ein Import mit SCA-Binding im ersten Modul erstellt. Wenn dieser Service in WebSphere Studio Application Developer
Integration Edition veröffentlicht wurde, um ihn extern zugänglich zu machen, finden Sie weitere Informationen im Abschnitt "SCA-Exporte für den Zugriff auf den migrierten Service erstellen".
- Verbinden Sie den entsprechenden Verweis des ersten Geschäftsprozesses mit dem Import, den Sie gerade in diesem Modul erstellt haben.
- Speichern Sie das Assembly-Diagramm.
- So erreichen Sie ein spätes Binding beim Aufruf des zweiten Geschäftsprozesses:
- Stellen Sie keine Verbindung zum Verweis der ersten Geschäftsprozesskomponente her. Öffnen Sie den ersten Prozess im BPEL-Editor und wählen Sie im Abschnitt für die Verweispartner denjenigen Partner aus,
der dem zweiten BPEL-Prozess entspricht, um den Aufruf mit einem späten Binding zu erreichen.
- Geben Sie in der Sicht 'Eigenschaften' auf der Registerkarte Beschreibung den Namen des
zweiten Geschäftsprozesses im Feld für die Prozess-Schablone ein.
- Speichern Sie den Geschäftsprozess. Der Aufruf mit spätem Binding ist hiermit eingerichtet.
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:
- 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.
- 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).
- 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.
- Erweitern Sie in der Geschäftsintegrationsperspektive das migrierte Modul und öffnen Sie das Assembly-Diagramm im Assembly-Editor.
- 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.
- Wählen Sie die Erstellung eines Imports mit Web-Service-Binding.
- 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.
- Speichern Sie das Assembly-Diagramm.
Wenn Sie diesen Vorgang abgeschlossen haben, müssen Sie den Service neu verbinden:
- Wenn dieser Service durch einen Geschäftsprozess in demselben Modul aufgerufen wird, stellen Sie eine Verbindung vom entsprechenden Geschäftsprozessverweis zu diesem Import her.
- Wenn dieser Service von einem Geschäftsprozess in einem anderen Modul aufgerufen wird, erstellen Sie einen Export mit SCA-Binding und ziehen und über geben Sie diesem Export vom anderen Modul zum Assembly-Editor dieses Moduls, um den entsprechenden Import mit SCA-Binding zu erstellen. Verbinden Sie den entsprechenden Geschäftsprozessverweis mit diesem Import.
- Speichern Sie das Assembly-Diagramm.
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:
- 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.
- 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).
- 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.
- Erweitern Sie in der Geschäftsintegrationsperspektive das migrierte Modul und öffnen Sie das Assembly-Diagramm im Assembly-Editor.
- 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.
- Wählen Sie die Erstellung eines Imports mit Web-Service-Binding.
- 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.
- Speichern Sie das Assembly-Diagramm.
Wenn Sie diesen Vorgang abgeschlossen haben, müssen Sie den Service neu verbinden:
- Wenn dieser Service durch einen Geschäftsprozess in demselben Modul aufgerufen wird, stellen Sie eine Verbindung vom entsprechenden Geschäftsprozessverweis zu diesem Import her.
- Wenn dieser Service von einem Geschäftsprozess in einem anderen Modul aufgerufen wird, erstellen Sie einen Export mit SCA-Binding und ziehen und über geben Sie diesem Export vom anderen Modul zum Assembly-Editor dieses Moduls, um den entsprechenden Import mit SCA-Binding zu erstellen. Verbinden Sie den entsprechenden Geschäftsprozessverweis mit diesem Import.
- Speichern Sie das Assembly-Diagramm.
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:
- 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.
- 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).
- Als nächstes fügen Sie einen Import hinzu, der der Anwendung ermöglicht, mit einer
JMS-Warteschlange gemäß dem SCA-Programmiermodell zu interagieren.
- 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.
- Ein Dialog namens Erstellung von Komponenten ermöglicht Ihnen die Auswahl des zu erstellenden Komponententyps. Wählen Sie Ohne Binding importieren.
- 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.
- 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.
- 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>
- 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:
- JMS-Importbinding (diese ist am wichtigsten)
- Verbindung
- Ressourcenadapter
- JMS-Ziele
- Methodenbindings
Wenn Sie diesen Vorgang abgeschlossen haben, müssen Sie den Service neu verbinden:
- Wenn dieser Service durch einen Geschäftsprozess in demselben Modul aufgerufen wird, stellen Sie eine Verbindung vom entsprechenden Geschäftsprozessverweis zu diesem Import her.
- Wenn dieser Service von einem Geschäftsprozess in einem anderen Modul aufgerufen wird, erstellen Sie einen Export mit SCA-Binding und ziehen und über geben Sie diesem Export vom anderen Modul zum Assembly-Editor dieses Moduls, um den entsprechenden Import mit SCA-Binding zu erstellen. Verbinden Sie den entsprechenden Geschäftsprozessverweis mit diesem Import.
- Speichern Sie das Assembly-Diagramm.
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:
- Erstellen Sie ein neues Geschäftsintegrations-Modulprojekt, um diesen neuen IMS-Service zu speichern.
- Rufen Sie zur Neuerstellung des EIS-Service die Optionen Datei -> Neu -> Sonstige -> Geschäftsintegration -> Externer Service auf.
- 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.
- 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.
- Ö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:
- Erstellen Sie die J2C Java-Bean durch Klicken auf Datei -> Neu -> J2C -> J2C-JavaBean
- Wählen Sie die 1.5 Version des IMS-Connector für Java und klicken Sie auf Weiter.
- Markieren Sie Verwaltete Verbindung und geben Sie den JNDI Lookup-Namen ein. Klicken Sie auf Weiter.
- 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.
- 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.
- 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.
- Wenn Sie die Erstellung von Java-Methoden abgeschlossen haben, klicken Sie auf Weiter.
- Schließen Sie die verbleibenden Schritte in diesem Assistenten ab, um Ihre J2C Java-Bean zu erstellen.
- 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.
- 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:
- Die erste Option verwendet die Standard-SCA-Komponenten zum Aufruf des IMS-Service.
- Die erste Option unterliegt den folgenden Einschränkungen:
- Die SDO Version 1 Spezifikations-API bietet keinen Zugang zur COBOL-
oder C-Bytefeldgruppe - dies betrifft Kunden, die mit IMS-Multisegmenten arbeiten.
- Die SDO Version 1 Spezifikation für serielle Verarbeitung unterstützt keine COBOL-Neudefinitionen oder C-Datentypvariablen.
- Die zweite Option verwendet die Standard-JSR 109-Methode für die Verbindung mit dem IMS-Service.
Diese Funktion ist verfügbar als Bestandteil von Rational Application Developer.
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:
- Durchsuchen Sie das Verzeichnis, in dem WebSphere Integration Developer installiert ist, und führen Sie eine Detailabfrage/-analyse unter Ressourcenadapter -> cics15 -> cicseci.rar durch.
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".
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:
- 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.
- Ö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.
- 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.
- 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:
- Kopieren Sie das Client-Proxy-Java-Projekt in den neuen Arbeitsbereich und importieren Sie es durch Klicken auf
Datei -> Importieren -> Vorhandenes Projekt in Arbeitsbereich.
- 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, 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).
- 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.
- 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.
- Eine generische Komponente wird im Assembly-Diagramm angezeigt. Markieren Sie sie und gehen Sie zur Sicht Eigenschaften.
- 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).
- 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.
- 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:
- Verschieben Sie die Logik von der ursprünglichen Java-Klasse in diese Klasse und passen Sie sie an die neue Datenstruktur an.
- Erstellen Sie eine private Instanz der alten Java-Klasse in dieser generierten Java-Klasse und schreiben Sie Code, um Folgendes zu tun:
- Konvertieren aller Parameter der generierten Java-Implementierungsklasse in Parameter, die die alte Java-Klasse erwartet
- Aufrufen der privaten Instanz der alten Java-Klasse mit den konvertierten Parametern
- 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:
- Wenn dieser Service durch einen Geschäftsprozess in demselben Modul aufgerufen wird, stellen Sie eine Verbindung vom entsprechenden Geschäftsprozessverweis zur Schnittstelle dieser Java-Komponente her.
- Wenn dieser Service von einem Geschäftsprozess in einem anderen Modul aufgerufen wird, erstellen Sie einen Export mit SCA-Binding und ziehen und über geben Sie diesem Export vom anderen Modul zum Assembly-Editor dieses Moduls, um den entsprechenden Import mit SCA-Binding zu erstellen. Verbinden Sie den entsprechenden Geschäftsprozessverweis mit diesem Import.
- Wenn dieser Service in WebSphere Studio Application Developer
Integration Edition veröffentlicht wurde, um ihn extern zugänglich zu machen, finden Sie Informationen zur Neuveröffentlichung dieses Service im Abschnitt "SCA-Exporte für den Zugriff auf den migrierten Service
erstellen".
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:
- EJB
- IBM Web
Service (SOAP/JMS)
- IBM Web
Service (SOAP/HTTP)
- Apache Web Service (SOAP/HTTP)
- JMS
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:
- Wählen Sie das Element Verbinden in der Symbolleiste.
- Klicken Sie auf die andere Komponente, um sie als Quelle der Verbindung auszuwählen.
- Klicken Sie auf die Komponente BPEL SCA, um sie als Ziel für die Verbindung auszuwählen.
- 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:
- Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
- 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:
- Klicken Sie mit der rechten Maustaste auf die BPEL-Komponente im Assembly-Editor.
- Wählen Sie Exportieren....
- Wählen Sie SCA-Binding.
- Wenn es mehrere Schnittstellen für den Prozess gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
- 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.
- 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:
- Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
- 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:
- Wählen Sie das Element Standalone References in der Symbolleiste aus.
- Klicken Sie auf den Erstellungsbereich des Assembly-Editors, um eine Standalone
References SCA-Entität zu erstellen.
- Wählen Sie das Element Verbinden in der Symbolleiste.
- Klicken Sie auf die Entität Standalone References, um sie als Quelle für die Verbindung auszuwählen.
- Klicken Sie auf die Komponente BPEL SCA, um sie als Ziel für die Verbindung auszuwählen.
- Es erscheint die Warnung Am Quellenknoten wird ein übereinstimmender Verweis erstellt. Möchten Sie fortfahren?. Klicken Sie auf OK.
- 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.
- 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.
- Wenn es mehrere Schnittstellen für den Prozess gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
- 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:
- Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
- 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:
- Klicken Sie mit der rechten Maustaste auf die BPEL-Komponente im Assembly-Editor.
- Wählen Sie Exportieren... .
- Wählen Sie Web-Service-Binding.
- Wenn es mehrere Schnittstellen für den Prozess gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
- Wählen Sie den Transport: soap/http oder soap/jms.
- 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.
- 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:
- JNDI Verbindungsfactory - Standard ist jms/BPECF
(dies ist der JNDI-Name der Verbindungsfactory-Warteschlange des Geschäftsprozesscontainers)
- JNDI-Zielwarteschlange - Standard ist jms/BPEIntQueue
(dies ist der JNDI-Name der internen Warteschlange des Geschäftsprozesscontainers)
- JNDI Provider URL: Vom Server bereitgestellt oder benutzerdefiniert -
Sie müssen eine Adresse eingeben. Standard ist iiop://localhost:2809
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:
- Wählen Sie das Element Verbinden in der Symbolleiste.
- Klicken Sie auf die andere Komponente, um sie als Quelle der Verbindung auszuwählen.
- Klicken Sie auf die Komponente BPEL SCA, um sie als Ziel für die Verbindung auszuwählen.
- 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:
- Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
- 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:
- Klicken Sie mit der rechten Maustaste auf die BPEL-Komponente im Assembly-Editor.
- Wählen Sie Exportieren....
- Wählen Sie SCA-Binding.
- Wenn es mehrere Schnittstellen für den Prozess gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
- 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.
- 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:
- Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
- 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:
- Wählen Sie das Element Standalone References in der Symbolleiste aus.
- Klicken Sie auf den Erstellungsbereich des Assembly-Editors, um eine Standalone
References SCA-Entität zu erstellen.
- Wählen Sie das Element Verbinden in der Symbolleiste.
- Klicken Sie auf die Entität Standalone References, um sie als Quelle für die Verbindung auszuwählen.
- Klicken Sie auf die Komponente BPEL SCA, um sie als Ziel für die Verbindung auszuwählen.
- Es erscheint die Warnung Am Quellenknoten wird ein übereinstimmender Verweis erstellt. Möchten Sie fortfahren?. Klicken Sie auf OK.
- 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.
- 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.
- Wenn es mehrere Schnittstellen für den Prozess gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
- 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:
- Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
- 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:
- Klicken Sie mit der rechten Maustaste auf die BPEL-Komponente im Assembly-Editor.
- Wählen Sie Exportieren... .
- Wählen Sie Web-Service-Binding.
- Wenn es mehrere Schnittstellen für den Prozess gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
- Wählen Sie den Transport: soap/http oder soap/jms.
- 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.
- 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:
- 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.
- Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
- 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.
- Wählen Sie Exportieren... .
- Wählen Sie JMS-Binding.
- Wenn es mehrere Schnittstellen für den Prozess gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
- Wählen Sie in der nächsten Anzeige (JMS-Exportbindingattribute) die Option JMS-Nachrichtendomäne. Definieren Sie dieses Attribut als Punkt-zu-Punkt.
- 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):
- Für Text, wählen Sie die Verwendung des JMS-Standardfunktionsselektors oder geben Sie den vollständig qualifizierten Namen der
FunctionSelector-Implementierungsklasse ein.
- Für Objekt, wählen Sie die Verwendung des JMS-Standardfunktionsselektors oder geben Sie den vollständig qualifizierten Namen der
FunctionSelector-Implementierungsklasse ein.
- 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.
- 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.
- 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.
- Wählen Sie das Inhaltsteilfenster 'Binding', um weitere Optionen anzuzeigen.
- 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:
- Für Dokumentstil war der Standard DOCUMENT / andere Option:
RPC
- Für Dokumentverwendung war der Standard LITERAL / andere Option: ENCODED
- Für JNDI Provider URL war es entweder Server angegeben oder Benutzerdefiniert (eine Adresse muss eingegeben werden, Standard ist iiop://localhost:2809)
- Für Zieladressstil war der Standard Warteschlange / andere Option war Thema
- Für JNDI-Verbindungsfactory war der Standard jms/qcf (dies ist der JNDI-Name der Warteschlangen-Verbindungsfactory für die generierte MDB-Warteschlange)
- Für JNDI-Zielwarteschlange war der Standard jms/Warteschlange (dies ist der JNDI-Name der generierten MDB-Warteschlange)
- Für MDB Listener-Port war der Standard <Serviceprojektname>MdbListenerPort.
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:
- Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
- 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:
- Klicken Sie mit der rechten Maustaste auf die SCA-Komponente im Assembly-Editor.
- Wählen Sie Exportieren....
- Wählen Sie Web-Service-Binding.
- Wenn es mehrere Schnittstellen für die Komponente gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
- Wählen Sie die Transport-soap/jms.
- 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.
- Speichern Sie das Assembly-Diagramm.
- 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.
- 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:
- 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.
- 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.
- 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.
- Gehen Sie zur Registerkarte 'Quelle'. Löschen Sie alle in dieser Datei definierten WSDL
PortTypes und Nachrichten.
- 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.
- 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.
- Speichern Sie die WSDL-Datei.
- Aktualisieren/erstellen Sie das Projekt neu. Wechseln Sie in die Geschäftsintegrationsperspektive. Öffnen Sie das Assembly-Diagramm des Moduls im Assembly-Editor.
- 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.
- 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.
- Speichern Sie alle Änderungen.
- 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"/>
- 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.
- 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:
- Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
- 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:
- Wählen Sie das Element Standalone References in der Symbolleiste aus.
- Klicken Sie auf den Erstellungsbereich des Assembly-Editors, um eine Standalone
References SCA-Entität zu erstellen.
- Wählen Sie das Element Verbinden in der Symbolleiste.
- Klicken Sie auf die Entität Standalone References, um sie als Quelle für die Verbindung auszuwählen.
- Klicken Sie auf die Komponente BPEL SCA, um sie als Ziel für die Verbindung auszuwählen.
- Es erscheint die Warnung Am Quellenknoten wird ein übereinstimmender Verweis erstellt. Möchten Sie fortfahren?. Klicken Sie auf OK.
- 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.
- 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.
- Wenn es mehrere Schnittstellen für den Prozess gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
- 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:
- Für Dokumentstil war der Standard RPC / andere Option: DOCUMENT
- Für Dokumentverwendung war der Standard ENCODED / andere Option: LITERAL
- Für Router-Adressen war der Standard http://localhost:9080
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:
- Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
- 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.
- Wählen Sie Exportieren....
- Wählen Sie Web-Service-Binding.
- Wenn es mehrere Schnittstellen für die Komponente gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
- Wählen Sie die Transport-soap/http.
- 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.
- Speichern Sie das Assembly-Diagramm.
- 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:
- 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.
- 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.
- 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.
- Gehen Sie zur Registerkarte 'Quelle'. Löschen Sie alle in dieser Datei definierten WSDL
PortTypes und Nachrichten.
- 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.
- 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.
- Speichern Sie die WSDL-Datei.
- Aktualisieren/erstellen Sie das Projekt neu. Wechseln Sie in die Geschäftsintegrationsperspektive. Öffnen Sie das Assembly-Diagramm des Moduls im Assembly-Editor.
- 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.
- 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.
- Speichern Sie alle Änderungen.
- 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"/>
- 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.
- 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:
- Öffnen Sie den Assembly-Editor für das vom Migrationsassistenten erstellte Modul.
- 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:
- Wählen Sie das Element Standalone References in der Symbolleiste aus.
- Klicken Sie auf den Erstellungsbereich des Assembly-Editors, um eine Standalone
References SCA-Entität zu erstellen.
- Wählen Sie das Element Verbinden in der Symbolleiste.
- Klicken Sie auf die Entität Standalone References, um sie als Quelle für die Verbindung auszuwählen.
- Klicken Sie auf die Komponente SCA, um sie als Ziel für die Verbindung auszuwählen.
- Es erscheint die Warnung Am Quellenknoten wird ein übereinstimmender Verweis erstellt. Möchten Sie fortfahren?. Klicken Sie auf OK.
- Wählen Sie die Entität Standalone References, die soeben erstellt wurde, und wählen Sie in der Sicht 'Eigenschaften' das Inhaltsteilfenster Beschreibung.
- 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.
- Wenn es mehrere Schnittstellen für den Prozess gibt, wählen Sie die zu exportierende Schnittstelle(n) mit diesem Bindingtyp aus.
- 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:
- Für die Dokumentdarstellung war dies RPC (keine sonstige Option verfügbar)
- Für SOAP Aktion war dies URN:WSDL PortType name
- Für Adresse war dies http://localhost:9080/Service Project NameWeb/servlet/rpcrouter
- Für 'Codierung verwenden' war der Standard Ja (Bei Ja wurde die Codierungsdarstellung auf: http://schemas.xmlsoap.org/soap/encoding/ eingestellt)
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)".
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
-
- WSIF- und WSDL-basiert
- Generierte Proxys für Services
- Beans und Formatsteuerroutinen für Typen
- Version 6.x - Programmiermodell (Java-zentrierter)
-
- SCA-Services basierend auf SDOs mit Doclet-Tags
- Schnittstellenbindings für Services
- 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.
- 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.
- 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.
- Wählen Sie das Verbindungstool, klicken Sie auf den Serviceverweis und daraufhin auf Importieren.
- Klicken Sie auf OK, wenn Sie gewarnt werden, dass ein übereinstimmender Verweis am Quellenknoten erstellt wird.
- 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?:
- 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.
- 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.
- 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.
- 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.
- Vergewissern Sie sich, dass WebSphere Process Server oder WebSphere Application Server installiert ist.
- 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).
- Wählen Sie für den Client-Proxytyp Java-Proxy und klicken Sie auf Weiter.
- Die Position der WSDL sollte angegeben sein. Klicken Sie auf Weiter.
- 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.
- 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.
- Vergewissern Sie sich, dass WebSphere Process Server oder WebSphere Application Server installiert ist.
- 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).
- Wählen Sie für den Client-Proxytyp Java-Proxy und klicken Sie auf Weiter.
- Die Position der WSDL sollte angegeben sein. Klicken Sie auf Weiter.
- 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.
- 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.
- Vergewissern Sie sich, dass WebSphere Process Server oder WebSphere Application Server installiert ist.
- 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).
- Wählen Sie für den Client-Proxytyp Java-Proxy und klicken Sie auf Weiter.
- Die Position der WSDL sollte angegeben sein. Klicken Sie auf Weiter.
- 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.
- 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:
- Nachrichten verfügen über nicht-primitive Abschnitte, um die Benutzerfreundlichkeit der Datenstruktur der Nachrichten zu verbessern.
- 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:
- Wählen Sie den Prozesserstellungsbereich oder eine Aktivität im Prozess.
- Wählen Sie in der Sicht 'Eigenschaften' die Registerkarte Client, um die Web-Client-Einstellungen zu überarbeiten.
- Migrieren Sie alle benutzerdefinierten JSPs manuell:
- Weitere Informationen zu Programmiermodelländerungen finden Sie im Abschnitt "Migration zum SCA-Programmiermodell".
- 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.
- 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:
- Rufen Sie die Optionen Datei -> Neu -> Andere -> Geschäftsintegration aus, und
wählen Sie Externer Service. Klicken Sie auf Weiter.
- Wählen Sie Adapter. Klicken Sie auf Weiter.
- 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.
- Ü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.
- Akzeptieren Sie die Konfigurationsparameter für das Geschäftsobjekt und klicken Sie auf OK.
- Wiederholen Sie diesen Vorgang für jedes Geschäftsobjekt.
- Klicken Sie auf Weiter.
- 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.
- 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:
- 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.
- Schließen Sie alle laufenden Instanzen von WebSphere Integration Developer im
6.x-Arbeitsbereich.
- 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"
- Beim Öffnen von WebSphere Integration Developer müssen Sie das EJB-Projekt aktualisieren, um die aktualisierten Dateien zu erhalten.
- 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"/>
- 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:
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
- WebSphere Studio
Application Developer Integration Edition konnte die Konsistenz zwischen den WSDLs und anderen Artefakten in Projekten nicht sicherstellen . WebSphere Integration Developer ist wesentlich genauer und meldet Inkonsistenzen, die von WebSphere Studio Application Developer
Integration Edition nicht angezeigt wurden (und die während der Laufzeit von WebSphere Business Integration Server
Foundation auch keine Probleme verursachten).
- Im Gegensatz zu WebSphere Studio Application Developer Integration Edition lässt
WebSphere Integration Developer die Verwendung mehrerer identischer Web-Service-Bindings und Servicedefinitionen (Name und Namensbereich)
nicht zu. Sie müssen diese Duplikate vor der Migration (in WebSphere Studio
Application Developer Integration Edition) bzw. nach der Migration (in WebSphere Integration
Developer) manuell auflösen. In WebSphere Studio Application Developer
Integration Edition sahen beispielweise alle generierten Servicedefinitionen in den WSDL-Dateien mit unterschiedlichen Namen (Endung _EJB, _JMS usw.) wie folgt aus:
<service name="OrderProcessIntfcService">
Fügen Sie zur Korrektur des Duplikats einfach den Bindingtyp an das Namensattribut an. Bei der Datei *_EJB.wsdl sieht die Änderung wie folgt aus:
<service name="OrderProcessIntfcServiceEJB">
Bei der Datei *_JMS.wsdl sieht die Änderung wie folgt aus:
<service name="OrderProcessIntfcServiceJMS">
Nach Änderung des Namens muss auch der Export, der für diesen Service in WebSphere Integration
Developer generiert wurde, hinsichtlich des richtigen Namens geändert werden.
- Dieser Migrationsassistent kann keine vollständigen Arbeitsbereiche von WebSphere Studio Application Developer
Integration Edition verarbeiten. Er ist dazu gedacht, ein WebSphere Studio
Application Developer Integration Edition-Serviceprojekt zur Zeit zu migrieren.
- Der Migrationsassistent migriert keine Anwendungs-Binaries - er migriert nur Quellenartefakte, die in einem WebSphere Studio Application Developer Integration
Edition-Serviceprojekt enthalten sind.
- Business Rule Beans werden in WebSphere Process Server 6.x nicht mehr unterstützt, es gibt während
der Installation von WebSphere Process Server jedoch eine Option, die Unterstützung für die nicht mehr unterstützten
Business Rule Beans zu installieren, damit diese auf einem Server von
WebSphere Process
Server 6.x "ohne Wartung (auf AS-IS-Basis)" ausgeführt werden können. Es gibt jedoch keine Toolunterstützung für die alten Business Rule Beans, und wenn die alten Business
Rule Bean-Artefakte in den Tools kompiliert werden sollen, müssen Sie den Anweisungen in der Dokumentation von WebSphere Integration Developer für die Installation dieser nicht mehr unterstützten Funktionen über den eingebetteten Testserver von WebSphere Process
Server 6.x folgen und die nicht mehr unterstützten JAR-Dateien zum Klassenpfad des Projekts als externe JARs hinzufügen. Sie sollten die neuen Geschäftsregeltools verwenden, die in WebSphere Integration
Developer zur Verfügung stehen, um ihre Geschäftsregeln gemäß der 6.x-Spezifikation neu zu erstellen.
- Die erweiterte Nachrichtenübertragung wird in WebSphere Process Server 6.x nicht mehr unterstützt, es gibt während
der Installation von WebSphere Process Server jedoch eine Option, die Unterstützung für die nicht mehr unterstützten
Funktionen der erweiterten Nachrichtenübertragung zu installieren, damit diese auf einem Server von
WebSphere Process
Server 6.x "ohne Wartung (auf AS-IS-Basis)" ausgeführt werden können. Es gibt jedoch keine Unterstützung für die alten Funktionen der erweiterten Nachrichtenübertragung, und wenn die alten Artefakte der erweiterten Nachrichtenübertragung in den Tools kompiliert werden sollen, müssen Sie den Anweisungen in der Dokumentation von WebSphere Integration
Developer für die Installation dieser nicht mehr unterstützten Funktionen über den eingebetteten Testserver von WebSphere Process
Server 6.x folgen und die nicht mehr unterstützten JAR-Dateien zum Klassenpfad des Projekts als externe JAR-Dateien hinzufügen.
- Das bereitgestellte JMS-Standarddatenbinding ermöglicht keinen Zugriff auf die angepassten JMS-Headereigenschaften. Damit die SCA-Services auf alle angepassten JMS-Headereigenschaften zugreifen können, muss ein angepasstes Datenbinding geschrieben werden.
Einschränkungen für das SCA-Programmiermodell
- Die SDO Version 1 Spezifikations-API bietet keinen Zugang zur COBOL-
oder C-Bytefeldgruppe - dies betrifft diejenigen, die mit IMS-Multisegmenten arbeiten.
- Die SDO Version 1 Spezifikation für serielle Verarbeitung unterstützt keine COBOL-Neudefinitionen oder C-Datentypvariablen.
- Beachten Sie bei der Überarbeitung Ihrer Quellenartefakte gemäß dem SCA-Programmiermodell, dass der WSDL-Stil für den Einschluss eines Dokuments/Literals (dies ist der Standardstil für neue mit WebSphere Integration Developer-Tools erstellte Artefakte) die Methodenüberlastung nicht unterstützt. Die anderen WSDL-Stile werden nach wie vor unterstützt, daher wird empfohlen, einen anderen WSDL-Stil/Verschlüsselung als Einschluss eines Dokuments/Literals für diese Fälle zu verwenden.
- Die native Unterstützung für Feldgruppen ist beschränkt. Um einen externen Service aufzurufen, der eine WSDL-Schnittstelle mit Feldgruppentypen 'soapenc:Array' zugänglich macht, müssen Sie eine WSDL-Schnittstelle erstellen, die ein Element definiert, dessen Attribut 'maxOccurs' größer als 1 ist (dies ist der empfohlene Vorgang für den Entwurf eines Feldgruppentyps).
Technische Einschränkungen für den BPEL-Migrationsprozess
- Mehrere Antworten pro BPEL Operation - In WebSphere Business
Integration Server Foundation konnte ein Geschäftsprozess über eine Empfangsaktivität und mehrere Antwortaktivitäten für dieselbe Operation verfügen. Wenn Sie über einen Geschäftsprozess mit mehreren Antworten für dieselbe Operation verfügen, stellen Sie im Falle von Client-Einstellungen sicher, dass alle Antworten für diese Operation über dieselben Client-Einstellungen verfügen, da in Version 6.x nur ein Satz mit Client-Einstellungen pro Operationsantwort unterstützt wird.
- Einschränkungen der BPEL Java Snippet-Migration - Das Programmiermodell hat sich von WebSphere Studio Application Developer
Integration Edition zu WebSphere Integration Developer erheblich geändert und nicht alle unterstützten WebSphere Studio
Application Developer Integration Edition APIs können direkt zu entsprechenden WebSphere Integration
Developer APIs migriert werden. Die Java-Logik kann in den BPEL Java Snippets gefunden werden, sodass das automatische Migrationstool möglicherweise nicht jedes Java Snippet in das neue Programmiermodell konvertieren kann. Die meisten der Standard Snippet API-Aufrufe werden automatisch von der Version 5.1 desJava Snippet-Programmiermodells zur Version 6.x des Java Snippet-Programmiermodells migriert. WSIF-API-Aufrufe werden wenn möglich zu DataObject API-Aufrufen migriert. Alle benutzerdefinierten Java-Klassen, die WSIFMessage-Objekte übernehmen, erfordern manuelle Migration, sodass sie stattdessen commonj.sdo.DataObject-Objekte übernehmen und zurückgeben:
- WSIFMessage-Metadaten-APIs - Für gewisse WSIFMessage-Metadaten und andere WSIF-APIs ist möglicherweise eine manuelle Migration erforderlich.
- EndpointReference/EndpointReferenceType APIs -
Diese Klassen werden nicht automatisch migriert. Manuelle Migration ist erforderlich, da die Partnerlink Getter/Setter-Methoden mit commonj.sdo.DataObject-Objekten statt mit dencom.ibm.websphere.srm.bpel.wsaddressing.EndpointReferenceType-Objekten aus 5.1 arbeiten.
- Komplexe Typen mit doppelten Namen - Wenn eine Anwendung komplexe Typen (in WSDLs oder XSDs) mit identischen Namensbereichen und lokalen Namen deklariert, oder unterschiedliche Namensbereiche mit identischen lokalen Namen, könnenJava Snippets, die diese Typen verwenden, nicht korrekt migriert werden. Überprüfen Sie die Snippets auf ihre Korrektheit, wenn der Migrationsassistent abgeschlossen ist.
- Komplexe Typen mit lokalen Namen, die mit den Java-Klassen im java.lang-Paket identisch sind - Wenn eine Anwendung komplexe Typen
(in WSDLs oder XSDs) mit lokalen Namen deklariert, die mit Klassen im java.lang-Paket von J2SE 1.4.2 übereinstimmen, können Java Snippets, die die entsprechende
java.lang-Klassen verwenden, nicht korrekt migriert werden. Überprüfen Sie die Snippets auf ihre Korrektheit, wenn der Migrationsassistent abgeschlossen ist.
- BPEL-Variablen mit Lesezugriff und mit Schreib-/Lesezugriff - In 5.1 konnte in jedem Java-Snippet-Code eine BPEL-Variable mit Lesezugriff definiert werden, was bedeutet, dass sich keine an diesem Objekt vorgenommenen Änderungen auf den Wert der BPEL-Variablen auswirken. Außerdem konnte eine BPEL-Variable mit Schreib-/Lesezugriff definiert werden. Dies bedeutet, dass alle am Objekt vorgenommenen Änderungen für die BPEL-Variable selbst wiedergegeben werden. Mit den folgenden vier Methoden könnte ein Lesezugriff auf ein Java-Snippet in einem beliebigen
5.1-BPEL-Java-Snippet erfolgen:
getMyInputVariable()
getMyInputVariable(false)
getVariableAsWSIFMessage("MyInputVariable")
getVariableAsWSIFMessage("MyInputVariable", false)
Mit den beiden folgenden Methoden könnte ein Schreib-/Lesezugriff auf eine BPEL-Variable in
einem beliebigen 5.1-BPEL-Java-Snippet erfolgen:
getMyInputVariable(true)
getVariableAsWSIFMessage("MyInputVariable", true)
In Version 6.x wird der Lesezugriff und der Schreib-/Lesezugriff auf BPEL-Variablen für jedes Snippet separat verwaltet. Dies bedeutet,
dass Sie einen besonderen Kommentar zum BPEL-Java-Snippet hinzufügen und auf diese Weise angeben können, ob Aktualisierungen der BPEL-Variablen nach Abschluss der Snippetausführung gelöscht werden oder erhalten bleiben sollen. Standardzugriffseinstellungen für die BPEL-Java-Snippettypen der Version 6.x:
BPEL-Java-Snippet-Aktivität
Standardzugriff: Schreib-/Lesezugriff
Standardzugriff überschreiben mit Kommentar:
@bpe.readOnlyVariables names="variableA,variableB"
BPEL-Java-Snippet-Ausdruck (wird in Zeitlimit, Bedingung usw. verwendet)
Standardzugriff: Lesezugriff
Standardzugriff überschreiben mit Kommentar:
@bpe.readWriteVariables names="variableA,variableB"
Während der Migration werden diese Kommentare automatisch erstellt, sobald der Zugriff auf eine Variable in einer Weise erfolgt, die in Version 6.x nicht als Standard definiert ist. Falls es zu einem Konflikt kommt (es also im gleichen Snippet einen Lesezugriff und einen Schreib-/Lesezugriff auf die BPEL-Variable gab), wird eine Warnung ausgegeben, und der Zugriff wird auf Schreib-/Lesezugriff gesetzt. Wenn Sie solche Warnungen empfangen, stellen Sie sicher, dass die Einstellung des Schreib-/Lesezugriffs für die BPEL-Variable in Ihrer Situation korrekt ist. Andernfalls müssen Sie die Einstellung
mit dem BPEL-Editor von WebSphere Integration Developer manuell korrigieren.
- Mehrwertige Eigenschaften in komplexen Typen - In 5.1 werden mehrwertige Eigenschaften durch Feldgruppen des Eigenschaftentyps dargestellt. Daher verwenden Aufrufe für den Abruf und die Einstellung der Eigenschaft Feldgruppen. In 6.x wird java.util.List
für diese Darstellung verwendet. Die automatische Migration verarbeitet alle Vorgänge, bei denen es sich bei der mehrwertigen Eigenschaft um einen beliebigen Typ eines Java-Objekts handelt, wenn es sich beim Eigenschaftentyp jedoch um Java-Basiselemente handelt (int, long, short, byte, char, float,
double und boolean), werden Aufrufe für den Abruf und die Einstellung der gesamten Feldgruppe nicht konvertiert. Die manuelle Migration macht in einem solchen Fall möglicherweise das Hinzufügen einer Schleife für den Einschluss / das Auspacken der Basiselemente in/aus ihrer entsprechenden Java Wrapper-Klasse (Integer, Long, Short,
Byte, Character, Float, Double und Boolean) für die Verwendung im verbleibenden Snippet erforderlich.
- Instanzerstellung von generierten Klassen, die komplexe Typen darstellen -
In 5.1 können in einer Anwendung definierte Klassen komplexer Typen leicht in einem Java-Snippet mit dem Standard No-Argument-Konstruktor instanziiert werden. Es folgt ein Beispiel hierfür:
MyProperty myProp = new MyProperty();
InputMessageMessage myMsg = new InputMessageMessage();
myMsg.setMyProperty(myProp);
In 6.x muss eine spezielle Factory-Class verwendet werden, um diese Typen zu instanziieren, oder es kann eine Instanz des übergeordneten Typs zur Erstellung des Subtyps verwendet werden.
Wenn eine BPEL-Prozessvariable InputVariable als Typ InputMessage definiert wurde,
würde die 6.x-Version des vorhergehenden Snippets folgendermaßen lauten:
com.ibm.websphere.bo.BOFactory boFactory=
(com.ibm.websphere.bo.BOFactory)
com.ibm.websphere.sca.ServiceManager.INSTANCE.locateService(
"com/ibm/websphere/bo/BOFactory");
commonj.sdo.DataObject myMsg =
boFactory.createByType(getVariableType("InputVariable"));
commonj.sdo.DataObject myProp =
myMsg.createDataObject("MyProperty");
Der Snippet Converter versucht, diese Änderung durchzuführen, wenn jedoch die Reihenfolge, in der die ursprünglichen Instanzerstellungen auftreten, nicht dem Hierarchiemuster (übergeordnet gefolgt von untergeordnet) folgt, ist eine manuelle Migration erforderlich (d.h. der Converter versucht nicht, die Instanzerstellungsanweisungen im Snippet intelligent neu anzuordnen).
- In WebSphere Business
Integration Server Foundation 5.1 wurden dynamische Verweise als WSDL-Nachrichtenteile des Typs EndpointReferenceType oder Elements EndpointReference aus dem folgenden Namensbereich dargestellt:
http://wsaddressing.bpel.srm.websphere.ibm.com
Solche Verweise werden zum Standard-Elementtyp service-ref aus dem Standardnamensbereich des Geschäftsprozesses migriert:
http://schemas.xmlsoap.org/ws/2004/03/business-process/
http://schemas.xmlsoap.org/ws/2004/08/addressing
Anweisungen für den manuellen Import dieser Schemadefinitionen in Ihr Projekt, so dass alle Verweise ordnungsgemäß aufgelöst werden können, finden Sie in der BPEL-Editor-Dokumentation.
- Nachrichtentyp für BPEL-Variable - Für alle BPEL-Variablen,
die in Java-Snippets verwendet werden, muss ein WSDL-Nachrichtentyp angegeben werden. Java-Snippets, die ohne angegebenes Attribut 'messageType' auf BPEL-Variablen zugreifen, können nicht migriert werden.
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.