Recommended framework for Java Web Services

Question

With an abundance of frameworks and stacks for Java Web Services (Axis2, Spring WS, CFX, Metro, ...), which one should be selected for new projects? What are the pros and cons for each one? How well have they worked for you?

See related Q here

Answer 1

We are using a "Java first" approach. This means we generate our Java classes, and then use the web services framework to dynamically generate WSDL from those classes. The alternative is "WSDL First", where you use tools to generate Java stub code from the WSDL and XSD.

If you like the Java-first approach, I can recommend CXF as a reliable framework for quick creation of web services. It works well.

For now I have/had 3 issues with CXF:

1. One of pitfall that me wet was a data binding. Standard JAXB data binding works only in simple cases without additional tuning. Because of that we decided switch to native CXF data binding Aegis.

2. A minor but annoying issue exists with the use of Collections in a POJO classe exposed as a web service. Classes that you plan to put into Collections must implement Comparable interface otherwise you'll get a strange runtime exception.

3. You can't have both CXF and it's predecessor XFire library in your classpath. Not sure that it's important for you, but it can be sufficient for an upgrade from XFire to CXF.

And my last point that isn't directly related to CXF. If you plan to call web services through Mule 2.x ESB (as we are) you can find that it's not as easy as it was with Mule 1.x and XFire.

Update: New issue that you can meet calling WS throw the CXF API. If your WS is shielded by HTTP basic authentication (i.e. username and password) and you call WS using a dynamic proxy, you most probably will get a 401 error (authentication challenge). Workaround described here.

Regarding Spring WS, AFAIK it's wsdl first approach. If you like it, possible it's your case.

Answer 2

XFire, the precursor to CXF, is great for systems forced to use Java 1.4. I have no idea if CXF is any good, the whole API changed. XFire's API was much easier for me to understand compared with a cursory glance at CXF's API. However, you have to jump through hoops to override defaults in certain situations sometimes.

Answer 3

I personally use Axis 2.

For the pros it's very simple to write a service : create a class with method -> generate WSDL from Java (Java2WSDL in axis) -> generate client code (WSDL2Java) to deploy the service you can use the axis webapp (in any servlet container), package the service class with an extra services.xml into a file *.aar (the services.xml is not very hard to write) and put the service in the axis webapp (putting the file in the services/ directory or via an administration page in the axis webapp) For a simple webservice it's very simple

For the cons, well the documentation is not very reach. I had many trouble for implementation of WS-Security as the "rampart" module is missing example in my opinion, I had to buy a book...

Answer 4

In a recent project we are using Spring Web Services. I do like it - it is quite easy to use, well documented and flexible as well. Of course, it makes the most sense to use it if you are using Spring for your application, anyway.

I have tried Axis, Axis2 and Spring WS so far - I do like Spring the most and I think it is the easiest to use, once you understood how Spring itself works. (Except that you do have a nice "create webservice project with Axis/Axis2" wizard in eclipse, which you don't have with Spring.) Axis2 wasn't too well documented the time I tried it, but this might have changed.

Answer 5

I would recoomend axis2 IF you decide to use eclipse as your ide. Using the webtools project and the axis2 service archiver you have pretty much everything you need. You can simple write a set of functions you would like for your webservice and than generate a webservice, so there ist literarry no learning curve you write just the things you want and it works. The client is also simple, the only thing you will have to get your head around is generating a stub which will call your webservice. I personally tried CXF and axis2 is in my oppinion easier and more hands on approach.

Answer 6

A nice thing about Metro is the support for streaming large files, which solves a problem that is often brough up against Web Services in general.

Answer 7

I just came across a web service framework called enunciate from codehaus.

I've done a prototype application for work and REALLY like how easy it was, all the nice additional features & the configuration options.

Supports SOAP, RESTful and JSON endpoints. Generates tons of good documentation and a variety of client libraries for JDK 1.4, or 6.

You can choose which framework you'd like to leverage for the service - Apache, JAX-WS... I'm going to use XFire.

http://enunciate.codehaus.org

Check out the Getting Started Guide. Includes output samples and real-world examples, not just another Hello World

Answer 8

Jersey: https://jersey.dev.java.net/

I have not used it myself, but it seems very simple to get up and running.

Answer 9

Spring Web Service is good choice for new projects. It is easy to use and you can find lots of documents about it.

Answer 10

I've been using Spring Web Services (both client-side and server-side) for the past several months and have been pretty satisfied with it. Started with a schema and wsdl supplied by a third-party, so the contract-first approach was a natural fit. The documentation is reasonably good and the framework is pretty easy to use and configure. For my needs, using JAXB 2 and AbstractValidatingMarshallingPayloadEndpoint has worked well. I found the Validator component simple to use. I had a requirement to use an x.509 cert on the client-side, which was not too difficult to configure using the Wss4jSecurityInterceptor. The framework mostly abstracts away the underlying http layer, but at one point I needed to access the HttpServletResponse from my web services code to set an http response header. After a bit of searching, I was able to do this via the TransportContextHolder's getTransportConext() static method.