Saturday, 7 November 2009

Introducing Taban - The JSON REST Database for OSGi

I've been toying with the concept for a while that some web based applications (call them RIAs, Web 2.0, whatever) don't really need much in the way of 'server' infrastructure, and that a lot of the time they just need somewhere to persist their data. It is easy to make this complex but since the UI often knows the model it wants to use for persistence, it could be a lot easier. Even if they do need something complex rapid development of UI prototypes often exclude the persistence layer.

Here is where I introduce 'Taban - The JSON REST Database for OSGi'. However, at this stage I don't know if I'll actually use it, or if anyone else will find it useful, but I am also using this to 'practice' my OSGi coding (not that I don't do enough) and to play around with some web client technologies, namely Apache Pivot (I am a PPMC member and minor committer) and GWT (for no other reason than just because, really).

The idea behind Taban is that an web application will simply use HTTP methods (GET, PUT and DELETE) to perform the usual CRUD operations required for persistence, but using JSON as the data exchange format. In fact, the default implementation of Taban will pretty much store the JSON as is in to a db4o database, interrogating the JSON only to allow 'indexing' of the objects for the purpose of querying/filtering.

Alternative implementations could convert the JSON to a real object model and store that, again either straight in to db4o (which is the absolute easiest option), or if they really want the pain, in a RDBMS via some ORM technique. Taban will facilitate all these options, but will be fully useable 'out of the box'.

Since REST is more of a concept than a specification I have designed the following approach to URI handling, but please consider that this is still a work in progress:

GET - If the URI ends in a forward slash, the default action is to return a list of children as a JSON array. However, if the URI does not end in a forward slash the JSON content at that location (if it exists) will be returned directly.

PUT - If the URI ends in a forward slash the JSON content will be inserted and an ID will be automatically generated. ID generation is plug-able, but the default will be to use an integer based auto-increment for that particular URI. If the URI does not end in a forward slash the JSON content will overwrite any content at that address, if it exists, inserting it otherwise.

DELETE - Only URIs without a forward slash are supported by the DELETE method.

POST, TRACE, OPTIONS - Not likely to be used, though I am toying with the idea that a POST might support 'updating' the JSON at that location, rather than replacing it, but how and what to update at this point doesn't seem trivial to determine, though I have done similar work on this on Apache Pivot's resource handling which is JSON based.

In addition to the HTTP methods listed there will be a number of additional HTTP headers used in order to allow more fine grained control over the response as well as facilitating filtering and limiting of results.

Taban is (will be) implemented as OSGi bundles and will call out to/depend on a number of OSGi services, namely:
  • Configuration Admin (optional)
  • Event Admin (optional, but will allow other bundles to do stuff with the JSON that is being stored)
  • HTTP Service (required)

It will also depend on:
  • db4o to provide the default implementation of the database, though it will be designed such that any persistence layer could be implemented and replace this dependency
  • Arum Glue, an interface/convention based Inversion of Control and Dependency Injection manager
  • Jackson JSON, which is a fantastic and super-fast JSON library

Finally, securing the database is also pluggable but Taban will not be shipped with an authentication module, at least initially. I envisage it would be very easy to add BASIC or Digest authentication support, but for the purpose of getting Taban off the ground this is a low priority for me.

So, applications served from the web which have a rich client (by rich I mean most or all of the functionality is loaded in to the client/browser as opposed to a click-request-response approach) can use Taban to persist their application model data with very little effort in terms of setting up 'backend' services, and yet Taban will allow developers to make the server as complex as their business requirements dictate. We make no distinction between these front end technologies, so long as they can support a full range of HTTP interactions (sorry Flex people).

At this stage, it is likely to be a programming exercise, so I am very interested to hear from people if they think this is something they might find useful. If there is enough demand I will probably push my work to

Oh, I should also point out that Taban is a celtic/gaelic name that means 'genius' - not blowing my own trumpet, but more of an expression of the simplicity and flexibility of the product.