My day to day tasks involves a lot of Web Services ;) sometimes, I encounter strange things, I've recently found some cool things to share in the team, but I am just waiting for team to provide some inputs. Once I see some more articles from you guyz, I'll put them online. As of now read some tips for Web Services Interoperability
Look at this:
10. Watch out for Empty Arrays
Sending empty arrays over Web Services can create issues – some toolkits recognize an empty array as a single null value. If you are sending arrays of objects over a Web Service, always ensure that the array contains valid data.
9. Use Package and Type Name Options when Generating Client Proxies
Many Java based tools have the option of specifying a unique package and type name when generating client proxies (for example, BEA WebLogic uses clientgen parameters to do this). This is essential when you are creating proxies for Web Services that share the same data type.
8. Testing Generated Java Beans for Null
When using tools or an IDE to generate Java Beans from an XSD file, always make sure that you know how to test to see if the object is null. In some instances this is done using the isNil() method on the bean itself.

7. Null Dates and Times are recognized by Java, but not by .NET

In Java, java.util.Date and java.util.Calendar are classed as reference types. In .NET, System.DateTime is considered a value type. Reference types can be null, whereas value types cannot. If you are planning to send null date values across a Web Service, always send the value in a complex type, and set the value of the complex type to null. This will help prevent the null date value being interpreted incorrectly (and raising an exception).

6. Always use compareTo() when comparing dates/times

If sending dates and times over a Web Service between .NET and Java, always use the appropriate compareTo() method in Java to compare dates (as opposed to date == value). This will help ensure accuracy for date comparisons between the platforms, especially when trying to compare those milliseconds values.

5. Use Trace Tool to Investigate

A Trace Tool can be invaluable for investigating SOAP requests and responses between Web Services. It can help validate data types and the construct of the message, and also report SOAP faults that you may miss in a browser. Using one that intercepts the request is more difficult to setup, but easier to use than looking through trace files

4. Add Option to Change Host and Port

When designing your Web Service client, consider adding a helper method to change the host and port values of the Web Service location. This makes it easy if the location of the Web Service changes in the future or you want to redirect the output to a trace tool.

3. Ensure Document/Literal when generating Web Services

Many toolkits have the option of choosing either RPC/Encoding or Document/Literal as the default format when generating Web Services. To help ensure compliance with the WS-I Basic Profile 1.0, select Document/Literal as the default encoding mechanism for all of your Web Services.

2. Use Unit Tests to Test Interoperability

Unit tests (using NUnit for .NET and JUnit for Java) are invaluable for testing interoperability of multiple data types over a Web Service. Re-running the tests if data types change (or if you change versions of Web Services toolkits!) will give you the confidence that the Web Services that you design are fully interoperable.

1. Use XSD First

When designing for interoperability, always start with defining the data first. Deciding on what data will be sent, creating the data type in XSD first, and then using tools to generate classes from the XSD file will help guarantee data type interoperability on the wire.

Source URL : http://blogs.msdn.com/smguest/archive/2004/08/12/213659.aspx