The Web Graph Database


Principle: Flexible Persistence

Virtually all applications have to have a way of storing information beyond the next reboot. Traditionally, this has meant that the application developer picks a suitable persistence technology (like flat files, structured files, a relational database etc.) and codes the application against the API provided by that persistence technology.

The problem with this approach is that all application logic tends to depend on the details of the persistence technology. For example, typical Java programs that use a relational database have SQL statements sprinkled all over the application. This makes it virtually impossible to migrate an application from one persistence technology (say, a relational database) to another (say, a grid storage). Even if the persistence technology remains the same and only the vendor is being changed (say, switching from one relational database to another), often major amounts of changes need to be made to update the application code to use a slightly different version of SQL. Supporting a choice of persistence technology typically requires application developers to write their own abstraction layer, thereby complicating application development and maintenance.

For InfoGrid, we decided that the application developer should not have to worry about the persistence technology at all. Application code should not depend on it at all; instead, it should only be a configuration step towards the end of the development cycle. It should be possible for third parties to invent new ways of persisting data, and it should be possible to use those new inventions with any InfoGrid application without requiring application code changes, just changing the configuration.

This principle caused us to design MeshObject as an abstract information object that just happens to be in memory when needed, and Store as the general-purpose lower-level persistence API.

Last modified 9 years ago Last modified on 01/19/10 05:57:11