Amit Chawla DotNet: All and Sundry

The last time I did any significant Java was in 2001 when I wrote an object bridge to integrate Microsoft COM+ technology with CORBA objects. Back then I was purely a Java guy. It was a rather sweet feeling to be able to accomplish the task. I used the combination of VJ++, IDL2Java compiler and Remote Method Invocation (RMI) technologies to accomplish that. It wasn’t straightforward.

Cut to 2008. The technology world has moved on. The way we do B2B today is by using Simple Object Access Protocol (SOAP). The key is the word, Open. Open, as in Interoperable. Interoperability is not that difficult to achieve, but it is still easier said than done. 

One of our vendors needed to integrate with our externally facing web services written in .Net. The technology they were using was a combination of Java 2.0 and Axis2.  There were issues. Admittedly, our WSDL interface, while fully interoperable, is rather complicated. It uses every conceivable XSD construct. Complex Types, Inheritance, Choice, Restrictions, Enums, Type Substitution (late binding) and so on.

Wsdl2Java

Axis2 comes with the WSDL2Java tool that generates Java classes based on the WSDL endpoint. WSDL2Java has plethora of command line options. As a result of that, this tool can produced highly configurable source code. It also gives you an option to generate code targeted to multiple XML parsers in order to perform XML -> Java -> XML data binding. In .Net we know this as serialization.

ADB

This is the default option and produces proxy (stub) code that targets the adb parser libraries. The problem with adb is that it is buggy. The code generated does not understand xsd type substitution, can have ambiguous type references  (non fully qualified), does do null checks objects before accessing them, and prints out a frivolous <toMakeJavaBuildDoNotUse> tag. (At least, these are the problems I ran into). While these problems are fixable, you still need to do fair amount of hacking in the generated code in order to get the correct request and response serialisation. In order to work with adb, you will need to provide the classpath reference to the axiom-api, axiom-dom and axiom-impl JAR files. To generate proxy/stub code for adb, use the following wsdl2java command line:

C:\> wsdl2java -uri webservice.wsdl

JAXB

This is another popular parser you can use with Axis2. Using jaxb produces a lot cleaner code. Organises code nicely under a sensible folder-structure. However, it cannot do ONE thing. The code does not know how to interpret XSD type substitution. Have a look here for more detail on type substitution. In order to use jaxb in your code, you will need provide the classpath reference to the jaxb-api.jar file in your project. To generate proxy/stub code for jaxb, use the following wsdl2java command line:

wsdl2java -uri webservice.wsdl -d jaxbri

XMLBEANS

This is by far, the most advanced XML parser / binding framework available in the Java land. It produces code that is nicely organised within the src folder. It also produces resources that contain the schemaorg_apache_xmlbeans folder and sub folders with a whole lot of complied xdb files. The resources folder needs to be in the classpath. The jar files needed for xmlbeans are, xbean_xpath.jar, xbean.jar, xbeans-qname.jar. To generate proxy/stub code for xmlbeans, use the following wsdl2java command line:

wsdl2java -uri webservice.wsdl -d xmlbeans

Conclusion

The world has indeed moved on from arcane proprietary remote object access protocols, such as, CORBA, DCOM, RMI. SOAP is indeed the best way forward.  When building a Java client for a web service, my platform of choice is Axis2 with xmlbeans. Simply because it produces correct target XML and can deal with complex XSD constructs.

Filed under: Technology