It's a good time for Java Content Repositories. The second version of the JCR API has been released for public review as JSR-283 and, at the same time, the first version (JSR-170) has been doing well: Jackrabbit is now a top-level Apache project, is gaining object-content mapping tools and has started to move beyond content management systems to fill roles in other development efforts, such as the persistent store for business rules in JBoss Rules' BRMS and artifactory, a Maven 2 repository.
JSR-283 aimed to improve on JCR 1.0 in the following ways:
- Management of access control and nodetypes
- Improved interoperability through new standardized node types including meta-information and internationalization
- Extensions to content-modeling capabilities
- Federation, cross-repository and cross-workspace functionality
- Active development of existing query-languages, versioning and observation
- Remoting and client/server protocol mappings
InfoQ took the opportunity to speak with David Nuescheler, CTO of Day Software and the spec lead for JSRs 283 and 170 about Java Content Repositories and the public review of the second version of the API. On the subject of adoption of JCRs by implementors:
The adoption on both sides of the API has exceeded my expectations. On the content repository implementation side of things we have probably a couple of dozens of implementations.
What I find particularly noteworthy is that we have already four independant opensource implementations of JCR, which is a fantastic achievement for a v1.0 standard in such a short timeframe, and I can't remember any other JSR which was adopted that quickly.
And on the subject of adoption by developers:
More importantly on the other side of the API, on the application side, we have seen a tremendous pick-up of projects and products that are using JCR. We try to keep a list of the tip of the ice-berg on the (jackrabbit wiki)[http://wiki.apache.org/jackrabbit/JcrLinks], but it is hard to keep track.
JCR has certainly grown beyond any other content repository technology in that respect. I think the number of independent application developers already today has outgrown any proprietary content repository API.
When asked what applications are well-suited for using a Java content repository, particularly in contrast to a use of a relational database:
I would call it a common misconception that the use of content repositories is limited to to "content management systems" of any form or shape (DM, DAM, WCM, SCM). I think it is important to understand that JCR is an ideal storage layer for for webbased CMS but is also an ideal storage for most other applications.
In my mind a content repository is the ideal storage for just about any modern application that would like to make use versioning, fine grained access control, full-text search, large binaries and all the other services that the content repository exposes.
Personally, I would always prefer the richer JCR interface over a JDBC interface in any of my applications, but this is largely due to fact that I am very comfortable using JCR.
For people that have no previous experience with JCR i would recommend to pick a (what i would call) obvious application. This would be an application that leverages the additional services of a content repository like versioning, access control or a hierarchy.
Talking about the overall theme for JCR 2.0:
We certainly put a lot of effort together with the large ECM vendors in JSR-283 to come closer to commonly used ECM practices and therefore make it much easier for vendors to become compliant the specification.
David also lists his personal 'top ten' features from JCR 2.0:
- Query extensions mainly around extended support for SQL, specifically JOINs; We also introduced Java Bindings for the Query Object model that allow for easier "query wizards" and last but not least "Prepared" queries.
- Access Control Management to go beyond the introspection that is already specified in JCR v1.0.
- Retention Policy & Hold Support to enable records management applications sitting on top of JCR repositories in a standardized fashion.
- Simple versioning to provide for repositories that only support linear versioning. Versioning extensions around "Baselines" and "Activities" to cover the full configuration management spectrum.
- Lifecycle Management to allow to easily hook content into a process engine.
- Standardized Nodetype Registration that allow application to register and manage their nodetypes with repository.
- New property types and new nodetypes to enhance application interoperability around common meta data.
- Workspace Management to allow for creation and deletion of workspaces in a repository.
- Shareable nodes that allow the tree in a content repository workspace to become a more implicit network.
- Journalling Observation that allows offline/polling applications to find out what happend in a content repository since they last checked.
For more information, you can read the public review of JSR-283, David's Simple Rules for Blissful Content Modeling and stay tuned to InfoQ's coverage of Java Content Repositories.