We need impartial SOAP stack comparison

I've been asked by couple of friends who are evaluating different opensource Web services stacks, to be used within their projects. Since I've been an Axis2 developer for a long time it is fair enough to label me as biased.
But ... when I searched online for these comparisons I didn't see a single comprehensive comparison good enough to answer my fiends' questions. Most of these comparisons out there are

1. biased towards one particular implementation where the author is affiliated or "paid"
2. distorts certain facts about other engines
3. doesn't contain a full and comprehensive comparison.

These comparisons are similar to the benchmarks various hardware vendors provide highlighting the features of their hardware. But what I'm asking is a project (may be a good idea for a google summer of code project) where some one talks to most of the communities, at least major ones like Axis2, XFire, CXF, Metro, and then come up with a good document.

Having said that, let me answer some of the comments about Axis2 from my point of view, assuming these will be useful for a future impartial comparison.

• CXF has Spring support in-built in to it, which I don't think Axis2 has. Axis2 has spring support, but I don't think it has first class support for that.
• This thread mentions that Axis2 always has proprietary APIs and promotes JAX-WS, JAX-RPC etc. I agree to most of the points mentioned in that thread, but I don't think we need to have first class support for Java apis. Practically only few people care about it. All what matters for most of the developers is to get their Web service deployed easily or invoking a Web service very easily. I don't think they will want to learn one more set of Java interfaces to do that. Stubs and skeletons that Axis2 generates will be more than enough for their requirements, at least IMHO.
• This blog post highlights XFire for Spring 2.0 XML support, RESTful service support,JSON support, some of WS specs support as well.
  

Axis2 REST support

In Axis2, we are the pioneers of supporting REST with Web services. Axis2 was the first Web services stack to support standardised way of exposing Web services, using WSDL 2.0 HTTP bindings. During the last WSDL 2.0 interop held in France in 2006, only we had a full implementation of WSDL 2.0 HTTP binding. One would argue that this is not REST (which I also agree to some extent). But for most of the people REST is mostly XML over HTTP.
Again one might say no one uses WSDL 2.0. May be true, but we can use same methods to expose some of the Web services, even without WSDL 2.0, with REST.

Axis2 JSON support

Yes, Axis2 has JSON support. Not only that it has the flexibility of integrating with any type of transport (like HTTP, XMTP, XMPP, TCP, UDP, etc.,) or any type of message formating (JSON, XML, binary XML). Currently we have implementations for all of these. To give the proper credit, we initially evaluated XFire implementation for JSON support, but I'm not sure whether we ended up using it.

WS-* spec support

This is a very disappointing argument to say that Axis doesn't have WS-* spec support. Any Web services engine must have support for WS-* specs. This blog mentions that Axis2 has support for WS-* specs using add-on modules. Thats the whole point of Axis2. We didn't want to put all the spec implementations within Axis2 and I don't think anyone can do that. We wanted to provide a solid framework so that any spec can be implemented and that was one of the main design decisions we had since first Axis2 F2F.
One can write modules implementing various specs and just drop them in to Axis2, which I think is very cool. The same blog complains that one needs knowledge on ant to use Axis2. Yeah, I know people who know about Axis2 will laugh now. We auto-generate ant build files to ease the task of the developer to use the generated code. It doesn't mean one has to use it. Also using ant is so trivial and what is hard in it. If you don't like ant, I'm not sure how good you will be with C deevlopment with make files :)

At last, the only post I found interesting was from Bjorn. But I think it should be more comprehensive. All in all, I think most of the stacks provide almost the same thing. It all depends on the requirements, may be in-terms of performance, features, extensibility, APIs, etc.,
Even I agree that Axis2 is cumbersome to use for smaller tasks. I think that can be the reason why Amazon used XFire for their SOAP api implementation on EC2. Being open-minded rather than being restrained to a certain framework will always be good to get what you want.

(I hope no one will bile-blog after this and hoping to get constructive ideas on this matter)

Read more...