IBM WebSphere Integration Developer

Migration

Version 6.0.2
SC12-3569-01
Hinweis

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

Vierte Ausgabe (Dezember 2006)

Diese Veröffentlichung ist eine Übersetzung des Handbuchs

IBM(R) WebSphere(R) Integration Developer Version 6.0.2 Migration Guide

IBM Form SC10-4211-01

herausgegeben von International Business Machines Corporation, USA

(C) Copyright International Business Machines Corporation 2006 (C) Copyright IBM Deutschland GmbH 2006

Informationen, die nur für bestimmte Länder Gültigkeit haben und für Deutschland, Österreich und die Schweiz nicht zutreffen, wurden in dieser Veröffentlichung im Originaltext übernommen.

Möglicherweise sind nicht alle in dieser Übersetzung aufgeführten Produkte in Deutschland angekündigt und verfügbar; vor Entscheidungen empfiehlt sich der Kontakt mit der zuständigen IBM Geschäftsstelle.

Änderung des Textes bleibt vorbehalten.

Herausgegeben von: SW NLS Center Kst. 2877 Dezember 2006

Copyright International Business Machines Corporation 2006. Alle Rechte vorbehalten.

Inhaltsverzeichnis

Kapitel 1. Migration von Anwendungen mithilfe von WebSphere Integration Developer
Migration zu WebSphere Integration Developer
Migration zu WebSphere Process Server von WebSphere InterChange Server
Migration zu WebSphere Integration Developer von WebSphere MQ Workflow
Migration von Quellenartefakten zu WebSphere Integration Developer von WebSphere Studio Application Developer Integration Edition
Bemerkungen

Kapitel 1. Migration von Anwendungen mithilfe von WebSphere Integration Developer

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

Die folgenden Themen beschreiben das Konzept, Verweise und schrittweise Anleitungen für die Migration zum WebSphere Integration Developer:

Migration zu WebSphere Integration Developer

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

Anmerkung:
WebSphere Integration Developer 6.0.2-Projekte können in WebSphere Integration Developer 6.0.1 nicht verwendet werden. Wenn Sie ein Upgrade auf WebSphere Integration Developer 6.0.2 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, die Code in ein Repository einchecken oder Projekte exportieren, die mit einem Benutzer von WebSphere Integration Developer 6.0.1 gemeinsam genutzt werden, steht ebenfalls keine Unterstützung zur Verfügung.

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

Migration zu WebSphere Process Server von WebSphere InterChange Server

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

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

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

Unterstützte Migrationspfade für WebSphere InterChange Server

WebSphere Process Server-Migrationstools unterstützen die Migration von WebSphere InterChange Server Versionen 4.2.2, 4.2.3 und 4.3.

Jedes WebSphere InterChange Server Release vor Version 4.2.2 muss vor der Migration zu WebSphere Process Server zunächst zu Version 4.2.2, 4.2.3 oder 4.3 migriert werden.

Vorbereitung für die Migration von WebSphere InterChange Server

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

Diese Migrationstools können folgendermaßen aufgerufen werden:

Die Eingabe für die Migrationstools besteht aus einer Repository-JAR-Datei, die aus

WebSphere

InterChange Server exportiert wurde. Daher müssen Sie vor dem Zugriff auf die Migrationstools mit einer dieser Optionen zunächst Folgendes ausführen:

  1. Stellen Sie sicher, dass Sie eine Version von WebSphere InterChange Server ausführen, die zum WebSphere Process Server migriert werden kann. Siehe das Thema "Unterstützte Migrationspfade für WebSphere InterChange Server".
  2. Exportieren Sie Ihre Quellenartefakte aus WebSphere InterChange Server in eine Repository-Jar-Datei mit dem WebSphere InterChange Server repos_copy-Befehl, wie in der Dokumentation für WebSphere InterChange Server beschrieben. Diese Jar-Datei wird den Migrationstools hinzugefügt.

Migration von WebSphere InterChange Server mithilfe des Migrationsassistenten

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

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

  1. Wählen Sie Datei -> Importieren -> WebSphere InterChange Server - JAR-Datei aus, um den Assistenten aufzurufen:
    Importauswahl für WebSphere InterChange Server-JAR-Datei
    Sie können den Migrationsassistenten auch auf der Willkommensseite öffnen, indem Sie auf das Symbol Benutzer von Vorversionen Benutzer von Vorversionen klicken, um die Seite 'Benutzer von Vorversionen' zu öffnen (Sie können jederzeit zur Willkommensseite zurückkehren, indem Sie auf Hilfe -> Willkommen klicken):
    Seite 'Benutzer von Vorversionen'
    Klicken Sie links auf der Seite 'Benutzer von Vorversionen' auf Migration, um die Seite 'Migration' zu öffnen:
    Seite 'Migration'
    Wählen Sie auf der Seite 'Migration' die Option Ein WebSphere ICS-Repository migrieren Seite 'Migration' mit ausgewählter Migrationsoption für ein WebSphere ICS-Repository aus.
  2. Der Migrationsassistent wird geöffnet. Geben Sie den Namen der Quellendatei im Feld Quellenauswahl durch Klicken auf die Schaltfläche Durchsuchen und Navigieren zur Datei ein. Geben Sie den Bibliotheksnamen in das entsprechende Feld ein. Klicken Sie auf Weiter.
    ICS-Migrationsassistent
  3. Das Migrationsoptionenfenster wird geöffnet. Hier können Sie die Migrationsstandardeinstellungen akzeptieren oder ein Markierungsfeld zum Ändern der Option auswählen.
    Migrationsoptionen
    Klicken Sie auf Fertig stellen.

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:

Migrationsergebnisfenster

