See Features for background on the evaluation.
JSR 170 is a Java repository API
developed through the Java Community Process. The intent of the API is to
improve application interoperability by providing a standard way to manage content.
Implementations of JSR 170:
Applications which can use JSR 170 repositories:
- Mangolia is a commercial course management system which can use a JSR 170 repository.
JSR 283 builds on JSR 170.
JSR 170 has two compliance levels and a set of optional features. The
compliance levels are designed to ease implementation. The first level
defines a simple read-only repository with support for searching.
The second level adds write support. The optional components
are transactions, versioning, observation, access control, locking, and more
JSR 170 uses the javax.jcr namespace.
A Java content repository consists of a set of workspaces. Each workspace
contains a tree of items. Items are either nodes or properties. Each node has
a type, a name, a set of node children, and a set of property children.
Properties have a name, a definition, and a value or an array of values of
a single type. Properties cannot have children.
A node type constrains the names and types of child nodes and properties.
Each node must have a primary type. Noe types support inheritance.
A node may also have a set of mixin types. Mixin types provide additional
constraints on a node. A property definition can constrain the type and
value range of a property.
A new node is created by retrieving an item from the repository
and adding a child to the item.
A repository may optionally support reference nodes. A reference node is
required to have a UUID (universally unique identifier). During the creation
of a reference node, a UUID is assigned as a property of the node.
Properties are added by calling Node.setProperty.
The absolute path to a node in the item tree of a workspace is a unique
identifier, but may not persist.
Nodes are either accessed directly by UUID or through the item tree.
Items are selected from the tree by using a XPath like notation.
An item (node or property) is removed by calling the remove method
of the item. Descendants of the item are also removed.
Item.remove modifies the transient storage of the session.
Properties are removed calling Property.remove or Node.setProperty
with a null value argument.
An item can also be moved to another location in the item tree with
Workspace.move and Session.move.
Nodes may hold references to other nodes using reference properties.
A reference property holds the UUID of a node.
A node that is referenced by another node cannot be removed until
the source of the reference is removed. Attempting to do so will cause
Item.remove to throw a ReferentialIntegrityException
Removing a node that is required by the type constraints of another node
will cause a ConstraintViolationException to be thrown.
Node mixin types can be added and removed. The node name cannot be modified.
JSR 170 supports aggregations through the item tree.
An aggregation is a node. Members of the aggregation are children
of the aggregation node.
An aggregation is created by creating a new node in the item tree.
An aggregation is removed by removing the aggregation node.
Change aggregation membership
Aggregation membership can be changed by adding and removing children of
the aggregation node.
Finding aggregation members
An aggregation is iterated over by obtaining an iterator object from
JSR 170 defines a mappings of the data model to XML called the system view.
The system view contains the complete content of a repository workspace.
A less complete, but more human readable, document view is also defined.
Binary property values are stored inline as base64 encoded text.
Data converted to the system or document view format can be imported into a
workspace with Workspace.importXML. Depending on the data, such a
conversion might be awkward. Alternatively, a user could write a tool to
ingest data in a different format.
The contents of a workspace can be serialized to XML with
Workspace.exportSystemView or Workspace.exportDocumentView.
Node types are not serialized. The specification discusses how to
store node types as nodes. This would provide a way to serialize node types,
but repositories are not required to store node types as nodes.
Alternatively, a user might create a tool which writes the contents of a
workspace to a different format.
The user supplies credentials to Repository.login. The content of the
credentials is implementation dependent.
JSR 170 does not define a mechanism for setting access control policies.
The intent is that an external mechanism like
JAAS be used.
If an unauthorized action is attempted, an exception will be thrown.
Session.checkPermission can check whether or not the current session can
perform an action on a node.
There is no support for user management.
There is no support for managing security policies.
There is support for locking individual nodes as an optional feature. Only nodes with a lockable mixin type can be locked. A lock may optionally apply to descendants of the locked node.
Virtual object representation
There is no support for virtual representations.
Transactions are an optional feature based on
JRA JTA transactions are either container
managed or user managed. Container managed transactions are transparent to
the user. User managed transactions require the user to directly control
transactions with JTA.
Transient storage is in memory storage associated with a session.
Persistent storage refers to the actual content stored in the repository.
Support for repositories changes the behavior or Session.save, Item.save,
and Workspace.save. Session.save and Item.save still modify transient storage,
but Workspace.save no longer writes changes to persistent storage. Changes
are not persisted until a transaction is committed. Commits are either done
directly with JTA by the user or indirectly by the container.
When a transaction is rolled back, only changes to persistent storage are
rolled back. Changes to transient storage in a transaction are not recorded.
Versioning is an optional feature.
Versionable nodes must have a versionable mixin type.
Modifying a versionable node requires checking the node out,
doing the modification, and then checking the node back in.
The check in step creates a new version of the node.
The versions of a node are stored as a graph of nodes called a version history.
Each version has a reference to the history. Version histories can
be searched and traversed
Old versions can be made current by calling Node.restore.
Level 1 compliance requires support for XPath queries.
Only a subset of XPath 2.0 is required.
A repository may optionally support an SQL based query language.
XPath queries are evaluated on an XML view of a workspace.
SQL queries are evaluated on a database view of a workspace.
A query returns a set of nodes in a workspace.