Efficient technology for the enterprise

As mentioned in Web Services and Null Values – Part I-II one should not return a Java wrapper type, e.g. Boolean, from a Web Service as this type is modeled as xsd:boolean in the WSDL file.
If the service returns a null value for an xsd:boolean the caller might get in throuble.
In .NET it’s not a problem to return a Boolean because it can’t be null. That’s because Boolean is a value type.
Whereas in Java boolean and Boolean are different types in .NET they are the same System::Boolean.

Java

boolean (native)
Boolean (java.lang.Boolean reference type)

C#

bool (System.Boolean value type)
Boolean (System.Boolean value type)

If you need to transfer an parameter in a Web Service message for which null is a legal value always use a custom complex type.

Assume you have the following Web Service method:

public bool isCompany()
{
    return true;
}

If the requested information is not known it might be good idea to use Boolean instead of the native type boolean like in the following code snippet:

public Boolean isCompany()
{
    return null; // that means unknown
}

Here null is returned to indicate that the information is not known.

If you generate the WSDL from this code you will get an xsd:boolean on the wire. The result is the same for Boolean and boolean.
That means in XML the boolean value is not nullable anymore.
If you want the transfer a nullable type wrap it in a complex type:

public class WSBoolean
{
    public boolean;
}

public WSBoolean isCompany()
{
    return null; // that means unknown
}

I experienced this behaviour on BEA Weblogic 8.1 SP3, but I expect other frameworks/platforms like .NET or Websphere to behave in the same way.
If you wrap your nullable types you are on the safe side.

The meaning of a null is “value not set”. Apparently it is a difference whether you say the credit limit is zero or not set. Therefore sometimes it is necessary to convey null values over Web Services.
Luckily Web Services provide the means to express null values.
Assume the following Web Service method:

public String getName()
{
    return null;
}

The reponse in the SOAP Message uses the xsi:nil=”true” to express the null value on the wire.

This is fine as long as we use certain types as e.g. strings.
But if we use types which have a different representation on different plattform we might run into problems. Even though they are represented by a legal XML Schema type.
For instance the java types java.util.Date and java.util.Calendar are reference types on the Java platform.
The equivalent type System.DateTime is a value type on the .NET plattform which can’t be null.
If a reference type set to null is returned from a Java Web Service it causes a System.FormatException on the .NET plattform.
As the SOAP reponse is valid it seems to be a bug in the .NET implementation.

To avoid the problem wrap the reference type in an complex type as follows:

public class ServiceCalendar
{
    public ServiceCalendar(Calendar date)
    {
        this.date=date;
    }

    public ServiceCalendar getDate()
    {
        return new ServiceCalendar(cal); // or return null;
    }
}

Enjoy

The meaning of a null is “value not set”. Apparently it is a difference whether you say the credit limit is zero or not set. Therefore sometimes it is necessary to convey null values over Web Services.
Luckily Web Services provide the means to express null values.
Assume the following Web Service method:

public String getName()
{
    return null;
}

The reponse in the SOAP Message uses the xsi:nil=”true” to express the null value on the wire.

This is fine as long as we use certain types as e.g. strings.
But if we use types which have a different representation on different plattform we might run into problems. Even though they are represented by a legal XML Schema type.
For instance the java types java.util.Date and java.util.Calendar are reference types on the Java platform.
The equivalent type System.DateTime is a value type on the .NET plattform which can’t be null.
If a reference type set to null is returned from a Java Web Service it causes a System.FormatException on the .NET plattform.
As the SOAP reponse is valid it seems to be a bug in the .NET implementation.

To avoid the problem wrap the reference type in an complex type as follows:

public class ServiceCalendar
{
    public ServiceCalendar(Calendar date)
    {
        this.date=date;
    }

    public ServiceCalendar getDate()
    {
        return new ServiceCalendar(cal); // or return null;
    }
}

Enjoy