There are a small number of known restrictions that apply
when using service integration bus-enabled web services.
Passing SOAP headers through the service
integration bus
If the WSDL for your service contains
<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.
The following scenarios
are also not supported:
- Using DIME.
- Using the mime:mimeXml WSDL tag.
- Nesting a mime:multipartRelated inside a mime:part.
- Using arrays or vectors of DataHandlers, images,
and so on.
The MIME headers from the incoming message are not preserved
for referenced attachments. The outgoing message contains new MIME
headers for
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
When using
WS-Security, the following contents of a JAAS Subject credentials
set are not guaranteed to be available to code running on an outbound
service if they are set on the processing of an inbound service request:
- 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.
Bus-enabled web services
support applications that produce messages where the message parts
are misnamed, provided that they still match the general form of the
schema. With this support:
- Poorly-formed messages can be accepted by the bus.
- Poorly-formed messages can be produced by the bus.
For output messages, a poorly formed message is only produced
if the input message is poorly formed and the message does not have
to be rewritten by bus-enabled web services. Whenever bus-enabled
web services have to rewrite the message (for example because it has
been modified by a mediation) they produce a well-formed SOAP message
using the correct names for the parts as defined in the WSDL document.
In each of these cases, if your service or client relies on the response
message part names being misnamed, either modify the client or restructure
the WSDL that is associated with the bus-enabled web service so that
the part names match those that the applications are expecting.
Note: Only
incorrect part names are tolerated. Incorrect operation names or incorrect
part structure are not tolerated.
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.
When you configure an outbound service
to use a WSDL port that uses the EJB binding, all the classes passed
to the enterprise bean must be present in the WebSphere Application Server class path
When
you configure an outbound service to use a WSDL port that uses the
EJB binding, service integration technologies invokes the service
using Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP).
However, all the classes passed to the enterprise bean must be present
in the
WebSphere Application Server class path. For
example:
- If you pass an object of type Address, that class
and the classes of all the objects serialized within an Address 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 of Address objects
then the Address class must be on the WebSphere Application Server class path.