I am currently looking into implementing a client which will use an existing extensive SOAP management API.
I looked into different SOAP implementations like pysimplesoap and SUDS. While the first had problems parsing the WSDL because of too much recursions, suds worked fine (but slow) and I really like module.
However, there seem to be several issues with SUDS like the high memory consumption, the WSDL parsing speed and missing support for some WSDL attributes (eg. choice attribute).
While there are a lot of people actively committing bug reports and patches, there was no release of SUDS since 0.4 on 2010-09-15. Also, the wiki and roadmap look a bit neglected.
For me it looks like SUDS is no longer maintained.
So here my questions:
[Update November 2013]
More than two years have passed and it turns out the original suds project is really dead. There have been no further releases since 2010. Due to this fact a lot of people started forking suds and and distributions like Debian are deploying patched versions of the original suds package to fix some of the issues.
I can recommend Jurko's actively maintained fork which I used successfully. It supports python 3 and addresses a lot of suds' known problems. Release notes and bug tracker are available on Bitbucket the package is also available on PyPI so it can be installed using pip.
'Suds' is a lightweight SOAP-based web service client for Python licensed under LGPL (see the LICENSE. txt file included in the distribution).
Suds is a lightweight library that uses SOAP based clients for python. SOAP is an RPC (Remote Procedure Call) that uses object-oriented protocol. Suds is actually lightweight SOAP python client that provides a service proxy for web services.
Python Web Services and Zolera Soap Infrastructure ((ZSI on PyPi) provides both client and server SOAP libraries.
While there isn't a certified standard, if you must use SOAP, Suds is your best choice. Suds can be slow on large WSDLs, and that is something they are working on.
In the meantime, if you don't expect your WSDL to change often, you have two options that can buy you a lot of speed:
Downloading your WSDL
With large WSDLs part of the problem is that first you must download the WSDL every time, which can add overhead. Suds will take the time to download and parse the entire WSDL on startup to make sure that it hasn't changed.
If you can download it to the local system and then pass it to the Client
constructor using a file://
scheme in the URL. Since Suds uses urllib2
for the HTTP transport, this is perfectly legit.
Now, because you're not providing a hostname in your WSDL URL, you will also have to pass a location
argument specifying the actual URL of the SOAP application.
Here is an example:
from suds.client import Client # The service URL soap_url = 'http://myapp.example.notreal/path/to/soap' # The WSDL URL, we wont' use this but just illustrating for example. This # would be the file you download to your system and save as wsdl_file wsdl_url = 'http://myapp.example.notreal/path/to/soap?wsdl' # The full path to the downloaded WSDL file on your local system wsdl_file = '/path/to/myapp.wsdl' wsdl_url = 'file://' + wsdl_file # Override original wsdl_url client = Client(url=wsdl_url, location=soap_url)
If you're interested, I have used this approach in my work and have open sourced the code.
Caching your WSDL
The other option is to use Suds' excellent caching feature. You must explicitly create a cache object and then pass that to the constructor using the cache
argument. Otherwise it defaults to an ObjectCache
with a duration of 1 day.
You might also consider using both of these approaches.
There is new well maintained SOAP client called zeep. It supports both Python 2 and 3 and is based upon well known lxml and requests libraries.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With