This topic lists the main known restrictions that apply when using the Web services enablement of the service integration bus.
The service integration bus supports SOAP messages that contain either old-style attachments (as described in the SOAP with attachments W3C Note) or attachments that use the Web Services-Interoperability (WS-I) Attachments Profile Version 1.0. If you need to transform attachments from one style to another, you can use a mediation to map between attachment encoding styles. However, if a message containing a WS-I Attachments Profile Version 1.0 compliant attachment is routed to a mediation or outbound protocol attachment in a WebSphere® Application Server Version 6.0 or Version 6.0.1 application server, it is possible for the message to be serialized in a nonconforming manner.
Bus-enabled Web services cannot invoke a Web service that is hosted by WebSphere Application Server Version 6 if the service has an operation that does not have attachments in its request message and does return an attachment in its response message.
If you pass a large attachment through the service integration bus, you might get an out-of-memory error in the Java™ virtual machine. To solve this problem, increase the JVM heap size as described in Tuning bus-enabled Web services.
For more information, see Passing SOAP messages with attachments through the service integration bus.
For example, if a custom TokenConsumer is configured within the WS-Security configuration and bindings applied to an inbound port, and the TokenConsumer sets a token within the private credentials of the JAAS subject, and that token implements com.ibm.wsspi.security.token.Token and sets the forwardability attribute to "false", then any custom TokenGenerator configured on the corresponding outbound port WS-Security configuration and bindings should not rely on that token being available within the JAAS Subject.
Bus-enabled Web services perform more validation on Web service messages than is done in WebSphere Application Server Version 5. As a result, some client applications that use poorly-formed requests or responses (where the message parts are misnamed), and that work when using Version 5, are identified as poorly-formed in Version 6.
Versions of the WS-Security draft specification that were supported by the general Web services support in previous versions of WebSphere Application Server are not supported by service integration technologies. Service integration technologies only support the "OASIS Web Services Security Version 1.0 specification", the "Username token Version 1.0 profile", and the "X.509 token Version 1.0 profile". For more information about these supported specifications and profiles, see Supported functionality from OASIS specifications.
All client applications and target services that use WS-Security to interact with service integration technologies must also conform to the supported levels of these specifications. Client applications and target services that conform to previously supported versions of the WS-Security draft specification are not able to interact with service integration technologies because the wire format of the SOAP message with WS-Security has changed in the OASIS Web Services Security Version 1.0 specification and is not compatible with previous drafts of the specification.
When you pass messages into the service integration bus at a destination by sending Web service messages directly over the bus from a JAX-RPC client, there are limitations regarding the Java types you can use.
You can only retarget services that limit the types that are used in their interface to those that have defined mappings in the JAX-RPC specification. This limits the support to a subset of the possible XML schema that can be used in a WSDL document. For example, if the interface has any element that maps to SOAPElement it cannot be retargeted over the bus.
You can retarget services that use any Java type that has a defined mapping in the JAX-RPC specification, or any additional Java class that is allowed by the XML schema for a WSDL document, including SOAPElement as defined in the JAX-RPC support for SOAP.