As we already discussed in our previous article Technology Guide To Adobe Experience Manager, The JCR 2.0 standard, JSR 283, specifies a vendor-independent and implementation-independent way to access content bi-directionally on a granular level within a content repository. The JSR 283 was released back on 2009, as of now it is eleven years old. The JSR 283 was developed by the Java Community Process.
Notable contributors from Day Software AG were David Nuescheler (Specification Lead) and Roy Fielding. Read more about contributors here.
Note: Day Software was the company that created Communiqué, which after the Adobe acquisition in 2010, was rebranded briefly as Adobe CQ and then named Adobe Experience Manager.
Repository Model
The repository model describes the objects, types and structures that compose a JCR repository. The description is language-neutral and focuses on the static aspects of the data model.
The followings are the main behavioral aspects of the repository, and in particular the Java API for performing operations on the model:
Connecting
To begin using a repository, an application must acquire a Repository object. Access to a Repository object may be provided through a number of standard Java naming and discovery mechanisms, but must at the minimum be provided through an implementation of the RepositoryFactory interface.
Reading
There are three types of read access which a session may have with respect to a particular item, depending on that session’s permissions:
- direct access,
- traversal access, and
- query access.
Query
The repository can be searched via query. The structure and evaluation semantics of a query are defined by an abstract query model (AQM) for which two concrete language bindings are specified:
- JCR-SQL2, which expresses a query as a string with syntax similar to SQL
- JCR-JQOM (JCR Java Query Object Model), which expresses a query as a tree of Java objects.
Export
A JCR repository must support export of content to XML format. The standard describes in details two types of export documents – system view and document view.
Writing
Of course to save nodes and data, a repository may be writable. Whether an implementation supports writing can be determined by querying the repository descriptor table with Repository.WRITE_SUPPORTED.
Observation
A repository may support observation, which enables an application to receive notification of persistent changes to a workspace. JCR defines a general event model and specific APIs for asynchronous and journaled observation. A repository may support asynchronous observation, journaled observation or both.
Whether an implementation supports asynchronous or journaled observation can be determined by querying the repository descriptor table with the keys
Repository.OPTION_OBSERVATION_SUPPORTED or Repository.OPTION_JOURNALED_OBSERVATION_SUPPORTED.
Versioning
A repository may support simple versioning or full versioning. This section describes the syntax and behavior of the Java API for both types of versioning. Details on the underlying concepts, data structures and node types can be found in §3.13 Versioning Model.
Whether an implementation supports simple versioning can be determined by querying the repository descriptor table with
Repository.OPTION_SIMPLE_VERSIONING_SUPPORTED.
Whether it supports full versioning can be determined by querying
Repository.OPTION_VERSIONING_SUPPORTED.
Access Control Management
A repository may support access control management, enabling the following:
Privilege discovery: Determining the privileges that a user has in relation to a node.
Assigning access control policies: Setting the privileges that a user has in relation to a node using access control policies specific to the implementation.
Whether a particular implementation supports access control can be determined by querying the repository descriptor table with
Repository.OPTION_ACCESS_CONTROL_SUPPORTED.
A return value of true indicates support
Locking
A repository may support locking, which enables a user to temporarily prevent other users from changing a node or subgraph of nodes.
Whether an implementation supports locking can be determined by querying the repository descriptor table with
Repository.OPTION_LOCKING_SUPPORTED.
A return value of true indicates support
Transactions
A repository may support transactions.
Whether a particular implementation supports transactions can be determined by querying the repository descriptor table with
Repository.OPTION_TRANSACTIONS_SUPPORTED.
A return value of true indicates support for transactions (see Repository Descriptors).
A repository that supports transactions must adhere to the Java Transaction API (JTA) specification
Your AEM Team should be well versed on this standard
When you are hiring an AEM developer for your Experience Project implementation, ensure that they know well the JCR 2.0 (JSR 283) standard.
If you are in doubt, you can always contact KBWEB Consult AEM team for help.
[contact-field required="1" type="name" label="Name"/] [contact-field required="1" type="email" label="Email"/] [contact-field type="textarea" label="Message"/]