Im Fenster mit den Migrationsergebnissen 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 mit "ToDo"-Tasks in der Tasksicht zu erstellen. Sie können auch Speichern als... auswählen, um die Nachrichten in einer Textdatei im Dateisystem zu speichern.

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 anfänglich mit WebSphere InterChange Server besser auskennen. Wenn Sie jedoch mehr Erfahrungen mit WebSphere Process Server und seinen neuen Artefakten sammeln, möchten Sie die migrierten Artefakte in WebSphere Integration Developer möglicherweise reparieren.
  1. Wenn die Art des Fehlers es erlaubt, können Sie die WebSphere InterChange Server-Artefakte mit dem WebSphere InterChange Server-Toolset anpassen, die jar-Datei erneut exportieren und die Migration erneut versuchen.
  2. Sie können alle Fehler in den resultierenden WebSphere Process Server-Artefakten durch Bearbeiten der Artefakte in WebSphere Integration Developer korrigieren.

Durch Migrationstools verarbeitete WebSphere InterChange Server-Artefakte

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

Die Migration ist bei den folgenden Artefakten möglich:

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

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

Unterstützte WebSphere InterChange Server-APIs

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

Anmerkung:
Diese APIs werden nur zur Unterstützung von migrierten WebSphere InterChange Server-Anwendungen bereitgestellt, bis diese für die Verwendung der neuen Process Server-APIs geändert werden können. Sämtliche angegebenen WebSphere InterChange Server-APIs sind veraltet und werden in einem künftigen Release entfernt.

Die unterstützten WebSphere InterChange Server-APIs in Process Server sind in Folgenden aufgelistet. Diese APIs bieten in Process Server ähnliche Funktionen wie in WebSphere InterChange Server. Funktionsbeschreibungen dieser APIs finden Sie in der Dokumentation von WebSphere InterChange Server.

CwBiDiEngine
AppSide_Connector/

JavaConnectorUtil
AppSide_Connector/

BusObj
Collaboration/

BusObjArray
Collaboration/

BaseDLM
DLM/

CwDBConnection
CwDBConnection/
CxCommon/

CwDBConstants
CwDBConnection/
CxCommon/

CwDBStoredProcedureParam
CwDBConnection/
CxCommon/

DataHandler (Abstract Class)
DataHandlers/
crossworlds/
com/

NameHandler (Abstract Class)
DataHandlers/
crossworlds/
com/

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

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

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

BusinessObjectInterface
CxCommon/

CxObjectAttr
CxCommon/

CxObjectContainerInterface
CxCommon/

DtpConnection
Dtp/
CxCommon/

DtpDataConversion
Dtp/
CxCommon/

DtpDate
Dtp/
CxCommon/

DtpMapService
Dtp/
CxCommon/

DtpSplitString
Dtp/
CxCommon/

DtpUtils
Dtp/
CxCommon/

BusObjInvalidVerbException (extends InterchangeExceptions)
Exceptions/
CxCommon/

IdentityRelationship
relationship/
utilities/
crossworlds/
com/

MapExeContext
Dtp/
CxCommon/

Participant
RelationshipServices/
Server/

Relationship
RelationshipServices/
Server/

UserStoredProcedureParam
Dtp/
CxCommon/

BaseCollaboration
Collaboration/

CxExecutionContext
CxCommon/

CollaborationException
Collaboration/

Filter
crossworlds/
com/

Globals
crossworlds/
com/

SmartCollabService
crossworlds/
com/

StateManagement
crossworlds/
com/

EventKeyAttrDef
EventManagement/
CxCommon/

EventQueryDef
EventManagement/
CxCommon/

FailedEventInfo
EventManagement/
CxCommon/

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

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

Allgemeine Informationen

Ladevorgänge

Beim Laden wird eine Laufzeit-XML von

WebSphere

InterChange Server in eine BusinessGraph AfterImage-Instanz von

WebSphere

Business Integration geladen.

Speichervorgänge

Beim Speichern wird eine BusinessGraph AfterImage-Instanz von

WebSphere

Business Integration in einer Laufzeit-XML von

WebSphere

InterChange Server gespeichert. Falls das eingegebene BusinessGraph kein AfterImage ist, wird eine Ausnahmebedingung ausgelöst.

Attributverarbeitung

Bewährte Verfahren für den WebSphere InterChange Server-Migrationsprozess

Die Richtlinien in diesem Thema sollen Ihnen bei der Entwicklung von Integrationsartefakten für WebSphere InterChange Server helfen. Wenn Sie anhand dieser Richtlinien vorgehen, können Sie die Migration von Artefakten aus WebSphere InterChange Server zu WebSphere Process Server vereinfachen. Diese Empfehlungen sind nur als Leitfaden für die Entwicklung neuer Integrationslösungen gedacht. Es versteht sich, dass vorhandener Inhalt diese Richtlinie möglicherweise nicht beachtet. Außerdem gibt es immer wieder Fälle, in denen eine Abweichung von diesen Richtlinien erforderlich ist. 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. Bitte beachten Sie, dass die hier dargestellten Richtlinien die bewährten Verfahren für die Entwicklung von WebSphere InterChange Server-Artefakten im Allgemeinen nicht enthalten. Sie beschränken sich vielmehr auf diejenigen Empfehlungen, die eine künftige Migration von Artefakten vereinfachen könnten.

Bewährte Verfahren: 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 bewährten Verfahren für die allgemeine Entwicklung von auf WebSphere InterChange Server basierenden Lösungen zusammen, die die künftige Migration vereinfachen:

