However, if I swap the php client code for the MS Web Services behavior I get non-return codes that tell me very little about what is going on, or where in the process pipeline things are going astray, so I have very little to share with you. In short, I have to play detective here with 'nary a clue to go on, so I'm beginning here with this mailing list, seeking an experienced voice.
Not familiar with the MS Web Services behavior, but suggest you install a tool like MS SOAP ToolKit 3 (from the SOAP SDK on MSDN) and examine (and post, if necessary) the SOAP request/responses with both the PHP client and the MS Web Services behavior as the client, to see what the difference is.
this technique out for a standards-based one. With Shane now having the WSDL capability built into PEAR::SOAP, the reasons for me *not* to make the move seem trivial.
The WSDL support is limited. Make sure it supports the types you plan to use before getting into anything complicated.
Also, if I may, does anyone know of any other browser-based techniques for consuming web services as an alternative to the MS one? My goal here is to replace my current RemoteScripting/DHTML technique with the conventional XML/SOAP/WSDL one. I wish to use straight JavaScript. And before it gets asked, in no way, shape, or form am I going to commit myself to .NET.
Java applets spring to mind for browser-side web service consumption, if the web service is in the same domain as the applet. Wouldn't be my first choice though. If you want to use JavaScript to consume services you will have to (AFAIK) make either a COM or .NET object that can handle SOAP messaging - subsequently locking you into IE. Somebody here may be able to guide you to a better solution.
Best,
Chris.
-- PHP Soap Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
