JSR 170: A standard content repository

The databases underlying many applications aren't particularly suited for content management, due to special requirements specific to content management for handling objects such as documents and images.

That's where content repositories come into play. Typically sitting on top of a database, repositories add functionality, such as relationships (say, indicating that one page links to another), versioning, or fine-grained security. To make this architecture work, an API, which allows applications to interact with the repository, is required.

Trouble is, practically every CMS has its own, often proprietary, content repository -- each requiring a nonstandard API. A few years back, Day Software proposed creating an expert group to define a standard content repository API. The result is the Content Repository API for Java Technology (or simply JSR 170) specification, which was just formally adopted.

Already there's been a lot of interest in and, more importantly, tangible products built around JSR 170 Version 1.0. Day provides a JSR 170-compliant repository as part of its commercial Communiqué 4 enterprise CMS and sells the stand-alone Content Repository Extreme (CRX). The company also licensed this specification to The Apache Software Foundation (ASF), where it's the cornerstone of the open source Jackrabbit project.

As shown with JBoss and Liferay (which use Jackrabbit), JSR 170 enables developers to quickly program to a content repository. Equally significant, if you want to swap in a different compliant repository you can without recoding. Further, the repository isn't tied to any one application. This added benefit permits a single repository to be shared by your portal, CRM system, or legacy application.

Day also sells JSR 170 repository connectors for EMC Documentum and BEA WebLogic Portal -- with others in the works for Microsoft SharePoint, FileNet, OpenText LiveLink, and Interwoven. As a result, even though these products do currently have legacy repositories, Day's connectors should reduce a lot of work normally associated with integration projects. IT staff only need to learn one API and should no longer be concerned about which vendor's repository is underneath their applications.

But, like any technology, there's room for improvement. JCR 2.0 (JSR 283) was just proposed. This covers areas such as access control and new node types (for instance, meta information and better ways to handle internationalization).

Still, JSR 170 is an admirable starting point. It benefits enterprises by not tying you to a particular repository, eases development, and streamlines repository management. In fact, some organizations have already consolidated dozens of disparate repositories into just one or two. Finally, application vendors can focus on improving their product's unique features and leave the content repository part to companies that do that best, such as Day or the ASF.