WSIF - Bekannte Einschränkungen
Die bekannten Einschränkungen, die für die Verwendung von WSIF gelten, sind Einschränkungen des Threadings in SOAP-Headern und nicht referenzierten Anhängen und in Datentypzuordnungen.
- Threading
- WSIF ist nicht sicher für Threads.
- Externe Standards
- WSIF unterstützt Folgendes:
- SOAP Version 1.1 (nicht Version 1.2 oder eine höhere Version)
- WSDL Version 1.1 (nicht Version 1.2 oder eine höhere Version)
- Vollständiges Schema-Parsing
- WSIF bietet keine Unterstützung für vollständiges Schema-Parsing. Beispielsweise werden WSDL-Referenzen in komplexen Typen im Schema nicht unterstützt und Attribute werden ebenfalls nicht unterstützt.
- Die XML-Schemaelemente des Typs "redefine" werden ignoriert.
- SOAP
- WSIF bietet keine Unterstützung für Folgendes:
- SOAP-Header, die als <parts> übergeben werden.
- Nicht referenzierte Anhänge in SOAP-Antworten oder die im Artikel SOAP-Anhänge - Nicht unterstützte Szenarien beschriebenen Szenarien.
- SOAP-Nachrichten mit Document-Encoded-Darstellung. Anmerkung: Dies ist nicht primär eine Einschränkung von WSIF. Obwohl Sie die Document-Encoded-Darstellung in WSDL angeben können, gilt dies im allgemeinen nicht als gültige Option und wird von der Web Services Interoperability Organization (WS-I) nicht unterstützt.
- Interoperabilität zwischen SOAP-Providern
- Der aktuelle WSIF-SOAP-Standardprovider (der Provider IBM® Web Service SOAP) unterstützt keine vollständige Interaktion mit Services, die unter dem früheren Provider (Apache SOAP) ausgeführt werden. Diese Einschränkung ist darauf zurückzuführen, dass der Provider IBM Web Service SOAP für eine vollständige Interaktion mit JAX-RPC-kompatiblen Web-Services bestimmt ist und Apache SOAP nicht in der Lage ist, einen solchen Service bereitzustellen. Wie Sie diese Einschränkung umgehen können, können Sie im Artikel WSIF-SOAP-Provider: Mit vorhandenen Anwendungen arbeiten nachlesen.
- Die WSIF-Unterstützung für SOAP-Fehler (Faults) ist auf SOAP-Fehler beschränkt, die von Web-Services verursacht werden, die mit dem SOAP-Provider für IBM
Web-Services ausgeführt werden. Anmerkung: Dies ist nicht primär eine Einschränkung von WSIF. Die aktuelle Spezifikation für SOAP-Fehler schreibt nicht vor, wie ein SOAP-Fehler zu codieren ist, damit er einer Java-Ausnahme zugeordnet werden kann. Derzeit wählt die Laufzeitumgebung jedes Web-Service ihr eigenes Format der SOAP-Fehler. Der SOAP-Provider für IBM Web-Services kann seine eigenen SOAP-Fehler erkennen, nicht aber die von anderen Providern.
- Datentypzuordnung
- Der aktuelle WSIF-Standard-SOAP-Provider
(der IBM Web-Service-SOAP-Provider) befolgt die
JAX-RPC-Typenzuordnungsregeln, die fertiggestellt wurden,
nachdem der frühere Provider (Apache SOAP) erstellt wurde.
Die Mehrheit der Datentypen wird von beiden Providern auf dieselbe Art und Weise zugeordnet.
Ausnahmen sind xsd:date, xsd:dateTime, xsd:hexBinary und xsd:QName.
Falls einer dieser vier Datentypen verwendet wird, müssen
sowohl der Client als auch der Service dieselben Zuordnungsregeln anwenden.
Nachfolgend ist eine Tabelle mit Einzelheiten zu den Zuordnungsregeln für diese vier Datentypen
aufgeführt.
Tabelle 1. Zuordnungsregeln für die vier Datentypen, die von Apache SOAP und JAX-RPC direkt zugeordnet werden. Spalte 1 gibt den XML-Datentyp an, Spalte 2 den entsprechenden Datentyp für Apache SOAP und Spalte 3 den für JAX-RPC entsprechenden Datentyp.
XML-Datentyp Apache-SOAP-Java-Zuordnung JAX-RPC-Java-Zuordnung xsd:date java.util.Date Nicht unterstützt xsd:dateTime Nicht unterstützt java.util.Calendar xsd:hexBinary Hexadezimale Zeichenfolge byte [ ] xsd:QName org.apache.soap.util.xml.QName javax.xml.namespace.QName - Arrays und komplexe Typen
- WSIF unterstützt keine allgemeinen komplexen Typen,
sondern lediglich komplexe Typen, die Java-Beans zugeordnet sind.
Damit Sie komplexe Schematypen verwenden können, müssen Sie
eigene angepasste Serialisierungsmethoden schreiben.
Die spezielle Unterstützung der komplexen Typen und Arrays für abgehende WSIF-Aufrufe von Web-Services sieht wie folgt aus:
- WSIF unterstützt Java-Klassen, die von WSAD-IE-Nachrichtengeneratoren generiert wurden (der normale Fall, wenn WSDL-Dateien von einem anderen Ort heruntergeladen werden; WSAD-IE = WebSphere Studio Application Developer - Integration Edition). Die WSAD-IE-gestützte Generierung erfolgt automatisch, wenn Sie den BPEL-Editor verwenden oder die im Kontextmenü der Enterprise Services verfügbaren Generierungsaktionen oder die Business-Integration-Funktionsleiste.
- WSIF bietet keine Unterstützung für Java-Beans die von anderen Tools, einschließlich dem Basis-WSAD-Tool generiert wurden.
- Für Java-Beans, die von WSAD-IE generiert wurden, funktionieren die in WSDL definierten Attribute nicht. Dies bedeutet, dass diese Attribute zwar in den Java-Beans erscheinen, die zur Darstellung des komplexen Typs generiert wurden, in der von WSIF erstellten SOAP-Anforderung aber nicht erscheinen.
- WSIF unterstützt keine Arrays, wenn diese ein Feld einer Java-Bean sind, d. h., WSIF unterstützt lediglich einen Array, der als benannter <part> übergeben wird. Ist ein Array in eine Java-Bean gepackt, wird er nicht auf dieselbe Art und Weise wie die Java-Bean serialisiert.
- Objektserialisierung
- WSIF bietet keine Unterstützung für die Release-übergreifende Serialisierung von Objekten.
- Asynchroner Aufruf
- WSIF unterstützt synchronen Aufruf für alle Provider. Für JMS- und SOAP-JMS-Provider unterstützt WSIF auch asynchrone Aufrufe. Bevor Sie versuchen, eine asynchrone Operation auszuführen, sollten Sie die Methode supportsAsync() aufrufen.
- Der EJB-Provider
- Der Zielservice des WSIF-EJB-Providers kann kein EJB-Local-Home-Interface sein, sondern muss ein Remote-Home-Interface sein. Außerdem müssen die EJB-Stub-Klassen im Pfad der Clientklasse verfügbar sein.
- Ausführung außerhalb von WebSphere Application Server
- Die Verwendung von WSIF außerhalb von WebSphere Application Server wird nicht unterstützt.