wsdl2py

ZSI also now comes with a script, wsdl2py, which is undocumented as far as we can tell, but the Python source carries the doc string:

"A utility for automatically generating client interface code from a wsdl definition, and a set of classes representing element declarations and type definitions. This will produce two files in the current working directory named after the wsdl definition name."

This sounds promising, and we thought it might see the WXSDT dateTime parameters defined in the WSDL file and generate all the magic we needed to marshall these values from Python. The script can't handle WSDL URLs, so we had to download the definition to a local file. Here is an example of how to use the wget command on UNIX:

wget -O SBGGetAirFareQuote.wsdl \
http://wavendon.dsdata.co.uk:8080/axis/services/SBGGetAirFareQuote?wsdl

Unfortunately, we didn't get very far with the wsdl2py script, as the following listing shows:

wsdl2py -f SBGGetAirFareQuote.wsdl

Traceback (most recent call last):

  ... Part of traceback omitted for brevity ...


  File "/usr/lib/python2.2/site-packages/ZSI/wsdl2python.py", line 1058, 
  in _fromComplexType
    self._complexTypeComplexContent(tp)
  File "/usr/lib/python2.2/site-packages/ZSI/wsdl2python.py", line 1147, 
  in _complexTypeComplexContent
    arrayinfo = dt.getArrayType()
  File "/usr/lib/python2.2/site-packages/ZSI/wsdlInterface.py", line 1712, 
  in getArrayType
    raise WsdlInterfaceError, 'could not determine array type'
ZSI.wsdlInterface.WsdlInterfaceError: could not determine array type

It appears the script cannot handle the array of complex types in the search return structure for the getAirFareQuote operation, as represented in the WSDL types section:

      <complexType name="ArrayOfAirFareQuote">
        <complexContent>
          <restriction base="soapenc:Array">

            <attribute wsdl:arrayType="impl:AirFareQuote[]" ref=
            "soapenc:arrayType"/>
          </restriction>
        </complexContent>
      </complexType>
      <element nillable="true" type="impl:ArrayOfAirFareQuote" name=
      "ArrayOfAirFareQuote"/>
      <complexType name="ArrayOf_xsd_string">

        <complexContent>
          <restriction base="soapenc:Array">
            <attribute wsdl:arrayType="xsd:string[]" ref=
            "soapenc:arrayType"/>
          </restriction>
        </complexContent>
      </complexType>

      <element nillable="true" type="impl:ArrayOf_xsd_string" name=
      "ArrayOf_xsd_string"/>

To be fair to ZSI, WSDL array types are perhaps the most notable exemplar of everything that is poor about encoding RPC payloads in XML, but that's a topic for another article. After commenting out the above type definitions -- and replacing them in the WSDL with dummy WXSDT string types -- wsdl2py succeeded in producing two modules packed with impressive-looking code. Unfortunately squinting at all this code didn't shed much light into how to properly marshall the input date parameters, so we sadly called it a defeat. To be sure we weren't completely off the rails, we asked one of the ZSI developers about the trouble marshalling date types. His response indicates that it probably is indeed a bug in ZSI, but it is also likely to be fixed soon. If we learn more about this problem we'll make sure it's posted to the forum for this column (see Resources).

A wrapper for ZSI and a wrap-up

At least one developer trying to use ZSI has decided that there has to be an easier way to take advantage of the richness underlying ZSI's difficult interface. OSE is a framework for distributed and Web-based applications which offers SOAP support, building on ZSI. Part of OSE is the zsirpc package which provides a more friendly wrapper for ZSI, although it only handles Web services that are encoded in similar fashion to XML-RPC. Most usefully, it provides straightforward wrappers for passing boolean, binary (encoded as BASE64), date, dateTime, time and duration types, which ZSI supports, but as we have learned, only with a lot of extra work by the programmer writing specialized structures.

We hope that some of the code from zsirpc makes it into ZSI itself. This would make life a lot easier for developers of RPC-style Web services. Then again, perhaps it is better to continue to encourage developers towards the document-literal style of Web services. We have long been advocates of such style and it is good to see that the mainstream of Web services finally tend in this direction. It will finally allow developers to express messages in terms of the dynamics of XML itself, rather than bewildering layers of conventions to try to extend a single data model for communications across platforms and languages.

ZSI isn't the only Python Web services library to go through significant development. SOAPpy is also in active development, and WSDL is also a large part of this work. We shall have a look at what's new in SOAPpy in the near future.