After investigating
JCR 1.0 (spawn of
JSR-170) implementations (
Alfresco and
JackRabbit, both excellent realizations) for a few days, I feel a strange combination of excitation and disappointment. I am excited by the idea of having a standardized API to hit content repositories, a playground where proprietary interfaces have been ruling for a long time. The reason of my disappointment will take a little longer to explain.
One of the key selling point of JCR 1.0 is that it enables you to swap your repository from vendor A to vendor B, provided that they both support the same level of feature (so far JSR-170 defines 2 levels). This is true and it works but to some extent; and it is in this restriction that lies the glitch that annoyed me so much.
JCR repositories rarely come as naked JSR-170 implementations: they usually come complete with other ways of reaching their content (WebDav, CIFS, portals...) and - hopefully - useful administration tools.
Because JCR 1.0 is an extremely granular API, where familiar concepts like folders and files are not handled as such but abstracted as general purpose nodes, it allows each implementation to decide how to represent the classical hierarchy of folders everybody is used to and expects to find in a repository. And this is the crux of the problem: if you stick to the pure JCR API, you will be able to run your code on any compatible repository but the connected tools and other data retrieval channels will not recognize your data structure and will ignore it.
For example, a block of code will create a data structure that JackRabbit WebDav access represents as a folder containing a file, while the same block of code will store data that Alfresco will not be able to display in any of its data or web access tools. I have even come to inconsistencies (not the proper term because it is logical that it does not work) within the same tool: code that creates this folder and file that JackRabbit browser interface can render will be exposed as meaningless folder and files in its WebDav access.
The conclusion of this story is that yes, you will be able to swap one repository for another, but the trade-off is that you will potentially loose some or all of the extra features of the repositories. To me, this sounds like a major loss.
All this reminds me of JDO: so generic and versatile that it has never been good enough in one particular persistence strategy compared to Hibernate database-only persistence that has reached excellence and universality.
Let u’s hope that JCR 2.0, the upcoming spawn of JSR-283, will address this concern. But will it? Is it the interest of the expert group members to be potentially swapped-out when all of them look for lock-in strategies? Only time will tell.
