[Soap-Python] soap library for python-3.x

[Mariano Reingart]

On Fri, May 9, 2014 at 11:30 AM, Felix Schwarz <felix.schwarz at oss.schwarz.eu
> wrote:

>
> Am 25.04.2014 11:56, schrieb Deepika Nagpal:
> > We have to start a project for developing a soap server in python-3.x
> for which I am
> > looking for a soap server side library. Please let me know what are the
> options
> > available for python-3.x and which of these libraries are actively
> maintained. Thanks.
>
> (Disclaimer: I'm one of the maintainers of "soapbox-bsd".)
>
>
(Disclaimer: I'm the creator and one of the maintainers of "pysimplesoap".)

TL;DR: see the summary at the end

I think you should check out soapbox-bsd which is the only real option for
> server-side SOAP in Python: https://github.com/FelixSchwarz/soapbox-bsd
>
> I realize I made a bold strong statement so let me quickly explain why I'm
> saying this.
>
>
Personally, I don't believe in "one size fits all", that could tend to a
harmful monoculture thinking that could not take into account different
user needs, expertise, backgrounds and use cases. Diversity is good. IMHO


> A bit of background first:
> - I'm not doing SOAP for fun or to provide "just another RPC layer".
>

Me too, PySimpleSOAP is focused on SOAP and was born from a commercial
project to build interfaces for Argentina's Federal Tax Administration
 (AFIP, equivalent to IRS in the US), originally for electronic invoicing,
but then it spawn to agriculture, foreign trade, customs, foreign exchange,
etc.
Also, it added support for even other government agencies like medical drug
traceabilitty, precursors chemical, etc.:

https://code.google.com/p/pyafipws/

It is currently one of the most used interfaces to consume the AFIP
webservices and has a forum with +230 members

http://groups.google.com/group/pyafipws

I also offer commercial support for the SOAP library itself:

https://code.google.com/p/pysimplesoap/

I'd been contracted by several internatinal corporations (including Tier2/3
ERP vendors), hundreds of SME and profesional individuals:

http://www.sistemasagiles.com.ar/trac/wiki/PyAfipWs#ReferenciasComerciales

In fact, the server (including web2py) is being used internally in a
related project for an important network information center.

- I need to implement SOAP protocols defined by others without any chance to
>   change a tiny bit.
>

PySimpleSoap also has some hacks to support this, and you could mimic other
webservices implementations.
In fact, initially I developed it to make a "simulator" of a government
.NET webservice that only published the WSDL:

https://www.sistemasagiles.com.ar/simulador/wsfev1/call/soap?WSDL

for

https://wswhomo.afip.gov.ar/wsfev1/service.asmx?WSDL

(yes, it is not an exact emulation but just to show the point)

Some contributors have sent patches to extend the use cases, and the
underlying XML abstraction layer uses the standard library minidom that
should be enought to ad-hoc support most "esoteric" soap features.


> - I have an unknown number of SOAP clients, most proprietary desktop
>   applications from a random number of ISVs (each with their own bugs). I
>   need to be interoperable with every single one.
>
>
Yes, this is a frequent issue.
I've tested and adapted PySimpleSoap with common ones: .Net, Java, etc.
(there is a wiki page explaining it)
My approach is to adapt internally the library to support the different
soap dialects, and expose a minimal API to use it.
I found this easier than exposing a large API and object model that the
user has to understand and tailor.
Also, I think it is more uniform and the same internal quirks could be used
in other applications by unexperienced users (my next step is to
automatically detect the soap dialect for a seamless operation)


> From my experience rules out any library which supports SOAP among others.
> I
> needed complete control over the complete request/response parsing
> (including
> the ability to process/return invalid SOAP to satisfy specific clients).
>
>
You said the magic words ;-)
The question is what is the experience and what are the use cases of the
user requesting this recommendaton.

PySimpleSOAP is targeted more to users that need a rapid & dynamic
solution, without needing to go too deep on technical details.

The idea is maintaining it codebase as simple and small as possible, so it
could be easily understood by novice users, and even individual
intermediate users could contribute patches. There should be no need to
hire an expert or a consulting firm to use this library for common use
cases (although paid tech support has made possible many complex
enhancements). YMMV
The library implements a SimpleXMLElement object to dynamically abstract
xml manipulation via python objects, and the API is really simple: just
mainly a Client and a Server classes (using python builtin types, dict,
list, etc., to construct even complex element structures, for RPC input and
output parameters).
This were inspired by the PHP SOAP extension, so other goal of this project
is to help with the transition from other programming languages.
Also, this simplified and dynamic approach hepls to lower the memory
consumption and could speed up processing considerably, compared to other
implementations (in some cases, see comment in issue
49<https://code.google.com/p/pysimplesoap/issues/detail?id=49#c3>
)

