First of all: Yes, I know that there are plenty of SOAP/WSDL/Python Questions. And no, none of the answers I found was really helpful (anymore).
Secondly: Yes, I wouldn't use SOAP/WSDL anymore if I wouldn't need to. Unfortunately there are still huge software companies only offering web service through this interface. And I have to communicate with such a system. The specific company suggests the usage of PHP but I'm not really a PHP fan when it comes to serious things. I know that there seem to be good SOAP solutions for Java but Java is no option in this context.
The problem: There exists a multitude of SOAP packages for Python and quite some of them support WSDL. Foremost SOAPpy and ZSI. Unfortunately they usually depend on PyXML, which isn't compatible to recent Python versions anymore. I'm fine with Python 3 or Python 2.7, but nothing previous to that.
Since I don't want to ride a dead horse: Are there still any solutions to use SOAP / WSDL within current Python versions?
Check out: What SOAP libraries exist for Python 3.x?
I've used suds before and it feels good. It does seem pysimplesoap is more maintained though - I've only used pysimplesoap server side, not for consuming (e. client).
Related
I'm doing server/client application similar to Ubuntu Landscape (http://www.canonical.com/enterprise-services/ubuntu-advantage/landscape) for my school project.
The client part of application will send different informations (disk usage, packages etc.) to server. I know how to get informations and hot I'll handle them on the server side.
But I don't know how what is the best way to exchange informations. Would SOAP be ok or is there any better way for doing this? Messages can be large (for example a list of installed packages) or very small. I was looking at Twisted but don't know where to start. I have experience with SOAP in PHP, Java and C#.
And recommnedation is welcome, thanks
Look into XMLRPC or JSON-RPC which is likely supported in some why by all language through modules or packages.
SOAP is a complete bloat and widely considered as a failed hype.
I recommend using flask or smisk. Both frameworks are REST based, powerful, lightweight and pythonic. Flask is probably more mature and maintained. If you go down the SOAP road, you'll regret it sooner or later.
Any recommendations for auto-generating the WSDL for a Python/Twisted SOAP Server?
I've found lots of examples for taking an existing WSDL and generating the stubbed Python code, but am looking for the reverse operation.
The point is, all the python libraries out there are not complete and no more supported as well.
There is a library we are working on and maintaining, called soapbox, on this link.
This library has all the features that you need and more, and we are working on to add more features and capabilities.
Kindly note that, we are the only python soap library that is actively supported in the market, and because of this specific reason, people migrate from python to other languages when it comes to complex soap projects.
Let me know if you have further questions or enquiries.
Thanks!
I've finally concluded that I can no longer afford to just hope the ongoing Py3k/WSGI disasterissues will be resolved anytime soon, so I need to get ready to move on.
Unfortunately, my available options don't seem a whole lot better:
While I find a few different Python modules for FastCGI scattered around the web, none of them seem to be getting much (if any) attention and/or maintenance, particularly with regard to Python 3.x, and it's difficult to distinguish which, if any, are really viable.
Falling all the way back to the built-in CGI module is hardly better than building something myself from scratch (worse, there's an important bug or two in there that may not get attention until Python 3.3).
There is no higher sin than handling HTTP directly in a production webapp. And anyway, that's still reinventing the wheel.
Surely somebody out there is deploying webapps on 3.x in production. What gateway interface are you using, with which module/libraries, and why?
CherryPy 3.2 release candidates support Python 3.X. Because it only supports WSGI at the web server interface layer and not through the whole stack, then you are isolated from issues as to whether WSGI will change. CherryPy has its own internal WSGI server, but also can run under Apache/mod_wsgi with Python 3.1+. See:
http://www.cherrypy.org/wiki/WhatsNewIn32
http://code.google.com/p/modwsgi/wiki/SupportForPython3X
bottle supports Python 3, but it suffers from the broken stdlib. However, multipart reimplements cgi.FieldStorage and can be used with bottle to build a Python 3 WSGI web app. I just published a demo. For the moment it is just a test, but as far as I can tell it works well.
I want to access web service in Python or/and Perl scripts. What are the most popular and reliable libraries today?
I read this question, and I know about SOAPpy and ZSI. Can anybody say something about this libraries? Are they reliable enough for use in production?
If you're talking about SOAP then for Python I would definitely recommend suds :
https://fedorahosted.org/suds/
Checking couple of libraries for SOAP (including suds) only ZSI worked reliably for me. It is not complicated to use and it just works(tm). I recommend that.
Perl has fantastic CPAN libraries available for doing SOAP. Probably the easiest would be SOAP::Lite:
SOAP::Lite is a collection of Perl modules which provides a simple and lightweight interface to the Simple Object Access Protocol (SOAP) both on client and server side.
See more on the CPAN page.
what is the advantage of using a python virtualbox API instead of using XPCOM?
The advantage is that pyvb is lot easier to work with.
On the contrary the documentation for the python API of XPCOM doesn't exist, and the API is not pythonic at all. You can't do introspection to find methods/attributes of an object, etc. So you have to check the C++ source to find how it works or some python scripts already written (like vboxshell.py and VBoxWebSrv.py).
On the other hand pyvb is really just python wrapper that call VirtuaBoxManager on the command line. I don't know if it's a real disadvantage or not?
I would generally recommend against either one. If you need to use virtualization programmatically, take a look at libvirt, which gives you cross platform and cross hypervisor support; which lets you do kvm/xen/vz/vmware later on.
That said, the SOAP api is using two extra abstraction layers (the client and server side of the HTTP transaction), which is pretty clearly then just calling the XPCOM interface.
If you need local host only support, use XPCOM. The extra indirection of libvirt/SOAP doesn't help you.
If you need to access virtualbox on a various hosts across multiple client machines, use SOAP or libvirt
If you want cross platform support, or to run your code on Linux, use libvirt.
From sun's site on VirtualBox python APIs:
SOAP allows to control remote VMs over
HTTP, while XPCOM is much more
high-performing and exposes certain
functionality not available with SOAP.
They use very different technologies
(SOAP is procedural, while XPCOM is
OOP), but as it is ultimately API to
the same functionality of the
VirtualBox, we kept in bindings
original semantics, so other that
connection establishment, code could
be written in such a way that people
may not care what communication
channel with VirtualBox instance is
used.
From that article, I'm having trouble seeing the difference between "python virtualbox API" and "XPCOM". Could you provide a link to the API you're thinking of?