Auch wenn dieser Hinweis möglicherweise überflüssig ist: Die Integrationslösungen müssen sich unbedingt an das Programmiermodell und die Architektur halten, die durch WebSphere InterChange Server bereitgestellt werden, denn diese sind für echtzeitorientierte, automatisierte Prozessintegrationslösungen optimal geeignet. Auch 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 bewährtes Verfahren, das den Erfolg künftiger Migrationsprojekte erheblich 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.

Bei der Entwicklung von Java-Code in den Collaboration-Schablonen, Zuordnungen, Dienstprogrammen für allgemeinen Code und anderen Komponenten müssen verschiedene Punkte berücksichtigt werden:

Verwenden Sie für die Artefakte nur die in der Produktdokumentation veröffentlichten APIs. Diese APIs sind in den Entwicklungshandbüchern zu WebSphere InterChange Server ausführlich beschrieben. In vielen Fällen werden zwar Kompatibilitäts-APIs in WebSphere Process Server bereitgestellt, aber nur die veröffentlichten APIs sind enthalten. Auch wenn WebSphere InterChange Server viele interne Schnittstellen enthält, deren Verwendung für einen Anwendungsentwickler wünschenswert wäre, kann die künftige Unterstützung dieser Schnittstellen nicht garantiert werden.

Achten Sie bei Analyse/Entwurf von Geschäftslogik und Konvertierungsregeln in Zuordnungen und Collaboration-Schablonen darauf, weitestgehend mit dem Aktivätseditor zu arbeiten. 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. Vermeiden Sie nach Möglichkeit über Felder entwickelte Dienstprogrammbibliotheken für allgemeinen Code, die als JAR-Datei (Java Archive) in den Klassenpfad von WebSphere InterChange Server aufgenommen werden, da diese manuell migriert werden müssen.

In jedem Java-Code-Snippet, dessen Entwicklung erforderlich ist, sollte der Code so einfach und 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 u. a. 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 generell ein bewährtes 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 beispielsweise die Vermeidung von statischen Variablen, des Startensvon Threads und der Platten-E/A. Diese Verfahren sind nicht nur generell ausgezeichnet geeignet, sondern insbesondere für die Portierbarkeit unabdingbar.

Bewährte Verfahren: Dienstprogramme für allgemeinen Code

Wie bereits erwähnt sollte die Entwicklung von Dienstprogrammbibliotheken für allgemeinen Code 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.

Bewährte Verfahren: Datenbankverbindungspools

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

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.

Bewährte Verfahren: Geschäftsobjekte

Primär ist bei der Entwicklung von Geschäftsobjekten wichtig, dass nur die bereitgestellten Tools für die Konfiguration von Artefakten verwendet werden, dass für Datenattribute explizite Datentypen und Längen eingesetzt werden und dass ausschließlich dokumentierte APIs zum Einsatz kommen.

Geschäftsobjekte in WebSphere Process Server basieren auf SDOs (Service Data Object - Servicedatenobjekt), die stark typisierte Datenattribute verwenden. 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 in der Spezifikation der Datentypen explizit sein.

Da Geschäftsobjekte in WebSphere Process Server möglicherweise in der Laufzeit serialisiert werden, wenn sie zwischen Komponenten übergeben werden, ist es von erheblicher Bedeutung, 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 - insbesondere bei gelöschten Einträgen - nicht garantieren.

Wie bereits an früherer Stelle erwähnt, ist es 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.

Bewährte Verfahren: Collaboration-Schablonen

