Tuesday, December 19, 2006

WebServices --- Java/.NET interop issues

I've been working on a project where I need to port an existing service written in C# to Java. Your first question would be -- WHY ?? One should be able to access the service irrespective of the language its written in; So whats the point in porting a .NET service to Java ? I am not too sure about this, but I think the client wants all his applications in one language, so that its easy to modify it as and when needed.

With that answered, one would think its pretty much straight forward to port such a service. After all Java and C# have similar frameworks/libraries and constructs. Well.. that’s where most of us go wrong :(. Let me explain ---

This service is currently used only by .NET clients (but would soon be used by Java clients too). Many methods of the service return .NET specific data types like DataSet. This works fine with .NET clients since DataSets are serializable. When you come across such a method while porting, you realize you are pretty much screwed. Java doesn’t understand DataSets !! So, this is what we did -- we wrote a class which contains the following:-
1) Column names array (from the ResultSet metadata)
2) Column types array (from the ResultSet metadata)
3) Array of rowData objects ( each rowData object is an array of column values obtained from the resultSet)
4) Table name (required by DataSet)

An object of this class can be serialized and sent across to the client. On the Java side, you can create/generate this class and use it to read the results. On the .NET side, you can set the metadata and rowdata objects to a DataSet and also set the table name. You could then use that DataSet as before.
We could not return a 2 dimensional array of values (instead of array of rowdata), since we had problems deserializing the 2 dimensional array on the .NET side.

There have been quite a few such issues over the past couple of weeks, and I am sure there are more to confront. I’ll post again when I come across such issues. Btw, if you are designing web services with Apache Axis, do take a look at their wiki page for .NET interop issues ---> http://wiki.apache.org/ws/FrontPage/Axis/DotNetInterop

Some points for making interoperable services. Please avoid the following (taken from the wiki) :-
* Standard Java Collection classes.
* Typesafe enumerations. Use static final variables within Java instead.
* Multi-dimensional and jagged arrays.
* Sparse arrays (allowed in SOAP 1.1, not in SOAP 1.2).
* The Java char datatype is not supported because of an omission in XML Schema.
* Avoid using the same method name multiple times with varying parameters on a web service.


One last point --- If you are using Axis, please start with the WSDL first. Do not generate the WSDL from your classes/interfaces. Its a BAD idea !! Doing the WSDL first would help you comply with the W3C xml standard types, so you'd be almost guaranteed to interoperate. Unfortunately, we learnt it the hard way :(

3 comments:

Anonymous said...

You mention several things not to do or to be aware of, but you don't explain what trouble they may cause should I use, say java standard collections.

Chirdeep Shetty said...

You could use Java collections on the service, but the problem occurs during (de)serialization.
lets say you expose an ArrayList over a WS interface. Axis would serialize it as a complex type with an element name and min and max occurs tags -- something like this (just to illustrate... may not be what axis generates)
"<" element name="value" minOccurs="0" maxOccurs="unbounded" "/> "
On the .NET side this would not necessarily deserialize to an ArrayList. It would deserialize to a custom object, which is very similar to an ArrayList in structure (or proabably an array). You would then need to convert it to an Arraylist if needed. You could also write a custom serializer/deserializer to do the same.
I would much rather convert the ArrayList to an Array on the Java side before sending it over.

Vikas said...

This is the reason that I try to avoid dataset. Nice Workaround.


http://vikasnetdev.blogspot.com/2006/09/why-do-i-perfer-custom-collection-over.html