Soap 1.2 & WSDL 2.0 support

[stepank]

No description provided.

[superflit]

need that !

[stepank]

sorry to say that, but i don't think i will be able to implement this feature in the nearest future (at least a year) as it requires a substantial amount of work and i just don't have enough time for it

[auvipy]

whats the update?

[auvipy]

How can I help?

[stepank]

sorry, but unfortunately pyws is not very high in my priorities now. i only do some support and bug fixes if it is necessary. if you decide to implement this feature yourself, i can provide some guidance

[auvipy]

if you can provide me some guidance I will try to implement and send pull for review :)

[stepank]

Hello again,

Sorry for the late answer, I was moving to another country and it took virtually all my attention.

So, about SOAP 1.2 and WSDL 2.0 support.

First of all, a short notice about SOAP 1.1 support. When I implemented support of SOAP 1.1, my intention was to offer a simple way to expose APIs that would have very high interoperability with various SOAP clients. To meet this requirement, I had to implement a rather narrow subset of SOAP, but test it with as many SOAP clients as possible. I suggest using the same approach with SOAP 1.2.

Since I haven't ever worked with SOAP 1.2, but only with SOAP 1.1, to make things easier, I would try to mimic the behavior of one of the existing SOAP engines, for instance, Apache Axis 2. To do this I would:

1. Set up a simple SOAP server with only one function - string concatenation. As far as I can tell, a good starting point is http://axis.apache.org/axis2/java/core/docs/quickstartguide.html. The result of this step should not be a server that can only receive requests and produce responses, but rather it should be a server that is also able to generate its description via WSDL.
2. Generate a SOAP client from the WSDL of your service using one of the existing libraries. Since you are interested in a SOAP 1.2 server, I assume you have at least one such library in mind, what is it, by the way?
3. Make them work together.
4. Write an implementation of this service using pyws.

The last step is, of course, the longest and the most difficult:

1. First, make sure that you can run all (or at least suds based) pyws tests, read more about it here - http://stepank.github.io/pyws/dev/running_tests.html. This will guarantee that you can run a test server without any problems.
2. Then I suggest creating a new class, Soap12Protocol, in src/pyws/protocols/soap/__init__.py. You should probably derive it from SoapProtocol because they will have quite a lot in common.
3. Override attributes name (set it to soap12) and namespaces. As far as I understand, the latter should have only one element http://www.w3.org/2003/05/soap-envelope.
4. Extend class SoapServer in src/pyws/server.py so that it defines not only an instance of the existing SoapProtocol, but also an instance of Soap12Protocol.
5. At this point, provided that you set up everything correctly, you will be able to run a test server (go to project_root/examples/_wsgi and run make run), and send requests and receive responses. SOAP 1.2 endpoint will be at http://localhost:8000/api/soap12.
6. There is also a chance that the client you generated earlier will be able to work with this server. If not, make it so by fiddling with the code of Soap12Protocol.
7. Make your server generate WSDL. To do this, override the get_wsdl function of Soap12Protocol and write it the way that it generates the same WSDL as you got from the Axis2 server. You might want to look at src/pyws/protocols/soap/wsdl.py for some inspiration as well. Now you should be able to make the earlier generated client understand the WSDL and work with your server (WSDL will be at http://localhost:8000/api/soap12/wsdl).
8. Finally, you will have to add an automated test for all of this. How exactly you will do this will depend on the client you will use, so we can discuss it later. Some examples can be found here: https://github.com/stepank/pyws/tree/develop/tests. Note however, that without an automated test I will not merge your pull request because such tests are absolutely necessary to ensure interoperability.

If you walk through all of these steps, you will have one function working with strings only implemented. You will have to do this for all other types as well (integers, floats, dicts, lists etc), but it will become a bit easier because you will be quite familiar with the code.

If after reading this remark, you still decide to embark on this venture, you will, I assume, have a lot of questions. Don't hesitate to ask them either here or via my e-mail, I'll try to help as much as I can.