Contact Information

Chris Toohey

Like what you see? Help feed-the-beast by donating to the site and it's humbly thankful author!

My Twitpic Updates
    Site Resources

    RSS Site Content
    Syndicate This Site!
    DG Banner Logo
    Advertisements

    IBM Lotus Notes and Domino 7 now available

    Domino 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:

    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...

    Permalink | Domino Development | Digg This! | Comments (3)

    Like what you see? Help feed-the-beast by donating to the site and it's humbly thankful author!

    Comments

    Nathan T. Freeman
    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.

    Chris Toohey
    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

    Thomas Bahn
    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

    Add a New Comment


    (Not Published/Public)
    Remember my Information!

    (Enter the text from the image to proceed)

    (Full markup allowed in the comment field below; play nice!)

    Live Comments Preview