WAS v8.5 > Reference > Troubleshooting tips

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

If the WSDL for the 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:


Limitations in the support for SOAP with attachments

The service integration bus supports SOAP messages containing 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 v1.0. If we have to transform attachments from one style to another, we 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:

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 Tune 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:

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 WAS v5.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 v5.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 they still match the general form of the schema. With this support:

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 associated with the bus-enabled web service so the part names match those the applications are expecting.

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 WAS are not supported by service integration technologies. Service integration technologies only support the "OASIS Web Services Security v1.0 specification," the "Username token v1.0 profile," and the "X.509 token v1.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 v1.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 we can use.

We can only retarget services that limit the types 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.


Configure an outbound service to use a WSDL port

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 WAS class path. For example:


+

Search Tips   |   Advanced Search