Java Web Service framework/library, which is a better one and why?

Question

Currently I am evaluating number of web service frameworks in Java. I need web service framework that will help me to expose some functionality of existent application running on JBoss, The application is mostly developed using Spring and POJOs (no EJBs).

What I need is a framework having following properties:

1. It should provide tools for automatic generation of boilerplate code and save time by eliminating repetitive tasks, for example tools generating WSDL from Java (java2wsdl), tools generating endpoints etc.
2. Applications should be easily deployed on existent J2EE platform (JBoss), this means that it should contain as less as possible configuration files (like axis2.xml in axis2 framework).
   • Also it is preferred to be able to deploy web service within .war archive of existent application. (it seems that Axis2 need a separate archive for web service app.)
   • It will be very cool to use a combination of POJOs and Spring.
   • Generally, the framework should have clean structure and design (for example Spring-WS lacks it), good documentation and whatever else characterizes a good piece of software.
   • It is preferred that framework incorporates some standard features like JAX-WS etc. instead of vendor specific methods.

I have briefly examined

• Axis2
• Apache CXF
• and Sun's Metro
• Spring WS

But still it is difficult to decide what to use in my case:

• Axis2 seems to be so low level, it requires separate application archive and lots of configurations
• Spring WS seems to be too opaque and "sophisticated for impression purposes (?)"
• Apache CXF and Metro probably are two frameworks that I prefer to chose from but still

I need your opinion and experience about usage of some of them in a real-world applications.

Answer 1

I've used CXF's forerunner, XFire, for a while now and it's not been too bad. At the time, we migrated from Axis for two major reasons: performance and ease of development. At the time (don't know if this is true now), the performance of XFire was much better than anything out there, and with annotation-driven development, instead of having to run stub generation, it was really really easy to add new web services.

CXF seems to be more of the same but better - we haven't migrated yet due to constraints on development time as well as not having a pressing reason to do so (plus the relative lack of documentation 6-12 months ago wasn't too encouraging). Additionally I haven't really evaluated the market of late, so I can't tell you how CXF stands up to its contemporary competitors.

Regarding your points:

1. There is no boilerplate code to be generated, the WSDL is automatically created from the service class' annotations and published by the server.
2. Deployment in Tomcat was relatively simple. Just define another servlet in web.xml and map a URL pattern to this servlet.
3. Our web services were deployed in WAR files, I'm not sure what the alternatives are in fact but this seemed to be the default and obvious way to do it.
4. POJOs work fine initially; we've now moved most of the web service object creation to Spring in order to wire more complex conditional dependencies in and have had no problems with this.
5. Documentation was a weak point with CXF originally, though having just had a look it seems to be better now. The general design and architecture seems relatively sane; slotting in one's own filters to modify the transmission details was not very painful, and extending existing classes has generally been considered (so sensible methods are marked protected instead of private, for example).
6. JAX-WS is full supported in CXF.

So I'm probably a little impartial as I haven't tried the other ones, but I'll give a thumbs up to having a look at CXF. It's pretty fast, relatively simple to get going with and fairly powerful if you need to tweak it.

Answer 2

We have tried Metro and CXF and kept CXF because Metro includes too many dependencies like Sun's APIs in its jar files which makes it difficult to integrate in another application server than Glassfish. CXF has a cleaner packaging with explicit external dependencies. We also failed to enable Gzip compression with Metro while it worked like a charm with CXF.