Viele der zuvor beschriebenen Richtlinien gelten auch 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 expliziten Transaktionsangaben (d. h. explizite COMMIT-Operationen & 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. Wie bereits erläutert, sollten Operationen mit einem externen EIS-System 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.

Verwenden Sie in den Namen von Eigenschaften für Collaboration-Schablonen keine Sonderzeichen. Sonderzeichen sind in den BPEL-Eigenschaftennamen, in die sie migriert werden, ungültig. Benennen Sie vor der Migration Eigenschaften um, und entfernen Sie diese Sonderzeichen aus den Namen, 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 deklariert sind, mit einem Standardwert, z. B. '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.

Bewährte Verfahren: Zuordnungen

Viele der für Collaboration-Schablonen 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 ein untergeordnetes Geschäftsobjekt verweisen, verwenden Sie für das untergeordnete Geschäftsobjekt eine Unterzuordnung.

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

Wenn Sie in einem Geschäftsobjekt eine Feldgruppe verwenden, können 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 - insbesondere 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 expliziten Transaktionsangaben (d. h. explizite COMMIT-Operationen & 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 über die Grenzen von Transaktionsknoten hinweg in Java-Snippet-Code aktiv sind. Dies gilt für alle Verbindungen zu einem externen System und auch für die benutzerdefinierten Datenbankverbindungspools. Wie bereits erläutert, sollten Operationen mit einem externen EIS-System innerhalb eines Adapters verwaltet werden, und der Code für Datenbankoperationen sollte in einem einzigen Code-Snippet enthalten sein.

Bewährte Verfahren: 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.

Bei Beziehungen ist es am wichtigsten, nur die bereitgestellten Tools für die Konfiguration der zusammengehörigen Komponenten zu verwenden und ausschließlich die veröffentlichten APIs für Beziehungen in Integrationsartefakten einzusetzen.

Beziehungsdefinitionen sollten nur mit dem Tool 'Relationship Designer' bearbeitet werden. 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 Relationship Designer bereitgestellten Funktionen zu verwenden.

Wie bereits erwähnt, dürfen nur die veröffentlichten APIs für Beziehungen in Integrationsartefakten verwendet werden.

Bewährte Verfahren: 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.

Migration zu WebSphere Integration Developer von WebSphere MQ Workflow

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

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

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

Anmerkung:
Der Migrationsassistent beinhaltet nicht die Migration von:

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

Vorbereitung für die Migration von WebSphere MQ Workflow

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

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

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

In der folgenden Tabelle werden die angewendeten Zuordnungsregeln aufgelistet:

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

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

Migration von WebSphere MQ Workflow mithilfe 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 XMLSchema-Definitionen für Geschäftsobjekte, WSDL-Definitionen, BPEL, Import- und Komponentendefinitionen sowie TEL-Definitionen.

Anmerkung:
Der Migrationsassistent beinhaltet nicht die Migration von:

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

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

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.

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

Migrationsergebnisfenster
Im Fenster mit den Migrationsergebnissen 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 mit "ToDo"-Tasks in der Tasksicht zu erstellen. Sie können auch Speichern als... auswählen, um die Nachrichten in einer Textdatei im Dateisystem zu speichern.

Einschränkungen des Migrationsprozesses (von WebSphere MQ Workflow)

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

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 in den WebSphere-Basisanwendungsserver 6.0 verschoben worden. Tipps zur Migration dieser Funktionen finden Sie auf der folgenden Site: Tips for migrating programming model extensions (Tipps für die Migration von Programmiermodellerweiterungen).

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

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

Anmerkung:
Die Laufzeitmigration (Upgradepfad) wird in WebSphere Process Server 6.0.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.0.x.

Unterstützte Migrationspfade für die Migration von Quellenartefakten

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

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

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

Quellenartefakte für die Migration vorbereiten

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

In den folgenden Schritten wird beschrieben, wie Sie Ihre Umgebung vor der Migration von Quellenartefakten zu

WebSphere

Integration Developer von

WebSphere

Studio Application Developer Integration Edition vorbereiten:

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

Nun können Sie mit dem Migrationsprozess beginnen.

Serviceprojekte mit dem WebSphere Integration Developer-Migrationsassistenten migrieren

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

Anmerkung:

Der Migrationsassistent führt die folgenden Schritte aus:

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

Führen Sie die folgenden Schritte aus, um Serviceprojekte mit dem

WebSphere

Integration Developer-Migrationsassistenten zu migrieren:

  1. Rufen Sie den Assistenten durch Auswahl von Datei -> Importieren -> WebSphere Studio Application Developer Integration Edition-Serviceprojekt auf.
    Importauswahl für Quellenartefaktmigration
    Sie können den Migrationsassistenten auch auf der Willkommensseite öffnen, indem Sie auf das Symbol Benutzer von Vorversionen Benutzer von Vorversionen klicken, um die Seite 'Benutzer von Vorversionen' zu öffnen (Sie können jederzeit zur Willkommensseite zurückkehren, indem Sie auf Hilfe -> Willkommen klicken):
    Seite 'Benutzer von Vorversionen'
    Klicken Sie links auf der Seite 'Benutzer von Vorversionen' auf Migration, um die Seite 'Migration' zu öffnen:
    Seite 'Migration'
    Wählen Sie auf der Seite 'Migration' die Option Ein Integration Edition 5.1 Serviceprojekt migrieren Seite 'Migration' mit ausgewählter Migrationsoption für Serviceprojekt aus Integration Edition 5.1 aus.
  2. Der Migrationsassistent wird geöffnet. Geben Sie den Pfad für die Quellenauswahl ein oder klicken Sie auf die Schaltfläche Durchsuchen, um sie zu suchen. Geben Sie außerdem den Modulnamen für die Position des zu migrierenden Serviceprojekts von WebSphere Studio Application Developer Integration Edition ein:
    Migrationsassistent für Quellenartefakte
    Hinweis: Es wird empfohlen, dass Sie den Namen des Serviceprojekts als Modulnamen auswählen, denn wenn sich andere Projekte im WebSphere Studio Application Developer Integration Edition-Arbeitsbereich befinden, die von diesem Projekt abhängen, müssen Sie die Klassenpfade des untergeordneten Projekts nach deren Import in WebSphere Integration Developer nicht aktualisieren.
  3. Wählen Sie in den Migrationsoptionen 'Ursprüngliche BPEL Java-Snippets beibehalten' im Markierungsfeld für Kommentare aus:
    Migrationsoptionen
    Klicken Sie auf Fertig stellen.
  4. Wenn der Migrationsprozess abgeschlossen ist, wird das Fenster mit den Migrationsergebnissen geöffnet:
    Migrationsergebnisfenster
    Es wird automatisch eine diese Migrationsnachrichten enthaltende Protokolldatei im .metadata-Ordner des 6.0 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 doppelklicken Sie auf das BI-Modulprojekt. Hier können Sie Abhängigkeiten von Projekten für Geschäftsintegrationsbibliotheken,

Java

-Projekten und J2EE-Projekten hinzufügen.

Manuelle Migration der Anwendung

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

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

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 Projekte erfordern eine Neuvernetzung nach der Migration, um die Services wie in 5.1 neu zu verbinden. Beispielsweise müssen alle migrierten Geschäftsprozesse neu mit ihren Geschäftspartnern verbunden 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. Hinweis: Das Migrationsprogramm versucht eine automatische Ausführung; Sie können die Arbeitsschritte des Tools anhand der folgenden Informationen jedoch 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 abhing, kopieren Sie die vorhandenen Projekte in das neue Arbeitsbereichsverzeichnis und importieren Sie sie in den

WebSphere

Integration Developer mithilfe des Assistenten unter 'Datei' -> 'Importieren' -> 'Vorhandenes Projekt in Arbeitsbereich'.

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

Es gibt zahlreiche neue Komponenten in 6.0, 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:

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 benutzerdefinierte Java-Komponente erstellen: Option 1

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

Führen Sie die folgenden Schritte aus, um die benutzerdefinierte

Java

-Komponente zu erstellen:

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

Die folgenden Code-Beispiele zeigen:

  1. Relevante Definitionen aus der 5.1 WSDL-Schnittstelle
  2. Die WebSphere Studio Application Developer Integration Edition 5.1 Java-Methoden, die der WSDL entsprechen
  3. Die WebSphere Integration Developer 6.0 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.0

Java

-Methoden für die gleiche WSDL:

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

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

Sie müssen nun Code dort eingeben, wo die "//TODO"-Tags in der generierten

Java

-Implementierungsklasse angezeigt werden. Es gibt zwei Optionen:

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

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

Einen Java-Web-Service erstellen: Option 2

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

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

Wenn Sie eine Bottom-up-Methode in

WebSphere

Studio Application Developer Integration Edition verwendet haben, um WSDL um die

Java

-Klasse herum zu generieren, führen Sie die folgenden Schritte aus:

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

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

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

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

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

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 mithilfe des Assistenten unter 'Datei' -> 'Importieren' -> 'Vorhandenes Projekt 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:

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

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

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

Die benutzerdefinierte EJB-Komponente erstellen: Option 1

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

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

So erstellen Sie die benutzerdefinierte EJB-Komponente:

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

Die folgenden Code-Beispiele zeigen:

  1. Relevante Definitionen aus der 5.1 WSDL-Schnittstelle
  2. Die WebSphere Studio Application Developer Integration Edition 5.1 Java-Methoden, die der WSDL entsprechen
  3. Die WebSphere Integration Developer 6.0 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.0

Java

-Methoden für die gleiche WSDL:

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

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

Sie müssen nun echten Code dort eingeben, wo die "//TODO"-Tags in der generierten

Java

-Implementierungsklasse angezeigt werden. Zunächst müssen Sie einen Verweis von dieser

Java

-Komponente zur aktuellen EJB erstellen, so dass sie auf die EJB gemäß dem SCA-Programmiermodell zugreifen kann:

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

Sie müssen das SCA-Programmiermodell verwenden, um die EJB aus der generierten

Java

-Klasse aufzurufen. Öffnen Sie die generierte

Java

-Klasse und befolgen Sie diese Schritte, um den Code für den Aufruf des EJB-Service zu schreiben. Für die generierte

Java

-Implementierungsklasse:

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

Für jedes "//TODO" in der generierten

Java

-Implementierungsklasse:

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

		try {

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

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

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

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

	}
Einen EJB-Web-Service erstellen: Option 2

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

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

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

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

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

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

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

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

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

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 mithilfe eines WSIF-Prozessbindings aufgerufen wird. Dieser Abschnitt beschreibt die Migration von BPEL zu einem BPEL-Serviceaufruf mithilfe einer Verbindung oder eines Imports/Exports mit SCA-Binding.

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

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

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

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

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

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

Migration eines Web-Service (SOAP/HTTP)

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

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

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

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

Migration eines JMS-Service

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

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

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

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

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

Migration eines J2C-IMS-Service

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

Verwenden Sie keine der

WebSphere

Studio Application Developer Integration Edition-Artefakte, die für diesen

IMS

-Service generiert wurden. Sie müssen den Service mithilfe der 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.

Vor-und Nachteile jeder der Neuvernetzungsoptionen des J2C-IMS-Service

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

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

Erstellen Sie einen SCA-Import zum Aufrufen des IMS-Service: Option 1

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

Führen Sie die folgenden Schritte durch, um einen SCA-Import zum Aufrufen des

IMS

-Service zu erstellen:

  1. Erstellen Sie ein neues Geschäftsintegrations-Modulprojekt, um diesen neuen IMS-Service zu speichern.
  2. Klicken Sie zur Neuerstellung des EIS-Service auf 'Datei' -> 'Neu' -> 'Sonstige' -> 'Geschäftsintegration' -> 'Enterprise Service Discovery'.
  3. Mit diesem Assistenten können Sie einen Service aus einem EIS-System importieren. Er ähnelt dem WebSphere Studio Application Developer Integration Edition-Assistenten, der den WSIF-basierten EIS-Service in 5.1 erstellt hat. Sie können den neuen J2C IMS-Ressourcenadapter mit diesem Assistenten importieren. Durchsuchen Sie das Verzeichnis, in dem WebSphere Integration Developer installiert ist, und führen Sie eine Detailabfrage/-analyse unter Ressourcenadapter -> ims15 -> imsico9102.rar durch.
    Anmerkung:
    Weitere Informationen zum Abschluss der Eigenschaften für Speichern und Fenster für Operationen finden Sie im Information Center. Beim Enterprise Service Discovery-Assistenten sind Sie während des Hinzufügens einer Operation in der Lage, Geschäftsobjekte für den Eingabe- oder Ausgabedatentyp der Operation zu 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 mithilfe des separaten Assistenten unter 'Datei' -> 'Neu' -> 'Sonstige' -> 'Geschäftsintegration' -> 'Enterprise Data Discovery' importieren.
  4. Wenn Sie den Assistenten beendet haben, öffnen Sie die Geschäftsintegrationsperspektive und erweitern Sie das Modul, so dass Sie ihren Inhalt anzeigen können. In den Datentypen des Moduls sollten neue Geschäftsobjekte und in den Schnittstellen neue Schnittstellen aufgelistet sein.
  5. Öffnen Sie den Assembly-Editor durch Doppelklicken auf das erste Element unterhalb des Modulprojekts (es verfügt über denselben Namen wie das Projekt). Im Erstellungsbereich sollte ein Import vorhanden sein, der über EIS-Binding verfügt und den soeben von Ihnen erstellten Service darstellt.

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

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

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

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

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

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

IMS

-Service aufzurufen.

Migration eines J2C-CICS ECI-Service

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

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

IMS

RAR-Datei importiert wird:

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

Java

-Beans.

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

Migration eines J2C-CICS EPI-Service

Es gibt keine direkte Unterstützung für den J2C-CICS EPI-Service in WebSphere Integration Developer. Um auf diesen Service von einem SCA-Modul aus zuzugreifen, müssen Sie mithilfe 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 mithilfe des Auslastungsszenarios migrieren.

Anweisungen zur Migration dieses Servicetyps zu

WebSphere

Integration Developer finden Sie im Thema "Auslastungsszenario für Servicemigration".

Migration eines Umsetzungs-Serviceprojekts

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

Die Datenzuordnungs- und Schnittstellenzuordnungskomponenten sind neu in Version 6.0. Sie bieten ähnliche Funktionen wie der Umsetzungsservice in 5.1, verfügen jedoch nicht über die vollständige XSL-Umsetzungsfunktionalität. Wenn Sie Ihren Umsetzungsservice nicht mit einer dieser Komponenten ersetzen können, müssen Sie mithilfe des Auslastungsszenarios migrieren, da es keine direkte Unterstützung für den Umsetzungsservice in

WebSphere

Integration Developer gibt. Führen Sie die Schritte aus, die im Abschnitt "Auslastungsszenario für Servicemigration" dokumentiert sind, um auf diesen Service von einem SCA-Modul aus zuzugreifen.

Auslastungsszenario für Servicemigration

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

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

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

Nun können Sie zu WebSphere Integration Developer migrieren:

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

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

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

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

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

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

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

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

Migration von EJB und EJB-Prozessbindings

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

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

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

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

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

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

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

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

Tabelle 4. Weitere Informationen zur Migration von Clients
Clienttyp Weitere Informationen finden Sie in
EJB Client, der die generierte Session-Bean aufruft. Ein solcher Client ruft eine EJB-Methode auf, die der aufzurufenden BPEL-Operation entspricht "Migration des EJB Client"
WSIF Client, der das EJB Prozessbinding verwendet "Migration des EJB-Prozessbinding-Client"
Generischer Geschäftsprozess-Choreographer EJB API "Migration des generischen Geschäftsprozess-Choreographer EJB API Client"
Generische Geschäftsprozess-Choreographer-Nachrichtenübertragungs-API "Migration des generischen Geschäftsprozess-Choreographer Messaging API Client"
Ein weiterer BPEL-Prozess im gleichen Modul N/V: BPEL-Komponenten mithilfe des Assembly-Editor 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

Wenn der Geschäftsprozess einen Verweis an sich selbst außerhalb seines Moduls übergibt (über einen Serviceverweis), müssen Sie immer der untenstehenden Option 1 folgen (Sie können jederzeit mehr als eine dieser Optionen durchführen), um einen Export mit SCA-Binding für den Geschäftsprozess durchzuführen. Es kann nur ein Geschäftsprozess pro Modul seinen Serviceverweis außerhalb des Moduls übergeben, da sein Export als der Standardexport des Moduls markiert sein muss. Dies geschieht durch Angabe von "true" für das Attribut namens "Standard" eines Exports, wie in:

Standardendpunktverweis

Sie müssen den Export dieses Geschäftsprozesses manuell als Standard markieren, indem Sie mit der rechten Maustaste auf den Export in der Sicht 'Geschäftsintegration' klicken und Öffnen mit sowie Texteditor auswählen.

Migrationsoption 1 für EJB und EJP-Prozessbinding

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tabelle 5. Weitere Informationen für die Migration von Clients
Clienttyp Weitere Informationen finden Sie in
WSIF Client, der JMS-Prozess-Binding verwendet "Migration des generischen Geschäftsprozess-Choreographer Messaging API Client und des JMS-Prozessbinding-Client"
Generischer Geschäftsprozess-Choreographer EJB API "Migration des generischen Geschäftsprozess-Choreographer EJB API Client"
Migration des Unternehmens durch generische Geschäftsprozess-Choreographer-Nachrichtenübertragungs-API "Migration des generischen Geschäftsprozess-Choreographer Messaging API Client"
Ein weiterer BPEL-Prozess im gleichen Modul N/V: BPEL-Komponenten mithilfe des Assembly-Editor 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.

Wenn der Geschäftsprozess einen Verweis an sich selbst außerhalb seines Moduls übergibt (über einen Serviceverweis), müssen Sie immer der untenstehenden Option 1 folgen (Sie können jederzeit mehr als eine dieser Optionen durchführen), um einen Export mit SCA-Binding für den Geschäftsprozess durchzuführen. Es kann nur ein Geschäftsprozess pro Modul seinen Serviceverweis außerhalb des Moduls übergeben, da sein Export als der Standardexport des Moduls markiert sein muss. Dies geschieht durch Angabe von "true" für das Attribut namens "Standard" eines Exports, wie in:

Standardendpunktverweis

Sie müssen den Export dieses Geschäftsprozesses manuell als Standard markieren, indem Sie mit der rechten Maustaste auf den Export in der Sicht 'Geschäftsintegration' klicken und Öffnen mit sowie Texteditor auswählen.

Migrationsoption 1 für JMS und JMS-Prozessbinding

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Migration zum SCA-Programmiermodell

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

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

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

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

Migration von WSIFMessage API-Aufrufen zu SDO APIs

In dem folgenden Abschnitt wird die Migration vom alten WebSphere Business Integration Server Foundation Version 5.1 Programmiermodell, in dem der Datenfluss durch die Anwendung als WSIFMessage-Objekte mit einer generierten Schnittstelle, die getypt (strongly typed) 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 getypte 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 länger 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 einfachgetypten 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.

Getypte Getter-Methoden für WSIFMessage-Abschnitte und generierte Java-Beans sollten nicht verwendet werden. Ungetypte SDO APIs sollten für den Abruf von DataObject-Eigenschaften verwendet werden.
Getypte Setter-Methoden für Nachrichtenabschnitte von BPEL-Variablen sind nicht länger verfügbar. Ungetypte SDO APIs müssen für die Einrichtung der DataObject-Eigenschaften verwendet werden.
Ungetypte Getter-Methoden für WSIFMessage-Eigenschaften sollten nicht länger verwendet werden. Ungetypte SDO APIs müssen für die Einrichtung der DataObject-Eigenschaften verwendet werden.
Ungetypte Setter-Methoden für WSIFMessage-Eigenschaften sollten nicht länger verwendet werden. Ungetypte SDO APIs müssen für die Einrichtung der DataObject-Eigenschaften verwendet werden.
Alle WSIFMessage API-Aufrufe sollten wenn möglich zur SDO API migriert werden. Migrieren Sie den Aufruf wenn möglich zu einem äquivalenten SDO API-Aufruf. Überarbeiten Sie die Logik, wenn dies nicht möglich ist.
Migration des WebSphere Business Integration Server Foundation Client-Codes

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

Migration des EJB Client

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

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

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

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

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

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

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

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

Migration des EJB-Prozessbinding-Client

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

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

IBM

Web Service Client API verwenden, um den Service aufzurufen (der migrierte Geschäftsprozess muss über einen Export mit Web-Service-Binding verfügen).

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

Migration des IBM Web Service (SOAP/JMS) Client

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

Für vorhandene Clients ist während der Migration keine Migration erforderlich. Beachten Sie, dass Sie das generierte Webprojekt manuell ändern müssen (erstellen Sie eine neue servlet-Zuordnung) und manchmal das Kontextstammverzeichnis des Webprojekts im Implementierungsdeskriptor der Unternehmensanwendung, um den Service mit der gleichen Adresse zu veröffentlichen, unter der er in

WebSphere

Business Integration Server Foundation veröffentlicht war. Weitere Informationen enthält das Thema "Migration des

IBM

Web-Service-Binding (SOAP/JMS)".

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

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

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

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

Für vorhandene Clients ist während der Migration keine Migration erforderlich. Beachten Sie, dass Sie das generierte Webprojekt manuell ändern müssen (erstellen Sie eine neue servlet-Zuordnung) und manchmal das Kontextstammverzeichnis des Webprojekts im Implementierungsdeskriptor der Unternehmensanwendung, um den Service mit der gleichen Adresse zu veröffentlichen, unter der er in

WebSphere

Business Integration Server Foundation veröffentlicht war. Weitere Informationen enthält das Thema "Migration des

IBM

Web-Service-Binding (SOAP/HTTP)".

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

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

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

Migration des Apache Web Service (SOAP/HTTP) Client

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

Weitere Informationen enthält das Thema "Migration des

IBM

Web Service (SOAP/HTTP) Client".

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

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

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

Migration des JMS Client

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

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

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

Migration des generischen Geschäftsprozess-Choreographer EJB API Client

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

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

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

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

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

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

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

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

In WebSphere Process Server 6.0 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.0 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.0 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.0 dieser Anwendung finden Sie in der "Business Process Choreographer Explorer"-Dokumentation.

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

Diese JSPs sind insbesondere in folgenden Fällen hilfreich:

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

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

  1. Wählen Sie den Prozesserstellungsbereich oder eine Aktivität im Prozess.
  2. Wählen Sie in der Sicht 'Eigenschaften' die Registerkarte Client, um die Web-Client-Einstellungen zu überarbeiten.
  3. Migrieren Sie alle benutzerdefinierten JSPs manuell:
    1. Weitere Informationen zu Programmiermodelländerungen finden Sie im Abschnitt "Migration zum SCA-Programmiermodell".
    2. Der Web-Client verwendet die generischen APIs für die Interaktion mit Geschäftsprozessen. In diesen Abschnitten finden Sie Informationen zur Migration von Aufrufen zu diesen generischen APIs.
  4. Geben Sie den Namen der neuen JSP in den 6.0 Web-Client-Einstellungen für den Prozess an
Anmerkung:
Die Zuordnung von JSPs ist mit dem 6.0 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.0 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 länger 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.0-Snippets verwendet werden können, besteht weniger Bedarf an lokalen Variablen als in 5.1.

Die getypten (strongly-typed) 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.0 Java-Snippetcode 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 länger 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.
Getypte Getter-Methoden für BPEL-Variablen sind nicht länger 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).
Getypte Setter-Methoden für BPEL-Variablen sind nicht länger 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).
Ungetypte Getter-Methoden für BPEL-Variablen, die eine WSIFMessage zurückgeben, sind nicht länger 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.

