Imaginons que votre site vient de lancer une énorme promotion internationale. Des pages doivent être créées, de nouveaux actifs stockés, et les clients affluent sur votre site. Et puis… votre site cède. C’est la dernière chose dont vous avez besoin.
Pour que votre système de gestion de site gère les choses en douceur quelle que soit la charge, il a besoin d’une architecture qui fonctionne comme une machine bien huilée. Mais si vous n’êtes pas sûr de l’apparence de l’architecture de votre site, il est difficile de déterminer sa résilience.
L’AEM propose une architecture capable de croître avec vous, et c’est un excellent exemple de cette machine bien huilée. Alors, mettons-la sous un microscope pour voir ce qui la fait fonctionner !
Architecture AEM : Vue d’ensemble de base
En examinant l’architecture d’Adobe Experience Manager avec une perspective plus large, la plateforme est composée de quatre composants architecturaux de base :
- Auteur
- Publication
- Dispatcher
- Équilibreur de charge
Ces composants fonctionnent ensemble pour assurer des lancements fluides de nouveau contenu de site et un chargement rapide et sans interruption pour les utilisateurs de votre site.
Nous n’entrerons pas dans les détails techniques, mais examinons de manière générale la responsabilité de chacun de ces composants.
Auteur
Le niveau auteur d’AEM est l’endroit où votre équipe de production de contenu travaille. Essentiellement, c’est l’environnement de travail où toutes vos pages web seront créées, organisées et mises à jour. C’est également là qu’ils téléchargeront tous les médias que vous prévoyez d’utiliser pour votre site, tels que les images, les vidéos, etc.
Le niveau d’auteur n’est jamais visible pour vos utilisateurs finaux, ce qui signifie que tout ce sur quoi vous travaillez ici est invisible tant que vous n’avez pas décidé de l’approuver et de le publier. Cela donne à vos créateurs de contenu toute latitude pour modeler et remodeler, écrire et réécrire, concevoir et reconcevoir jusqu’à ce qu’ils aient créé une page qu’ils sont prêts à présenter à vos clients.
Publication
Si vous recherchez la partie d’AEM que vos visiteurs de site voient, c’est celle-ci. Le niveau de publication est l’endroit où tout votre contenu de site approuvé et finalisé existe, en direct pour le public.
Une fois que vous avez approuvé quelque chose pour publication dans le niveau d’auteur, il sera déplacé vers le niveau de publication et sera accessible à tous et à chacun.
Dispatcher
Probablement l’une des fonctionnalités les plus essentielles de l’architecture d’AEM, les dispatchers sont responsables de diriger le trafic de votre site vers des routes qui permettent l’expérience de site la plus rapide.
Les dispatchers accomplissent deux tâches principales qui aident votre site à fonctionner aussi vite que possible : la mise en cache et l’équilibrage de charge.
Le cache du dispatcher une page après la première visite d’un utilisateur. Les visiteurs suivants reçoivent la version mise en cache. C’est fait pour accélérer votre site et réduire la charge directe sur les serveurs.
De plus, les dispatchers distribueront équitablement le trafic réseau dirigé vers les serveurs, afin qu’aucun serveur ne soit surchargé de requêtes.
Équilibreur de charge
En plus des fonctions d’équilibrage de charge du dispatcher, un autre équilibreur de charge existe pour disperser uniformément le trafic des créateurs de contenu et des utilisateurs finaux entre les instances d’auteur, de publication et de dispatcher (lorsqu’il y en a plusieurs).
Différences d’architecture d’AEM as a Cloud Service
L’architecture d’AEM Cloud Service présente des similitudes avec AEM 6.5 (sur site) mais aussi des différences notables.
Ces différences peuvent être observées à la fois au niveau de l’architecture d’exécution d’AEM (le comportement interne du logiciel avec ses composants) et de son architecture de déploiement (la manière dont le code du logiciel est modifié).
Examinons rapidement la manière dont les architectures d’exécution et de déploiement sont configurées spécifiquement au sein d’ AEM as a Cloud Service.
Architecture d’exécution
Au sein d’AEMaaCS, il existe des niveaux « auteur », « publication » et « dispatcher », tout comme dans AEM classique. Plusieurs instances d’auteur, de publication et de dispatcher peuvent exister dans chaque niveau. Généralement, chaque niveau possède un minimum de deux instances.
L’une des principales différences et avantages de l’architecture AEM Cloud est que ces instances d’auteur, de publication et de dispatcher peuvent toutes évoluer à l’infini en fonction de la demande de trafic de votre site.
Une autre différence significative dans l’architecture d’AEMaaCS est l’inclusion d’un « niveau de prévisualisation » dédié. C’est là que tout le contenu que vos créateurs produisent dans le niveau auteur peut être prévisualisé avant la publication finale. Le fait de disposer d’un niveau séparé pour ce processus rend la révision des modifications du site et des nouvelles pages plus facile et plus rapide.
Architecture de déploiement
L’architecture de déploiement d’AEMaaCS fonctionne très différemment de celle d’AEM classique. Cette fonctionnalité entièrement nouvelle confère un autre des plus grands avantages d’AEMaaCS : Aucun temps d’arrêt.
Que vous apportiez des mises à jour au code de votre application AEMaaCS, ou qu’Adobe déploie des mises à jour automatisées, le processus est le même :
- Cloud Manager créera une nouvelle version (non publiée) de votre application.
- Les modifications de code seront apportées à cette nouvelle version.
- Des tests rigoureux seront exécutés automatiquement en arrière-plan pour s’assurer que tout fonctionne correctement dans la version mise à jour.
- Cloud Manager bascule ensuite vers la nouvelle version.
Lors du passage à la nouvelle version de votre application AEM, Cloud Manager utilise un modèle de mise à jour progressive. Cela signifie qu’il met à jour quelques parties de votre application à la fois, afin que la majorité des parties restantes restent actives et fonctionnelles.
Ceci est nettement différent d’AEM 6.5, où les mises à jour de code doivent être effectuées manuellement et sont souvent des tâches complexes pour votre équipe technique. De plus, les mises à jour d’AEM 6.5 nécessitent généralement un certain temps d’arrêt pour être déployées. Comme vous pouvez l’imaginer, cela rend difficile de s’assurer que vous utilisez toujours la dernière version.
L’architecture de déploiement d’AEMaaCS garantit spécifiquement que vous disposez toujours de la dernière version du logiciel, car Cloud Manager peut installer automatiquement les mises à jour du logiciel en arrière-plan sans aucune interruption.
Pile Technologique AEM
Toute grande plateforme est alimentée par une pile robuste de frameworks et d’outils qui l’aident à fonctionner en toute transparence, et AEM ne fait pas exception.
AEM a nécessité un ensemble spécifique de technologies de pointe travaillant d’arrache-pied pour assurer une vitesse de site constante, une fiabilité du site et une expérience de création et de publication fluide.
Alors, sans plus tarder, nous allons mettre en lumière certains des acteurs majeurs en coulisses.
Cadre Apache Sling
La principale responsabilité d’ Apache Sling au sein d’AEM est de gérer la manière dont le contenu de votre site est livré au public. Cela consiste en un certain nombre de fonctionnalités clés :
- Servir aux utilisateurs la page web à laquelle ils essaient d’accéder.
- Associer la bonne URL à la bonne page web.
- Chargement du contenu correct (images, texte, etc.) sur la page sur laquelle il est censé exister.
- Apporter des modifications au contenu existant (tel qu’il a été créé par votre équipe).
- Empêcher les utilisateurs non autorisés d’accéder aux pages confidentielles.
- Ajouter des fonctionnalités personnalisées à la plateforme AEM.
Sans Apache Sling, il serait impossible pour AEM d’afficher les bonnes pages, le bon contenu ou les URL correspondantes à quiconque visite votre site, ce qui en fait un composant essentiel de la fonctionnalité globale d’AEM.
Framework OSGi
Alors qu’Apache Sling gère la diffusion de votre contenu, OSGi gère le code et les ressources qui permettent aux applications d’AEM de fonctionner globalement.
Il regroupe les composants principaux d’AEM en bundles plus petits et plus faciles à gérer, qui, dans ce contexte, sont des fichiers d’archive Javascript. Il maintient également l’organisation et l’ordre entre ces bundles.
OSGi maintient l’ordre du code d’AEM en :
- Isolant les bundles les uns des autres, afin que les modifications apportées à l’un n’affectent pas les autres.
- Facilitant l’ajout et la suppression de bundles pendant qu’AEM est en cours d’exécution, sans redémarrage.
- Gardant un œil sur les services que certains bundles fournissent, afin qu’il soit plus facile pour AEM de trouver et d’utiliser ces services pour les fonctionnalités selon les besoins.
- Stockant des versions alternatives du même bundle afin qu’AEM maintienne la compatibilité ascendante.
- Supervisant les dépendances des bundles les uns envers les autres, et s’assurant que les bundles codépendants sont utilisés ensemble.
- Gérant le moment où les bundles doivent être activés et désactivés tout au long de leur cycle de vie.
Granite UI
Dans AEM, Granite UI est la technologie à travers laquelle votre équipe construira vos différentes interfaces utilisateur au sein de votre site. Elle jette les bases de votre couche d’auteur et est responsable de choses telles que :
- Fournir les outils nécessaires aux auteurs de contenu pour créer des composants personnalisés dans AEM.
- Structurer, définir et interpréter les entrées de données des formulaires intégrés à votre site.
- Mettre en place et gérer des dialogues, qui sont des composants interagissant avec ou sollicitant des informations de la part des utilisateurs de votre site.
- Permettre une personnalisation étendue de l’interface utilisateur, pour une adaptation facile à des projets uniques.
- Rationaliser le processus d’édition en offrant une interface plus conviviale.
Référentiel de Contenu Java
Au sein de leurs sites web, la plupart des grandes entreprises peuvent s’attendre à disposer d’une bibliothèque quasi illimitée d’actifs et de ressources. Et lorsque vous téléchargez ces actifs dans AEM, ils doivent tous être stockés quelque part.
Heureusement, c’est à cela que sert le Java Content Repository (JCR). Le Java Content Repository d’Adobe Experience Manager fonctionne comme votre système de stockage et d’organisation privilégié pour tout type d’actif que vous pourriez avoir besoin d’utiliser sur votre site. Cela inclut les images, les vidéos, le texte, l’audio, et bien plus encore.
Le JCR est le moteur de :
- Stocker et cataloguer tout le contenu.
- Organiser votre contenu de manière hiérarchique.
- Suivre les différentes versions de votre contenu.
- Attribuer des métadonnées à votre contenu.
- Des capacités de requête de recherche robustes qui vous permettent de trouver rapidement du contenu.
- S’assurer que seuls les utilisateurs ayant accès au contenu peuvent le voir.
Apache Jackrabbit Oak
Travaillant en tandem avec le JCR, Apache Jackrabbit Oak est responsable de la bonne implémentation du JCR au sein d’AEM. Tandis que le JCR lui-même est une liste de directives générales pour les fonctionnalités du référentiel de contenu, Apache Jackrabbit Oak est chargé de concrétiser ces fonctionnalités.
Apache Jackrabbit Oak ajoute également des fonctionnalités supplémentaires au référentiel de contenu d’AEM.
Plus important encore, c’est le principal moteur d’une évolutivité accrue dans JCR, et cela permet de stocker, d’organiser et d’interpréter de plus grands volumes de contenu simultanément.
Apache Jackrabbit Oak permet également une meilleure personnalisation de JCR pour répondre aux besoins uniques de gestion de contenu.
Conteneur Apache Felix OSGi
Le conteneur Apache Felix OSGi sert de cadre sous-jacent qui prend en charge l’architecture modulaire d’Adobe Experience Manager (AEM).
Il permet à AEM d’être hautement adaptable en permettant aux développeurs d’ajouter ou de supprimer des fonctionnalités, appelées « bundles », sans avoir à redémarrer l’ensemble du système.
Cette flexibilité garantit qu’AEM peut évoluer avec les besoins de votre organisation, permettant des mises à jour et une évolutivité sans heurts sans perturber les opérations en cours.
Traitement des requêtes Sling
Le traitement des requêtes Sling est le composant responsable de la gestion des requêtes entrantes provenant des navigateurs web et de leur acheminement vers le contenu approprié au sein d’AEM.
Il utilise un mécanisme de mappage pour localiser le contenu demandé en fonction des URL et traduit ces requêtes en pages web dynamiques à l’aide du référentiel de contenu d’AEM.
En assemblant dynamiquement le contenu, Sling garantit que les utilisateurs bénéficient d’expériences web personnalisées et réactives, adaptées à leurs requêtes et préférences spécifiques.
Sightly (HTL)
Sightly, également connu sous le nom de HTML Template Language (HTL), est le langage de templating utilisé dans AEM pour créer des pages web et des composants.
Il offre une approche structurée et sécurisée du développement web, en imposant une séparation des préoccupations entre les couches de contenu et de présentation.
Les développeurs peuvent écrire du code propre et maintenable en utilisant Sightly, réduisant ainsi le risque de vulnérabilités de sécurité telles que le Cross-Site Scripting (XSS) et améliorant la stabilité et les performances globales des sites web alimentés par AEM.
GraphQL
GraphQL est un langage de requête et un environnement d’exécution pour les API qui permet aux clients de demander des données spécifiques aux systèmes backend d’AEM.
Contrairement aux API RESTful traditionnelles, GraphQL permet aux clients de définir la structure des données dont ils ont besoin, réduisant ainsi le sur-récupération et le sous-récupération d’informations.
En donnant aux clients la possibilité de demander uniquement les données nécessaires, GraphQL optimise l’efficacité du réseau et améliore la réactivité des applications basées sur AEM, améliorant ainsi l’expérience utilisateur globale.
Modules AEM (Composants Core)
L’interface d’édition d’AEM a été conçue en pensant à une facilité d’utilisation, une capacité robuste et une personnalisabilité. Lorsque les auteurs sont en plein travail de création ou d’édition de pages web dans AEM, ils ne travailleront pas avec une plateforme rudimentaire et vide.
Il existe trente composants core au sein de l’interface d’édition d’AEM, tous conçus pour une utilisation fiable et une personnalisabilité. Voici un bref aperçu de certains des plus grands avantages de tous les composants :
- Capacité cloud, qui permet aux composants de fonctionner de manière fiable.
- Polyvalence, qui permet aux auteurs de contenu de créer des mises en page illimitées.
- Compatibilité SEO, qui renforce les sites avec une sortie HTML sémantique.
- Capacité de versioning, qui protège votre site contre les pannes lors de la mise à jour des composants.
- Open-sourcing, qui ouvre la voie aux développeurs pour améliorer ce qui existe.
Si cela vous donne envie de tester l’interface d’édition d’AEM, nous comprenons. C’est une boîte à outils puissante qui fait passer la création de pages au niveau supérieur et permet à AEM d’être aussi simple ou aussi complexe que vous le souhaitez.
Conclusion
À présent, vous devriez avoir une vue d’ensemble des quatre éléments architecturaux vitaux d’AEM, ainsi que de la pile technologique qui constitue les fonctions essentielles d’AEM.
Surtout lorsque les entreprises se développent, s’étendent sur plusieurs sites et élargissent leurs horizons, AEM est conçu pour évoluer en parallèle. Ainsi, que vous ayez de nombreux besoins d’édition simultanés, de nombreuses requêtes de pages ou un trésor d’actifs à stocker, la solution CMS alimentée par Adobe Experience Cloud s’adapte sans hésitation.
Et, dans le paysage en ligne complexe et en rapide évolution d’aujourd’hui, c’est ce dont les marketeurs et les concepteurs d’interface utilisateur ont le plus besoin.
FAQ
Dans quel langage AEM est-il écrit ?
AEM est basé sur Java.
Quels sont les modèles de conception Java utilisés dans AEM ?
Grâce aux capacités modulaires d’OSGi, de nombreux modèles de conception Java sont pris en charge, y compris (mais sans s’y limiter) : Singleton, Whiteboard, Adapter, Resource Adapter, Decorator et Observer.
AEM dispose-t-il d’une API ?
Oui, AEM utilise une variété d’API, y compris (mais sans s’y limiter) : l’API JCR, l’API Apache Sling, les API RESTful et les API Javascript.
AEM utilise-t-il Spring ?
AEM n’est pas intrinsèquement basé sur le framework Java Spring ; cependant, il peut être intégré à du code personnalisé ou à des extensions personnalisées créés avec Spring.
Où AEM stocke-t-il le contenu ?
Le contenu est stocké dans le Java Content Repository d’AEM, qui utilise Apache Jackrabbit Oak.
