On Fri, May 9, 2014 at 11:30 AM, Felix Schwarz <[email protected] > 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
_______________________________________________ Soap mailing list [email protected] https://mail.python.org/mailman/listinfo/soap
