Channels ▼
RSS

JVM Languages

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.

Node Type Description
ATTRIBUTE_NODE Represents an attribute of an XML element; for instance, <Score type="percent">100</Score >.
CDATA_SECTION_NODE Represents data that is not to be interpreted as markup.
COMMENT_NODE Represents a comment within the XML; for instance, <!-- This is a comment -->.
DOCUMENT_FRAGMENT_NODE Represents a lightweight Document object.
DOCUMENT_NODE Represents the XML Document root.
DOCUMENT_TYPE_NODE Represents the XML document type attribute.
ELEMENT_NODE Represents an XML element tag; for instance, <LastName>Bruno</LastName>.
ENTITY_NODE Represents a basic piece of XML data.
ENTITY_REFERENCE_NODE Represents an XML entity reference, which is a substitution for another character; for instance, <command>java -cp &lt;classpath&rt;</commmand>.
NOTATION_NODE Represents a DTD construct used to format an unparsed XML entity.
PROCESSING_INSTRUCTION_NODE Represents an instruction for parsing the XML; for instance, <?xml-styleshhet href=...>.
TEXT_NODE Represents the text content within an XML element or attribute; for instance, <LastName>Bruno</LastName>.

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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video