Changing of the Guard: AXIS out, JAXWS in


I have come to a conclusion: I no longer want to deal with the hassle that has become Apache AXIS.


Back in the day, when interconnecting Java to .NET was still novel, I started using Apache SOAP to show how interop between .NET and JAva was possible.  I was looking for something simple and easy, something that would allow interconnection without a ton of pain.  Apache SOAP was that thing.   But Apache SOAP was brittle.  It had scads of problems with xsi:type and SOAP Section 4 encoding.  I needed something more flexible, something easier.


Then came Glue from The Mind Electric.  Glue was the easier, more flexible web services stack.  It was simple.  It worked.  It was actively maintained. Graham Glass came regularly to Redmond to make sure the interop with .NET was good.


Then TME got bought by WebMethods, and Glue disappeared.  I needed to pick a new Java stack. When AXIS came out, I switched, looking for better tools, and something that would be reliable, maintained longer term. 


At that time, I looked at Sun’s web services stuff, but it was always bundled with a Web server or Open Office or a Sun Ray or something else from Sun I didn’t want. It was like Scott McNealy’s proverbial furball.  I just wanted a working web services stack, I didn’t want to buy a Solaris Server.  I didn’t want a furball.  So I went with AXIS.  I could use it on Tomcat, on JBoss, or on Jetty. I could use it client or server side.  I wrote a few pages on the AXIS wiki, specifically around how to get it to work with .NET. I sat on the AXIS users mail list, responded to interop questions.


AXIS (Version 1) worked great for a long time, still does in fact. It has connected to many different endpoints for me – Excel Services, WCF endpoints, .NET, SQL Server, and many other pieces.  It was neat and clean; the tool options made sense.  The code it generated was pretty clean. 


But AXIS1 is no longer being maintained.  Any new standards (like MTOM – heh, new since 2005) will not be supported in AXIS1. Also, it didn’t work so well when it came to connecting to Exchange. AXIS2 likewise. And that allowed me to step back and re-evaluate.  AXIS2 is current, but has become very large, the doc is poor, the support is invisible, the generated code smells, and the seams are everywhere.  Fifty nine jar files?  Really?   Do I need this hassle?  With JAX-WS, do I need AXIS any longer? I think not.


I’m switching to JAX-WS


This is kinda backwards, because my goal is to show customers that they can in fact connect disparate systems together.  Given that goal, my own interests should rank near the bottom in the list of criteria for selecting a web services library.  It should be – what are customers using?    What do customers want to see?  But I honestly cannot believe customers will continue to put up with the furball that AXIS2 has become.


And if I am in a position to make a recommendation, I will recommend JAX-WS.


It works. There is a single runtime jar file. The tools are better.  The interop is good. It’s fast.  I’m happy.


I’m changing my decision but I haven’t changed my criteria.  I still want something that just works, simply.  Basically I want the closest philosophoical equivalent of .NET, but in Java.    AXIS used to be that.  Now, JAX-WS fits that bill.


I still love .NET and WCF.   But if I need to connect to .NET from Java, I will use JAX-WS. 


 

Comments (5)

  1. "Fifty nine jar files?  Really?   Do I need this hassle?"

    My sentiment EXACTLY!! Thank you! It’s so nice to know that I’m not the only one who is FED UP with the crap that is Axis2.

    I maintain a few Axis web services and they seem to be in good shape. But I am tired of the circus that Axis2 has become.

    If web services are all about interoperability, maybe the Axis2 team needs to go back and remember that themselves. I can’t get any client except an Axis2 client to talk to an Axis2 service. Maybe it’s me…maybe it’s the service…but maybe, just maybe, it’s Axis2.

  2. Harel says:

    "Fifty nine jar files"

    The large number of jar files is a result of using Maven and breaking the functionality into smaller components.

    (They can just as well toss it all into a one big jar file)

    It’s true that Axis2 is a bit bloated if you just need the core web services, but I prefer their maven driven component approach design as opposed to monolithic design.

    btw, I am using Axis2 in a production environment with various clients consuming it.

  3. cheeso says:

    I’m sure that AXIS2 is being used, and I’m glad you’re getting a good experience out of it.  

    Isn’t there a major problem with the entire philosophy of Maven and the implications of independently versioned subcomponents?  There are too many moving parts, too many versioned components.  The test matrix is huge.

    When AXIOM or JAXB or XMLbeans or etc etc gets updated, how does one go and verify that everything is still working properly?  

    It’s Jar Hell, which I’ve written about before.  

    If the idea is that the 59  jars from AXIS will not be shared by any other system (thereby avoiding most of Jar Hell) , then it really SHOULD be a single monolithic jar.  

    Just my opinion.  I’m not an Apache member, I just use the stuff.