SOAP -- and I'm being nice here -- is a pain in the ass.

It's even worse than dealing with HTML interoperability, because it's cumbersome to set up a range of tests for each toolkit, as it can require setting up a seperate client built from each toolkit.

There are many, many things that can go wrong when trying to parse the results, but here are a few to start you off:

• the SOAP::SOM object returned from a method call has a lot more detail than the value returned from $som->result(). The result() method only returns the _first_ value returned, if it was a list.
• Look into the paramsout() and paramsall() methods to SOAP::SOM
• You can access values via XPath using the valueof() method to SOAP::SOM.

Look over the SOAP::Lite documentation ... and as you try more with it, look over it again. It hardly made any sense to me the first time through, over a year ago, but as I use it more, it starts making more and more sense.

As you start working with it more, you'll find that it makes a whole lot of assumptions, that can make easy cases trivial to implement, but causes a whole lot more work when the assumptions fail ... like if '20040101' is a string, not an integer... or if you're trying to emulate a document/literal webservice as opposed to RPC/encoded.