JCR Deep Dive

Introduction: Managing Content

A good content management system should be able to manage highly structured content. It does not only need to manage the content and its properties, but also associated metadata, versions, and state (such as locking/unlocking and publication state). The resulting structure is essentially an object graph of various nodes: content, properties, versions, metadata.

Let’s explore this idea by the example of a simple web page. The page contains a headline, left column that contains a teaser and a formatted text field, and a sidebar column that contains two teaser modules.

Applying object-oriented design principles, we can identify the following major classes:

• Page which contains the headline as well as properties for the left column and sidebar which can reference any number of content modules
• Content Module as a superclass for the two different types of content modules found on this page: Teaser and Formatted Text Module. This was derived using the object-oriented principle of abstraction and generalization: a Teaser is a Content Module.
• Teaser: Teaser module which inherits the title from the parent class
• Formatted Text Module: Contains a formatted text properties

Consequently, the sample page above can be depicted using the following object graph:

Naturally, this graph will become more complex once adding version nodes of the individual content and property objects. Modeling an entire web site in this fashion results in an even bigger object graph.

Object-oriented databases have traditionally been excellent at persisting complex hierarchical data. For example, Poet, one of my former companies, had implemented an enterprise content management system on top of their object-oriented database. Most other vendors, however, embraced existing enterprise infrastructures and built their repositories on top of relational databases. The repository, as outlined previously, acts as an abstraction, providing applications access to the content (the above object graph) while insulating the application from the storage implementation details.

Other content management systems that have followed this approach are, amongst many others, CoreMedia, Fatwire, and Day Systems. Day systems pioneered the Java Content Repository standard that specifies a vendor-neutral API to access and store content structures. However, in the author’s experience, object oriented content modeling techniques can be applied to almost any enterprise content management system, even if the support the different frameworks offer for this architecture vary greatly.

The Java Content Repository

The Java Content Repository (JCR) standard, which is based on the Java Specification Requests JSR170 (version 1.0) and JSR 283 (version 2.0), provides a Java-centric object-oriented storage API specifically targeted at content management scenarios. The JCR is not a content management system or a full-fledged content management system API, but rather a content repository API. A content repository provides a common API for all content-driven applications and CMS components, which require access to the content. It provides methods to read, write, and query content. The primary motivation of the JCR standard is to provide a standard and vendor-neutral programmatic interface for content repositories, allowing applications of multiple vendors to interact efficiently.

This chapter will provide an overview of the basic concepts of the JCR, which are a foundation to the subsequent chapters. The chapter will not give you an overview understanding of the JCR specification, but will not fully cover the JCR in-depth, as this would most definitely be beyond the scope of this book. There are numerous excellent resources to consult, first and foremost the JSR 170 and JSR 283 specifications and accompanying API documentation.

This chapter covers concepts found both in JSR 170 and JSR 283 and will point out any features that are limited to JSR 283 as most JCR-compliant implementations currently only implement the JSR170 specification. All sample code in this chapter has been written to work using Apache’s open source implementation of JSR 170, JackRabbit.

Comments