There's a lot of talk in the last few months about automating checks and intrpducing approval processes, to ensure that services are interopable (what's often called "SOA governance"). Inside Actional, because our product line can be mixed and matched across .NET and Java, we've experienced a lot of these interoperability issues head-on. I wanted to call out a few of the less obvious (and below the radar screen issues) issues. This is a blog entry for code jockies - you've been warned.
Most people are probably familiar with the best practices such as "don't use platform specific data types (e.g. .NET DataSets) in your web service interfaces" - just don't do it.
There are two lesser known issues we've encountered that are due to platform differences between .NET and Java. The first is the use of "nillable" elements. The intent, in XML scheme, is to indicate that this element may not have a value. The real issue comes when you mix nillable and fundamental types (e.g. int, float, boolean, etc.): In Java these would be represented as java.lang.Integer, etc. - a type which can either be null or have a defined value. The issue is that, when .NET imports a WSDL containing nillable fundamental types, there are a few issues: with RPC encoded WSDLs, there's no way to represent a null value in .NET (there's a workaround to this, but it requires modifying the generated .NET code -- though the modification can be automated via scripts). With doc-literal encoded WSDLs, they support null values, but in an extremely error prone way. For every field that is nillable, there's a separate boolean field which indicates whether a null value should be used - so the developer needs to manually keep these fields in sync: something that has a very high likelihood of having bugs. So, be careful about depending on the notion of nillable.
The above nillable issue could be flagged as a warning by automated tools so people know to look into it. This next issue is even more insidious. In XML, a date/time type includes date, time, and timezone. In Java this is represented relatively faithfully by the Calendar data type. In .NET, however, the native DateTime datatype represents a date and time without a timezone. What .NET does when it receives dates in a web service call is convert them to the current timezone. Similarly, when it sends a date, it assumes the value is in the current timezone. But, basically, when you go into .NET you lose the timezone information (even if the number represents the same "world clock" time). So, never depend on the timezone being preserved in web services. If you need to worry about timezone, transmit that as a separate field by itself. The nasty thing about this issue is that no automated tool can scan for this (it would have to flag every date/time field as an issue - which would be really annoying).
If you're trying to build Web services that are interoperable across platforms, hopefully you'll find these simple tips helpful. Of course, there are many other issues to contend with - for example, what rules can you use to maintain backwards compatibility of a service you're versioning and still have it be interoperable. We've worked out a set of rules we use internally for our own products, and I'll share some of these over time.
I read your comments and needed more information if you could provide. I am trying to make a service application which would talk to services created in .net on one server and services created in java on another server. This will allow the common interface to access the database of .net or java application and manipulate it. Now I may not be clear about this since I am still investigating interoperability between the two. Could you perhaps provide me with some links that demonstrate consumption of .net and java services from a common place and platform independent. Thanks for your time