ActiveSpaces

The simplest way I can explain ActiveSpaces is with this single sentence:

• ActiveSpaces is a distributed middleware that offers the functionality of a database and of a messaging system in a single interface.

In essence, ActiveSpaces is what you get when you Mashup a database and a messaging system together. Of course, a 'one-liners' like this may sound like a bold claim, and I certainly won't claim that it implements every single feature offered by any of the existing database and messaging systems, but read on and I hope to be able to explain that it implements the features most applications need most of the time.

Databases are good at storing or looking up data, and using stored procedures you can even validate or eventually transform the data in an event-driven manner as updates happen, but you are ultimately limited by the fact that the database server is a non-distributed shared resource that is expensive to scale. And because client applications can not be proactively notified of changes in the data they are interested in by the server it is very difficult or expensive to create elastic distributed event driven applications using only a database (even in association with a cache).

Messaging systems are very good at distributing data and events through publish/subscribe and therefore greatly simplify the creation of scalable distributed applications, but publish/subscribe can induce unwanted temporal coupling because the receiving application has to be on-line and subscribing at the time a message is published in order to receive it. Message queues and guaranteed messaging can be used to avoid this problem and provide the temporal independence that you naturally get from a database by 'buffering' data, but only temporarily: messages are forgotten as soon as they are consumed. Ultimately, a messaging system is a store-and-forward 'data pump' designed to distribute data, not hold it as a system of record for later perusal.

So what happens is that in order to achieve a scalable architecture those that can afford it (or have no other choice) use both a database and a messaging system at the same time. But even then, besides the potential inefficiencies and operational complexity, there is a lot of development work to be done to deal with the impedance match between the two worlds: for example coordinating data models or translating between the data formats, or dealing with the 'iterator driven' versus 'callback driven' orientation of each interface (not to mention the synchronization of the transition between the results of a query and the reception of update messages).

ActiveSpaces offers all of those features and none of the headaches because everything is integrated in a single easy to use interface:

• Similarly to a database you can put, get and even take (atomic get and remove) rows. You can either get a single row back by getting a tuple by it's key field values, or use a SpaceBrowser to view a filtered subset of a space.

• Like with a messaging system, you can be notified of changes in the data proactively and immediately using Listeners.

But the Mashup does not stop here...

• Tuples are self-describing and platform independent map of fields, just like messages.

• Unlike database queries, SpaceBrowsers are not just static 'snapshots' of the data, they are continuously updated according to the changes in the Space, as those changes happen.

• Unlike when subscribing with most messaging systems you can request to get 'initial values' and specifying a filter query when creating a Listener.

• SpaceBrowsers can also be used to monitor events through an iterative rather than callback driven interface

• Concurrent modification of the data can be controlled using either 'Compare and Set' operations or locking or even transactions (optimistic or pessimistic control).

• And of course, let's not forget that ActiveSpaces itself is an embeddable peer-to-peer distributed system...

There's of course a few other interesting 'details' that I will expand on in future posts, and remember that I am only describing version 1.0 of ActiveSpaces ;). But the important message that I hope to have conveyed here is that picking the most useful features of database and messaging systems in order to create a single 'best of both worlds' interface is the underlying theme of ActiveSpace's feature set, and the key to distributing (and therefore elastically scaling) enterprise applications.