So in a way, with current XML processing methods, it is difficult to get both high processing/memory efficiency and ease of use. But there is more to think about.

Right now, parsing SOAP messages, whether the application uses DOM or SAX, is pretty much inevitable, even if it is done repetitively to the same messages. Would it be nice if there is a pre-parsed form of XML directly reusable without the overhead of parsing every time?

Also consider modifying the text content of the following XML file.

<color> red </color>

Using DOM, it would require at least the following three steps: build the DOM tree, navigate to and then update the text node, write the updated structure back into XML. So no matter how trivial the modification is, there is a round trip penalty of parsing the document and writing it back out. What if it is only a snippet buried within a big document? Would it be nice to be able to surgically remove then insert the update "in-place?"

VTD: A Simple Solution
Historically, the first step of text processing is usually to tokenize the input file into many little null-terminated strings. But there is another way to tokenize. Rather than extracting the token content out of the input, one can instead retain the original document intact in memory and use the offsets and lengths to describe tokens. In other words, tokenization can be done "non-extractively." We can look at how this "non-extractive" tokenization approach works in practice and compare it with traditional "extractive" view of tokens in the context of some common usage scenarios.

1. String comparison- Under the traditional text-processing framework, C's "strcmp" function (in <string.h>) compares an "extractive" token against a known string. In our new "non-extractive" approach, one can simply use C's "strncmp" function in <string.h>.
2. String to numerical data conversion- C's "atof" and "atoi" convert strings into numerical data types. One can introduce new functions or macros to convert "non-extractive" tokens into integers or floats. For example, the new "atof_ne" would have to take three inputs: the character pointer, the starting offset, and the length. Notice that the character pointer points at the memory buffer in which the entire document resides.
3. Trim- To remove leading and trailing white spaces of "non-extractive" tokens, we only need to re-compute the offsets and lengths based on their older values. To do the same thing to extractive tokens usually involves creating new tokens.

Above considerations have led to the design of a "non-extractive" token encoding specification called Virtual Token Descriptor (VTD). A VTD record is a 64-bit integer that encodes the length, the starting offset, the token type and nesting depth of a token in XML. For certain types of tokens, the length field further encodes the prefix length and qualified name length, since both share the identical offset.

One immediate benefit of VTD's non-extractive tokenization is that, because the document is kept intact, VTD allows applications to surgically insert and remove XML content similar to manipulating a byte array. For example, removing or changing the value of an attribute value or text content is the same as skipping the segment marked by the offset and length containing "unwanted" text. Also VTD makes possible the removal of entire element by simply skipping it according to its offset and length.

