JSR 170 Report Card

Another open source product supporting JSR 170 is the Exo Portal, level 2 I believe. Exo has their own implementation of the spec. Magnolia does not implement the spec but uses Apache Jackrabbit (or Day’s implementation for a price). Keep in mind that a CMS’ data model will typically be the result of several years of development, and moving over to the JCR is not a decision that will be taken lightly. Also, the spec was only finalized half a year ago, so I think it’s too early to be disappointed.

Anyhow, there is a problem here: CMS customers do not realize the value of having a standardized (and portable) content repository, and therefore there is definitely no value for the vendor (why should they remove the lock-in to their repository?). I believe we need to to clarify business value that benefits proprietary vendors before the JSR 170 lifts off.

I believe the reasons that JSR-170 has not taken off as fast have to do the same reasons that we (Alfresco) were initially reluctant to support the standard. Its core model of node management is overly generalized and yet it tackled versioning and XML management to a degree that went way beyond what most vendors supported. The position to challenge the vendors to raise the bar in their capabilities was a political mistake. It wasn’t so much creating a lowest common denominator as trying to shift the paradigm in how content applications are created. Also, the lack of any metadata standardization with no standardized way of creating metadata types made creating portable applications very difficult.

However, JSR-170 is a good model for some types of applications. Tree-traversal fits the node/tree model quite well. A generalized mechanism to extract properties and their values provides a good mechanism to inspect any repository and can be used intelligently to pick apart the content. There can be some applications for web content management (analyzing a web site) and records management (view, but not really write to a records store). There is perhaps an over reliance on XML, but it does present a query interface that is flexible and capable of searching through most types of content stores. Unfortunately, it relies a bit too much on XPath (due to IBM’s insistence from what I hear), but hopefully that is compensated by the “SQL-like” query language that more programmers will recognize. The generalized nature of JSR-170 can come in handy in the import/export capability to allow the underlying implementations to decide how to dump and load data, interpreting semantics to their advantage.

In the greatest strength that JSR-170 has is that it is about the only game in town at the moment, with the possible exception of WebDAV. Because of this, I believe several ECM vendors are implementing JSR-170 (perhaps kicking and screaming).

We are not reluctant implementors now as we see an advantage to our customers and partners in JSR-170. There is still a need for a platform independent, stateless API, but JSR-170 can serve the Java community well. We also believe that some of the short-comings can be addressed in JSR-283: particularly standardization of data types, security, and introducing SPIs that can help standardize semantics. Simplifying some of the concepts of versioning and workspaces can also bring a lot more of the vendors along as well.

The Alfresco implementation of Level 2 is probably closer than you think. It is currently in the Release Candidate of Version 1.2 with the final release coming out shortly.

By the way, Magnolia’s Document Management has been open sourced.

Magnolia believes in JSR-170 - we have bet our product on it 3 years ago. Today we have obviously more experience with JSR-170 than most vendors out there, and are potentially the only one that lets you plug & play repositories.

Ah, Exo has won deals against Magnolia? I guess we all win deals against our competitors one day or the other - for instance, Alfresco’s big and only reference customer runs their intranet on Magnolia.

Exo is relevant in France. Everything that is relevant in France is ignored everywhere else, and vice versa