Python SOAP Client - use SUDS or something else?

circus picture circus · Oct 12, 2011 · Viewed 61.1k times · Source

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:

  1. Does it make sense to base a larger project on suds as soap client?
  2. Is there a suds fork that already implements some of the patches available in the ticketing system?
  3. What alternatives are available, that have a lower memory footprint and are easy to use and can handle complex large WSDL files

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

Answer

jathanism picture jathanism · Oct 21, 2011

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:

  1. Downloading your WSDL to localhost
  2. Using caching

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.