I know very little about web services (from the POV of people who know about web services; probably quite a lot if you don't care).
1. I've got a web service what I wrote, in Java (in that I wrote the methods to be exposed, and then invoked the magic tools to turn them into a web service).
2. I wrote a client, in Java (in that I downloaded the descriptor file created by step 1, and invoked the magic tools on it to create helper classes), which invokes the services, and prints some results.
So the concept is basically ok.
3. And then, somebody else at work is trying to access it, using Python. Of course, it goes wrong, or I wouldn't be posting here.
Now, who do I know around here,
who knows Python? Or Web services? (The web services is more relevant knowledge...)
If we use wsdl2py, from the ZSI utilities, to generate Python helper classes, then the XML that is generated for the service request is:
AN
This looks reasonably alright, but the server side code complains that:
No Deserializer found to deserialize a ':specCode' using encoding style '
http://schemas.xmlsoap.org/soap/encoding/'.
It turns out that my java client sends exactly the same request, but instead of sending AN, it sends AN and everything is fine.
So: is this xsi:type="xsd:string" attribute required by the specification of a web service (and the python code is incorrect to omit it), or optional (and my java code is incorrect to demand it)?
Subsequent to that, we found that using the ZSI.ServiceProxy instead, and building everything dynamically, at runtime, it sends the equivalent request with the xsi:type attribute, and results are returned (Wahey! But the ZSI library is being inconsistant).
But... (oh yes, there's a second problem).
One of the methods in my server-side Java class is returns a String. In some cases, this string is actually a null pointer, and is encoded into the result XML as: . This makes the Python client explode with ZSI.EvaluateException: Non-nillable element is NIL. We're currently working around it by returning an empty string, rather than a null pointer. The resulting XML is LN69, and everything at the Python end is fine. But my Java client coped with it. Is the Python wrong?
I could conceive that the problems are caused simply a discrepancy between web service specification versions, if null elements used not to be allowed, but now are. But I know too litle to answer this.