One Web services interoperability issue that I have been investigating recently has to do with using null DateTime values between .NET and Java. Here's the problem:
System.DateTime in the CLR is considered a value type, where as the equivalent in Java (java.util.Calendar) is not. In .NET, value types, including int, double, short etc. cannot be assigned to null. This applies equally to DateTime:
For example, the following command in C# will not compile.
System.DateTime myDate = null;
(In VB.NET you may think you can do this, but really you can't <g>)
In Java, java.util.Calendar can be assigned to null - which introduces a couple of problems when you consider passing dates and times over Web Services between the two:
1) How do I send a null DateTime from .NET to Java?
2) What happens if Java sends me a null DateTime?
For #1, this is really up to how you want to handle it (and this is easier to spot as the problem will normally be detected at compile time). Here are some options:
- Both the client and the Web service agree a certain date (e.g. 01/01/0001 12:00:00 AM) as a null date.
- Make the interface expose a string and pass the date that way instead. From experience, if you were to do this, I would pass an empty string to indicate a null date.
- Create a XSD complexType that contains a DateTime value and pass this instead. Set the value of this complexType to null to indicate a null date. (this would be my recommended approach as it get's you into the habit of passing messages between the two, instead of primitives <g>).
#2 is a little more tricky because if .NET receives a null DateTime from a Java Web Service, it will throw a System.FormatException - which you won't catch at compile time. Again, the options above are equally applicable on the Java side.
Which option you choose will depend on your particular situation - and may also be based on whether you are using Web services internally or externally.
The good news is that we are working on a set of guidance for this and other similar issues. Catch any my talks, visit the Web services interoperability booth at TechEd or watch this space to find out more...