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?

WAS V7 XML Feature Pack Beta Refreshed (With focus on XSLT 2.0)

Today we have released an updated XML Feature Pack Beta. The beta is available here.

Since the first release two months ago (which had full XPath 2.0 and partial XSLT 2.0/XQuery 1.0), we have added quite a bit to XSLT 2.0 (making us nearly spec complete) and more to XQuery 1.0.

Among the biggest features added in the XSLT 2.0 area is XML Schema awareness. This includes validation which allows you to validate (make sure it contains data that is allowed per the schema) the incoming data to transformations, temporary trees of data, and output data from transformations. Also, as is important when working with vertical industry standard schemas, our schema awareness support includes schema assessment. This means that your XSLT stylesheets know when an attribute or element content is an integer or date and you can treat it as such. Taking this to the next level, if you extend your industry standard schema type of a bill of materials, you can write templates that match that type (schema-element(*, tns:BillOfMaterialsType)). In the past you would have had to made templates that were of the industry standard element names as well as all extending element names (tns:BillOfMaterialsName, mycompany:FullfillmentBillOfMaterialsName, mycompany:PurchasingBillOfMaterialsName, etc.).

Other new XSLT 2.0 features in this refresh are collections support (allows multiple input data sources in a well defined way), "undeclare-prefixes" serialization parameter(simplifies namespace in XML 1.1), next-match (allows you to call overridden templates) element, required parameters and "as" attributes (helps guarantee stylesheet elements are called correctly) and full support of XSLT keys.

Another major feature of this refresh is ability to pre-compile XML artifacts. This refresh contains tools that compile XPath, XSLT, and XQuery to java classes. These classes are basically the same logic that previously was interpreted by the XML runtime. However, with them now being compiled, they run much faster than interpreted. The refresh offers three modes:

• interpreted - best when the XML artifacts are created ad hoc at runtime and not reused


• compiled - best when the XML artifacts are created ad hoc at runtime but reused


• pre-compiled - best when the XML artifacts are known at compile time of your application

We have also expanded our XQuery 1.0 support in this refresh.

Please let me know if any of these new features help you in your applications. I'm excited to hear of all the applications that are being tested against this functionality.

Finally, I have created another three demos to be posted on YouTube. Over the couple of days, I'll post them with links here. Hopefully they will help you understand how to use this functionality in your own applications.

It's a Dessert Topping AND a Floor Wax

There has been some recent blogging about general confusion on whether or not SCA constitutes a new programming model or not; for instance Dave Chappell blogs here, Mike Rowley of BEA here, and Sanjay Patil of SAP here.

Of course SCA defines a new programming model, however, it also specifically defines an invocation model, a component model, and an SOA assembly model which embraces other, non-SCA programming models. Blur in the fact that the term "programming model" has specific language connotations (at least in my mind), while SCA and its cousin SDO were designed to be specifically language neutral.

What we need for building SOA applications is a contract to describe dependencies, policies and implementation with as little knowledge of or need to impact existing business logic. It needs to lift us out of the computer science goo and into building business logic that is meaningful to the business.

The fact that one can or cannot use SCA with or without another container, or as a client with any at all is less important in my mind as the importance of its design points of separation of concerns and insulating the business logic from specific protocol and data bindings which lead to fragile, inflexible applications.

Steve Kinder