in Web Services

Axis2 and the Let Us Repeat Success Strategy

Sanjeeva Weerawarana of Axis-fame gave a candid and somewhat introspective talk on Web Services Middleware a few weeks ago at Google. The talk was mostly about the history behind SOAP and WSDL, about how Axis1 was designed, how Axis2 is radically different, and the grand scheme of things around Axis. A video of this talk is available at http://video.google.com. This is a talk worth listening to. Sanjeeva does a good job at summarizing things around SOAP, WSDL and Axs. Based on his overview, and my own limited experience, I think Axis2 is based on a good architecture, but it may have come late to the field, and with lots of bugs and compatibility problems.

It is amusing to watch one of the SOAP-proponents admit that “letting a Java class be turned into a web service” was a big mistake. I must congratulate him for being so candid about it. He also points out that every web services stack worth a name now follows the same paradigm – write a Java class, click a few buttons, and out comes a web service – to become part of a grand SOA soup. Of course, this approach demos well – marketing folks love this kind of stuff. JSR 181 takes it one step further by letting you add Java annotations to Java classes to turn them into a web service. I bet this class-first approach will turn out into a nightmare once the service is put into serious use. Well – it is too late.

Coming back to Axis, IMO, Axis 1.x was good enough for most applications. It promotes the class first approach, has a built in Java-XML binding framework, and works reasonably well. It was widely used, and most bugs got fixed over time. May be having Java-XML binding at the core was a mistake – but who cares – most developers write code using the generated beans anyway. Apparently this was not good enough for some, and Axis had to be rewritten.

I’m not a big fan of rewriting software for architectural reasons. Just because the original version was successful, it is naive to assume that the rewrite will be equally, if not more, successful. Moreover, rewrites usually break feature, API and bug compatibility – and Axis2 did that completely.

Here is my personal experiece with Axis. Our team at work uses Axis to drive some web services for testing our product. Our experience with Axis versions upto 1.3 was satisfactory. We did generate POJOs from a WSDL and schemas, and wrote test clients using the generated code. Then came a new version of the WSDL, and Axis 1.3 could not handle that. We ran into some serialization bugs, and so wanted to try 1.4. No luck with that either. Then we tried the all new Axis2. What a disappointment? It is completely incompatible with Axis 1.x at the source level itself. Moreover, it had new kinds of feature incompatibilities and bugs forcing us to hack it to make it work. Another consequence of this rewrite exercise is that bugs filed against Axis 1.x now go into the use new version please void.

To give a more concrete example, Axis 1 had a nifty little feature to let the stub instance replay cookie headers between requests. You just call setMaintainSession(true) on the stub instance. Internally, this class makes the stub capture all Set-Cookie headers from responses and send Cookie headers on future requests. You might ask why would I want to care about transport headers while writing web services. Well, web services is a leaky abstraction, and protocol agnosticism does not work in reality.

Axis2 supposedly has an equivalent of setMaintainSession(true. The equivalent is to do something like

Options options = new Options();
options.setManageSession(true);
ServiceClient sender = new ServiceClient();
sender.setOptions(options);

But this turned out be more complex than I originally thought. This was not a replacement at all. Instead of capture any cookie, Axis2 looks for some internal cookie named axis_session. I suppose that this is the name of the cookie that Axis2 may set on the server side. I was more horrified to see some WS-Addressing related code for session management. I have not spent enough time to make it work, but I came across some code using WS-Addressing for session management in Axis2. This is also confirmed by this article Axis2 Session Management.

There are few more stories about feature incompatibility. See [axis2] a little frustrated for example. (Thanks to my colleague Nate Lipke for forwarding this link.)

One last comment about Axis2. Right now, it does not implement JAX-WS and related specs, making it even harder for JEE fans to consider using Axis2. I wonder why Axis user community (including some corporations who built their products on top of Axis) did not speak up against the rewrite idea. Oh well – repeating a success story is such a bad idea.

P.S.: Just to spice your reading experience up a bit, also check out The S stands for Simple.

Write a Comment

Comment

  1. I think you missed the point about axis2 .. it wasn’t rewritten to beautify the underlying architecture. It was rewritten because axis1 isn’t capable of supporting other WS-* specs properly. Plus it performs a lot faster than axis1.

    BTW did you try version 1.1 or 1.0? We know 1.0 had some problems for sure and a lot of those were fixed in the new release. Version 1.1 also has a partial axis1 compatible codegen mode to make porting easier.

    Sessions- setMaintainSession does support http sessions. If it didn’t work for you please file a bug report- open source projects improve when users report bugs, not just blog about them. Same goes for the other bugs you ran into.

    Thanks for trying axis2- I hope it will end up working for you.

  2. Thanks for your comments. May be Axis2 does perform better while supporting latest WS standards, but I don’t think it is impossible to make these changes without breaking bug/API/feature compatibility. It may be more challenging to do so than rewriting from ground up, but it is worth it, given the pain rewrites cause.