Java Content Repository API Introduction

As content management applications become more popular, the need for public, standard content warehouse APIs is becoming increasingly apparent. The goal of the Content Repository for Java™technology API (JSR-170) is to provide such an interface. In this article, I will implement the Apache Jackrabbit with open source JSR-170, design a simple backend similar to the Viking Encyclopedia, and study the features offered by this promising framework.

If you've ever tried to develop a content management application, you should be very clear about the inherent challenges of implementing your content system. The territory is a bit fragmented and many suppliers have their own private warehouse engines. These difficulties exacerbate the complexity and maintainability of such systems, enhance vendor lock-in, and increase the need for long-term support for traditional systems in the enterprise market. With the increasing popularity of enterprise weblog and electronic Enterprise document management, the demand for standardized content warehouse interface is more significant than ever before.

The content Repository for Java Technology specification is developed as a JSR-170 in the Java Community process, and its goal is to meet the needs of these industries. The specification provides a unified API in the JAVAX.JCR namespace that allows vendor-neutral access to any conforming warehouse implementations.

But API standardization is not the only feature that Java Content Repository (JCR) brings. One of the main advantages of JSR-170 is that it is not tied to any particular underlying architecture. For example, the backend data stores implemented by JSR-170 can be file systems, WebDAV warehouses, XML-supported systems, or SQL databases. Also, the export and import capabilities of JSR-170 allow integrators to seamlessly switch between backend content and JCR implementations. Finally, JCR provides a simple interface to place the interface over a variety of existing content warehouses, while standardizing some complex features such as versioning, access control, and search.

There are several ways to use when discussing JCR. In this article, I study the features provided by the JSR-170 specification from a developer's perspective, focusing on the available APIs and interfaces that allow programmers to efficiently utilize JSR-170 warehouses when designing content applications. As a hypothetical example, I'll implement a small backend for a Viking-like encyclopedia called Jcrwiki, which will support binary content, versioning, backup, and search. I use the Apache jackrabbit (JSR-170 Open Source implementation) to develop this application.

Warehouse Model

Let me start with a high-level discussion of the warehouse model to familiarize you with JCR. The warehouse model is a simple hierarchical structure that looks like a tree with n forks. It consists of a single content warehouse with one or more workspaces. (The discussion in this article is limited to a single workspace.) Each workspace contains a project tree, and the project can be either a node or a property. A node can have 0 or more child nodes and 0 or more related properties, and the actual content is stored in child nodes and attributes.

Each node has and has only one primary node type. The primary node type defines the characteristics of the node, such as the attributes and child nodes that the node is allowed to have. In addition to the primary node type, a node can have one or more mixed (mixin) types. A mixed type is more like a decorator, providing additional features to the node. Specifically, the JCR implementation can provide three types of predefined blends:

Mix:versionable: Allow node to support version management

Mix:lockable: Support node locking function

Mix:referenceable: Provides an automatically created Jcr:uuid attribute that gives the node a unique identifier that can be referenced

This structure is shown in Figure 1. The circle represents the node, and the rectangle represents the property. See nodes A, B, and C, all derived from a root node. Node A has two properties, namely a string "John" and an integer 22.

Figure 1. Warehouse model with more than one workspace