Home:Learn XQuery:White Papers:ACORD:Why DataDirect XQuery™ Beats SQL and XML DOM

Comparing Solutions Using DataDirect XQuery™ versus SQL and XML DOM

The XQuery and Java examples described in XQuery Operation Examples for an ACORD Insurance Application and Using DataDirect XQuery™ to Bind External Variables to Dynamic Values are all very interesting, and show how powerful XQuery and the DataDirect XQuery™ implementations are in manipulating ACORD XML messages, EDI messages, and relational databases. But why do you need them? Can you implement the same tasks writing traditional Java code that executes SQL queries over JDBC and that fetches/create XML documents through XML DOM interfaces? Of course you can, but the cost of doing that compared to the combination of XQuery and Java is huge, and the best way to describe that is to show a couple of examples that you can compare with the XQuery solutions described in the other sections.

The first example is about processing an ACORD message requesting information about a specific policy product (tc=201) (the corresponding XQuery is described in Updating a Relational Database, and the necessary Java layer to execute the XQuery is described in Using DataDirect XQuery™ to Bind External Variables to Dynamic Values. If we want to solve the same problem using Java+SQL+XML DOM (already it seems more complicated), then you need a Java application similar to the one described in this file: acord201JDBC.java.

Just comparing the visual size of the two solutions makes the XQuery-based approach particularly appealing. Not only does the XQuery solution provide coding economy, but it does not suffer from any of the drawbacks of the Java+SQL+XML DOM approach. In the Java+SQL+XML DOM approach:

• Most of the Java code is dedicated to fetching information from the incoming XML message and to formatting the resulting XML response following the ACORD standards.
• The code dealing with XML is difficult to read, difficult to maintain, and error prone.
• The SQL statement and its execution is fairly simple, but its use in conjunction with XML data makes it cumbersome — as you try to perform more complex operations with the resulting XML message (reporting and some of the more complex ACORD message types are typical examples of this), the SQL statements needed to meet these requirements become increasingly complicated.

The second example is based on an ACORD party inquiry, which requires joins across multiple tables, as described in Performing a Search and Inquiry Using Multiple Joins. This makes the Java+SQL+XML DOM solution much more complicated, as you can see in the Java code acord204JDBC.java. Now three SQL queries are needed, and the creation of the XML result gets significantly more complicated.

With its superior economy, ease of development (and ease of maintenance), simple access to and manipulation of relational and legacy data, and integration with XQJ, DataDirect XQuery™ provides an elegant solution for application developers and integration architects working with ACORD and other standards. Try it yourself!

What's Next?

Go to Installing and Running DataDirect XQuery™ ACORD Examples to learn how to install and run the examples described in these pages on your local machine.