This describes the objects that are generated when a WSDL definition is imported and some restrictions that you need to be aware of.
If you need to parse SOAP 1.2 instance documents you should manually remove the SOAP 1.1 definitions and import the SOAP 1.2 definitions via the Message Definition File wizard, selecting IBM supplied message.
If your message set has TDS or CWF layers you may find that you get a number of warnings against the imported SOAP definitions. Most of these can be ignored, but you may need to take account of the allowed values for boolean attributes. In SOAP 1.1 a boolean has the value 1 or 0, whilst in SOAP 1.2 the values are true and false. The XML representation of boolean values for a message set is specified in the physical properties for the XML physical format and may need to be set accordingly.
The xsi:type Output Policy on the message is set to “Never”.
An input message | An output message | |
---|---|---|
Derived From | wsdl:input child (if any) of WSDL operation, and the WSDL message and parts which it identifies | wsdl:output child (if any) of WSDL operation, and the WSDL message and parts which it identifies |
Name of Element | value of the name attribute on the WSDL operation element | value of the name attribute on the WSDL operation element suffixed by "Response" |
Namespace of Element | value of the namespace attribute on the corresponding soap:body element | value of the namespace attribute on the corresponding soap:body element |
Each message is of local complex type, being a sequence of elements. The name of each element is the value of the name attribute on the WSDL parts of the message identified by the input or output element respectively. These elements have no namespace (the underlying schema representation has form="unqualified") and are locally scoped to avoid name clashes. The type of these local elements is the XML Schema type referred to by the type attribute of the corresponding part element. (The type will be global in the WSDL schema.)
If the soap:body was defined with use="encoded" in the WSDL definition then the message definition includes a reference to the attribute group encodingStyle in the SOAP-ENV namespace and the xsi:type Output Policy on the message is set to "Follow SOAP encoding rules". Otherwise the xsi:type Output Policy on the message is set to "Never".
<xsd:complexType name="t"> <xsd:complexContent> <xsd:restriction base="SOAP-ENC:Array"> <xsd:sequence> <xsd:element name="item" type="string" maxOccurs="unbounded"/> </xsd:sequence> <xsd:attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="xsd:string[]"/> </xsd:restriction> </xsd:complexContent> </xsd:complexType>
Some uses of SOAP array syntax are not fully supported. Although a useful tree is created during parsing (and can be serialized when writing), note that:
For example, the first element of an array specified with offset[2] would be accessed in ESQL not as InputRoot.MRM.array.item[3], but as InputRoot.MRM.array.item[1].
<SOAP-ENC:Array SOAP-ENC:arrayType="xsd:string[3]"> <item xsi:type="xsd:string">A general text string</item> <item xsi:type="xsd:token">A restriction of the string type</item> <item xsi:type="xsd:Name">ARestrictionOfTheTokenType</item> </SOAP-ENC:Array>
The broker model handles this as expected, but in SOAP encoding, array elements are also allowed to use the type-elements from the SOAP encoding namespace. This means an application using the same WSDL definition might create an instance document of the following form:
<SOAP-ENC:Array SOAP-ENC:arrayType="xsd:string[3]"> <SOAP-ENC:string>A general text string</SOAP-ENC:string> <SOAP-ENC:token>A restriction of the string type</SOAP-ENC:token> <SOAP-ENC:Name>ARestrictionOfTheTokenType</ SOAP-ENC:Name> </SOAP-ENC:Array>
The broker model created by importing the WSDL would have to be manually edited to handle this case, unless it is acceptable to have the parser treat it as a self-defined element.