© Copyright International Business Machines Corporation 2005. All rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
This release notes file contains late-breaking information about limitations and known problems and workarounds for the WebSphereR Integration Developer assembly editor.
The convertion of a WSDL interface reference to a JavaTM interface reference on a Java component is not supported for cases where the WSDL interface definition has operations with a multi-part return type.
Additionally, the creation of a Java implementation for a Java component that has WSDL interfaces with operations that have a multi-part return type is also not supported.
These limitations exist because Service Component Architecture (SCA) does not support these cases.
There is a limitation on the types of WSDL interfaces that can be used in SCDL objects, including components, imports, exports, and stand-alone references.
The following schema patterns are not supported for these objects:
- WSDL interfaces with in-lined schemas that have a null targetNamespace
- WSDL interfaces with in-lined schemas that have an unreferenced XSD import.
Here are two examples of these patterns:
- NULL target namespace in-lined schema (notice the missing targetNamespace attribute):
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:tns="http://Test/Test"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="Test"
targetNamespace="http://Test/Test">
<wsdl:types>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="operation1">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="input1" nillable="true"
type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="operation1Response">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="output1" nillable="true"
type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="operation2">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="input1" nillable="true"
type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
<wsdl:message name="operation1RequestMsg">
<wsdl:part element="tns:operation1" name="operation1Parameters" />
</wsdl:message>
<wsdl:message name="operation1ResponseMsg">
<wsdl:part element="tns:operation1Response"
name="operation1Result" />
</wsdl:message>
<wsdl:message name="operation2RequestMsg">
<wsdl:part element="tns:operation2" name="operation2Parameters" />
</wsdl:message>
<wsdl:portType name="Test">
<wsdl:operation name="operation1">
<wsdl:input message="tns:operation1RequestMsg"
name="operation1Request" />
<wsdl:output message="tns:operation1ResponseMsg"
name="operation1Response" />
</wsdl:operation>
<wsdl:operation name="operation2">
<wsdl:input message="tns:operation2RequestMsg"
name="operation2Request" />
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>
- Unreferenced imports - Note that BO2.xsd is imported but no elements in the inlined schema reference anything in BO2.xsd. The type defined in it is referenced directly by the operation1ResponseMsg WSDL message.
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:bons1="http://Test"
xmlns:bons2="http://Test/BO2" xmlns:tns="http://Test/Unref"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="Unref"
targetNamespace="http://Test/Unref">
<wsdl:types>
<xsd:schema targetNamespace="http://Test/Unref"
xmlns:bons1="http://Test" xmlns:bons2="http://Test/BO2"
xmlns:tns="http://Test/Unref"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:import namespace="http://Test"
schemaLocation="BO1.xsd" />
<xsd:import namespace="http://Test/BO2"
schemaLocation="BO2.xsd" />
<xsd:element name="operation1">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="input1" nillable="true"
type="bons1:BO1" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
<wsdl:message name="operation1RequestMsg">
<wsdl:part element="tns:operation1" name="operation1Parameters" />
</wsdl:message>
<wsdl:message name="operation1ResponseMsg">
<wsdl:part type="bons2:BO2" name="operation1Result" />
</wsdl:message>
<wsdl:portType name="Unref">
<wsdl:operation name="operation1">
<wsdl:input message="tns:operation1RequestMsg"
name="operation1Request" />
<wsdl:output message="tns:operation1ResponseMsg"
name="operation1Response" />
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>
For process and task component names, you must only use ASCII characters. Using non-ASCII characters can cause the installation of the Enterprise Application on the WebSphere Process Server fail, because these names will become part of an EJB name that currently has this limitation.
If you need to show national language characters, such as Hebrew or Chinese names for processes or tasks, to the user, you can enter these names into the Display name field. These fields are used in the Business Process Choreographer Explorer to display the task or process name.
The Open Interface action, and the Open push button on the Properties view of the assembly editor might open the interface editor for the wrong interface. This situation could occur if you have a WSDL file that contains more than one interface (or wsdl:portType). In that case, the interface editor could open for a different interface in that file than the one you expect.
To open the editor for the correct interface, locate the interface in the Business Integration view and open it from there.