Ungetypte Setter-Methoden für BPEL-Variablen sind nicht länger 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).
Ungetypte 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 ungetypten 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.0 geboten:

getVariableProperty(String variableName, QName propertyName);  		

In 6.0 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.0 Snippet verwendet und kann jederzeit aktualisiert werden.

Ungetypte 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 ungetypten 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.0 geboten:

setVariableProperty(String variableName, QName propertyName,
Serializable value);
Getypte Getter-Methoden für BPEL-Partnerverbindungen sind nicht länger verfügbar. Migrieren Sie zu den ungetypten Getter-Methoden für BPEL-Partnerverbindungen.
Getypte Setter-Methoden für BPEL-Partnerverbindungen sind nicht länger verfügbar. Migrieren Sie zu den ungetypten Setter-Methoden für BPEL-Partnerverbindungen.
Getypte Getter-Methoden für BPEL-Korrelationsgruppen sind nicht länger verfügbar.
V5.1-Snippet:
String corrSetPropStr = 
getCorrelationSetCorrSetAPropertyCustomerName();
int corrSetPropInt = 
getCorrelationSetCorrSetBPropertyCustomerId();
V6.0-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 ungetypten Getter-Methoden für benutzerdefinierte BPEL-Aktivitätseigenschaften.
V5.1-Snippet:
String val = getActivityCustomProperty("propName");
V6.0-Snippet:
String val = getActivityCustomProperty
("name-of-current-activity", "propName");
Zusätzlicher benötigter Parameter für die ungetypten Setter-Methoden für benutzerdefinierte BPEL-Aktivitätseigenschaften.
V5.1-Snippet:
String newVal = "new value";
setActivityCustomProperty("propName", newVal); 
V6.0-Snippet:
String newVal = "new value";
setActivityCustomProperty("name-of-current-activity", 
"propName", newVal);
Die Methode raiseFault(QName faultQName, Serializable message) ist nicht länger 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 Enterprise Service Discovery 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 die Tools von Enterprise Service Discovery aufzurufen:

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

