I'm attempting to use an Apache SOAP 2.2 client to invoke a service running
under Microsoft SOAP Toolkit 2.0, so naturally I'm encountering
interoperability problems. Since I'm a total neophyte in this world, I can't
tell whether there's something I'm just not understanding or whether this stuff
is actually as messed up as it appears (I mean, the whole point of a standard
like SOAP is supposed to be interoperability, right?).
Anyway, consider a simple "hello world" example straight out of the O'Reilly
cookbook. Microsoft's helpful .asmx page tells me they are expecting something
like:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
<soap:Body>
<sayHello xmlns="urn:Example1">
<name>Foonblatz</name>
</sayHello>
</soap:Body>
</soap:Envelope>
After a bit of tweaking around, I get Apache SOAP to send the following, which
actually results in a partially successful invocation of the service:
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance";
xmlns:xsd="http://www.w3.org/1999/XMLSchema";>
<SOAP-ENV:Body>
<ns1:sayHello xmlns:ns1="urn:Example1"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";>
<name xsi:type="xsd:string">Foonblatz</name>
</ns1:sayHello>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
When I say "partially successful", I mean that the service executes and
successfully returns a result (which I successfully deserialize), but the
result value itself is wrong because the actual value of the 'name' parameter
was never seen by the service -- it saw a null string instead.
The problem seems to be in the way XML namespaces are handled in the
marshalling of the parameters. If I manually feed the server a tweaked version
of Apache's XML with the body encoded to match the pattern of Microsoft's
namespace use:
<SOAP-ENV:Body>
<sayHello xmlns="urn:Example1"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";>
<name xsi:type="xsd:string">Foonblatz</name>
</sayHello>
</SOAP-ENV:Body>
I get a correct result. Alternatively, if I feed it:
<SOAP-ENV:Body>
<ns1:sayHello xmlns:ns1="urn:Example1">
<ns1:name xsi:type="xsd:string">Foonblatz</ns1:name>
</ns1:sayHello>
</SOAP-ENV:Body>
that also works. And indeed, my barest fingernail's grasp of how XML
namespaces work suggests to me that Apache SOAP's interpetation of things is
simply wrong and Microsoft's is (as much as it pains me to say it) correct.
However, there doesn't seem to be any graceful way to coax Apache SOAP into
generating either of the correct (or, at least, acceptable-to-Microsoft) XML
patterns short of simply modifying Apache SOAP itself. The latter expedient
was only a two line change to org.apache.soap.rpc.RPCMessage, but that seems to
me to be far too radical and dangerous a way to deal with the situation, given
that my understanding of all this is as poor as it is.
Anybody out there with more of a clue than I care to share?
Thanks,
Chip
