Skip to main content

Part I : XRX Architecture - Unleashed

During my tenure at Software AG, I was introduced to the power of XML. To my candor, i was very impressed to see the wide range of problems that XML promised to solve. Especially, to mention the performance power-punch that XML databases unleash when combined with XQuery and REST.

A couple of years later, I moved into the consultancy world. Being back in the consultancy world and seeing business systems with my renewed XML-ized eyes (all credits to Software AG Tamino API and tools laboratory), I was highly dismayed to find that business oriented systems seldom use the real power of XML. The usage of XML herein has been more-so confined to defining application configurations and bare minimum transformation to either render interface elements or reports. I agree, there have been a few exceptions to this statement too.

After spending quite some years revolting the general underutilization of XML; apparently I found my preferred architecture – i.e. XRX (XForms/REST/XQuery).

What is so unique about XRX architecture...?

Generally, web application architectures accept inputs from HTML forms, which provide the user inputs in flat key-value pairs, thereafter these data structures are converted to middle tier objects such as Java or .Net and then transformed into tabular data streams so they can be stored in relational databases. Once in the relational database, the data must then be re-serialized by doing SELECT statements, converted into objects and the objects then converted back into HTML forms. This is four-step translation architecture.

In contrast to the above discussed conventional approach, XRX uses the zero-translation architecture. Zero translation implies that XML is stored in the web client, transmitted to a middle tier validation rules engine in XML and then stored in its entirety in an XML database. The storage in a single XML object is also known as a zero-shredding process since the data files are not separated into Third Normal Form (3NF) data structures. The key here is to break the myth and realize that 3NF shredding does not add any business value to the system.


Over the years, I have preached XForms as a very solid architectural composite; as it offers an order-of-magnitude improvement over other web front-end development architectures. Now, XForms when combined with the traditional XML performance power-punch i.e. REST and XQuery, defines a radical architecture that works wonders.

I'm sure you must be already wondering: how to build this magical combination of XForms - REST - XQuery (XRX)? The following architecture view depicts the approach at an abstract, to facilitate and initiate your quest -


Following are some of the distinct advantages rendered by XRX architecture -
  • A web development architecture with a 10x productivity improvement over traditional Javascript/Object Oriented/RDBMS methods
  • A development architecture based on international standards that is designed to minimize the probability of vendor-locking
  • An architecture that gives a rich user experience without creating mountains of spaghetti procedural code on either the client or the server
  • A system that leverages the REST architecture to take advantage of high-performance and simple interfaces using web standards
  • Portability on both the client and the server using a variety of forms players and XQuery databases
  • The option of avoiding costly shredding (and reconstitution) of complex XML documents into RDBMS tables
  • A community of standards/tools and a "complete solution" ecosystem that can give you a proven ROI on IT investment
The forthcoming post in this series, i.e. "Part II : XRX Architecture - Illustrated", will walk you through an elaborate tutorial on building a sample application that implements the XRX architecture.

Adieu for now...

Comments

Jason Monberg said…
Rahul,

Looking forward to your illustrated architecture.

What types of applications are best suited to XRX? I imagine the front end interface and the types of data being stored are critical.

Can you provide more detail on achieving 10x productivity improvement? Is this achieved when developing just the form component or across the entire application development cycle?

I've spent significant time developing applications (www.mydashlight.com) on an XML Server using XQuery and REST but have not used XForms yet. I had greater productivity over traditional architectures but not at the 10x scale.

I used Mark Logic's XML Server (Note that I have worked for Mark Logic in various capacities over the last 12 months) to handle XML storage and XQuery processing. If you have experience with their server in your architecture I would love to hear about what did and did not work for you. You can try their server here: http://www.marklogic.com/product/download-software.html

Keep up the XRX posts!
Rahul Roy said…
Jason,

Thanks for your interest in the write-up. I'm still working on the illustrated write-up, which will be published here in some days.

Meanwhile, the 10x improvement that i mentioned here is with regards to the entire application. Its cumulative, i.e. not only your development time but also your application's through-put. When you use the REST interface over a XML DB, you dont really need to get into all that costly transformation deal, right? That one place where you save your processing time and resources. Now, if you implement XFroms on the presentation layer you need not do many things, like custom validations and stuff. All that would be taken care by XForms for you directly from the Schema. Now, isn't that a nice bonus...? You again save upon all the time to implement a synced up validating implementation.

These are just a few to name here, try implementing a sample application in XRX and you'd know it for yourself. :)

Hope this helps...

Popular posts from this blog

Shard – A Database Design

Scaling Database is one of the most common and important issue that every business confronts in order to accommodate the growing business and thus caused exponential data storage and availability demand. There two principle approaches to accomplish database scaling; v.i.z. vertical and horizontal. Regardless of which ever scaling strategy one decides to follow, we usual land-up buying ever bigger, faster, and more expensive machines; to either move the database on them for vertical scale-up or cluster them together to scale horizontally. While this arrangement is great if one has ample financial support, it doesn't work so well for the bank accounts of some of our heroic system builders who need to scale well past what they can afford. In this write-up, I intend to explain a revolutionary and fairly new database architecture; termed as Sharding, that some websites like Friendster and Flickr have been using since quite sometime now. The concept defines an affordable approach t...

FAINT - Search for faces

Lately, I've been playing around a bit with facial pattern recognition algorithms and their open source implementations. I came across many reference implementation but a very few were implemented in Java, and the Eigenfaces algorithm by far happens to be the best amongst them all. During my research around the said topic i happened to stumble-upon an implementation called FAINT (The Face Annotation Interface - http://faint.sourceforge.net). Faint by far the best facial pattern recognition API and as you must have already guessed, it implements the Eigenfaces algorithm. Now enough of theory talks, how about implementing an example with faint...? Here is one for all you face-recognition enthusiasts. The following example simply searches for faces in a given photograph and thumbnails them. Now, I know thats not face recognition; but be a little creative here. Once you have the facial thumbnails extracted, its never a big deal to look further in the Faint API and find methods which ca...

Is Java String really immutable...?

In many texts String is cited as the ultimate benchmark of Java's various immutable classes. Well, I'm sure you'd have to think the other way once you have read this article. To start with, let's get back to the books and read the definition of immutability. The Wikipedia defines it as follows - 'In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created.' I personally find this definition good as it mentions that an immutable instance's state should not be allowed to be modified after it's construction. Now keeping this in the back of our minds, let's decompile Java's standard String implementation and peep into the hashCode() method - public int hashCode() { int h = hash; if (h == 0) { int off = offset; char val[] = value; int len = count; for (int i = 0; i h = 31*h + val[off++]; } hash = h; } return h; } A detailed ...