Last week I looked into getting web services running in Python for one of the NRCC projects. Having heard a lot about the simplicity of programming Python and apparent simplicity of using web services, I expected this to be quite easy task. My expectations were somewhat mistaken.
There are two web service libraries for Python: SOAPpy and ZSI. SOAPpy theoretically has the simpler approach to accessing a web service:
# create the WSDL proxy
_server = WSDL.Proxy("http://www.webservicex.net/LondonGoldFix.a
# call web service
res = _server.GetLondonGoldAndSilverFix()
Unfortunately, this only works for very few web services. For most of them, SOAPpy generates types and SOAP envelopes not compatible with the web service. I have not discovered a simple way to manually create correct SOAP envelope in SOAPpy and at the same time retain its automatic services for parameter passing and result conversion to Python objects. This is the admirable goal of SOAPpy and Python web service implementation. Unfortunately, right now it fails.
It does not help that SOAPpy latest release is dated in 2004, while the newest release candidate is dated February 2005. In the fast moving world of web services, this seems like a slow pace and makes one doubt the vitality of SOAPpy project. (It also raises more general questions about free software tool development, but that's a theme for a separate message).
Another Python Web Service infrastructure is ZSI. ZSI seems to be more current with latest release candidate dated January 2006. For a long time ZSI has been an arcane way to access SOAP from Python. However, recent versions have added a more user-friendly way to accessing web services through WSDL. Alas, not all well is here, either. There are two ways for accessing WSDL services from ZSI. Direct way is similar to what was shown above with SOAPpy. Unfortunately, it does not work. Another way is to generate the arcane ZSI SOAP code using wsdl2py script on a WSDL file or URL. This works. Sometimes. At least it seems that it has improved since the last ZSI release and is beginning to handle more and more complex data types in WSDL descriptions. For me it worked on about 70% of the web services. Which is a reasonable percentage. The question is still: why do we generate mysterious intermediate SOAP code if the promise was a transparent access in 2 lines (see above)? The answer remains elusive.
It is possible to generate SOAP envelopes and requests in your program by using string concatenation and then parse the returned results to extract information. It's just that all this work should be done by SOAPpy and ZSI already.