C++, Java, & XML Processing

When it comes to data processing and string manipulation, C++ is a top performer. Therefore, it makes sense that XML processing and C++ belong together. Although most XML tools target Java programmers, there are tools for the C++ developer. In this article, I compare XML processing in both Java and C++ using the Apache Xerces XML parser (http://xml .apache.org/) for both Java and C++. Xerces supports XML parsing via the Simple API for XML (SAX) as well as the Document Object Model (DOM).

SAX and DOM Parsing

SAX provides an event-based paradigm for traversing XML. With SAX, the given XML is traversed in its entirety, from top to bottom, sequentially. As the XML is processed, methods are called on your class providing information for each node, its attributes, and data, in the order that they appear in the XML. With SAX, you must traverse an entire document, even if you are only interested in a portion of it.

DOM parsing provides an alternative to SAX, letting your code locate a specific node in an XML document while ignoring the rest. The DOM also supports creating XML documents within your code, which you can serialize as a file on disk.

Although these two features make DOM parsing seem much more appealing than SAX processing, they come with a price. DOM parsing typically uses more memory and time to process XML, as it must create an object hierarchy in memory for the entire XML document before your application can use it. If the XML you are parsing is particularly large, this may not be an option.

In most cases, however, DOM parsing is the most efficient and useful way of working with XML in an application. This is especially true if your application needs to create XML documents from its own generated data. For these reasons, I'll focus here on using the DOM parser in both C++ and Java.

The Scenario

For the purpose of illustration, I examine a scenario such as an off-site conference, where the organization hosting the conference would like to process attendees as they enter. Assume that for cost and convenience purposes, the organization plans to equip its greeters with wireless, hand-held PocketPC devices as opposed to notebook computers.

The mobile device must gather credit-card payment information for each attendee, and send that data to a server for processing. The server, written in Java, sends a response to the mobile device indicating whether the payment has gone through.

Your job is to choose the best architecture and tools to build the client application for the mobile device. One option is to write the client application in Java and use Remote Method Invocation (RMI) to communicate with the server. The second option is to use Visual Basic to build the application, as it makes building GUIs a breeze.

However, both scenarios introduce some problems. First, using Java to develop GUIs isn't ideal and requires a Java virtual machine (JVM) to run. The JVM might prove to be too resource intensive to run even a simple application on a mobile device. Second, using Visual Basic can also be resource intensive, and leaves little or no option to communicate with the Java server.

The third option is to use C++ to build the client application, which should yield excellent results in terms of size and performance. Using XML to communicate with the server should provide an ideal level of abstraction.

If this scenario sounds familiar, it may be because Microsoft recently held a developer conference where they used hand-held, wireless PocketPC devices to process registrants as they arrived at the conference. Although I don't know any of the details regarding the applications they ran on these devices, I assume the issues Microsoft had to tackle were similar to those presented here.

The Solution

The solution presented here is based on the third option. The client application will be written in C++ to offer the best performance. The server is written in Java, and communicates with a payment-processing system over the Internet. Client-server communication is done through XML files written to a network drive accessible to both the client and server applications. Figure 1 illustrates the proposed solution.

Figure 1:Proposed system solution.

The client application has a user interface (Figure 2) that lets users enter a customer's name, address, and credit-card information. The application is written as a Visual Studio 6.0 C++ application that can run on a Windows desktop computer. The main thread of the client application takes data from the user, creates an XML document from it, and serializes the document to a file. A child thread running in the background continuously checks a folder for an XML file containing the server response.

Figure 2: The customer check-in user interface.

The server application is written in Java, has no user interface, and is intended to run on a server. A child thread is created that continuously checks a folder for payment-request XML files. When a file is found, it is processed using the Xerces Java DOM parser, and all of the payment-request data is extracted.

When a (simulated) credit-card response is received, an XML document is created that contains the customer's name and the payment approval or denial. Finally, the XML is serialized to a file.

The Document Object Model

When an XML document is parsed using a DOM parser, the output is an object hierarchy, or tree, in the form of a Document object. This object serves as the root of the tree, which contains Node objects that can be traversed recursively to inspect the contents of the XML.

Every object in the DOM tree implements the Node interface and can be treated as a Node object, including the root Document object. Each Node itself contains a list of child Node objects, each representing an XML tag, attribute, or value, and so on. This allows you to write one method to recursively traverse the tree and process the contents of the entire XML document. Figure 3 is a UML class diagram for the Node interface.

Figure 3: UML class diagram for the Node interface.

DOM Node Types

Every Node in a DOM tree has a type, which can be queried; see Table 1. The first node in the tree is always a node of type DOCUMENT_NODE, but the most common type encountered is ELELMENT_NODE. This node type, and only some of the other common types, is discussed here.

Table 1: The DOM Node types.

The first element node in the tree is the root node of the parsed XML text. The name of an element node is the text located within the "<" and ">" characters in the XML. For the XML in Example 1, the root element node name is Customer.

Example 1: Sample XMLtext.

<Customer>
    <LastName>Bruno</LastName>
    <FirstName>Eric</FirstName>
    <CreditCard type="AMEX">
        <Number>1234567890</Number>
        <Expiration>1/2005</Expiration>
    </CreditCard>
</Customer>

Traversing the list of child nodes of an element yields the element's textual content, attributes, and other elements—with their children, and so on—if they exist. The Customer element node in Example 1 has three child nodes, LastName, FirstName, and CreditCard, all of which are element nodes themselves.

The Customer node does not contain any textual content, but the LastName element node does. Textual content—in this case the text "Bruno"—is identified as having the node type TEXT_NODE. Nodes that represent XML attributes, such as the type attribute of the CreditCard node, have the node type ATTRIBUTE_NODE.

Element, text, and attribute nodes are typically the most useful nodes in the DOM tree to deal with. Refer to the DOM documentation that came with your DOM parser for a complete description of these node types and the others not discussed here.

Creating XML Documents

Besides parsing existing XML files, the DOM lets you create new XML documents and serialize them to disk. This is useful when an application needs to generate an XML response to a request, or even the request itself. For instance, in my example, the PocketPC client application generates an XML request using the information entered in the edit boxes within the application GUI. The Java application parses the request XML and then generates the response XML based on the credit-card approval/denial. Before getting into the code details, first examine the general algorithm for the XML document creation with the DOM.

Building a DOM object hierarchy starts with a document factory object. In Java this is the DocumentBuilder object, and the DOMImplementation object in C++. Both objects let you either parse an existing document or create a new one from scratch. The result is a new Document object, which is really a Node object of type DOCUMENT_NODE.

The Document object is used to create Element node objects, which can be added as children of other Element nodes via the call appendChild. You have a complete DOM hierarchy when your code has created all of the element, text, and attribute nodes it needs, and has added each as children of the proper parents. The DOM can then be serialized to disk using a DOM serializer object.