Architecture: XRX? XR(P)X.

If you check lists in a previous post, you mention, that from higher level view an enterprise application turns into some black box, producing and consuming XML. If you look into, you will see XML metadata, transforms from one XML format to another.

The typical way would be follow example poor Seam application: WS-XML-Binding(JAXB) - Java(C#) processing - ORM (Hibernate). And back. And forth. And back... For different formats. If data is semi-structured 3 man-years will not be enough...

Landscape

So, do we need convert XML to a language representation just to make pair of transformations and send somewhere further? Can we use XML as format to represent data upon its full path effectively? As an Apache Cocoon user I answer yes and often more effectively, especially in memory terms.
And it would be essential to store XML as it is natively in XML database. Native XML databases provide currently amazingly good performance and reliability, both commercial and open source. Also Oracle and DB2 provide effective XML-relational hybrids.
To complete this idyllic XML landscape I will mention XForms - a forms layer from XHTML 2.0 standard: You describe form presentation, logic and model separately in XML, form queries and submits data in XML using REST - no DHTML Jiu-jitsu, no AJAX needed from you.

XRX

So XForms on client, REST communication with server, XQuery to XML database. Dan McCreary named them XRX in his famous post Introducing the XRX Architecture: XForms/REST/XQuery. His article XRX: Simple, Elegant, Disruptive describes an idea very briefly and clearly.
In brief - having an XML DB with REST frontend, capable to translate REST requests to XQuery you need nothing else. Here XML database plays to roles - application server and database itself.

Check XRX Wikibook for examples. Some typical example from wikibook of simplistic XRX approach clearly illustrates first problem of this over-simplistic approach -

• Layout, forms and data access logic are mixed - no any content separation.

Analogue in relational world would be Oracle HTTP package, where you expose stored procedures to web.

Other problematic moments when going large scale:

• Too much processing put into database.
• How to make queries to outer services?
• Security concerns - exposing database to public HTTP...
• Integration with existing ecosystem (security, portals & etc)
• Access JEE components.
• How to make some other things in Java if needed? REST controller for example?

Add pipelines

I have a desire to put something between REST frontend and XQuery interface in XRX. Definitely no any JAXB, just a tool to manipulate XML flow, make XSLTs, HTTP queries, combine results, make XQueries - an XML pipeline.

A pipeline concept sees XML being processed to flow throw line of pipes.
XML is initially generated - from HTTP (or other protocol) request or other source possibly using request parameters - this can be and XQuery to DB or just reading a file.
Next XML goes throw some transformers (pipes), each can modify it content using also data from other sources. For example first XSLT can prepare an XQuery HTTP request in some XML node, next transformer can use it as an instruction to perform a request and put result back to XML. Finally XML is sent to client or stored in its textual form.
Using special techniques like SAX or StAX event sequential processing makes pipelines effective in both memory and CPU terms, still allowing to manipulate XML in comfortable way.

Although new XML pipeline standard XProc appeared, I know no good implementation to use and I like Cocoon. New Cocoon 3.0 gives a freedom to mix Java and XML in a way I find pleasant and addresses all issues with simplistic XRX well.

So lets add a Pipeline to XR(P)X.

In next posts I will see at individual components I briefly mentioned here.