Dieses Tool migriert die alten XSDs in das Format, das von dem speziellen Datenbinding erwartet wird, entfernen Sie daher die alten XSDs für den Adapter von

WebSphere

Business Integration aus dem Modul und verwenden Sie die neuen XSDs. Wenn das Modul keine Nachrichten vom Adapter empfängt, löschen Sie die mit diesem Tool generierten Exporte. Wenn das Modul keine Nachrichten an den Adapter sendet, löschen Sie den Import. Weitere Informationen zu dieser Funktion finden Sie im Information Center.

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

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

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

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

WSDL-Beispielcode:

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

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

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

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

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

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

Beispielcode für einen Client dieses Web-Service:

  // Locate the vendor service and find the doFindVendor operation 

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

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

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

WSDL-Beispielcode:

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

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

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

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

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

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

</schema>

Beispielcode für einen Client dieses Web-Service:

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

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

Migration des WebSphere Business Integration EJB-Projekts

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

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

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

In WebSphere Studio Application Developer Integration Edition 5.1 wurde die Definition von zwei unterschiedlichen XSD- oder WSDL-Typen mit dem gleichen Namen und demselben Zielnamensbereich unterstützt. In WebSphere Integration Developer 6.0 wird dies nicht unterstützt. Falls Sie nach der Erstellung der migrierten Projekte Fehler aufgrund von doppelt vorhandenen Definitionen feststellen, ist eine manuelle Migration erforderlich.

