Table of Contents
Axiom stands for Axis Object Model and refers to the XML infoset model that is initially developed for Apache Axis2. XML infoset refers to the information included inside the XML, and for programmatic manipulation it is convenient to have a representation of this XML infoset in a language specific manner. For an object oriented language the obvious choice is a model made up of objects. DOM and JDOM are two such XML models. Axiom is conceptually similar to such an XML model by its external behavior but deep down it is very much different. The objective of this tutorial is to introduce the basics of Axiom and explain the best practices to be followed while using Axiom. However, before diving in to the deep end of Axiom it is better to skim the surface and see what it is all about!
This tutorial can be used by anyone who is interested in Axiom and needs to gain a deeper knowledge about the model. However, it is assumed that the reader has a basic understanding of the concepts of XML (such as Namespaces) and a working knowledge of tools such as Ant. Knowledge in similar object models such as DOM will be quite helpful in understanding Axiom, mainly to highlight the differences and similarities between the two, but such knowledge is not assumed. Several links are listed in the section called “Links” that will help understand the basics of XML.
Pull parsing is a recent trend in XML processing. The previously popular XML processing frameworks such as SAX and DOM were "push-based" which means the control of the parsing was in the hands of the parser itself. This approach is fine and easy to use, but it was not efficient in handling large XML documents since a complete memory model will be generated in the memory. Pull parsing inverts the control and hence the parser only proceeds at the users command. The user can decide to store or discard events generated from the parser. Axiom is based on pull parsing. To learn more about XML pull parsing see the XML pull parsing introduction.
As mentioned earlier, Axiom was initially developed as part of Axis and simply called OM. The original OM was proposed as a store for the pull parser events for later processing, at the Axis summit held in Colombo, Sri Lanka, in September 2004. However, this approach was soon improved and OM was pursued as a complete XML infoset model due to its flexibility. Several implementation techniques were attempted during the initial phases. The two most promising techniques were the table based technique and the link list based technique. During the intermediate performance tests the link list based technique proved to be much more memory efficient for smaller and mid sized XML documents. The advantage of the table based OM was only visible for the large and very large XML documents, and hence, the link list based technique was chosen as the most suitable. Initial efforts were focused on implementing the XML infoset (XML Information Set) items which are relevant to the SOAP specification (DTD support, Processing Instruction support, etc were not considered). The advantage of having a tight integration was evident at this stage and this resulted in having SOAP specific interfaces as part of OM rather than a layer on top of it. OM was deliberately made API centric. It allows the implementations to take place independently and swapped without affecting the program later.
Axiom is a lightweight XML infoset representation that supports deferred building That means that the object model can be manipulated as flexibly as any other object model (Such as JDOM), but underneath, the objects will be created only when they are absolutely required. This leads to much less memory intensive programming. Following is a short feature overview of OM.
Lightweight: Axiom is specifically targeted to be lightweight. This is achieved by reducing the depth of the hierarchy, number of methods and the attributes enclosed in the objects. This makes the objects less memory intensive.
Deferred building: By far this is the most important feature of Axiom. The objects are not made unless a need arises for them. This passes the control of building over to the object model itself rather than an external builder.
Pull based: For a deferred building mechanism a pull based parser is required.
The Following image shows how Axiom API is viewed by the user
StAX
(JSR 173) is the standard pull parser API for Java.
Axiom makes use of the StAX API to allow application code to access the object model in streaming mode, which means
that application code can request an XMLStreamReader for any document or element information item.
In addition, support for deferred building relies on the usage of a pull parser. The two standard implementations
of the Axiom API (LLOM and DOOM) both use the StAX API for that. To work with these implementations, a StAX compliant
parser must be present in the classpath.
Since Axiom is a deferred built object model, It incorporates the concept of caching. Caching refers to the creation of the objects while parsing the pull stream. The reason why this is so important is because caching can be turned off in certain situations. If so the parser proceeds without building the object structure. User can extract the raw pull stream from Axiom and use that instead of the object model. In this case it is sometimes beneficial to switch off caching. Chapter 3, Advanced Operations with Axiom explains more on accessing the raw pull stream and switching on and off the caching.
In a nutshell SOAP is an information exchange protocol based on XML. SOAP has a defined set of XML elements that should be used in messages. Since Axis2 is a "SOAP Engine" and Axiom is built for Axis2, a set of SOAP specific objects were also defined along with Axiom. These SOAP Objects are extensions of the general object model classes.