Web services interoperability between Java and .Net

This entry can be summed up in two statements:

Use doc/literal web services for maximum interoperability
Use NullableTypes on the .Net side to handle null values

My discussion here will be about providing a web service in Java and consuming it in .Net. These problems may not exist in other situations.

One of the problems encountered with getting SOAP-based RPC web services to work between Java and .Net is the difference in handling of null values. A null value in Java does not translate properly to .Net because value types in .Net (other than string) cannot be null (this should change in .Net 2.0).

If you provide an rpc/encoded web service in Java, .Net does not provide a way for handling null values and simply converts them to the default value for the value type (e.g. an int would be 0 for a null). As far as I know, there is no way to do something different in a proxy class generated by the WSDL.exe tool. I don’t know of any way to handle a null value in .Net for an rpc/encoded web service, but would like to know if such a technique exists. In any case, the growing trend is to use doc/literal web services for maximum compatibility.

For consuming doc/literal web services, .Net gives the opportunity (in the proxy code) to convert the value provided from a string to whatever type you wish (as long as the conversion from string to that type can be done). You can even convert it to a string (which is nullable). This is as easy as modifying the type in proxy code. Granted, it is an extra step to perform after generating a web reference, but it can be automated using a Visual Studio Add In or a simple sed script. In either case, it’s best to search and replace using search terms such as:

(int
, int
public int

Although the two obvious options, using strings (since they are nullable) or writing your own custom code that translates the string to a value plus a boolean to signify null status, are both viable options, one pushes the task of conversion off to the caller and the other is both ugly in implementation and also for the calling code. Instead, I recommend checking out NullableTypes. This project provides nullable value types that can be used very easilly in a web service proxy. For example, a sed script to make the appropriate modifications to Reference.cs may look something like this:

s/(int/(NullableTypes.NullableInt32
s/, int/, NullableTypes.NullableInt32
s/public int/public NullableTypes.NullableInt32
s/(long/(NullableTypes.NullableInt64
s/, long/, NullableTypes.NullableInt64
s/public long/public NullableTypes.NullableInt64
s/(System.DateTime/(NullableTypes.NullableDateTime
s/, System.DateTime/, NullableTypes.NullableDateTime
s/public System.DateTime/public NullableTypes.NullableDateTime
...

Note that if you are returning nulls from Java doc/literal web services, you have to do something on the .Net side, otherwise it will throw an exception. This is different from .Net’s rpc/encoded support which simply ignores null values and defaults the types. Also note that if you are using Apache Axis, you will want to use style=”wrapped” use=”literal” in your service configuration for your RPC web services. Also, for Axis, be sure you get the namespace configuration right, otherwise you may have problems if you follow the typical examples (which generally only work for rpc/encoded). See the example from this page for a working wrapped/literal Axis configuration.

See these pages for more information on .Net/Java web service interop:

Nilesh D Kapadia

Web services interoperability between Java and .Net