Führen Sie die folgenden Schritte aus, um dieses Problem lösen:

  1. Falls die Definitionen identisch sind, löschen Sie eine der Definitionen. Anschließend müssen Sie das Projekt bereinigen und erneut erstellen. Korrigieren Sie alle hierdurch möglicherweise verursachten Fehler, indem Sie in vorhandenen XSDL-/XSD-Dateien auf die Datei mit der Definition verweisen, die Sie nicht gelöscht haben.
  2. Falls die Definitionen nicht identisch sind und Sie beide Definitionen im migrierten Service verwenden müssen, benennen Sie den Definitionsnamen oder den Zielnamensbereich um. Falls lediglich wenige Definitionen in der gesamten Datei doppelt vorhanden sind, empfiehlt es sich, ihre Namen zu ändern. Sind alle Definitionen in der Datei doppelt vorhanden, wird die Änderung des Zielnamensbereichs für alle Definitionen empfohlen. Bereinigen Sie das Projekt, und erstellen Sie es erneut. Achten Sie hierbei darauf, dass die Artefakte, die Sie in den geänderten Definitionen verwenden wollen, auf den neuen Definitionsnamen oder Namensbereich verweisen.
  3. Falls zwei Importanweisungen für denselben Namensbereich in einer WSDL-Datei vorhanden sind, können Sie dieses Problem lösen, indem Sie die Importe so verketten, dass eine der WSDL-Dateien die andere Datei importiert, die wiederum die nächste Datei importiert usw. Auf diese Weise findet nur ein Import für diesen Namensbereich pro WSDL-Datei statt. Anschließend müssen Sie das Projekt bereinigen und erneut erstellen.
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.0 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.

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

