Top Ten Tips for Web Services Interoperability

I thought it might be fun to put together a “Top Ten Tips for Web Services Interoperability” – especially between .NET and IBM WebSphere, BEA WebLogic and some of the open source toolkits.  I’d love to add other people’s experiences, findings and comments to this list…

Here goes (from the bottom):

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.

Comments (9)

  1. David says:

    In addition to 3: Make sure you use Wrapped for your .Net server, not Bare.

    That is the easy solution, alternatively you can do this: Make sure you have exactly ONE parameter per operation, AND make sure that no two operations per service have the same type for that one parameter. Yes, Wrapped is easier 😉

    This again is required for WS-I BP compliance with the (awful) R2710 and R2712.

  2. Billy Lo says:

    A few others that I learned from experience:

    1) avoid fancy xsd features (union, list, choice, attributeGroup)

    2) remember that <xsd:restriction> are not enforced at runtime. No schema validation for both .NET and WebSphere

    3) use elementFormDefault="qualified" all the time (I ran into some problem during .NET 1.0 days with empty namespace)

    4) avoid overloading method names

    5) beware of case (in)sensitivity in specific languages and reserved words

    6) remember that the client and server can be in different timezones. this can present problem when you need to present date/time on the .net client using the server’s timezone.

    7) this one is Java specific: if you do bottom-up (java2wsdl) with arrays, make sure your java class follows the javabean convention (i.e. must implement the indexed accessors.)

  3. Top Ten Tips for Web Services Interoperability – Simon Guest

  4. Number 1 for all Microsofties: Do NOT send DataSets.

  5. nice list: Top Ten Tips for Web Services Interoperability (via Sascha)…

  6. Anonymous says:

    Web Services Group : : ?????????????????? &raquo; Top Ten Tips for Web Services Interoperability

  7. Anonymous says:

    Web Services Group : : ?????????????????? &raquo; Top Ten Tips for Web Services Interoperability

  8. Started this morning in easy mode with a few hand-on labs focused on Visual Studio 2005 TS. Al worked…

  9. Started this morning in easy mode with a few hand-on labs focused on Visual Studio 2005 TS. Al worked…

Skip to main content