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 oeuvre les spécifications JSR-283 (JCR 2.0). Ses principaux objectifs de conception sont les suivants :
Le but de la couche de stockage est de :
Oak Core ajoute plusieurs couches à la couche de stockage :
L’objectif principal de Oak JCR est de transformer la sémantique JCR en opérations arborescentes. 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.
La couche de stockage Oak fournit une couche d’abstraction pour le stockage réel du 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 sous la forme de différents types d’enregistrements dans des segments plus volumineux. Les journaux sont utilisés pour effectuer le suivi de l’état le plus récent du référentiel.
Il repose sur plusieurs principes de conception clés :
Le contenu est stocké dans des segments d’une taille maximale de 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 tels qu’un nœud et ses enfants immédiats sont stockés dans le même segment. Cela permet de rechercher rapidement le référentiel et d’éviter la plupart des pertes de cache pour les clients et clientes standard qui accèdent à plusieurs nœuds associés par session.
La mise en forme des enregistrements est optimisée pour la taille afin de réduire les coûts d’E/S et d’intégrer le plus de contenu possible dans les caches.
Le stockage MongoDB utilise MongoDB pour le partage et la mise en grappe. 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 a plusieurs particularités :
Pour chaque mise à jour (validation) du contenu, une nouvelle révision est créée. Une révision est essentiellement une chaîne composée de trois éléments :
Les branches sont prises en charge, ce qui permet aux clients d’organiser plusieurs modifications et de les rendre visibles avec un seul appel de fusion.
Le stockage MongoDB ajoute des données à un document à chaque modification. Cependant, 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 ne contiennent que des données non modifiables, ce qui signifie qu’ils ne contiennent que des révisions validées et fusionnées.
Les données relatives aux nœuds de cluster actifs et inactifs sont conservées dans la base de données afin de faciliter les opérations de cluster.
Une configuration en cluster AEM typique avec un stockage MongoDB :
Oak étant rétrocompatible avec la norme JCR 1.0, il n’y a pratiquement aucune modification au niveau de l’utilisation. Cependant, il existe des différences notables dont vous devez tenir compte lors de la configuration d’une installation d’AEM basée sur Oak :
Pour plus d’informations sur la plateforme AEM, consultez également les articles ci-dessous :