Die folgenden Verfahren illustrieren das Design von WebSphere Studio Application Developer
Integration Edition Services, um deren erfolgreiche Migration zum neuen Programmiermodell sicherzustellen:
- Versuchen Sie, die Assign-Aktivität so häufig wie möglich zu verwenden
(im Gegensatz zum Umsetzungsservice, der nur benötigt wird, wenn eine erweiterte Umsetzung erforderlich ist. Sie sollten dieses Verfahren verwenden, da temporäre Komponenten erstellt werden müssen, so dass das SCA-Modul einen Umsetzungsservice aufrufen kann. Zusätzlich gibt es keine spezielle Toolunterstützung in WebSphere Integration
Developer für die Umsetzungsservices, die in 5.1 erstellt wurden (Sie müssen den WSDL- oder XML-Editor zur Bearbeitung der in der WSDL-Datei eingebetteten XSLT, wenn Sie das Verhalten des Umsetzungsservices ändern müssen).
- Geben Sie einen Teil pro WSDL-Nachricht an, gemäß der Web-Services Interoperabilitäts-
(WS-I)-Spezifikation und dem 6.0 bevorzugten Stil.
- Verwenden Sie den WSDL doc-literal-Stil, da dies der bevorzuge Stil in 6.0 ist.
- Stellen Sie sicher, dass alle komplexen Typen mit einem Namen versehen wurden und dass jeder komplexe Typ anhand seines Zielnamensbereichs und Namens eindeutig erkannt werden kann. Der folgende Code zeigt das empfohlene Verfahren für die Definition von komplexen Typen und von Elementen dieses Typs (Definition des komplexen Typs gefolgt von einer Elementdefinition, die den Typ verwendet):
<schema attributeFormDefault="qualified"
elementFormDefault="unqualified"
targetNamespace="http://util.claimshandling.bpe.samples.websphere.ibm.com"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://util.claimshandling.bpe.samples.websphere.ibm.com">
<complexType name="Duration">
<all>
<element name="hours" type="int"/>
<element name="minutes" type="int"/>
<element name="days" type="int"/>
</all>
</complexType>
<element name="DurationElement" type="tns:Duration"/>
</schema>
Das folgende Beispiel ist ein anonymer komplexer Typ, der vermieden werden sollte, weil er bei der Serialisierung eines SDO in XML Probleme verursachen kann (ein Element enthält eine Definition für einen anonymen komplexen Typ):<schema attributeFormDefault="qualified"
elementFormDefault="unqualified"
targetNamespace="http://util.claimshandling.bpe.samples.websphere.ibm.com"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://util.claimshandling.bpe.samples.websphere.ibm.com">
<element name="DurationElement">
<complexType>
<all>
<element name="hours" type="int"/>
<element name="minutes" type="int"/>
<element name="days" type="int"/>
</all>
</complexType>
</element>
</schema>
- Wenn Sie einen Service für externe Kunden veröffentlichen, generieren Sie Service-Implementierungscode mithilfe von IBM Web-Services (anstelle von Apache SOAP/HTTP), da IBM Web-Services
in 6.0 direkt unterstützt werden, Apache Web-Services jedoch nicht.
- Es gibt zwei Arten, auf die Sie WSDL- und XSD-Dateien in 5.1 organisieren können, um den von Ihnen durchzuführenden Reorganisationsaufwand während der Migration zu reduzieren. In 6.0 müssen gemeinsam genutzte Artefakte wie WSDL- und XSD-Dateien in BI-Projekten (Geschäftsintegrations- Module und Bibliotheken) abgelegt sein, damit auf sie von einem BI-Service verwiesen werden kann:
- Speichern Sie alle WSDL-Dateien, die vom mehr als einem Serviceprojekt gemeinsam genutzt werden, in einem Java-Projekt, auf das die Serviceprojekte verweisen können. Während der Migration zu 6.0 erstellen Sie eine neue Geschäftsintegrationsbibliothek mit demselben Namen wie für das gemeinsam verwendete Java-Projekt 5.1.
Kopieren Sie alle Artefakte aus dem gemeinsam genutzten Java-Projekt 5.1. zur Bibliothek, so dass der Migrationsassistent die Artefakte auflösen kann, wenn die Serviceprojekte, die diese Artefakte verwenden, migriert werden.
- Speichern Sie eine lokale Kopie aller WSDL/XSD-Dateien, auf die ein Serviceprojekt verweist, im Serviceprojekt selbst. WebSphere Studio Application Developer
Integration Edition-Serviceprojekte werden in ein Geschäftsintegrationsmodul in WebSphere Integration
Developer migriert und ein Modul kann keine Abhängigkeiten von anderen Modulen haben (ein Serviceprojekt mit Abhängigkeiten von anderen Serviceprojekten für die gemeinsame Nutzung von WSDL- oder XSD-Dateien kann nicht problemlos migriert werden).
- Vermeiden Sie die Verwendung der generischen Nachrichtenübertragungs-API (generische MDBs) des Geschäftsprozess-Choreographer, da diese in 6.0 nicht enthalten ist. Eine MDB-Schnittstelle, die ein spätes Binding bietet, steht in 6.0 nicht zur Verfügung.
- Verwenden Sie die EJB-API des generischen Geschäftsprozess-Choreographers, statt die generierten Session-Beans aufzurufen, die für eine bestimmte Version eines Prozesses spezifisch sind. Diese Session-Beans werden in V6.0.0.0 nicht generiert.
- Wenn Sie über einen Geschäftsprozess mit mehreren Antworten für dieselbe Operation verfügen, stellen Sie im Falle von Client-Einstellungen sicher, dass alle Antworten für diese Operation über dieselben Client-Einstellungen verfügen, da in 6.0 nur ein Satz mit Client-Einstellungen pro Operationsantwort unterstützt wird.
- Entwerfen Sie BPEL Java-Snippets gemäß den folgenden Richtlinien:
- Vermeiden Sie das Senden von WSIFMessage-Parametern zu benutzerdefinierten Java-Klassen
- versuchen Sie, wenn möglich nicht vom WSIFMessage-Datenformat abzuhängen.
- Vermeiden Sie wenn möglich die Verwendung von WSIF-Metadaten-APIs.
- Vermeiden Sie die Deklaration von lokalen Variablen in BPEL Java-Snippets, die denselben Namen wie die BPEL-Variablen haben. In 6.0 sind BPEL-Variablen direkt über die Snippets zugänglich, sodass lokale Variablen mit demselben Namen einen Konflikt verursachen können.
- Vermeiden Sie wenn möglich die Erstellung von Top-down EJBs oder Java-Services, da das Java/EJB-Gerüst, das aus den WSDL-Porttypen/Nachrichten generiert wird, von WSIF-Klassen abhängt (z. B. WSIFFormatPartImpl). Erstellen Sie stattdessen die Java/EJB-Schnittstellen zuerst und generieren Sie einen Service um die Java-Klasse/EJB herum
(Bottom-up-Methode).
- Vermeiden Sie die Erstellung oder Verwendung von WSDL-Schnittstellen, die auf den Typ soapenc:Array verweisen, da dieser Schnittstellentyp nicht naturgemäß im SCA-Programmiermodell unterstützt wird
- Vermeiden Sie die Erstellung von Nachrichtentypen, bei deren problemorientierten Nachrichtentypen es sich um einen Feldgruppentyp handelt
(maxOccurs-Attribut ist größer als eins), da dieser Schnittstellentyp nicht naturgemäß im SCA-Programmiermodell unterstützt wird.
- Definieren Sie Ihre WSDL-Schnittstellen genau - vermeiden Sie wenn möglich XSD complexTypes, die auf den Typ xsd:anyType verweisen.
- Achten Sie bei jeder WSDL- und XSD-Definition, die Sie aus einer EJB- oder Java-Bean generieren, darauf,
dass der Zielnamensbereich eindeutig ist (der Java-Klassenname und -Paketname werden durch den Zielnamensbereich dargestellt),
um bei der Migration auf WebSphere Process
Server V6 Kollisionen zu verhindern. In WebSphere Process
Server V6 sind zwei unterschiedliche WSDL/XSD-Definitionen mit einem identischen Namen und Zielnamensbereich nicht zulässig. Diese Situation tritt häufig auf, wenn der Web-Service-Assistent oder der Befehl
'Java2WSDL' ohne explizite Angabe des Zielnamensbereichs verwendet wird (der Zielnamensbereich ist zwar
für den Paketnamen der EJB-
oder Java-Bean eindeutig, nicht jedoch für die Klasse selbst, so dass bei der Generierung
eines Web-Services für zwei oder mehr EJB- oder Java-Beans im gleichen Paket Probleme auftreten). Die Lösung besteht darin, im Web-Service-Assistenten eine angepasste Zuordnung von Paket und Namensbereich anzugeben oder
die Befehlszeilenoption '-namespace' für den Befehl 'Java2WSDL' zu verwenden, um sicherzustellen, dass der Namensbereich der generierten Dateien für die jeweilige Klasse eindeutig ist.
- Verwenden Sie nach Möglichkeit für jede WSDL-Datei eindeutige Namensbereiche. In der WSDL 1.1-Spezifikation gibt es Einschränkungen hinsichtlich des Imports von zwei unterschiedlichen WSDL-Dateien mit demselben Namensbereich. Diese Einschränkungen werden in WebSphere Integration Developer 6.0
genauestens umgesetzt.