PHP, SOAP, WSDL, Pain.

After WSDLInterpreter moved out of beta just under a month ago, it's been getting a lot of use. I started this project because I wasn't pleased with the results I was getting from other wsdl2php solutions, and the native SoapClient class certainly has a lot of shortcomings that I've briefly outlined already. Some more things have come up in PHP's native SoapClient for what seems like some fairly basic usage, however.

The biggest issue so far seems to be (not) applying namespacing to deep wsdl objects. This one seems to work nearly uniformly for most of the other major languages' soap clients, but not PHP. An example of this is if I have class A with a member variable B (of type class B), with both classes defined by the wsdl, and class A is the parameter to the soap call, then class A will be properly namespaced but the member element B will not, and in the case of extended classes (for example, using class C which extends B as the value for $A->B), typing is not correct in most situations either. This causes problems on the server side, as the objects aren't marshaled in properly which then typically affects the responses returned. PHP's SoapVar can help you get around this by passing in a wrapped object instead of the native object, but this functionality should be the default rather than having to write methods to iterate through the objects being passed in to the soap call to ensure that all of the type information is properly set. With PHP being a weakly typed language, this is somewhat understandable from the native language perspective. However, when you venture in to the realm of web service calls, you are now dealing with a different language and need to respect its specifications in order to get back reliable results.

There is another problem with name spacing and with the structure of the native soap requests that seems to vary from many other languages' native soap clients, but I'm still investigating that to see what workarounds might be available.

A new release of WSDLInterpreter to address the first issue (and the second, if it ends up being worthy of addressing) is forthcoming. I plan on putting out an unstable release with these fixes and ask for support in testing it against all of the various wsdl's and web services that you all are using, as one thing remains true in the world of wsdl - standards are still 'evolving'.