Choosing Between Axis2 and XFire

Posted on: September 6, 2006 | Posted in: Web services

I used Axis 1.X in the past (not without some problems, but I was able to get the work done), and so when I needed an open source Web services stack, downloading Axis2 was my first impulse. Then, after playing with it for a short while, I had an afterthought and decided to look at XFire. I never looked back. Here are some things that made my decision not in Axis2 favor (there is actually a WS stack comparison on XFire site but I wanted to see for myself):

  • No JAX-WS or annotations support. I’m not even sure if Axis2 fully supports JAX-RPC for that matter, at least it was not obvious from the docs. I’m not a big fan of JAX-RPC (and who is?) but sometimes being able to use standard APIs is a plus.
  • Deployment model. Why invent a new “aar” archive type? So does it mean that now I have to run Ant (or the special AAR Eclipse plugin) to re-package my service every time I change a class? (It might be possible to put the exploded archive on the classpath but I did not try that.) How will this new component type integrate with app servers? How will the classloading work under different J2EE containers?
  • Data binding. It looks like there is some databinding support for the new AXIOM XML object model, but all examples use Axiom directly, so it was not very clear how to use it (at least not without resorting to WSDL2Java generator). Also, I don’t believe there is an ability to plug in different databinding frameworks such as Jaxb or Castor.

I’m sure Axis2 has a lot of good capabilities, its feature list seems impressive enough. But for now I will be sticking with XFire simply because it’s somewhat easier to setup, its API seems more intuitive, it integrates well with different conainers/app servers and also because of its JAX-WS support.

11 thoughts on “Choosing Between Axis2 and XFire”

  1. Agreed. The aar archive concept was too much for me as well. In addition, I found the documentation (including introduction/tutorial type articles) of Axis 2 very hard to follow.

    My development goal for selecting a SOAP stack was a document style SOAP service who’s responsibility was to just accept an XML document and forward it using JMS. For both XFire and Axis2, there seems to be a high emphasis of mapping payload XML to Java classes, their methods and arguments. Getting the raw SOAP content instead seems a challenge. At the end, I choose to just implement a servlet that modifies the SOAP header according to my software requirements and pushes the entire SOAP message into a JMS queue. Any comments or experience for this type of problem?

  2. Hi, actually the AXIOM in Axis2 gives very flexible way of handling raw xml, there is a rawXMLmessageReceiver there. If you find mapping payload is not desirable, just skip it in Axis2.

  5. To Marcel:
    Your needs can be etremely simple for now and so a servlet-based approach may suffice, however, in my view, it is still a mistake to mess with SOAP directly (that is, if you use SOAP). A WS engine (AXIS, XFire, etc) isolates you from SOAP headers and WS-* soup. What if your clients want to use WS-Security (at least, some aspect of it) or WS-Addressing in the future? How do you handle faults? How do you handle “mustUnderstand”? It can gets complicated pretty fast. However, if you control both client and server, then it’s a different story. In short, WS containers should not be viewed as purely XML mapping engines, they have much broader role. BTW, getting XML payload in XFire is extremely simple, you just specify XML source, DOM or JDOM document as a parameter type. JAX-WS also provides a mechanism for that.

  6. To Alexis MP:
    I think that RI and glassfish should definitely be considered, but this was just a quick a dirty blog entry, not a comprehensive market analysis. I did review RI some time back (http://myarch.com/jax-ws-and-annotations-looking-good) and overall found it a huge step forward from JAX-RPC RI. However, in my view, it still needs to catch up with XFire in the ease of use department. It’s not as easy to install and integrate with other app servers, code generation is still required in some instances (wrapped style). Keep in mind that this was a few months back, I’m sure many things improved.

  7. To Alexander Ananiev:

    Yes, The JAXWS 2.0 RI you tried was EA3 and since then it has came along quite a long way.

    Since then JAXWS 2.0 Final was released in June and JAXWS 2.1 is under active development.

    When I look at the WS Stack Comparison: http://xfire.codehaus.org/Stack+Comparison JAXWS 2.1 brings in most of these features and more.

    JAXWS 2.1 – an open source project at http://jax-ws.dev.java.net is architected for high performance, pluggability and extension. Various WS-* features, such as WS-Security,WS-ReliableMessaging, WS-Policy, WS-MEX, WS-Trust, WS-SecureConversation, WS-Tx(with GF v2), SOAP/TCP etc. These plugins are developed at WSIT – a sub-project of JAXWS at: http://wsit.dev.java.net and is available from jaxws download page:

    The other key features are:
    – Plugins thru Pipe and Message abstraction
    – Pluggable transport
    – SOAP 1.1, SOAP 1.2
    – WS-Addressing
    – Streaming MTOM
    – swaref and Mime
    – Uses JAXB 2.1 for all the databinding purposes
    – Stateful Web Services
    – Asynchronous Client and Server (under development)
    – Support for standards such as: JAXWS 2.0, JAXWS 2.1, WS-I Basic Profile 1.1, SSBP 1.0, AP 1.0 etc.

    Its worth mentioning that the entire JAXWS stack and WS-* features are regularly tested for interoperability with .NET 3.0.

    You may like to try JAXWS 2.1 from http://jax-ws.dev.java.net to see for yourself.

    Thanks,

    -vivek.

  8. I’m one of the core Axis2 developers. Here’s some more accurate info:

    – JAX-WS & annotations support: That’s not there in 1.1.1 but will be in 1.2, which is due in April.
    – No you do not need to create an .aar file and deploy it .. you can just copy the directory and deploy a service. Plus if you want more control you can totally bypass all that and deploy any way you want directly using the API.
    – Data binding: what you said is absolutely not true: Axis2 supports data binding via ADB (Axis Data Binding), XMLBeans, JAXB 2.0, JiBX. There’s also an example showing how to use Castor.

    Axis2’s core is designed to be an XML processing system. That doesn’t mean service programmers (such as yourself) have to be burdened with the data binding task unless you want to take it on. Its just FUD to think that Axis2 doesn’t support data binding.

    On the quality of the docs- Axis2 1.1.1 shipped with a totally rewritten user’s guide. If you see areas where its not clear please do report back via the user mailing list or JIRA.

    Thanks,

    Sanjiva.

Comments are closed.