Architectures using DBJSON

All the architectural solutions of databases with DBJSON interface fall into three categories:


Native database of DBJSONtm objects. This is a kind-of-a hierarchical database. This is also kind-of-a OO database. It contains DBJSONtm objects. It does not require transformations of relational DB entities to/from DBJSON entities. Internal user language of the DBJSON native DB is JavaScript. Stored procedure and functions in that DB are written in JavaScript, and send receive only DBJSON messages.

DBJSON Mediator

This is separate component that provides DBJSON interface to the user/caller on one side, and  communicates with the RDBMS on the other side.

DBJSONtm Mediator can be local (running on the same machine as the caller) or global (running on the same machine as the RDBMS it uses)

DBJSONtm Mediator can be in-process or out-of-process component.

Out-of-process mediator is very interesting because it can act as a cache of DBJSON objects. It also can be synchronised with RDBMS in the back in a separate parallel process.

DBJSONtm can serve many users and use many RDBMS’s in the same time, thus acting as an TP Monitor.

One DBJSON Mediator product would be required to comprehensively mediate to one RDBMS product. DBJSONSQLSVR , DBJSONORACLE, DBJSON*MySQL, etc.

The messaging protocol

DBJSON is JavaScript interface to the data base. DBJSONtm interface is a kind-of-a message based interface. Users are interacting with RDBMS through a message based interface. Until now SQL was the language which was used to made messages to call RDBMS. Return was in a form of binary blob, which was readable with a help of an iterator called “cursor”. This is a curious asymmetry.

DBJSONtm interface communication protocol is symmetrical. Stream of DBJSON objects is flowing both ways : to the DB and from the DB. DBJSON is actually communication protocol based on JSON. (please visit http://json.org)

DBJSONtm message is always one single JSON object. This is it:

As obvious, dbjson object is one single json object with a single property called ‘dbjson’. Type of a ‘dbjson’ property is an object. The whole dbjson message is allwys inside this object.

Next page please.

6 Replies to “DBJSON: SELECT * FROM persons AS JSON”

  1. I Like the idea very much. I think the bigger problem in the short term is that web browsers aren’t secure so you couldn’t use DBJSON to expose your database directly or else anyone could run any query they wanted to by hacking the JavaScript. It could work out of the box with Aptana’s Jaxer, with Rhino, or maybe even with Adobe AIR where the JavaScript runtime is more in the developers control. I’ll be interested to see how this goes.

  2. Thanks Ian,

    Text currently (05Nov08) on the blog contains a good idea but is shamefully chaotic, I know.

    The comment you made on the security is of course valid. Answering it properly opens a “can of worms” which is called : Server Side JavaScript ;o)

    I certainly would not allow my team to send SQL select statements from a browser page back to the RDBMS.
    But server side components written with JavaScript are an entirely different matter. Also.
    I can easily envisage an architecture where client-to-server selections are totally removed. And client-to-client_data selections are totally ok. Like TAFFY does.

    Interesting near future development are client side DB-s, full blown but lightweight , like SQL CE 3.5 SP1, etc … This is where client app talks to the local DB which is transparently synchronized with separate infrastructure with a DB back end, over the wire. I can immediately (today) write AJAX app which will run inside HTA pages and talk to the local SQLSVR CE3.5. Only DBJSON mediator is missing ;o)

    PS: DBJSON can have a secondary but still usefull role here: as an security broker/mediator.

    Regards: Dusan

    1. Zoom to March 2016: Who would think that NODE.JS would look so uncertain and distant, way back in 2008?

      But ok, I was not very far of the mark with “Server Side JavaScript” :)

  3. Very true. In fact I think Server Side JavaScript with tools like this has a really bright future and makes a lot of sense. Looking forward to seeing how this goes.

  4. @shadowbq : Thanks for your somewhat terse comment ;o)

    JavaScript in “CouchDB” is partial implementation of the “MapReduce” concept and framework.
    ( http://en.wikipedia.org/wiki/MapReduce )
    And on “MapReduce”, I am affraid I largely agree with David DeWitt and Michael Stonebraker, pioneering experts in parallel databases and shared nothing architectures. In short: thumbs down.

    I am talking here about ubiquitous add on to current SQL syntaxes inside RDBMS-es, which would be a key to people adopting and understanding JSON.

Comments are closed.