I’ve been quite disappointed by the progress made towards JSR 170 compliance. I was never very hopeful but this has been worse than I expected. Of the commercial product vendors, only Day has a product that is JSR 170 compliant. But then Day has been leading the effort and it is to be expected of them. Day have also created a connector for Documentum and connectors for different other commercial products are under development but then this is an effort by Day and not by those vendors.
The situation with Open Source, although slightly better, is still far from being as good as it should be. Magnolia is the only product that has a decent support for JSR 170. However, its Document Management offering is not Open Source. Alfresco, the newest Open Source product in this space has made its repository JSR 170 compliant, although very reluctantly. They only support level 1 though and support for level 2 will soon be there in future versions.
I hope the situation will improve soon and more products will start supporting JSR 170 (and JSR 283, which is an improvement over JSR 170).
Updated March 01, 2006
Alfresco 1.2 has been released. It now supports JSR 170, level 2.
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.
The reason I left out eXo is that I *think* it is more of a portal rather than a CMS product. And for portals, it makes sense to have JSR 170 compliance because they pull data from other repositories but for CMS products, it’s the other way round. If they make their repositories JSR compliant, they are letting other (portal?) products access data stored with them more easily. This has a potential of reducing their market share. Infact, BEA also recently incorporated JSR support. I think they also used Day’s implementation.
I agree with your observation about difficulties in moving over to a JCR repository. So I guess i’m being impatient in expecting the product vendors to be compliant so soon 🙂
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.
eXo has an ECM product that competes with Alfresco and others in its version 2. We have already won several bids were alfresco was there, and I guess the other is true too; same for Magniolia. So the Open Source Java ECM is rising and portal integration is at the center of it.
Actually there is the JCR product (level 1, 2 and all the optionnal features are supported) and on top of it several portlets that build the ECM suite.
For now the portlets are only deployed in eXo portal but will be in any portal soon.
As for the spec, I agree that it is too soon to make conclusions. The spec is not that simple to implement and it is quite a young one. Let’s see at the end of the year when we have more than 2 JCR full compliant impelmentations (eXo and JR so far and soon Alfresco as John says 🙂 ).
Ah, and note that Alfresco is deployable in eXo Portal 😉
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 😉
Except Day I was not able to find any JSR-170 commercial products (not open source) and due to this it seems to not be a good idea to use it since there is no alternative.
I think that JSR 170 is great and the specifications looks good. I cannot see why there are no requirements for it due to lack of commercial vendors.
Congratulations! You have just won a new feed reader 🙂 .. really nice blog, Mike.