Migrationsergebnisfenster

Im Fenster mit den Migrationsergebnissen 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 mit "ToDo"-Tasks in der Tasksicht 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.

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 mithilfe 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.

Bewährte Verfahren: Quellenartefakt-Migrationsprozess

Es gibt eine Reihe von bewährten Verfahren 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:

Einschränkungen des Migrationsprozesses (für Quellenartefaktmigration)

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

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

Allgemeine Einschränkungen

Einschränkungen für das SCA-Programmiermodell

Technische Einschränkungen für den BPEL-Migrationsprozess

Bemerkungen

Die vorliegenden Informationen wurden für Produkte und Services entwickelt, die auf dem deutschen Markt angeboten werden. Möglicherweise bietet IBM die in dieser Dokumentation beschriebenen Produkte, Services oder Funktionen in anderen Ländern nicht an. Informationen über die gegenwärtig im jeweiligen Land verfügbaren Produkte und Services sind beim IBM Ansprechpartner erhältlich. Hinweise auf IBM 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 anderen 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 dieser Veröffentlichung 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 sowie der Allgemeinen Geschäftsbedingungen der 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 IBM Musterprogrammen abgeleitet. (C) Copyright IBM Corp. 2000, 2006. 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 mithilfe 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

Siehe http://www.ibm.com/legal/copytrade.shtml.