Axis or Axis2

[Ice Penov]

Hi, guys.

I'm working on a project that I'm trying to make it as scalable and interoparable as possible. I had no previous knowledge of Web Services(only conceptual knowledge) and after digging deeper into the topic, I realized that application of Web Services in my project would be very appropriate.

In shortage of time, I've tried to propel myself into this technology and get only the knowledge I need to apply it in my project. In the past few days, I read 3-4 chapters of the Java BluePrints book related to Web Services, that gave me an overview but nothing concrete( although the book as a read is great ).

Later on, someone told me that there are tools that will make my life easy and help me develop and deploy Web Services with ease. I downloaded Axis , configured it, read the manuals and starting plugging the business logic.

Today, I discovered that there is Axis2 and that it is completely different from Axis !

Before completely loosing my temper and kick something, please, for Gods sake, answer me this questions :

Can I use Axis(not Axis 2) without suffering performance loses and risking interoperability in the long term ?

Can someone briefly describe the conceptual differences between Axis and Axis 2 ?

Are there other tools that I should need to know about when working with Web Services ? I already have jUDDI.

Ladies and gentleman, Thank You in advance.

[Ulf Dittmer]

Both Axis1 and Axis2 support the relevant standards (SOAP, WSDL), so in terms of interoperability there should be little difference. As to the other differences, the Axis2 documentation talks a bit about that. Performance is one of the areas that was improved, but Axis1 wasn't all that bad to begin with, so make sure the difference is noticeable in your situation before making a decision based just on that. I'd recommend sticking with Axis1, because it supports a number of things that Axis2 does not yet have, and has been through years of bug fixing.

As to other software, jUDDI is generally not that important (unless that's a specific requirement you have). If you're serious about security, you might want to add WSS4J, which implements the WS-Security standard on top of Axis.
[ October 21, 2006: Message edited by: Ulf Dittmer ]

[Ice Penov]

Thanks for the response and the link to WSS4J, Ulf. Although I'm serious about security, I'm not paranoid about it . Maybe I'll incorporate it under certain situations.
[ October 21, 2006: Message edited by: Ice Penov ]

[Peer Reynders]

As Ulf said it�s probably better to stick with Axis 1.x for now unless you have a very compelling reason for using the much more immature (and hence risky) Axis2 implementation. The data marshalling and unmarshalling cost will always be �significant� and you may find that you can gain more by making your interface sufficiently coarse-grained rather than switching to a new, elusively more-performant API.

It seems that sometimes preference is given to JSR 224: JavaTM API for XML-Based Web Services (JAX-WS) 2.0 (which Axis2 strives towards) because of the inclusion of JSR 181: Web Services Metadata for the JavaTM Platform because it makes the development "easier". However in many ways JSR-181 is aimed towards "relieving the developer of the burden of learning XML and WSDL". In many ways this seems to be as misguided as using entity beans so that your Java developers don't have to wrap their heads around the relational paradigm, databases, learning SQL etc.

Web services aren't really an ideal RPC mechanism - there is an "object-hierarchical impedance mismatch" between Java and XML, just as there is an "object-relational mismatch" between Java and relational databases.

So really Web services need to be treated for what they are - an exchange system for XML documents. Therefore one key towards an interoperable web service is to design the service XML/WSDL first (i.e. define the interface first). Then use the tools of your SOAP stack to generate the server/client stubs to hook up your service implementation against. That way your clients can "choose" how to interpret the XML directly, rather having to deal with an XML representation that is potentially obscured by the Java-to-XML translation (regardless of how standardized the rules of Java-to-XML mapping may be) .

Toufic Boubez Q&A - "WSDL tools an abomination" (language to WSDL tools that is)
Tech Talk: Ted Neward on Web Services and Security

Interestingly enough even Axis2 does not yet support JAXB 2.0 (experimental support will start in Axis2 1.1) even though Sun uses it as the standard XML data-binding API in Java 6 SE.

When using Axis 1.x you may want to observe the following points:

Stick to literal, i.e. no encoding: SOAP or otherwise.

Prefer Document over RPC style messaging if at all possible.

Make sure your WSDL is compliant with the Basic Profile

Patterns and Strategies for Building Document-Based Web Services
Server Side Commentary

Given your situation I would try to see if the following tactic is workable:

Design your XML Schemas for your documents first and incorporate them into your client exposed WSDL. Find an XML-tool that supports this type of activity. XMLSpy from Altova might be a good place to start.

When you are happy with your "interface", doctor the resulting WSDL so that your SOAP payload is simply a string. The idea is to leave all the SOAP stuff to Axis while you retain control of the XML to Java binding. Use WSDL2Java to create the server stub from the doctored WSDL.

Use JAXB 2.0 to do the XML-to-Java mapping of the SOAP payload. JAXB can take advantage of the schemas that you have created and you can use the JAXB mapping configuration to steer the mapping towards your own object representation. Its up to you if you want to use the resulting Java-objects directly in your service implementation. However it is probably wiser if you stay decoupled from the generated objects. But at least you can influence JAXB to generate an object representation that will minimize the necessary glue code. Alternately, if you are lucky enough that you can map the XML-data directly onto your own objects with JAXB or any other XML-to-Java mapping technology - even better. The XML-to-Java-to-XML mapping can also be independently reused for a potential XML-over-HTTP or even a REST-style interface.

Of course this approach is not necessarily "easier" in the short term but it may make it easier to drop in a new web service interface once things settle down a bit more.
[ October 22, 2006: Message edited by: Peer Reynders ]

[Ice Penov]

Peer, thanks for the detailed reply!

It was *very* helpful and just confirmed my views. Now I know that I'm probably 'thinking in the right way' and I feel kinda releived.

To cut the story short, I'm going 'the safe way' with Axis 1.x and using design approach and views similar to the ones you posted in your reply.

Thanks again,
Ice