WebSphere Message Brokers
File: ad30560_
Writer: Terry Cowling

Reference topic

This build: July 31, 2007 21:26:25

Importing from WSDL: generated objects and restrictions

This describes the objects that are generated when a WSDL definition is imported and some restrictions that you need to be aware of.

Generated objects

Files copied by command line import
The mqsicreatemsgdefsfromwsdl command copies the WSDL files it needs into the workspace before the import process is run. These are the top level WSDL file and any imports resolved via a relative location. The files are copied under the specified message set in to a folder called importFiles.
Report File
The WSDL importer appends the result of the import operation to a report file, listing any errors that occurred during the process. The file name of the report file is <message set>.wsdl.report.txt.
SOAP Message Definitions
The required SOAP mxsds are added to the message set. Currently the SOAP 1.1 definitions are always imported. There are several reasons for this:
  • SOAP 1.1 is more widely used than SOAP 1.2.
  • There is no standard SOAP 1.2 binding for WSDL 1.1. This will mean that the WSDL importer cannot reliably determine that SOAP 1.2 is required.
  • It is not possible to import both SOAP 1.1 and SOAP 1.2 definitions because they use the same message name (for example, Envelope).

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.

Message Definition Files
Other message definition file names are created as <input file name>.mxsd and their content depends on the WSDL style.
document-style
WSDL message parts for style=”document” (which includes all SOAP header, fault and headerfault parts) refer to an element defined in XML Schema. This element is imported as a global element and broker message in the mxsd.

The xsi:type Output Policy on the message is set to “Never”.

rpc-style
WSDL message parts for style=”rpc” (and exclusively those allocated to the SOAP body) refer to a type defined in XML Schema. In this case, input and output messages are created as follows:
  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".

Restrictions

This describes some of the restrictions related to importing WSDL definitions. These are where the WSDL definitions are not WS-I compliant.
SOAP Arrays
A WSDL 1.1 definition may define a SOAP Array (only applicable to the WSDL rpc-encoded style, and not WS-I compliant):
    <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:

  • the model does not take any account of the SOAP-ENC:arrayType attribute.
  • the model for partially transmitted arrays does not take account of the SOAP-ENC:offset attribute.

    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].

  • the model for multi-dimensional arrays flattens the representation into a single dimension. For example, a 2 dimensional array is accessed in ESQL not as InputRoot.MRM.array.item[x][y], but as InputRoot.MRM.array.item[i] where the index i would have to be calculated appropriately.
Anonymous Elements
The WSDL excerpt above describes a SOAP instance document of the following form:
    <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.

Related concepts
Message modeling
The message model
Related tasks
Developing message models
Working with a message definition file
Working with message model objects
Related reference
Message model reference information
Import formats
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2007Copyright IBM Corporation 1999, 2007. All Rights Reserved.
This build: July 31, 2007 21:26:25

ad30560_ This topic's URL is: