Java Content Repository – JCR
Posted on December 11, 2008
Filed Under jcr | Leave a Comment
In my last post I talked about the recently published Content Management Interoperability Services (CMIS) specification. A noble and worthwhile specification that enables content applications to access vendor-specific content repositories in a standard way. This is achieved by each vendor exposing their content services through CMIS web-based, service-oriented interfaces. The aim of CMIS is simple – the empowerment content applications. Arm content applications with enough of the common and core services typically attributed to managing content and sit back and see what good things we can make. As a fallback, content applications can always use vendor-specific, proprietary APIs to satisfy low level requirements.
However CMIS, pronounced see-miss, is the new kid on the block. Its older brother, JCR, has been around for a while but has had mixed reactions from the CMS community at large. Why is that?
Let’s start with what the JCR is? Well it’s THE Content Repository API for Java. It is a specification, for the Java Platform, that facilitates access to content repositories, in a uniform way. In the CMS world, a content repository is where applications store stuff such as pdfs, email, sms, voice message, word documents, images, and so on. Under the hood, nobody (read as customers) cares where the content is stored. Database, filesystem, XML files. Irrelevant. To the application accessing the content repository, there are a bunch of accessible content services for storing, retrieving, searching, observing, versioning, locking and moving content.
So the JCR is nice from a techie perspective, but where’s the business value. Well as you know content is everywhere. Content is stored in just about any place you can find it across the enterprise. Not only that, but content is stored in many different types of content repositories ranging from your everyday file systems and databases, to vendor-specific solutions such as Vignette, Documentum, Lotus Notes and Sharepoint. The JCR wraps a Java blanket over all these content repositories, enabling content applications to access them through a single API. So if you could go to your boss, and say that can write a single application can manage content across all the weird and wonderful content repositories in your organisation, I reckon they would see the immediate value. Don’t you. Taking this a little further, you can build content applications to multiple content repositories to perform intelligent search, export documents from one system and import them into others, audit documents, archive documents, monitor document flow and so on. With standards, doors kinda open.
This all sounds too good. So what’s the catch. Well to be honest, there isn’t one. However, depending upon your perspective, the JCR can be a non-starter. Firstly, if you’re seeking a tight integration with a content repository via the JCR, your content application needs to be Java because the JCR is a Content Repository API for Java. You can however interoperate via web services or RESTful APIs, but the communication is much looser in these cases. Moreover, the JCR specification imposes constraints on how you structure your content within the repository. However, that is always going to be the case. But the reality for some folks is that their content repositories will not map nicely onto the JCR content model making it hard for their content to be available to JCR-based content applications.
Also, when building content applications, its the small things that tend to catch you by surprise. For example, when integrating with Lotus Notes via JCR, a Lotus Notes database is a content repository. However, each email box within Lotus Notes is a separate database. Interesting. So, to write a JCR content application that searches 10 Lotus Notes email boxes requires you to connect to 10 content repositories. This is not really a big deal for a simple, read only search application. However, if you need to move mail between email boxes there is a whole other bunch of stuff you need to take into consideration. You have now entered a different world of challenges.
But these challenges are not restricted to the JCR but to CMIS and other vendor-related APIs. But if things were easy, life wouldn’t be interesting, would it now…
Comments
Leave a Reply
