Adam Keys makes a good argument why the budding NoSQL movement should instead be called post-relational. Among other things, he says:

Right now, the best we have is NoSQL. The problem with that name is that it only defines what it is not…

What weâ€™re seeing its the end of the assumption that valuable data should go in some kind of relational database. The end of the assumption that SQLand ACIDare the only tools for solving our problems. The end of the viability of master/slave scaling. The end of weaving the relational model through our applicationÂ code.

We agree, which is why we use the term post-relational when talking about InfoGrid.

In InfoGrid, the Code Generator is responsible for generating classes from interfaces/types. There is no need to represent (implementation) classes in the model. So EntityType in InfoGrid most closely resembles interface in UML.

InfoGrid is of course a (model-driven) software platform, while the UML is just a modeling language. This comparison is only about InfoGrid’s modeling language component and ignores the remainder (i.e. most) of InfoGrid. On the converse, InfoGrid’s modeling language component focuses on the information representation aspect, while the UML provides many more diagramming types — which of course can be used with InfoGrid.

It allows developers to interact with persistent data in the same way, regardless of the language in which the application is written.

It gives developers and system operators a way of quickly “looking at the data” when things go wrong.

On closer inspection, none of these stands up much. (The fourth argument — that SQL would allow developers to ignore which product of which vendor the data is stored in — is very obviously false.)

Argument #1 was the big one in the 70′s when SQL was invented. However, non-engineers using SQL never happened and by now the argument has been conclusively disproved. Users need user-friendly applications, not SQL, to accomplish anything.

Argument #2 sounds good from the perspective of the database vendor: hey, we can say we support FORTRAN just as well as Java and Python, all with the same code. The trouble is: it does not matter to developers, because they tend to develop in one language at a time. And given the hoops one has to go through to interact with a SQL database from the average language, it’s not even true.

Argument #3 is indeed true. But using SQL is hardly the only way to accomplish this objective. A debugger is another (and nobody has ever asked for a query language for a debugger.) Another way would be to map all data objects to web URLs as we do it in InfoGrid and use the web browser as the “query language”.

Although CDIF hasn’t been any more for over 10 years, it’s amazing how many people I still keep meeting that say they had been involved at some time, and that they have nothing but the highest respect for the work that was done there. I’m in that camp, and InfoGrid would not be if it hadn’t been for what I learned in CDIF.

CDIF was started to move information from one CASE tool to another. To accomplish this, the CDIF architects designed a very elegant architecture:

A language to express a conceptual information model. CDIF called this the MetaMetaModel.

An extensible list of conceptual information models. CDIF called those SubjectAreas.

Data instances that are instantiated according to the conceptual information model. CDIF called those Models of various kinds, given CDIF’s purpose.

A transfer format that could carry any data instances of any model that could be defined within the CDIF architecture.

The beauty of this architecture is the separation of concerns: the transfer format, for example, would transfer whatever information correctly, even if the schema for the information had not even been defined at the time the transfer syntax was frozen.

InfoGrid uses several technologies for instance transfer, including object serialization for persistance purposes, InfoGrid extensions to RSS and Atom, and the XPRISO protocol to keep distributed, replicated instances in sync with each other.

Naturally, given the many years that have passed, InfoGrid goes beyond CDIF in many ways, including:

[To be clear, this is just the part of InfoGrid inspired by CDIF. InfoGrid is a software platform, not just a way to move data around. It goes far beyond with REST-ful user interfaces, automatic persistence to a variety of different data store technologies, bidirectional synchronization, in real time, of instances held in different places, via the XPRISO protocol, and real-time information integration via the Probe Framework.]

This is as good a time as any to say thanks to the CDIF folks. CDIF was easily the place where I learned more about information technology in the shortest amount of time, ever. Probably because so many companies sent their chief architects to meetings. For some time I even had the fortune to serve as CDIF’s Technical Vice Chair.

So, thanks, to:

Adrian Blakey (Sybase)

Bob Lechner (Univ. Massachusetts, Lowell)

Bob Matthews (IBM)

Chuck Foley (Intersolv)

Chuck ‘CQ’ Rehberg (DEC)

David Swift (Cadre)

Hugh Davis (ICL)

Jacob Okyne (Lucas)

Kelsey Bruso (Unisys)

M’hamed Bouziane (DEC)

Mike Imber (LBMS)

Mary Lomas (Oracle)

Paolo Puncello (FINSIEL)

Pete Rivett (Virtual Software Factory)

Rob Hill (Deft/Sybase)

Woody Pidcock (Boeing)

Shaike Artsy (Transtar)

Tammy Kirkendall (NIST)

and many others…

For what it’s worth, InfoGrid would not have been conceived without you.

A variety of mechanisms are available to developers to get data into and out of InfoGrid applications. Here is an overview:

Export:

Each data element (aka MeshObject) in an InfoGrid application has a URL. The easiest form of export is to simply access the MeshObject at its URL (subject to access control).

The MeshWorld example application shows how the Viewlet Framework can be used to easily make multiple formats available at that same URL, e.g. HTML, JSON, RSS and Atom. For example, http://example.com/object-1 may be the MeshObject’s URL that emits HTML, while http://example.com/object-1?lid-format=mime:text/json emits a JSON feed.

The WritableProbe from the Probe Framework can be used to push data out, in any format, based on a configurable schedule. This is particularly advantageous if the InfoGrid application accesses an outside information feed, and makes changes to the imported objects; WritableProbe makes it easy to “write back” those changed objects to the feed from where they came from (assuming the feed permits updates in some fashion).

While the Probe Framework can be used to perform one-time imports, it goes beyond that. Usually, developers ask the Probe Framework to check back, on a regular or adaptive schedule, whether the content of the feed was updated since it was read last. If so, the Probe Framework will incrementally update the previously imported data with no additional programming effort. This enables the developer to focus on their application, and not on how to reconcile old and new data sets, which is typically a major expense and QA headache.