Library to create java stubs for webservice.

Question

Hello.

I would like to know if anyone can recommend a good library to generate java webservices stubs as clients.

Currently I'm using a product which has embedded a generator which only needs the WSDL and then creates the needed classes and methods.

My problems is it throws warnings and doesn't create any method for some webservices I'm trying to use.

The real problem is it doesn't explain what the problem is ( so I can go with the owner of the webservice and have it modified ) nor let me modify the ouput so I can probably fix the problem my self.

Yet, the owners of the webservices ( because this happens with several different ws ) say their ws runs fine and actually if I use soapUI they actually work!!!

I took a quick look at the libraries used by soapUI it self and I looks promising.

I know there is Axis which should do the work, but my concern is that my failing generator is using that library already ( which makes me thing it will fail again )

And lately I don't know if these two libraries generate the java source stub or only have methods like

Object [] args = ...;
service.inkvoke("updateCustomer", args );

When what I would like to have is something like:

CustomerWs cws = ....
cws.updateCustomer(custId, custName, custAddress /*etc*/ );

So, anyone has a GOOD ws stubs generator that can recommend?

_{I'm about to handcode my own, but it will definitely take several days to be acceptable}

Answer 1

Apache Axis 2 is the way to go... though you may need to play around a bit to get it right. It is perhaps the most common way to do it. Perhaps the tool that you are using is based on Axis 1?

Answer 2

The latest JAX-WS as part of metro (http://metro.dev.java.net) is a pretty nice abstraction layer. Takes a little adjusting to but it was a lot more intuitive to me than some of the other options out there.

Answer 3

What are you currently using? I use Axis Wsdl2Java as an Ant task. It generates the types of stubs you want. Works great, though setting up the classpath for running the build was a bit of a pain in Eclipse (there were a handful of jars I needed to track down and include). In my ant buildfile it looks like this:

<taskdef name="axis-wsdl2java" classname="org.apache.axis.tools.ant.wsdl.Wsdl2javaAntTask" />
<target name="foo">
<axis-wsdl2java
              output="${build.dir}"
              testcase="false"
              verbose="true"
        typemappingversion="1.2"
              url="http://ws.domain.com/url/of/WebService?wsdl" />
<!-- Compile, etc... -->
</target>

Answer 4

Be really careful when you refer to "Axis": Apache Axis 1 was abandoned in early 2006 with thread safety bugs leading to deadlocks and CPU spins (both of which we experienced). You will deeply regret using it. Apache Axis 2 is a complete rewrite and may be worth a look. But I would suggest you first look at Apache CXF and Glassfish Metro.

Update: Here are bug reports on the deadlock and 100% CPU spin. Here is Cyrille Le Clerc's proposed patch of three years ago, never committed.

We eliminated our deadlocks and spins by recoding our client in straight Java. And then the Axis server refused to talk with us, sending back HTTP 500 errors. We needed to falsely claim we were a Axis client to get a proper response. SOAP interoperability was not a priority for the Axis 1 team.

Answer 5

I like Apache CXF - it integrates nicely with Maven through a plugin, and it does it work. I have been using it for a while for client stub code generation, and in the last company I worked they were using it for the server part of the WS's too.

In the last projects that I worked on with CXF + Maven + Subversion, we didn't include the generated classes in Subversion, only a copy of the WSDL file - the stub classes were generated in the "generate" goal of Maven.

Answer 6

I would definitely suggest using something based on standards based API's. That would mean JAX-WS API's. Apache CXF and Metro are the two main JAX-WS implementations, although JBoss has an implementation as well. Axis2 has a non-certified implementation, but no code gen support.

The best part of using a standards based API is if you DO run into an issue with on product, you can try the other. In many cases I've seen, the other product also doesn't work, but will spit out a different error message or similar that helped diagnose the fact that it really is a problem in our own code or wsdl.

Also, JAX-WS is built right into Java6. If you are planning to run on Java6, you could use it and not have to deal with extra jars and such.