So far, the project involved around 4 owners, 20 commiters and 9
contributors (not all active right now). It started in 2010 as a spin-off
of the PyAfipWs (electronic invoicing webservices) project circa 2008.
Despite its name, the project is no more just a "simple" implementation, as
support for more advanced features were added over time. So, more or less,
it is now a complete implementation of the most used SOAP protocol specs
(including WSDL parsing and generation).
I'm thinking on changing its name to soap2py to avoid misunderstandings (a
better description would be "lightweight"), and I'm planning on a GUI
visual application (like SoapUI) to help even further prototyping,
development and debugging of webservices apps.
Governance is open and distributed; commit rights are granted to anyone
that sends significative patches, and the GitHub / GoogleCode project sites
has at least two owners and several commiters/contributors.
In fact, I didn't commit many of the new features / python 3 support
changes, and we reunificated a separate fork some years ago.

The library has been integrated to web2py (see the contrib packages), and
is documented in the web2py official book and web2py recipes book (Packt).
The client support several transports (urllib, httplib2, pycurl, etc.) and
the server is WSGI compilant, with sample apps for web2py, django and
possibly others, supporting non-trivial enterprise infrastructures
(propietary proxy auth, webservers, etc.)

It is licenced using LGPLv3 (weak copyleft, GPL compatible, OSI/FSF
approved, can be used in closed commercial projects, etc.) and the user can
choose any later version (so I think contributors agreements are not really
an issue).
BTW, the LGPLv3 is more updated and "internationalized" than other
permisive licences (for example, some sections of the classic MIT/BSD
licences could be considered abusive on some circunstances at least here in
Argentina, AFAIK).

Summary:

Pros:

- maitained by professional software developers (at least me), many
contributors so far
- active community management: unified github/googlecode and relicencing is
not required as it is LGPLv3+
- support for Python 2.6-3.x (mainly tested for 2.7, and less for 3.4 )
- no external dependencies are mandatory (works out of the box with the
python standard library)
- simple API for RPC using only builtin python types for parameters  (dict,
list, str, int, etc.)
- "pythonic" abstraction layer for XML (SimpleXMLElement)
- supports different dialects of SOAP (.NET WCF, Java Axis, etc.)
- everything is dynamic: no need for code generation, artifacts, custom
object model, mappers, etc.
- relative low memory footprint and possible speed-ups due the simple API
and dynamic abstraction model
- small codebase: 5 modules, 4 main classes, no advanced OOP skills required
- comprehensive implementation (including client/server and WSDL parsing /
generation)
- multi-transport (urllib2, httplib2, pycurl) and WSGI-compilant (web2py,
django)
- documented in the project site (wiki), and inside 2 printed books
- installabe through pypi (only the stable version)
- backward compatibility (almost no conflictive API changes between
releases)

Cons (see the open issues list for more info):

- not polished as a silver-bullet (but most use cases will work out of the
box, expect some hacking for special cases)
- "esoteric" rare used XML/SOAP features are not supported by now (ie.
element attributes, but raw request could be used)
- namespaces (complex wsdl parsing support), python 3, etc. are "recent"
additions that need more testing
- missing a simple & automatic object mapping function to expose more
complex structures of simple python types (causes a kind of "impedance
mismatch" with other frameworks that could be easily resolved
instrospectively in the serialization code, this is my next item in my TODO
list)
- contributor/user ratio is low and varying over time (don't expect hard
issues to be resolved fast ouside commercial tech support)
- some internal parts (specially wsdl parsing) needs serious refactoring to
be easier to understand and extend
- a lot of tests needs feedback for the users that sent the issues (some
may even fail due webservice no longer exists or changed)
- development pace is not as fast as it should be (due most important
features are mature enough at least for me, and other libraries could
attract users with more specific needs)
- some important features are only in the development repository, so
they're not yet released in the stable version (I'm planning a new release
ASAP)

Finally, another relevant library not mentioned previously in this thread
is WSME (WebServices made easy), that had a recent release:

http://wsme.readthedocs.org/en/latest/


Hope this help, and sorry for the long mail

Best regards,

Mariano Reingart
http://www.sistemasagiles.com.ar
http://reingart.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/soap/attachments/20140510/9b936c4a/attachment.html>