First of all, SOAP is not my web service protocol of choice since I think it is overkill for the most of applications. I prefer the simplest possible solution for the problem, but when the service that you need is only available through SOAP, you don’t have much choice.

The fact is that .NET developers like SOAP and use it as a de-facto the only way to expose their services. Simplicity to do so is certainly one of the most important factors in this decision. While there is nothing generally wrong with this, the simplicity hides some traps for those that don’t take care. One such trap is making methods return (or accept parameters) of general types such as ADO.NET DataSet (something like JDBC ResultSet in Java).

In order to explain what kind of problems you can expect in this case, let’s recapitulate the process of creating a Java client for arbitrary web service (using Apache Axis). Usually, you will get WSDL file from your service provider defining the service. Next, you will run WSDL2Java tool which will create stub classes that abstracts service methods and their arguments (and return values).

From that point on things are straightforward, since you are back in the Java world. Axis library did its job of abstracting the web service and providing you with ability to use regular Java objects to handle data through SOAP protocol.

In case that your service provider has chosen to pass DataSet objects through SOAP calls, the above scenario falls apart and you’re left on your own. The problem is that WSDL2Java tool cannot create proper stub classes for this general type, so you will get MessageElement object and you have to find your way to deal with it.

There is even an MSDN article that suggests to .NET developers that these practices are bad and that they will lead to broken “toolkit-compatibility”. This particular article even suggests a few techniques that could be used instead of sending raw DataSets in order to avoid this kind of problems.

But if you have a web service that exposes DataSet in its interface and cannot change that, what should you do? Theoretically, solution is simple: all you have to do is to make your code know how to format and parse valid XML representation of DataSet objects. Since the MessageElement class that you will get by your stub classes is the implementation of the DOM Element interface, you can use the DOM API to finish this work. The hard part is that syntax of these datasets is complex. I found this article as a good resource for introduction to this topic.

So, if your potential service provider didn’t start work on its web service, make sure that he reads these articles so that you can save a few days of hard work. For all others, these articles could be solid guides for general direction of their solutions. I hope that there will be some tool available soon that will bridge this functionality (if nothing else, I’ll try to find some time to write one).