Bus-enabled web services: Known restrictions
There are a small number of known restrictions that apply when using service integration bus-enabled web services.
SOAP restrictions
Security restrictions
Other restrictions
Passing SOAP headers through the service integration bus
<soap:header>
elements
within the <wsdl:definition>
element, then
the bus passes the SOAP headers through. This behavior is correct.
However, you also see the following effects:- The SOAP headers are not included in the WSDL that the service integration technologies generates.
- If you set the
must understand
flag on the SOAP message, then you get an error message.
Limitations in the support for SOAP with attachments
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 have to transform attachments from one style to another, you can use a mediation to map between attachment encoding styles.
Bus-enabled web services cannot invoke a web service that is hosted by WebSphere® Application Server if the service has an operation that does not have attachments in its request message and does return an attachment in its response message.
- Using DIME.
- Using
the
mime:mimeXml
WSDL tag. - Nesting a
mime:multipartRelated
inside amime:part
. - Using arrays or vectors of
DataHandlers
, images, and so on.
Content-Type
, Content-Id
and Content-Transfer-Encoding
.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.
JAAS Subject credential tokens not guaranteed to be available on outbound services
- Non-serializable contents.
- Any tokens that implement
com.ibm.wsspi.security.token.Token
or any of its sub-interfaces, and that do not set the forwardability attribute to true.
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.
Toleration of poorly-formed SOAP messages
Bus-enabled web services check the validity of web service messages more thoroughly than is done in WebSphere Application Server Version 5.1. 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.1, are identified as poorly-formed in later versions.
- Poorly-formed messages can be accepted by the bus.
- Poorly-formed messages can be produced by the bus.
Limitations in support for previous WS-Security draft specifications
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.
Limitations regarding the Java types used by services that are retargeted through a JAX-RPC client application
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.
Configuring an outbound service to use a WSDL port
- If you pass an object of type
Address
, that class and the classes of all the objects serialized within anAddress
object must be present on the WebSphere Application Server class path. - If the signature of a method on the enterprise bean
contains a
java.util.List
object and it is expected that the list is a list ofAddress
objects then theAddress
class must be on the WebSphere Application Server class path.