Different soap request in 9.2.0.4 linux and windows for same webservice

Question

hi,
i deployed a webservice on iis5 (dotnet 1.1). the client for this web service is written in java and is loaded into oracle db (9.2.0.4 linux). and there are errors. the same java code is working fine on 9.2.0.4 windows.
description of the error:
<?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/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:MethodName xmlns:ns1=http://tempuri.org/Service/message/ SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SomeString xsi:type="xsd:string" xsi:nil="true" />
<ErrorDes xsi:type="xsd:string" xsi:nil="true" />
</ns1:MethodName>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
there are problems with the 'SomeString' and 'ErrorDes' elements. there is an attribute xsi:nil="true". in the working requests this isn't present. the result of this, if for example DName isn't assigned a value this element isn't in the resulting response:
<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns=http://tempuri.org/ xmlns:types="http://tempuri.org/encodedTypes" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<q1:MethodNameResponse xmlns:q1=http://tempuri.org/Service/message/>
<Result xsi:type="xsd:int">0</Result>
<ErrorDes xsi:type="xsd:string">string</ErrorDes>
</q1:MethodNameResponse>
</soap:Body>
</soap:Envelope>
what can cause this behaviour? is there a way to prevent sending the xsi:nil attribute?
thanks
ralf

Answer 1

This is just one of the web service interop problems you can face. Both omitting the accessor with the NULL value as in your "working request" and placing xsi:nil attribute with the value "true" as in "not working request" are valid in soap messages. The problem happens when either the soap client or soap server/container does not fully support the soap spec or support with wrong interpretations. Most of the toolkit are not sophisticated enough to let you choose one of two options above.
Maybe you might want to consider not allowing non-null values so that you can get around with the interop problem, and add logic in the client and service implementation to handle special cases for default values indicating null.
Below is FYI.
SOAP 1.1 spec says the following.
"A NULL value or a default value MAY be represented by omission of the accessor element. A NULL value MAY also be indicated by an accessor element containing the attribute xsi:null with value '1' or possibly other application-dependent attributes and values."
On the other hand, there is no "null" attribute in http://www.w3.org/2001/XMLSchema-instance namespace referenced by xsi in your soap messages, and xsi:nil is the valid attribute name.
Regards,
Pyounguk