Limitations

The sections below discuss data handler limitations.

SOAP style and use guidelines

SOAP messages are created using a style and use defined by the web service. The SOAP data handler provides the levels of support shown in Table 36.

Table 36. Style and use guidelines
Style Use Parts defined using Data handler support
document literal element full
document literal type limited (see below)
document encoded element none
document encoded type limited (see below)
rpc literal element none
rpc literal type full
rpc encoded element none
rpc encoded type full

Part and part element order

When the SOAP data handler is transforming a SOAP message into a business object and the SOAP message follows either the document/literal/type or document/encoded/type formats, the message parts must be in the order described in the WSDL. For example, consider the following WSDL:

<operation name="GetQuote" 
      style="document" ...>
 <input>
    <soap:body parts="Part1 Part2 Part3 Part4" use="literal">
 </input>
 </operation>
  
 <definitions
  xmlns:stns="(SchemaTNS)"
 xmlns:wtns="(WsdlTNS)"
 targetNamespace="(WsdlTNS)">
  
 <schema targetNamespace="(SchemaTNS)"
                  elementFormDefault="qualified">
 <element name="SimpleElement" type="xsd:int"/>
 <element name="CompositElement" type="stns:CompositeType"/>
 <complexType name="CompositeType">
 <all>
       <element name='elem_a' type="xsd:int"/>
       <element name='elem_b' type="xsd:string"/>
 </all>
 </complexType>
 </schema>
  
 <message...>
 <part name='Part1' type="stns:CompositeType"/>
 <part name='Part2' type="xsd:int"/>
 <part name='Part3' element="stns:SimpleElement"/>
 <part name='Part4' element="stns:CompositeElement"/>
 </message>
 Ö
 </definitions>
 

The SOAP message must adhere to the order defined by the parts. In the SOAP example below, notice that Part1 elements precede Part2, Part3, and Part4 elements. This order must be maintained for proper BO resolution.

<soapenv:body... xmlns:mns="(MessageNS)"
    xmlns:stns="(SchemaTNS)">
    <stns:elem_a>123</stns:elem_a>
    <stns:elem_b>hello</stns:elem_b>
    <soapenc:int>123</soapenc:int>123</soapenc:int>123</soapenc:int>
    <stns:SimpleElement>123</stns:SimpleElement>
    <stns:CompositeElement>
       <stns:elem_a>123</stns:elem_a>
       <stns:elem_b>hello</stns:elem_b>
    </stns:CompositeElement>
 </soapenv:body>
 

When the SOAP message follows either the document/literal/type or document/encoded/type formats, part elements must be in order, too. In Part1 of the example above, the elem_a tag must precede the elem_b tag. This limitation is dictated by the data handler's business object resolution process. Since default business object resolution for document style makes use of the first element's body name and namespace, these must be the same element in all SOAP messages of this particular request, response, or fault so that the same business object is resolved in each case.

Note:
When the SOAP message follows either the document/literal/type or document/encoded/type formats, elements must not be optional.

XML limitations

The following XML structures, features, and notation are not supported:

Copyright IBM Corp. 1997, 2003