Wednesday, 19 August 2009

Arum DataEye™ as a Service

I've been fairly busy recently with a couple of exciting activities.

Firstly, in my spare time I have continued to increase my experience with the Android platform, but more Android stuff can be found on my Android projects home page. I plan on submitting at least one, possibly two applications, to the Android Developer Challenge.

For my paid job, at Arum I have been exploring the possibility of using DataEye in a hosted environment. were kind enough to allow us to Beta their new Cloud product and after a minor false start, which with the help of Sytemtriq I got over quickly enough, it didn't take long to get DataEye up and running on their cloud infrastructure.

You can see DataEye in action right now by clicking here:
Arum DataEye Demo

Once the application loads you can login with the user "E:Benson" and password "p" but without the quotes.

DataEye as a hosted service presents both an opportunity and a challenge.

For organisations who are light on infrastructure or internal IT support the hosted solution means they don't have to worry about looking after DataEye, backing up the data and those other IT tasks, reducing the cost of ownership considerably. However, the challenge is that we still have get their management information data in to DataEye.

To address this challenge I was able to get even more leverage out of the fact that DataEye is based on OSGi. DataEye is constructed using what is known as "the whiteboard model". Simply put this means that components register services in preference to looking them up. This level of de-coupling then makes it easy to replace services with alternative implementations.

So to cut a long story short, I created a bundle that can accept DataPoint information over the web (via HTTP) as JSON. The bundle decodes the JSON and then inserts the objects in to our embedded db4o via the regsitered DataPointRegistry interface.

On the other end of the wire, which would be in the customer's infrastructure, I created a minimal OSGi environment using Equinox and then installed a bundle which registers an implementation of the DataPointRegistry interface which is responsible for pushing the data to the remote DataEye server.

By using the same interface on the server and client, we can then build integration bundles on customer site as if DataEye was hosted locally. If we later decided to move DataEye in to the customer's environment the same integration bundles will work without *any* change, because they are talking to the same interface.

At this point it feels appropriate to talk about Distributed OSGi. Distributed OSGi is a change to the current specification which lays out my approach above in a standard and container supported way, but at the same time without enforcing any particular transport protocol.

The main advantage of the new specification is that in my DataPointRegistry changes above I have hard coded the ability to receive JSON data over HTTP. With the new specification I would simply define the interface and drop in a provider which can do the 'remoting' for me. While the above change only took a couple of days to implement, the new specification would reduce that to almost nothing.

Once the new specification is widely available and in use, we will move DataEye to use an OSGi server based on the latest OSGi specification, which then also gives us access to a raft of new, enterprise focus, features in the OSGi container.