Processing XML on iSeries, Part 2

Read here the first part of this article, about XML and database integration using Saxon.

In last October I looked at DataDirect's XQuery tools. These guys are serious. Their web site contains one of the best Xquery references on the web today.

If you are an iSeries professional, you may ask yourself WTH is xquery and why you should care.

Xquery is a bit more than yet another XML processing language.

It attempts to deal with XML files in a manner similar to relational databases, and this is good. Many developers find it cumbersome to program an event driven process to deal with basically recurring events, like records in a XML message. It seems easier to write a couple of FOR loops (XQuery) rather than trapping template occurences (xslt). For some tasks, a plain procedural program flow rules. I had to develop some pretty complex XML transformation processes lately, and I found using xquery to be both more productive and more readable than XSLT. It is also easier to understand for non-xml experts.

DataDirect support the standard xquery model exceptionally well. Their XML studio shines, and they also extended the standard and added database support, the result being that now it is really easy to define interactions between XML and databases.

Like almost everything Java, I like to see if it is feasible to run it on iSeries, especially as I immediately realized the benefits of native execution: finally a tool to enable XML integration with DB2 tables, NOT WRITTEN IN RPG, maintainable by non-iseries buffs, and able to be inserted into native iseries business processes.

The bulk of my experience is already detailed here and I will not repeat it in this blog. I can just say that it works.

However, not everything is bright and shiny with DataDirect XQuery.

First, there is performance: on my 520 it sucks. A program that took a couple of seconds on a PC runs for more than 30 seconds. There are simply too many dependencies and jars being loaded to execute a single XQuery program. I believe that this issue can be addressed by not spawning a distinct xquery instance for each xml file, but I haven't got to do anything about it.

Then, there is the price... I will be fair to DataDirect and not disclose the price they wanted for an execution license on a System i model 520, but it was a bit on the high side. Had they asked for a price similar to their X86 license plan, we would have almost certainly bought it....