« Getting to the Point | Main | links for 2006-08-28 »

Zope, Java Content Repository, and Web Architecture

Roy Fielding: "With the JSR170, and what's currently JSR283, we're trying to take the same engineering principles and architectural principles that we apply to the web, and try to see what's applicable to inside the application server, or inside the server based implementation of server based applications"

[the podcast entire is highly recommended for people who want to get some background history on the Web and REST architecture.]

Zope/ZODB is the most mature implementation of JSR170 I know of. The JSR170 content model is hierarchical, just like ZODB (and any interesting content model built on top, like CMF and Archetypes).

Here's the diagram from the JSR170 spec:

jcr.png

Anyone who ever had to explain Zope will be familiar with that kind of picture. The desirable characteristic about a tree based model is that you can store any data format in it, without hardcoding domain models and rulesets. By extension you can do this also with labelled graphs, which is how RDF gets to claim its high flexibility, being a graph based model. In an RDBMS you need to know the domain model to define tables and then you need to know the rulesets to decide what are integrity constraints and what are application specific concerns. To get a sense of the engineering work involved in trying to make an RDBMS flexible read Scott Ambler's Agile Database Techniques. It's possble, maybe, but not cheap to do. To be clear - preferring to manage content *as content*, instead of lossy extraction of domain entities is about preferring flexibility and independent evolution of systems. There's plenty of room for an argument that says RDBMS is suboptimal for managing content. And good luck with versioning or translation on top of relational databases while trying to manage the form and flexibility of the content over time. Yes, you can do it, but it's highly specialised and diffiicult work.

I doubt the backend storage is easily commoditised for tree based content. Like JCR, ZODB is ultimately an API but physical storage is difficult to abstract away for hieriarchal content models. It's not clear, at all, that RDBMS can sanely support a hieriarchal content model for the long haul. RDBMS is the gold standard for enterprise data management and JCR170 as a Java API plays squarely in the enterprise space. "Everyone" wants an RDBMS backend - not for the data itself, but for operational simplicity, enterprise IT rationalisation, and the predictable performance characteristics. It's tough to know what the right tradeoff is. Ignoring RDBMS tech suggests not taking enterprise concerns seriously and risking IT ops and predictability in systems design and management. Ignoring the content and data longevity concerns suggests you end up preferring expensive non-repurposable silos than allowing the business to function well. I think these are not mutually exclusive positions, but getting the balance right is tough.


August 26, 2006 01:20 AM

Comments

Bill Seitz
(August 26, 2006 01:24 PM #)

Forcing the object database to be hosted on an RDBMS seems pretty much like CargoCult thinking, doesn't it? OK, you have some admin tools, but most of them don't really buy you anything when the underlying logical structure isn't set-oriented. And any belief that performance and transactional integrity is provided automatically within the RDBMS engine itself seems misguided.

I wonder whether you'd be better off taking chunks of code from an OpenSource RDBMS and rebuilding a native-ODB with it... and then making the name a fork (MyOQL), etc. for marketing leverage... (pardon the brain fart)...

http://webseitz.fluxent.com/wiki/z2006-08-26-DehoraZodbFielding

Post a comment

(you may use HTML tags for style)




Remember Me?

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1954