What is JCR?

Content Repository API for Java (JCR) is a specification for a Java platform API for accessing content repositories in a uniform manner. The content repositories are used in content management systems to keep the content data and also the meta-data used in CMS such as versioning meta-data. The specification was developed under the Java Community Process as JSR-170 (Version 1) and as JSR-283 (Version 2). The main Java package is javax.jcr.

A JCR is a type of Object Database tailored to the storage, searching, and retrieval of hierarchical data. The JCR API grew out of the needs of content management systems, which require storage of documents and other binary objects with associated metadata. However the API is applicable to many types of applications. In addition to object storage the JCR provides APIs for versioning of data, transactions, observation of changes in data, and import or export of data to XML in a standard way.

The data in a JCR consists of a tree of Nodes with associated Properties. Data is stored in the Properties, which may hold simple values such as numbers and strings or binary data of arbitrary length. Nodes may optionally have one or more types associated with them which dictate the kinds of properties, number and type of child nodes, and certain behavioral characteristics of the nodes. Nodes may point to other nodes via a special reference type property. In this way nodes in a JCR offer both referential integrity and object oriented concept of inheritance. Additional node types include the referenceable node type which allows the user to reference said node through use of a universally unique identifier. Another popular type is the versionable type. This makes the repository track a document’s history and store copies of each version of the document.

The Content Repository API for Java Technology (JCR) is an ongoing effort to define a standard repository interface for the J2SE/J2EETM platforms. The goal of a content repository API is to abstract the details of application data storage and retrieval such that many different applications can use the same interface, for multiple purposes, without significant performance degradation. Content services can then be layered on top of that abstraction to enable software reuse and reduce application development time.

A traditional application uses multiple data stores during its operation. For example, a typical email application will store its configuration in a property list, its address book in a table, messages within indexed files (folders), message properties in separate tables, and search indices in a binary hash. In most cases, each of those storage formats would have their own interface. The application developer would spend a significant portion of the development effort designing, creating, and maintaining those interfaces.

For detailed information read below URL..

Introduction to JSR-170