The databases underlying many applications aren‘t particularly suited for content management, due to special requirementsspecific to content management for handling objects such as documents and images.
|
| |
That‘swhere content repositories come into play. Typically sitting on top ofa database, repositories add functionality, such as relationships (say,indicating that one page links to another), versioning, or fine-grainedsecurity. To make this architecture work, an API, which allowsapplications to interact with the repository, is required.
Troubleis, practically every CMS has its own, often proprietary, contentrepository -- each requiring a nonstandard API. A few years back, DaySoftware proposed creating an expert group to define a standard contentrepository API. The result is the Content Repository API for JavaTechnology (or simply JSR 170) specification, which was just formallyadopted.
Alreadythere‘s been a lot of interest in and, more importantly, tangibleproducts built around JSR 170 Version 1.0. Day provides a JSR170-compliant repository as part of its commercial Communiqué 4enterprise CMS and sells the stand-alone Content Repository Extreme(CRX). The company also licensed this specification to The ApacheSoftware Foundation (ASF), where it‘s the cornerstone of the opensource Jackrabbit project.
As shown with JBoss and Liferay(which use Jackrabbit), JSR 170 enables developers to quickly programto a content repository. Equally significant, if you want to swap in adifferent compliant repository you can without recoding. Further, therepository isn‘t tied to any one application. This added benefitpermits a single repository to be shared by your portal, CRM system, orlegacy application.
Dayalso sells JSR 170 repository connectors for EMC Documentum and BEAWebLogic Portal -- with others in the works for Microsoft SharePoint,FileNet, OpenText LiveLink, and Interwoven. As a result, even thoughthese products do currently have legacy repositories, Day‘s connectorsshould reduce a lot of work normally associated with integrationprojects. IT staff only need to learn one API and should no longer beconcerned about which vendor‘s repository is underneath theirapplications.
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 newnode types (for instance, meta information and better ways to handleinternationalization).
Still,JSR 170 is an admirable starting point. It benefits enterprises by nottying you to a particular repository, eases development, andstreamlines repository management. In fact, some organizations havealready consolidated dozens of disparate repositories into just one ortwo. Finally, application vendors can focus on improving theirproduct‘s unique features and leave the content repository part tocompanies that do that best, such as Day or the ASF.
