Contact Information
- Email: ctoohey@dominoguru.com
- BleedYelow.com: Chris Toohey
- Skype: ChrisToohey
- Gizmo: ChrisToohey
- Yahoo!: ChrsToohey
- Google: ChristopherToohey
(ctoohey@dominoguru.com) - AIM: ChrisToohey
- Twitter: ChrisToohey
- Facebook: ChrisToohey
- LinkedIn: Chris Toohey
- Videos:vimeo.com/christoohey
- Podcast Information
http://www.yellowcast.net
YellowCast @ Twitter - RSS:

- Guru Tag:

Like what you see? Help feed-the-beast by donating to the site and it's humbly thankful author!
My Twitpic Updates
My Twitter Updates
Publishings
Domino Development and Data Store Architecture 06/06/2008Domino Development RIM's Blackberry Connections Client - First Impressions (Part 2) 05/19/2008
My Gear RIM's Blackberry Connections Client - First Impressions 05/19/2008
My Gear Remove my name from the Domino Directory!! 02/05/2008
Lotus Notes Quick and Dirty Mail Application Document Importing 01/24/2008
Methods and Strategies Publishings Archive
Examples & Downloads
Showtime: Blackberry Enterprise Server Push Utility for the Lotus Notes Client - Release v0.1 11/13/2008Examples and Downloads MixMaster v0.1 - Remote NotesItem Manager 10/06/2008
Examples and Downloads No-View NotesDocument Lookups, UNID Logic, and Environment Variables - Example Application and Video Tutorial 09/16/2008
Examples and Downloads xCopy v0.2 - OS xcopy Client for Lotus Notes 08/07/2008
Examples and Downloads xCopy - Local Archiving and File Copying Utility for Lotus Notes 07/22/2008
Examples and Downloads E & D Archive
Resources
PlanetLotus.org [ Community ] Alan Lepofsky's Notes Tips [ Community ] Chris' The Business Controls Caddy [ Community ] Petr Stanicek [pixy] [ CSS ] JoeLitton.net [ Community ] Resources ArchiveDomino as an XML data store and a servlet as a message broker? We'll see!
06/03/2008 04:00:33 PM | Chris Toohey | Saylorsburg, PA
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:
- Complete separation of client UI and data.
- Treating the Domino database as an XML data store.
- 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...
Like what you see? Help feed-the-beast by donating to the site and it's humbly thankful author!
Chris Toohey | Domino Guru

Comments
http://nathan.lotus911.com
06/04/2008 07:09:31 AM
Chris, I swear... I can never understand what you're describing when you write something like this. :-)
Can you replace every instance of "utilize" with "use" and "communicate" with "talk?"
And I'm really confused by your description of your data store, because you say you'd have to write a web services consumer from scratch. You're talking about a data store -- don't you need a web services PUBLISHER? What would the data store be consuming? That doesn't make any sense to me.
http://www.dominoguru.com
06/04/2008 01:47:00 PM
@Nathan:
For the CMS, at least how I understand the industry-lingo, you'll need to build a web services consumer for web service-based clients that need to interact with our data store (again, Domino). So the message broker (our servlet) will consume the web service request(s), the broker will communicate directly to the data store (again Domino...) to create/modify/delete entries based on how you've defined (via the configuration documents - there's the skinning potential) what it's supposed to do with the given request.
Now, as far as the architecture of the data store, we're going to keep this as XML-ly as possible. As simple as possible. And those "configuration documents" are going to be the thing that does the "heavy lifting". Think Decepticon + YellowCake + Broker.
... not that that would clear up anything to anyone else... but I didn't use "utilize" once! :-P
http://www.assono.de/blog/
06/08/2008 08:29:11 AM
As far as I understand your approach, Notes client applications aren't your focus (nor easily doable). It's about Web applications and for clients, which could been build "around Web services".
Thus lead me to my essential question:
Why do you want to use Domino as your back-end system?
You are building a data centric application. That's okay, but most applications I do are more or less process oriented, including some workflows and such. Therefore my next question is:
What's about the application's logic? Where should/could it been placed?
Web services are great for some applications. But all solutions about security and encryption are still needing some (or some more ;-) ) amount of work. My third question is:
How do you want to built in data and transport security (besides SSL)? Authentication? Data access control?
There are the Domino security features, but they rely on data stored in documents and accessed as documents. How you plan to translate this to your servlet/XSLT approach?
Don't get me false, I think, yours is an interesting approach, but I still don't believe, it will work well. Or you invest so much work to get it working, an existing Java, (G)Rails or such solution would be a more effective approach.
Thomas