La plateforme AEM dans AEM 6 est basée sur Apache Jackrabbit Oak.
Apache Jackrabbit Oak vise à implémenter un référentiel de contenu hiérarchique évolutif et performant pour l’utiliser comme fondation des sites web modernes de classe mondiale et d’autres applications de contenu exigeantes.
Il succède à Jackrabbit 2 et il est utilisé par AEM 6 comme structure par défaut pour son référentiel de contenu, CRX.
Oak met en œuvre les spécifications JSR-283 (JCR 2.0). Ses principaux objectifs de création sont les suivants :
L’objectif du calque de stockage est le suivant :
Le cœur Oak ajoute plusieurs niveaux au niveau de stockage :
Le principal objectif de Oak JCR est de transformer la sémantique de JCR en opérations d’arborescence. Il est aussi chargé des éléments suivants :
En outre, les implémentations non Java sont désormais possibles et font partie du concept Oak JCR.
Le niveau de stockage Oak fournit un niveau d’abstraction pour le stockage de contenu.
Actuellement, il existe deux implémentations du stockage disponibles dans AEM 6 : le stockage tar et le stockage MongoDB.
Le stockage Tar utilise des fichiers tar. Il stocke le contenu comme divers types d’enregistrements dans des segments plus volumineux. Les journaux sont utilisés pour effectuer le suivi du dernier état du référentiel.
Il existe plusieurs principes de conception clés à partir desquels il est créé :
Le contenu est stocké dans les segments avec une taille pouvant aller jusqu’à 256 Ko. Ils sont inaltérables, ce qui permet de mettre en cache les segments utilisés fréquemment et de réduire les erreurs système susceptibles de compromettre le référentiel.
Chaque segment est identifié par un identifiant unique (UUID) et contient un sous-ensemble continu de l’arborescence de contenu. En outre, les segments peuvent référencer d’autres contenus. Chaque segment conserve une liste des UUID des autres segments référencés.
Les enregistrements associés comme un noeud et ses enfants immédiats sont habituellement stockés dans le même segment. Cela permet d’accélerer la recherche dans le référentiel et d’assurer la plupart des mises en cache pour les clients qui accèdent à plus d’un nœud relatif par session.
Le formatage des enregistrements est optimisé pour la taille de sorte à réduire les coûts E/S et pour accueillir le plus de contenu possible dans les caches.
Le stockage de MongoDB exploite MongoDB pour la fragmentation et la mise en cluster. L’arborescence du référentiel est conservée dans une base de données MongoDB où chaque nœud est un document distinct.
Il existe plusieurs particularités :
Pour chaque mise à jour (commit) du contenu, une nouvelle révision est créée. Une révision, finalement, est une chaîne qui se compose de trois éléments :
Les branches sont prises en charge, ce qui permet au client de présenter de nombreuses modifications et de les rendre visibles à l’aide d’un simple appel de fusion.
Le stockage de MongoDB ajoute des données à un document avec chaque modification. Toutefois, il supprime uniquement les données si un nettoyage est explicitement déclenché. Les anciennes données sont déplacées lorsqu’un certain seuil est atteint. Les documents précédents contiennent uniquement des données inaltérables, ce qui signifie qu’elles contiennent uniquement des modifications validées et fusionnées.
Les données sur les noeuds de cluster actifs et inactifs sont conservées dans la base de données pour faciliter les opérations de mise en cluster.
Une configuration en cluster AEM typique avec un stockage MongoDB :
Étant donné qu’Oak est conçu pour être rétrocompatible avec le standard de JCR 1.0, il n’y a quasiment aucune modification au niveau de l’utilisateur. Toutefois, il existe des différences perceptibles à prendre en compte lors de la configuration d’un Oak basé sur l’installation AEM :
Pour plus d’informations sur la plateforme AEM, vérifiez également les articles ci-dessous :