Introduce VTD-XML
Built on the concept of VTD, VTD-XML is the latest open source, "non-extractive," Java-based XML processing API (VTD-XML) ideally suited for SOAP processing. Currently it supports only five built-in entities (& < > &apos; "). The latest VTD-XML is version 0.8, which can be download here (http://vtd-xml.sf.net). Aside from maintaining the XML file intact in memory and exclusively using VTD to describe tokens, VTD-XML also introduces the concept of location caches that provide efficient random access. Different from DOM, VTD-XML's notion of hierarchy consists exclusively of elements, which essentially correspond to VTD records for starting tags. Resembling the index section of a book, location caches again make extensive use of 64-bit integers. The project web site (http://vtd-xml.sf.net) has an in-depth description on how VTD-XML achieves the purpose of random access with location caches.

VTD-XML should exhibit the following characteristics when used in a Web Services project. First, it parses SOAP messages at the performance level equivalent, if not faster, than SAX with the NULL content handler. On a 1.5 GHz Athlon processor, VTD-XML processes SOAP message at around 25~35 MB/sec. Second, unlike SAX, VTD-XML offers full random access as the entire parsed XML is resident in memory. Furthermore, if you are one of the developers that finds DOM's node-based API verbose and difficult to use, you should find VTD-XML's API clean and easy to comprehend. And VTD-XML's memory requirement is about 1.3x to 1.5x the size of XML, with 1 being the document itself as it is part of the internal representation of VTD-XML. Plus, incremental, dynamic update to the XML content is much more efficient than either DOM or SAX.

Why does VTD-XML consume less memory than DOM? In many VM-based object-oriented programming languages, per-object allocation incurs a small amount of memory overhead. VTD records are immune to the overhead because they not an objects. Also VTD records are constant in length and can be stored in large memory blocks, which are more efficient to allocate and garbage collect. For example, by allocating a large array for 4096 VTD records, one incurs the per-array overhead (16 bytes in JDK 1.4) only once across 4096 records, thus reducing per-record overhead to very little.

And more importantly, VTD's efficient memory usage has strong implication on its performance. DOM is slow in a very large part because it is resource intensive. The spirit of VTD is this: one simply doesn't have to, and has every incentive not to, create strings objects because they are slow to create. Even worse, they eventually need to be garbage collected. VTD-XML is able to achieve SAX's performance level because VTD significantly reduces DOM's memory usage, thus leading to savings on both object creation and garbage collection.

At the top level, VTD-XML provides three essential classes: VTDGen, VTDNav, and AutoPilot.

• VTDGen parses the XML/SOAP messages into VTD records and location caches.
• VTDNav is a cursor-based API allowing for DOM-like random access of the XML structure.
• AutoPilot works with VTDNav and emulates the behavior of DOM's node iterator.

A Sample Project
To process SOAP with VTD-XML, the starting point is a memory buffer filled with the content of XML/SOAP message. The sample message containing the purchase order (shown below) in the body section of the SOAP envelope. For simplicity reasons, the project assumes the message resides on disk. In real life, one is more likely to read the message off HTTP. (See Listing 1.)

At the top level, this project has a single main method (shown below) that wraps all code with a single try catch block that takes care of various exception conditions for IO operation, parsing and navigation. (See Listing 2.)

The following code parses the SOAP message. It first allocates a byte array, and reads into it the byte content of the SOAP message. Then, it instantiates VTDGen and passes to it the byte array. Next, it calls VTDGen's member method "parse()" to generate the internal, parsed representation of the SOAP message. Notice that "parse()" accepts the Boolean value of "true" to indicate the parsing is namespace-aware. (See Figure 3.)

After parsing, the sample code obtains an instance of VTDNav and uses the namespace aware "toElementNS()" to move the cursor to various positions of the element hierarchy and prints out corresponding text values, or selectively pulls out the XML fragment at the cursor position. (See Listing 4)

The code above concerning VTDNav has several points worth mentioning.

1. There is one and only one cursor available, which can be moved using "toElement()" or "toElementNS()." Those methods return a boolean indicating the status of the movement. If true, the cursor is repositioned; otherwise, no movement on the cursor.
2. Several member methods, such as "getAttrVal()" and "getText()", return an integer corresponding to the index value of the VTD record if there is one. -1 is returned if no such record is found.
3. VTDNav performs string to VTD record comparison directly, avoiding the round trip of creating and de-allocate string object.
4. VTDNav also performs VTD record to numerical data type directly for the same purpose.
5. There is a global stack available so one can save, then quickly store the the saved cursor location.
6. VTDNav also allows one to convert a VTD record into a string object. Use this carefully for reasons in 3.

The code that composes the invoice is shown in Listing 6.

The Road Map and a Quick Recap
The other property of VTD-XML is that its internal representation is inherent persistent, making it possible to avoid parsing for repetitive read-only XML processing. This also makes possible an XML upgrade path that improves XML processing performance without losing human readability.

As readers can see, VTD-XML, the new, non-extractive, Java-based XML processing API based on VTD, offers a number of benefits not found with existing XML processing APIs. The most significant one is that it simultaneously offers high performance, low memory usage, user-friendliness. Also it introduces the notion of incremental update. As XML makes inroads into IT and becomes increasingly indispensable in our lives, VTD-XML should find its way in more places and hopefully enable new exciting XML applications.