Appendix A. Limitations of Apache Axis

In most ways, Apache Axis is a very successful open source project in Java. Axis 1.x is probably the most widely used Java-based SOAP toolkit that is not tied to any particular J2EE application server. Unfortunately, Axis 1.x suffers from limitations that make some of the example code in chapters 6, 7, and 8 fail. In this appendix, we will describe these limitations. We will also briefly describe a new generation of Axis, Axis2 and tell you what you can and cannot do with it right now.

A.1. Buggy implementation of W3C DOM API in Axis 1.x

Axis does not correctly bind data in a SOAP message to an object tree as defined by the W3C DOM API. This causes failures in other XML-processing libraries (such as XPath interpreters and XML encryption/signature libraries) that assume a W3C DOM-compliant object tree. We have reported two such issues as AXIS-2125 and AXIS-2163 in the Apache bug database for Axis 1.x. In the rest of this section, we will explain these issues in greater detail.

SAAJ provides a standard API for programmers to create, parse, and manipulate SOAP messages. You have seen the use of several classes defined by this API in the code examples discussed in chapters 2-8. The SOAPMessage, SOAPPart, SOAPEnvelope, and SOAPElement classes from the javax.xml.soap package are all defined by SAAJ. Axis 1.x supports SAAJ APIs alongside its own custom APIs for dealing with SOAP messages programmatically.

SAAJ allows programmers to deal with data in a SOAP message as if it were a tree of objects. In other words, SAAJ provides its own DOM API for dealing with SOAP documents (messages). For good reason, SAAJ allows programmers to use either or both of the following DOM APIs when dealing with a SOAP message:

1. One is SOAP-specific, making it easy for developers to deal with SOAPlevel constructs. This API is defined by SAAJ itself using classes such as the ones listed previously in this section.
2. The second is the generic W3C DOM API that is defined independently of SOAP to manipulate any XML document:

There is a reason why SAAJ allows the use of generic W3C DOM API. Given W3C DOM’s large mindshare, which comes from being the first to market, W3C DOM API is still the lowest common denominator that most XML-related libraries assume. Programmers using SAAJ also often need to use generic XML-processing infrastructure such as XPath interpreters and the XML Encryption/Signature libraries. This infrastructure currently assumes the availability of an object tree that can be inspected and modified using the W3C DOM API.

For historical reasons, W3C DOM API is filled with a large number of methods that overlap in functionality. This makes W3C DOM API implementation a very tedious for task developers. Axis developers avoided some of this tedium by using tricks that pass the examination of a Java compiler and the Axis unit test suite but fail when exercised by arbitrary code.

In Apache Axis 1.4, if you inspect the source of the getAttributes() method in the org.apache.axis.message.NodeImpl class, you will find that attributes of an element (only element nodes can have attributes) are not created with the right ancestry. The attributes returned by node.getAttributes() are not created in the same document as the node to which they belong! Instead, the attributes returned by this method are created in a dummy document. This results in the situation shown in figure A.1.

Figure A.1. Faulty W3C DOM structure created by Axis 1.x. Observe that attributes belong to a dummy document and not to the SOAP Envelope document.

Problems such as these trip up the code in XPath interpreters and the XML Security libraries we use in chapter 6, 7, and 8.

A.2 Axis2 does not support JAX-RPC handlers

The Apache Axis team has recently released a new generation of Axis named Axis2. Axis2 seeks to deliver much higher performance than Axis 1.x by taking advantage of improvements in XML-parsing technology. Axis2 also supports asynchronous interactions by nonblocking clients. These and a number of other improvements make Axis2 technically superior to Axis 1.x.

Axis2 is not as widely adopted as Axis1.x for the following reasons.

• Axis2 reached the 1.0 milestone quite recently. It will be some time before mindshare of Axis2 in the development community reaches anywhere near that of Axis 1.x.
• Axis is not backwards compatible with Axis 1.x. The packaging and configuration mechanisms are quite different in Axis2.
• Support for JAX-RPC/JAX-WS standards is partial. JAC-RPC/JAX-WS handlers are not supported. Axis2 does provide its own handler API, though.

In spite of all the differences between Axis 1.1 and Axis2, working with Axis2 will not prove difficult for readers of this book. In fact, the same should apply for users of any web services toolkit, not just Axis. The conceptual understanding we provide in this book will hold you in good stead, no matter which toolkit you use to get your work done.