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.

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:
  • Verwendung von WebSphere InterChange Server für echtzeitorientierte, automatisierte Prozessintegrationslösungen
  • Dokumentierung des System- und Komponentenentwurfs
  • Bearbeitung von Integrationsartefakten mit den Entwicklungstools
  • Definition von Regeln mit den Tools und Java-Snippets gemäß den bewährten Verfahren

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 ggfs. 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 nur die veröffentlichten APIs.
  • Verwenden Sie den Aktivitätseditor.
  • Verwenden Sie Adapter für den EIS-Zugriff.
  • Vermeiden Sie externe Abhängigkeiten im Java-Snippet-Code.
  • Halten Sie sich an die J2EE-Entwicklungsverfahren für die Portierbarkeit.
  • Starten Sie keine Threads, und verwenden Sie keine Basiselemente der Thread-Synchronisation. Für den Fall, dass der Einsatz dieser Elemente zwingend erforderlich ist, müssen sie bei der Migration konvertiert werden, damit sie asynchrone Beans verwenden.
  • Führen Sie keine Platten-E/A unter Verwendung von 'java.io.*' aus. Speichern Sie Daten mit JDBC.
  • Führen Sie keine Funktionen aus, die möglicherweise für einen EJB-Container reserviert sind, wie beispielsweise Socket-E/A, Laden von Klassen, Laden von nativen Bibliotheken usw. Sind solche Aktionen zwingend erforderlich, müssen diese Snippets bei der Migration manuell konvertiert werden, damit EJB-Containerfunktionen verwendet werden.

Verwenden Sie für die Artefakte nur die in der 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 Startens von Threads und der Platten-E/A. Diese Verfahren sind nicht nur generell ausgezeichnet geeignet, sondern insbesondere für die Portierbarkeit unabdingbar.

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 ist jedoch der Benutzer zuständig.

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

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.

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 mithilfe von "this." auf Variablen. Verwenden Sie an Stelle von "this.inputBusObj" einfach "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.

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 einer Anweisung SET, da dies in WebSphere Process Server nicht gültig ist. Verwenden Sie stattdessen Konstanten. Wenn 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.

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.

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.
Zugehörige Tasks
Überprüfung der WebSphere InterChange Server Migration
Migrationsfehler von WebSphere InterChange Server beheben

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