Python/SOAP: second encounter
python soapIt looks like my experience in Python/SOAP programming no better than the first encounter. Here is the full story:
I am working on a client application to consume Microsoft SharePoint server web service recently. Since the client does not support scripting, I decided to develop a Python console application to ease my routine job.
The first two candidate are SOAPpy and ZSI. SOAPpy is the official library used in the DiveIntoPython, and ZSI is the succeeder of SOAPpy.
The first problem I have met in Python 2.5 environment is ZSI-2.0 depends on PyXML, which is not compatible to Python 2.5 though, so I migrated to ZSI-2.1_a1, and eventually get ZSI successfully imported. ZSI supports two approaches to use WSDL, I must admit I won’t consider any web service without WSDL.
- ServiceProxy: dynamically build the method proxy in the run time
- wsdl2py: generate the python code in compile time for later use
Neither of them works even for a simple web service from xmethods.com. Some type error or attribute exception is thrown when calling service method.
So I went back to the traditional SOAPpy. Though it is a little annoying to build fpconst, (thanks to easy_install to make it less painful), I really love the SOAPpy’s API, simple and stupid:
from SOAPpy import WSDL
wsdlFile = 'http://www.xmethods.net/sd/2001/TemperatureService.wsdl')
server = WSDL.Proxy(wsdlFile)
server.foo('bar')
However, the SOAPpy generate wrong SOAP message. Once the type is declared as
sequence
, the SOAPpy would insert <v\d+>
tag as the container, that failed
the service provider.
Don’t forget we have not touched the authentication, NTLM, the default certification policy used in most of the SharePoint server in the Intranet. This is really a long way to go.
UPDATE: Moved to Web category, so it won’t pollute the Gentoo Planet.
UPDATE: Thanks to Lawrence’s advice, I did try soaplib
last night. It is
really a promising library for SOAP, the parser is based upon cElementTree
, so
it is supposed fast and memory-friendly. Once you build the service provider;
bang, you already get the consumer application. The only problem is there is no
official support for WSDL. wsdl2py
in ext
package seems promising, it is
under active development, so it might not be production-ready. The last check
in is in 1 year ago, no wonder there are tons of errors in WSDL parsing. I just
wonder whether optio developers may have a private code repository for daily
check-in, and they may sync their work to the public from time to time.
Once I finish WSDL specification, I may refactor the wsdl2py
module.