Domino as an XML data store and a servlet as a message broker? We'll see!

06/03/2008 04:00 PM by Chris Toohey

So, while chatting with Tim last night about just what we are going to do with Broker (for those of you who haven't been following YellowCast <shame!> - that's our public will-be-open source Domino CMS project that's currently in the works), we thought that we would split out the workload.

Tim is going to head up the really difficult part: another attempt at the servlet handling the HTTP Method PUT and DELETE verbs.

Me? I'm currently working through the cloud of prescription medication to architect the Domino data store. And here's what I have so far:

1. Complete separation of client UI and data.
2. Treating the Domino database as an XML data store.
3. Utilizing XSLT for content rendering of XML data.

So, here's what we're basically looking to do:

Let's say we're using APP for our CMS engine for a particular client type - something either 3rd party (like ScribeFire let's say) or web based. Instead of directly calling a feed via (what most of us do today) a View Design Element or a NotesDocument via it's URI, we're going to utilize our servlet as a message broker to communicate with the back-end data store - in this case, Domino. Now, as mentioned, since I'm going to utilize APP, I'm going to need an ATOM-based XML feed for my data. Simple enough right? I could do that in the Designer Client with ease. What if I want to then - based on a future requirement - utilize another 3rd party solution that utilizes Web Services or XML-RPC for it's CMS client technology, I'm going to have to write from scratch a web services consumer - which would suck, as I'd need to crack open the Designer client each time. And each time I would do this, I would need to create a new View Design Element, a new Form Design Element (or a few maybe), and a whole slew of other Design Elements - all to support just-another-entry-point. Kinda silly huh?

Now, imagine if you will that the servlet message broker was designed to not only consume requests - be they RESTful, XML-RPC, or pick-your-poison - communicate said requests to the back-end data store (Domino), and respond as required for the given functional need. Pretty slick. Now, imagine if that was all configuration-based and thus "skin-able". You'd have the ability to support a new entry point into your solution - be it a CMS or content reader of choice - by simply enabling some configuration/control documents.

To do this, we're going to store the data in our Domino application - basically - under a XML-like architecture. NotesItems for Nodes, etc. Then, we'll use our "skinnable" configuration documents which are simply - which if you haven't seen where we were going with this at this point - XSLT libraries, to transform our XML data at runtime into whichever content is required.

Before anyone says this is "overkill" - we know it is... if you follow the standard Domino Web Development architectures. What we're looking to achieve is something that may at this time be unique in the development community from a functional architecture standpoint, but something that we think will completely revolutionize Domino Web Development. No longer will we be resigned to "Domino doesn't do that" - you'll have complete control over the rendered content, allowing you to integrate ancillary technologies with ease.

At least... that's the plan...