Frank Sommers has another article on Artima, called "Catch Jackrabbit and the Java Content Repository API." (Jackrabbit is the project name of the JCR reference implementation.) The article walks through the reasoning behind the API, and steps through creating a blog management app with Jackrabbit.

Perhaps the biggest benefit of the JCR API is that it doesn't try to persist Java objects, and cares little about an application's object model. Instead, the JCR API focuses entirely on the content, or data, of an application. While this may at first sound like a step backwards, it actually creates a very clean and easy-to-use programming model with a sharp focus on a handful of data management tasks, such as versioning.

What do you think?

I can think of many ways to use this type of repository. Widewpread adoption, however, will require implementation that are as fast and efficient as today's DBMS based solutions.

-Dave
<font size="-2">
My Blog
</font>

the repository can be built on top of RDBMS

Just because it (can) use an RDBMS underneath, does not mean it will be as fast. It will only use RDBMS to represent the REPOSITORY data model - not YOUR data model. Therefor, it applies another level of abstraction above it to translate the result sets into the JCR data model, much like the ORM tools do today.

Aside from that - it seems a promising technology, which I hope will get adopted. What does bother me, however, is that soon O/JCM mapping tools will start rising, since we will probably want to map the JCR data (Nodes, Properties, etc) into the application's domain objects. Who knows - maybe Hibernate will soon make a module that persists domain objects into JCR...

THEN I'd start worrying about speed ;-)

I can think of many ways to use this type of repository. Widewpread adoption, however, will require implementation that are as fast and efficient as today's DBMS based solutions

Nope, they only have to be as fast as necessary. RDBMSs do what they do well, and cover a very large domain of problems.

CRs are of a more limited domain, so while they need to perform well, they typically don't need to perform as well as a RDBMS.

Now if you try to stuff your order entry and inventory process into a CR, you will have problems, but that's not the CR's fault.

Very nice is the fact (as pointed out in the artima article) that this was the first JCP effort to be "open source" focused from the get go (thanks the the "flexibility" of the JCP 2.6).

Once the JCR is final (which appears inevitable?), and there is an open source type implementation (also already on track per Jackrabbit) if then certain *types* of content stores could agree on a "node type" vocabulary that would be ideal. That would be frankly cool as hell. (But even without that the JCR and Jackrabbit are still incredibly useful and would still become quite popular, at least I hope so because it would surely make a developers life easier ;).)

Hi Charlie:

This is something I've been thinking about. Would you please elaborate on what you meant by content stores agreeing on a node type vocabulary? Thanks in advance!

-assmund

After study Documentum's Document Object Model. I notice, you can use OR mapping tool like Hibernate to persistence the folder and document model easily.

It is just a tree of objects.

I can not understand why CMS vendor like Documentum use Oracle, it need only very based RDBMS feature, only primary key and index is enough. Documentum's Oracle schema does not even have foreign key.

Use Hibernate + Mysql, is very simple, and Hibernate can cache the object tree in the memory to get performance. For simple indexed search Mysql is much faster then Oracle.

I have been thinking to make my own CMS system based.

1) Standard Documentum Object Model like JSR 170
2) UI component model based on Java Server Face.

I just meant the obvious such as the article notes itself, in that something like a shared node "data model" from common types of content or common usage paradigms (such as blogs, calendaring/scheduling, cataloging products, etc) used in addition to the data model nuetral "content" API (JCR) would be powerful stuff that could enable a great deal of very easy interoperablity (at least theoretically ;)).