Browse Prior Art Database

Method for Providing Local and Remote Access to a Java Content Repository using Service Data Objects Disclosure Number: IPCOM000131171D
Original Publication Date: 2005-Nov-09
Included in the Prior Art Database: 2005-Nov-09
Document File: 3 page(s) / 34K

Publishing Venue



The Java Content Repository (JCR) specification ( defines data representations that are independent of their underlying repository implementation. It also provides persistence semantics and a caching mechanism to allow for efficient repository operations. However, given the connected nature of the JCR specification, it is difficult to provide a remoteable implementation of the JCR specification. The JCR representation of data is actually connected data which means that most of the operations invoked on the JCR data require calls back to the repository to maintain compliance with the specification. In an efficient remote implementation, it is critical to limit the remote calls given the speed of network response times. A method is proposed in this article to leverage the disconnected nature of the Service Data Object (SDO) specification (, and map SDO models to JCR types and constructs to provide for an optimized remote implementation.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 44% of the total text.

Page 1 of 3

Method for Providing Local and Remote Access to a Java Content Repository using Service Data Objects

     In order to expose JCR data so that it conforms to the SDO specification, a combination of mapping techniques and processing logic was developed to bridge the gap between the different data structures and capabilities provided by the two specifications. The JCR specification has the concept of a node type that defines the schema. The node type allows for property and child node definitions which can restrict the type of the data and the name of the data. There are several JCR property types such as the common primitives (long, double, string, date, etc.) as well as references and softlinks which serve to reference other data in the repository. SDO on the other hand has a simpler concept of data structures that consists of containment properties which are properties that contain children in the same SDO graph and non-containment properties which are either attributes or references to children in other graphs. The method documented bridges the two specifications in ways that are straightforward to the programmer and consistent with the intended usage of both specifications.

     Exposing the common primitives was a straightforward mapping. The JCR primitives were mapped to the SDO primitives and the mediator performed the required data translations. SDO supports more primitive types than the JCR, so in some cases, minimal data translation was required, such as converting a long to a short. The listing of simple types mapped is shown below:

JCR Type SDO Type

pt:string java.lang.String pt:date ** java.util.Date pt:long * java.lang.Integer pt:long * java.lang.Long pt:long * java.lang.Short pt:double * java.lang.Double pt:double * java.lang.Float pt:boolean * java.lang.Boolean pt:long * int pt:long long pt:long * short pt:double double pt:double * float pt:boolean boolean * denotes that some conversion was required either by casting or creating the required wrapper object ** denotes that some conversion was required that invoked a JCR utility

     To support residual property definitions, or properties that are not pre-defined in the node type schema but can be added at runtime, we had to generate a map accessor for each type of residual property definition. For instance, for a node type called ibm:document that had a residual property definition of type pt:string, we would create a map for the residual property definition that enforced the values to be of type string. If another residual of type pt:date was


Page 2 of 3

added to the node type, we would generate another map that enforced values of type date. Since residual properties could be named at runtime, the map proved to be an efficient data construct to allow the user to dynamically introduce new key / value pairs at runtime. Because the map implementations were strongly typed, the SDO disconnected data provided the same schema enforcement as the JCR. In the SDO generated class, the name...