Warning
You are looking at documentation for an older release. Not what you want? See the current release documentation.
The architecture of eXo Platform is summarized in the following schema:
Service Container
A container is always required to access a service, because the eXo Kernel relies on the dependency
injection. This means that the lifecycle of a service (for example, instantiating, opening and closing streams,
disposing) is handled by a dependency provider, such as the eXo Container, rather than the consumer. The
consumer only needs a reference to an implementation of the requested service. The implementation is configured
in an .xml configuration file that comes with every service.
Note
See Container, Kernel Reference for details.
Service
Containers are used to gain access to services. The followings are important characteristics of services:
The interface and implementation for a service are usually separate because of the Dependency Injection concept.
Each service has to be implemented as a singleton, which means it is created only once per portal container in a single instance.
A component equals a service. A service must not be a large application. A service can be a little component that reads or transforms a document where the term "component" is often used instead of service.
Note
See service configuration for beginners and in details for further references.
Java Content Repository
All data of eXo Platform are stored in a Java Content Repository (JCR). JCR is the Java specification (JSR-170) for a type of Object Database tailored to the storage, searching, and retrieval of hierarchical data. It is useful for the content management systems, which require storage of objects associated with metadata. The JCR also provides versioning, transactions, observations of changes in data, and import or export of data in XML. The data in JCR are stored hierarchically in a tree of nodes with associated properties.
Also, the JCR is primarily used as an internal storage engine. Accordingly, eXo Platform lets you manipulate JCR data directly in several places.
In Java Content Repository, there are 2 main parts:
Repositories and workspaces: A content repository consists of one or more workspaces. Each workspace contains a tree of items.
Tree structure - nodes and properties: Every node can only have one primary node type. The primary node type defines names, types and other characteristics of the properties, and the number of its allowed child nodes. Every node has a special property called jcr:primaryType that records the name of its primary node type. A node may also have one or more mixin types. These are node type definitions that can mandate extra characteristics (for example, more child nodes, properties and their respective names and types).
Data are stored in properties, which may hold simple values, such as numbers, strings or binary data of arbitrary length.
The JCR API provides methods to define node types and node properties, create or delete nodes, and add or delete properties from an existing node. You can refer to the 6.2.3 Node Read Methods in the JCR Specification document.
Note
See JCR Reference Guide for the full knowledge of JCR.