The Perfect Storm of XRX - XForms, Rest, XQuery

Funny chain of events.

Almost every customer I have talked to on the XML Feature Pack Beta has also been talking to our DB2 pureXML team about their native XML storage.

I have also talked with the Lotus Forms folks working on Ubiquity XForms.

These were all day job things that I do in my role as a XML Strategist for WebSphere and somewhat related to my main job - architect for the Feature Pack for XML for WAS V7 (currently in beta).

Recently I got onto Twitter and noticed a few tweets related to pulling similar technologies together into something called XRX. I won't go into a deep explanation of XRX but there are great definitions of it on Wikipedia and Orielly and a great class on it from Dan McCreary. In short, it is a model for web programming that is declarative and XML native end to end using XForms on the client, Rest to communicate to the server, and XQuery to work with data.

I happened to have planned a few days of strategic thinking this week and decided to play with this in relation to the XML Feature Pack (which has XQuery 1.0 support).

We have been working on internal samples of how to cleanly leverage DB2 from the XML Feature Pack. Its actually not hard at all to have the XML Feature Pack do middleware processing of data that comes from DB2 pureXML as we provide
XSource/XCollection/XResult resolvers that allow you to do just about anything you want with input and output (like issue a JDBC request to DB2 that returns XML column data in its native XML form). Actually this approach is very advanced as a) DB2 can provide massive storage and indexing of XML data via XQuery itself while returning smaller subsets of data to WAS and b) the XML Feature Pack can join this data to non-database stored data (web services, files) and transform it in ways you wouldn't want to do in the database. So, based on this we have the XQuery part (actually X-* including XQuery and XSLT) of XRX.

Today I hooked the XML Feature Pack into a JAX-RS implementation (Apache Wink). Again this was rather easy as I could define Providers for XQuery objects (well not really objects - just a token to hold the combination of an XQuery expression and a XML input source). I could then issue GET requests against the WAS web container that included parameters that identify the data set to be worked with (think collection in XQuery terms) and the XQuery program (or XSLT if I choose) to work with the data set. So, based on this we have the R part of XRX.

Next I need to work with the Ubiquity code to get the first X of XRX, but given I'm already returning XML datasets, I believe this will be straight forward.

I think this combination of enterprise scalable application server and database along with standard XForms will be quite useful to many scenarios. Also, as a performance geek, I can't help but be excited that this whole chain is not only very capable (with regards to programming model) but declarative end to end. This means, in implementing the runtime, I can make optimizations that aren't possible when this similar thing is programmed in imperative languages like Java using Java API's. This has very interesting multi-core optimization possibilities and is very interesting when combined with cloud like deployment scenarios. Additional benefits are that no XML is harmed by OO (Object Oriented) conversions end to end (think losing data and performance in the mapping), this model should be something non-Java programmers (Business Folks) can work with, and these are all W3C standards.

I'd like to consider a sample of this to share at some point with code. Anyone interested?