Busfähige Web-Services: Bekannte Einschränkungen
Es gibt einige wenige bekannte Einschränkungen, die bei der Verwendung SIB-fähiger Web-Services zu beachten sind.
SOAP-Einschränkungen
Sicherheitseinschränkungen
Weitere Einschränkungen
SOAP-Header über den Service Integration Bus übergeben
- Die SOAP-Header sind nicht in der WSDL enthalten, die die Serviceintegrationstechnologien generieren.
- Wenn Sie das Flag "must understand" für die SOAP-Nachricht setzen, erhalten Sie eine Fehlernachricht.
Einschränkungen bei der Unterstützung von SOAP with Attachments
Der Service Integration Bus unterstützt SOAP-Nachrichten, die Anhänge im alten Stil (siehe SOAP with attachments W3C Note) oder Anhänge im Stil Web Services-Interoperability (WS-I) Attachments Profile Version 1.0 enthalten. Wenn Sie Anhänge von einem Stil in den anderen umsetzen müssen, können Sie hierfür eine Mediation verwenden.
Busfähige Web-Services können keine Web-Services in WebSphere Application Server aufrufen, wenn der Service eine Operation verwendet, die keine Anhänge in der Anforderungsnachricht enthält und einen Anhang in der Antwortnachricht zurückgibt.
- Verwendung von DIME
- Verwendung des WSDL-Tag mime:mimeXml
- Verschachtelung von mime:multipartRelated innerhalb von mime:part
- Verwendung von Arrays und Vektoren von DataHandler, Bildern usw.
Wenn Sie einen großen Anhang über den Service Integration Bus übergeben, erhalten Sie möglicherweise einen Fehler bezüglich mangelnder Speicherkapazität in der Java™ Virtual Machine. Wenn dieser Fehler auftritt, müssen Sie die Größe des Heapspeichers, wie im Artikel Busfähige Web-Services optimieren beschrieben, erhöhen.
Weitere Informationen hierzu finden Sie im Artikel SOAP-Nachrichten mit Anhängen über den Service Integration Bus übergeben.
Verfügbarkeit von Berechtigungsnachweistoken für JAAS-Subjekte in Services für abgehende Daten nicht garantiert
- Nicht serialisierbarer Inhalt.
- Alle Token, die com.ibm.wsspi.security.token.Token oder eine der untergeordneten Schnittstellen implementieren, und das Attribut forwardability nicht auf true setze.
Wenn beispielsweise ein angepasstes TokenConsumer in der WS-Security-Konfiguration und den Bindungen für einen Port für eingehende Daten konfiguriert ist, der TokenConsumer ein Token in den privaten Berechtigungsnachweisen des JAAS-Subjekts definiert und dieses Token com.ibm.wsspi.security.token.Token implementiert und das Attribut forwardability auf false setzt, sollte sich ein angepasster TokenGenerator, der in der WS-Security-Konfiguration und den Bindungen für den entsprechenden Port für abgehende Daten konfiguriert ist, nicht darauf verlassen, dass dieses Token im JAAS-Subjekt verfügbar ist.
Duldung nicht korrekt formatierter SOAP-Nachrichten
Busfähige Web-Services prüfen die Gültigkeit von Web-Service-Nachrichten gründlicher, als es in WebSphere Application Server Version 5.1 der Fall ist. Deshalb werden einige Clientanwendungen, die nicht korrekt formatierte Anforderungen oder Antworten verwenden (in denen die Nachrichtenabschnitte falsch benannt sind) und in Version 5.1 funktionieren, in höheren Versionen als nicht korrekt formatiert eingestuft.
- können nicht korrekt formatierte Nachrichten vom Bus akzeptiert werden,
- können nicht korrekt formatierte Nachrichten vom Bus erzeugt werden.
Einschränkungen in der Unterstützung früherer WS-Security-Spezifikationen
Die Versionen der WS-Security-Spezifikation, die von der allgemeinen Web-Service-Unterstützung in früheren Versionen von WebSphere Application Server unterstützt wurden, werden von den Serviceintegrationstechnologien nicht unterstützt. Die Serviceintegrationstechnologien unterstützen nur die "OASIS-Spezifikation Web Services Security Version 1.0 ", das "Profil Username Token Version 1.0" und das "Profil X.509 token Version 1.0". Nähere Informationen zu diesen unterstützten Spezifikationen und Profilen finden Sie im Artikel Unterstützte Funktionalität der OASIS-Spezifikationen.
Alle Clientanwendungen und Zielservices, die WS-Security für die Interaktion mit den Serviceintegrationstechnologien verwenden, müssen mit den unterstützten Versionen dieser Spezifikationen konform sein. Clientanwendungen und Zielservices, die den zuvor unterstützten Versionen der WS-Security-Spezifikation entsprechen, können nicht mit den Serviceintegrationstechnologien interagieren, weil das Übertragungsformat der SOAP-Nachricht mit WS-Security in der Spezifikation OASIS Web Services Security Version 1.0 anders und nicht mit den früheren Entwürfen der Spezifikation kompatibel ist.
Einschränkungen bezüglich der Java-Typen, die von Services verwendet werden, die von einer JAX-RPC-Clientanwendung umgeleitet werden
Wenn Sie Nachrichten an ein Ziel des Service Integration Bus übergeben, indem Sie Web-Service-Nachrichten direkt über den Bus von einem JAX-RPC-Client senden, sind gewisse Einschränkungen bezüglich der verwendbaren Java-Typen zu beachten.
Sie können nur solche Services umleiten, die die Typen, die in ihren Schnittstellen verwendet werden, auf die beschränken, für die in der JAX-RPC-Spezifikation Zuordnungen definiert sind. Dies beschränkt die Unterstützung auf einen Teil des möglichen XML-Schemas, das in einem WSDL-Dokument verwendet werden kann. Wenn die Schnittstelle beispielsweise passende Elemente für SOAPElement enthält, kann sie nicht über den Bus umgeleitet werden.
Abgehenden Service für die Verwendung eines WSDL-Ports konfigurieren
- Wenn Sie ein Objekt des Typs Address übergeben, müssen diese Klasse und die Klassen aller Objekte, die in einem Objekt Address serialisiert sind, im Klassenpfad von WebSphere Application Server enthalten sein.
- Wenn die Signatur einer Methode in der Enterprise-Bean ein Objekt java.util.List enthält und erwartet wird, dass die Liste eine Liste mit Address-Objekten ist, muss die Klasse Address im Klassenpfad von WebSphere Application Server enthalten sein.