WebSphere WebSphere Application Server Express, Version 6.0.x Operating Systems: AIX, HP-UX, Linux, Solaris, Windows

SIBWS - Known restrictions

This topic lists the main known restrictions that apply when using the service integration bus Web services enablement (SIBWS).

SOAP restrictions

WSDL restrictions

Security restrictions

Other restrictions

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

[Version 6.0.2]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.

[Version 6.0.1 and earlier]Although the Web Services-Interoperability (WS-I) Attachments Profile 1.0 is supported by the general Web services support in WebSphere Application Server Version 6, it is not supported by the service integration bus.

The service integration bus Web services enablement (SIBWS) 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.

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 the SIBWS.

For more information, see Passing SOAP messages with attachments through the service integration bus.

Toleration of poorly-formed SOAP messages

The service integration bus Web services enablement (SIBWS) performs 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.

[Version 6.0.1 and earlier]In each of these cases either modify the client or restructure the WSDL that is associated with the service in the SIBWS so that the part names match those that the applications are expecting.

[Version 6.0.2]The SIBWS supports 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.
In the case of output messages, a poorly formed message is only produced if the input message is poorly formed and the message does not need to be rewritten by the SIBWS. Whenever the SIBWS has to rewrite the message (for example because it has been modified by a mediation) it produces 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 service in the SIBWS 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.

A referenced WSDL document cannot import an external schema

The service integration technologies do not support WSDL documents that import external schema.

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.

Reference topic

Terms of Use | Feedback

Last updated: 2 Aug 2005
http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp?topic=/com.ibm.websphere.pmc.express.doc\ref\rjw_restrict.html

© Copyright IBM Corporation 2004, 2005. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)