Yeah the extension already knows how to encode all (most) xsd types, soap,
apache so it assumes the correct namespace.
What about non-xsd types? It seems without wsdl there is no way to provide the element nodeName, namespace or type namespace.
My thinking here is if a server is soo type specfic that it wants long instead
of int or it has a specfic type. Then 99.9% of the time it will provied a wsdl.
Hmm, the general idea I have in regards to wsdl is that it is:
1. not part of the soap spec, therefore optional
2. independant of soap so it can be used for other serializations
3. not desirable to parse at runtime
Proxy classes can be built from wsdl which would allow for autogenerated client classes that do not require wsdl at runtime.
It can also be desirable to build a wrapper class for certain services to simplify their usage. Take for (a simple) example the Google web service. Every call requires a key as a parameter. A wrapper class can take the key as a parameter in the constructor, or read from a file, and automaticly add that into each call.
Neither of these are possible without having full control over serialization from the script.
There are of course 'super-complex' types that simply are not necessarily effectivly serialized without wsdl, such as arrays of complex types that contain hashes of complex types.
A small change to the API not as of a small change to the code.
Yes, I understand that is often the case.
Thinking more about your example it probally would make the proxy thing i was
talking about just a simple php script using the same api you defined. This
maybe the way to go.
now you could create new soap services by editing a xml document and pointing
all of your endpoints to something like
http://server.com/phpsoap_proxy.php/urn:myObject
That look pretty interesting.... but how does wsdl binding work.
per urn or per soapserver. The wsdl binding right now is per server.
wsdl binding could also be per-class, or in the eventuality that wsdl can be generated, each phpsoap_proxy.php script would generate a wsdl for anything it services.
I can keep this in mind when im doing other things.... but i'd rather see some
other issues addressed first.
Certainly, but this is one of the reasons these things need to be discussed. As other things are done, future events can be taken into consideration during the design.
What I am missing so far is how I define SOAPStruct is in the namespace http://soapinterop.org/xsd. If soapvar was changed to accept something like:
return SoapVar($retobj,'{http://soapinterop.org/xsd}SOAPStruct');
Again.. if you server isn't using soapenc:Struct for any struct encoding then
ALOT of the time it would use a wsdl. And when using wsdl's all the type stuff,
encoding and ns are all behind the scenes.
Based on the premise of always parsing wsdl at run-time I would agree with you. But for any possibility of generating proxies or wrappers based on wsdl, it's an important item.
Don't get me wrong I do understand that it is usefull to have all of that
flexabilty for interop issues. But i was focusing on wsdls and making it
simple.
I don't see it as soley an interop test issue, or an issue about simplicity, but rather as flexibility and extendability. The simple thing will always be using wsdl, or generating proxy from wsdl. I would never advise anyone to hand code a service.
Shane