Python-zeep: Possibility of adding server support?

[pope1ni]

Currently I help maintain soapfish which is a project that I help to maintain and inherited. In many ways it suffers because it is fragile in some areas, but for a long time there hasn't been a very good alternative. It takes an approach of being able to statically generate code from a WSDL or vice versa. We use it to consume other services, but also serve up our own web service via Django.

I see that zeep was created this year and I like the approach taken with respect to the implementation. From what I can tell, everything looks as though it works dynamically, using the WSDL directly which keeps client implementation clean and lightweight.

How difficult do you think it would be to add support for providing a server implementation capable of being dispatched via Django, Flask, etc? Although we currently provide the code and generate the WSDL via soapfish, I think it would make a lot of sense to just define the WSDL and use that hooking in where necessary to handle the request.

While I don't have any time right now to look into a possible implementation, I just wanted to see if you were open to it...

[mvantellingen]

Hi @pope1ni,

Sorry for the slow response. I've actually looked at soapfish before I started developing zeep (see the copyright notice). I'm personally not really interested in adding support for server capabilities. I think Spyne does an excellent job in that space.

I am of course open to making parts of zeep better suitable for reusability so that an other project can leverage code within zeep, but like you I currently don't really have the time for this :-)

Cheers, Michael

[pope1ni]

Hi Michael,

Thanks for your response.

I hadn't actually come across Spyne before - it looks very interesting, but potentially has the disadvantage of trying to support too many different protocols in one leaving some underdeveloped - many of the source files for the soap-related functionality have comments such as:

• "This modules is EXPERIMENTAL"
• "The functionality in this code is not well tested and is reportedly not working at all."

It also currently doesn't handle using a predefined WSDL - see the FAQ - and looking at genpy shows static code generation (which is what soapfish does).

As I mentioned before, I love that zeep can make use of a WSDL file without the static code generation for client-side consumption of a SOAP web service. Obviously on the server side this is less straightforward as there is the need to hook in to define the behaviour for handling the request, but a framework for hiding away all of the SOAP and XML schema complexity by using the WSDL directly would be very nice.

Perhaps - if you have no objections - this issue could be left open as a possible future development should I or someone else have a chance to work on it?

Thanks,

Nick

[plq]

Hey,

Spyne author here. Spyne's soap bits have been under development for almost 10 years now. The soap support is the least experimental part of Spyne. The not-well-tested-and-not-working bits are binary attachments to soap (MTOM) implementation. It never made prod quality because apparently noone is using SOAP to lug binary data around. Patches are welcome :)

cheers,

[plq]

Oh and genpy is just a PoC. The foundations for static code generation are there and to me what it can already accomplish in ~100loc is pretty amazing. In python world, it's silly to have client code generated like that -- this was mainly for generating server code to accommodate clients that expect a predefined WSDL on the server side.

In case you are interested in finishing that, I'd love to help you.

Spyne is a very bad SOAP client. Projects like Suds and now Zeep prevent me from persuading myself to finish those parts of Spyne :)

If you want to discuss further, please join the mailing list: http://lists.spyne.io/listinfo/people

Oh and I'd be happy if you'd stop spreading FUD like "potentially has the disadvantage of trying to support too many different protocols in one leaving some underdeveloped" or "many of the source files for the soap-related functionality have [EXPERIMENTAL] comments:" as none of these are true.

The protocol structure is pretty modular and well isolated to the point that eg you can have Spyne function as a HTTP/JSON server without even having lxml installed. There's not much difference from the soaplib 2.x days in terms of protocol structure. And SOAP support on the server side has been production-ready for years. WSDL parsing on the client side is not finished, but that is orthogonal to the quality of the server code.