Sometimes I wonder if the name "Generic Persistent Object Model" is misleading. Many people will, quite rightly, assume that it is primarily about "persistence". That the "objects" are stored "persistently" to some external media and later retrieved.
It is true that I consider this to be a major feature of the system, but it is also true that the model gains its expressive power from structures that have nothing to do with "persistence". It is simply that they have been implemented with "persistence" in mind.
I have always been fascinated by different programming idioms and paradigms. In particular I am intrigued by the different models of relational databases, object oriented programming and spreadsheets.
For example, given the same problem of sorting a set of data, how would a programmer
view the task if the data was 1) in a spreadsheet column, 2) in a database table, or 3) in
an in-memory java List.
I continue to be amazed at certain technologies. Consider a modern compiler:, lexical analysis, code generation, symbol management etc. It is a genuinely complex system that in just a few seconds achieves what used to take many hours, and does a better job. I am amused at the thought of a J2EE project given the task of writing a compiler. Of course, the tokenizer is a very useful component, so would be defined as a separate Web Service. We would define XML base messaging, using XSLT to transform between representations. We would undoubtedly utilize "Container Managed Persistence" to help with the symbal table, and JMS would further help to ensure we had modularised the system correctly. I imagine that a J2EE version of (say) a FORTAN compiler could well take around the same length of time to develop as the original version in the 1950s, but may not scale as well.
The point here is to try and imagine how you would achieve different functionalities with different idioms and approaches. Initially, databases were just a means to store data, then query languages developed that could take advantage of the table based representation. With, spreadsheets, simple row/column formulas helped accountants define simple models before graphics formulas dragged the spreadsheet into the management report.
Mainstream programming moved from procedural, library based development to data centric and object oriented approaches. But think for a while about not the "storage" models of applications, spreadsheets and databases, but rather the different models of computation. How these are expressed.
Because it is not only the "storage" domain that GPO addresses. But also the
"computational" domain. To ensure that GPO provides a powerful model to
develop systems.
Previous papers have addressed expressiveness compared to database operations and functional equivalence with spreadsheets. This paper address the idioms of java-based object oriented programming.
Okay, let's be clear, this isn't a tutorial. But let's consider how we connect objects together.
Typically, some object will have some data associated. Suppose we are defining a "shopping basket" type object.
We can create a new "basket", maybe we have a "current customer". We might have some application state that remembers this customer, and any "basket" we are filling.
The "basket", will have some array of "items". An "item" will have a "price" and "description" and some "productCode" possibly.
We would probably define some interface so that a new "item" could be added to the "basket".
Internally we might create a java.util.List object to manage the references to
each "item". We may define some methods that apply to an "item", in which case these methods
might specify an extra parameter for the "owning basket", or possibly we might "manage" a
reference to the "basket" from each "item". Both approaches might seem equally valid.
If an "item" was removed from the "basket", we would remove it from the List of items and null any reference from the "item" to the "basket" if one was maintained.
To compute the total cost of the basket, we would define a method "recalc" on the "basket" object to iterate over the "item" List and add all the values together.
All this should be pretty familiar to any programmer, whether they program in java, C++, C#, smalltalk, lisp, prolog, modula, pascal, ada, cobol, assembler, fortran etc...
Well, maybe some might be confused by the idea of objects and pointers, but they'd understand the basic process alright.
The Generic Model (we'll forget the Persistent bit for now) introduces
a new idiom. This idiom has more in common with Ted Nelson's ZigZag
than anything else I've found.
This new idiom can be considered as a fundamental mechanism to associate objects one to another, and it works. It really does.
Just like ZigZag the main feature of the Generic Model is two-way links. Consider:
GPOMap mgc = new GPOMap(om);
mgc.set("name", "Martyn");
GPOMap ctc = new GPOMap(om);
ctc.set("name", "Cut The Crap");
ctc.set("author", mgc);
In the above we have stated that mgc is the "author" of ctc, but look at this:
mgc.getLinkSet("author").size();
Would return the number of objects that define mgc as their "author".
This seems to have more in common with relational database functionality than conventional programming structures.
Consider for a while what this means.
This mechanism implements a "two-way" "one-to-many" object association. The programmer does nothing to maintain it, or even to define it. They simply set it.
Internally the generic model manages a number of double linked list structures
as the properties are set. But this is of no concern to the programmer, since they simply
work.
How would we maintain our "basket" using the generic model?
Pretty easily really:
basket.set("customer", customer);
item.set("product", product);
item.set("basket", basket);
From this we could find:
The customer of the basket and all the baskets of the customer
The product of the item and all the items of the product
The basket of the item and all the items in the basket
Don't you think, really, that that is pretty amazing!
This is just a taste of the generic model, if this has succeeded in
tantalising your tastebuds then checkout some of the other
whitepapers or
visit www.cutthecrap.biz and have a general
look around.
As always, I would appreciate all feedback. Even negative feedback is appreciated since at least it shows you can be bothered. Just mail me with your thoughts.