Laten we zeggen dat uw site net een enorme internationale promotie heeft gelanceerd. Pagina’s moeten worden aangemaakt, nieuwe assets moeten worden opgeslagen en klanten stromen massaal naar uw site. En dan… geeft uw site het op. Dat is het laatste wat u nodig heeft.
Om uw sitebeheersysteem zaken soepel te laten afhandelen, ongeacht de belasting, heeft het een architectuur nodig die werkt als een goed geoliede machine. Maar als u niet zeker weet hoe de architectuur van uw site eruitziet, is het moeilijk te zeggen hoe veerkrachtig deze is.
AEM-functies bieden een architectuur die met u mee kan groeien, en het is een uitstekend voorbeeld van die goed geoliede machine. Laten we het dus onder de loep nemen en kijken wat het laat werken!
AEM Architectuur: Een Basis Overzicht
Als we de architectuur van Adobe Experience Manager breed bekijken, bestaat het platform uit vier fundamentele architectonische componenten:
- Auteur
- Publisher
- Dispatcher
- Load balancer
Deze componenten werken samen om soepele lanceringen van nieuwe site-inhoud en naadloze, snelle laadtijden voor uw sitegebruikers te garanderen.
We gaan niet in op technische details, maar laten we op hoofdlijnen bekijken waar elk van deze componenten verantwoordelijk voor is.
Auteur
De auteurlaag van AEM is waar uw contentproductieteam werkt. Kortom, dit is de omgeving waar al uw webpagina’s worden gebouwd, georganiseerd en bijgewerkt. Hier uploaden ze ook alle media die u voor uw site wilt gebruiken, zoals afbeeldingen, video’s, enz.
De auteurlaag is nooit zichtbaar voor uw eindgebruikers, wat betekent dat alles waaraan u hier werkt onzichtbaar is totdat u besluit het goed te keuren en te publiceren. Dit geeft uw contentmakers de volledige vrijheid om te vormen en hervormen, te schrijven en herschrijven, te ontwerpen en herontwerpen totdat ze een pagina hebben gecreëerd die ze klaar zijn om aan uw klanten te tonen.
Publiceren
Als u op zoek bent naar het deel van AEM dat uw websitebezoekers zien, dan is dit het. De publish-laag is waar al uw goedgekeurde en voltooide websitecontent bestaat, live en publiekelijk toegankelijk.
Zodra u iets hebt goedgekeurd voor publicatie in de auteurlaag, wordt het verplaatst naar de publish-laag en is het toegankelijk voor iedereen.
Dispatcher
Mogelijk een van de meest essentiële functies van de architectuur van AEM, dispatchers zijn verantwoordelijk voor het leiden van uw websiteverkeer via routes die de snelste site-ervaring mogelijk maken.
Dispatchers vervullen twee primaire taken die uw site zo snel mogelijk laten werken: Caching en load balancing.
De dispatcher cachet een pagina nadat de eerste gebruiker deze bezoekt. Latere bezoekers ontvangen de gecachte versie. Dit wordt gedaan om uw site te versnellen en de directe belasting op de servers te verminderen.
Bovendien verdelen de dispatchers het netwerkverkeer dat naar de servers wordt geleid gelijkmatig, zodat geen enkele server overbelast raakt met verzoeken.
Load balancer
Naast de load-balancing taken van de dispatcher, bestaat er nog een andere load balancer om het verkeer van contentmakers en eindgebruikers gelijkmatig te verspreiden over auteur-, publish- en dispatcher-instanties (indien er meerdere zijn).
AEM as a Cloud Service Architectuurverschillen
De architectuur van AEM Cloud Service vertoont overeenkomsten met AEM 6.5 (on-premise), maar heeft ook opmerkelijke verschillen.
Deze verschillen zijn te zien in zowel de runtime-architectuur van AEM (het interne gedrag van de software met zijn componenten) als de implementatie-architectuur (hoe de code van de software wordt gewijzigd).
Laten we eens kort kijken hoe de runtime- en implementatie-architecturen specifiek zijn opgezet binnen AEM as a Cloud Service.
Runtime-architectuur
Binnen AEMaaCS zijn er auteur-, publisher- en dispatcher-“lagen”, net zoals in AEM classic. Meerdere auteur-, publish- en dispatcher-instanties kunnen in elke laag bestaan. Doorgaans heeft elke laag minimaal twee instanties.
Een van de grote verschillen en voordelen van de AEM Cloud-architectuur is dat deze auteur-, publish- en dispatcher-instanties allemaal oneindig kunnen schalen met de vraag van het verkeer op uw site.
Een ander belangrijk verschil in de architectuur van AEMaaCS is de toevoeging van een speciale “preview-laag”. Hier kan alle inhoud die uw makers produceren in de auteur-laag, worden bekeken vóór de definitieve publicatie. Het hebben van een afzonderlijke laag voor dit proces maakt het beoordelen van site-wijzigingen en nieuwe pagina’s gemakkelijker en sneller.
Implementatie-architectuur
De implementatie-architectuur van AEMaaCS werkt heel anders dan die van AEM classic. Deze geheel nieuwe functionaliteit draagt bij aan een van de grootste voordelen van AEMaaCS: Geen downtime.
Of u nu updates aan de code van uw AEMaaCS-applicatie uitvoert, of dat Adobe geautomatiseerde updates uitrolt, het proces is hetzelfde:
- Cloud Manager zal een nieuwe (niet-gepubliceerde) versie van uw applicatie creëren.
- Codewijzigingen zullen in deze nieuwe versie worden aangebracht.
- Grondige tests worden automatisch op de achtergrond uitgevoerd om ervoor te zorgen dat alles correct werkt in de bijgewerkte versie.
- Cloud Manager schakelt dan over naar de nieuwe versie.
Bij het overschakelen naar de nieuwe versie van uw AEM-applicatie gebruikt Cloud Manager een rolling update patroon. Dit betekent dat het telkens een paar delen van uw applicatie bijwerkt, zodat het merendeel van de overige delen actief en functioneel blijft.
Dit is duidelijk anders dan bij AEM 6.5, waarbij code-updates handmatig moeten worden uitgevoerd en vaak complexe taken zijn voor uw technische team. Bovendien vereisen updates naar AEM 6.5 meestal een zekere mate van downtime om te kunnen starten. Zoals u zich kunt voorstellen, maakt dit het moeilijk om ervoor te zorgen dat u altijd op de nieuwste versie draait.
De implementatiearchitectuur van AEMaaCS zorgt er specifiek voor dat u altijd de nieuwste versie van de software heeft, omdat Cloud Manager updates van de software automatisch op de achtergrond kan installeren zonder onderbrekingen.
AEM Technologie Stack
Elk geweldig platform wordt aangedreven door een robuuste stack van frameworks en tools die zorgen voor een naadloze werking, en AEM is daarin niet anders.
AEM vereiste een specifieke set kerntechnologieën die hard werken om consistente sitesnelheid, sitebetrouwbaarheid en soepele auteurswerkzaamheden en publicatie te waarborgen.
Dus, zonder verder oponthoud, lichten we enkele van de belangrijkste spelers achter de schermen toe.
Apache Sling Framework
De belangrijkste verantwoordelijkheid van Apache Sling binnen AEM is het beheren van hoe de inhoud van uw site aan het publiek wordt geleverd. Dit omvat een handvol belangrijke functionaliteiten:
- Gebruikers de webpagina tonen die ze proberen te openen.
- De juiste URL koppelen aan de juiste webpagina.
- Het laden van de juiste inhoud (afbeeldingen, tekst, etc.) op de pagina waarvoor deze is ontworpen.
- Wijzigingen aanbrengen in bestaande inhoud (zoals gecreëerd door uw team).
- Onbevoegde gebruikers weghouden van pagina’s die alleen voor specifieke ogen zijn bestemd.
- Aangepaste functionaliteiten toevoegen aan het AEM-platform.
Zonder Apache Sling zou AEM op geen enkele manier de juiste pagina’s, inhoud of bijbehorende URL’s kunnen tonen aan bezoekers van uw site, wat het een integraal onderdeel maakt van de algehele functionaliteit van AEM.
OSGi Framework
Terwijl Apache Sling zich bezighoudt met de levering van uw inhoud, behandelt OSGi de code en bronnen die de toepassingen van AEM in staat stellen om te functioneren.
Het groepeert de kerncomponenten van AEM in kleinere, gemakkelijker te beheren bundles, die in deze context JavaScript Archiefbestanden zijn. Het handhaaft ook de organisatie en volgorde tussen deze bundles.
OSGi handhaaft de volgorde van de AEM-code door:
- Bundles van elkaar te isoleren, zodat wijzigingen in de ene geen andere verstoren.
- Het vergemakkelijken van het toevoegen en verwijderen van bundles terwijl AEM draait, zonder opnieuw op te starten.
- Bijhouden welke services bepaalde bundles leveren, zodat het voor AEM gemakkelijker is om die services te vinden en te gebruiken voor functionaliteiten wanneer dat nodig is.
- Alternatieve versies van dezelfde bundle opslaan, zodat AEM achterwaartse compatibiliteit behoudt.
- Toezicht houden op de afhankelijkheden die bundles van elkaar hebben, en ervoor zorgen dat onderling afhankelijke bundles samen worden gebruikt.
- Beheren wanneer bundles geactiveerd en gedeactiveerd moeten worden gedurende hun levenscyclus.
Granite UI
In AEM is Granite UI de technologie waarmee uw team uw verschillende gebruikersinterfaces binnen uw site bouwt. Het legt de basis binnen uw auteurlaag en is verantwoordelijk voor zaken als:
- De benodigde tools bieden aan contentauteurs om aangepaste componenten te maken in AEM.
- Het structureren, definiëren en interpreteren van gegevensinvoer vanuit formulieren die in uw site zijn ingebouwd.
- Het opzetten en beheren van dialogen, dit zijn componenten die interageren met of invoer vragen van uw sitegebruikers.
- Uitgebreide aanpassing van de UI mogelijk maken, voor eenvoudige afstemming op unieke projecten.
- Het stroomlijnen van het auteursproces door een gebruiksvriendelijkere interface te bieden.
Java Content Repository
Binnen hun websites kunnen de meeste grote bedrijven een bijna oneindige bibliotheek aan activa en middelen verwachten. En wanneer u deze activa uploadt naar AEM, moeten ze allemaal ergens naartoe.
Gelukkig is dat waarvoor de Java Content Repository (JCR) er is. De Adobe Experience Manager Java Content Repository functioneert als uw standaard opslag- en organisatiesysteem voor elk type activa dat u op uw site wilt gebruiken. Dat omvat afbeeldingen, video’s, tekst, audio en meer.
JCR is de drijvende kracht achter:
- Het opslaan en catalogiseren van alle content.
- Het organiseren van uw content in een hiërarchie.
- Het bijhouden van de verschillende versies van uw content.
- Het toewijzen van metadata aan uw content.
- Robuuste zoekquerymogelijkheden die u in staat stellen content snel te vinden.
- Ervoor zorgen dat alleen gebruikers met toegang tot content deze kunnen zien.
Apache Jackrabbit Oak
In samenwerking met JCR is Apache Jackrabbit Oak verantwoordelijk voor de correcte implementatie van JCR binnen AEM. Terwijl JCR zelf meer een overkoepelende lijst van richtlijnen is voor de functionaliteiten van de contentrepository, is Apache Jackrabbit Oak verantwoordelijk voor het realiseren van die functionaliteiten.
Apache Jackrabbit Oak voegt ook enkele extra mogelijkheden toe aan de contentrepository van AEM.
Het belangrijkste is dat het de belangrijkste aanjager is van verhoogde schaalbaarheid in JCR, en het mogelijk maakt om grotere hoeveelheden content tegelijk op te slaan, te organiseren en te interpreteren.
Apache Jackrabbit Oak maakt ook een betere aanpasbaarheid van JCR mogelijk om te voldoen aan unieke behoeften op het gebied van contentbeheer.
Apache Felix OSGi Container
De Apache Felix OSGi Container dient als het onderliggende framework dat de modulaire architectuur van Adobe Experience Manager (AEM) ondersteunt.
Het stelt AEM in staat om zeer aanpasbaar te zijn door ontwikkelaars in staat te stellen functionaliteiten toe te voegen of te verwijderen, bekend als “bundels,” zonder het hele systeem opnieuw te hoeven opstarten.
Deze flexibiliteit zorgt ervoor dat AEM kan meegroeien met de behoeften van uw organisatie, waardoor naadloze updates en schaalbaarheid mogelijk zijn zonder lopende operaties te verstoren.
Sling Verzoekverwerking
Sling Verzoekverwerking is de component die verantwoordelijk is voor het beheren van inkomende verzoeken van webbrowsers en deze doorstuurt naar de juiste content binnen AEM.
Het maakt gebruik van een mapping-mechanisme om gevraagde content te lokaliseren op basis van URL’s en vertaalt deze verzoeken naar dynamische webpagina’s met behulp van de contentrepository van AEM.
Door content dynamisch samen te stellen, zorgt Sling ervoor dat gebruikers gepersonaliseerde en responsieve webervaringen krijgen, afgestemd op hun specifieke verzoeken en voorkeuren.
Sightly (HTL)
Sightly, ook bekend als HTML Template Language (HTL), is de templating-taal die in AEM wordt gebruikt voor het maken van webpagina’s en componenten.
Het biedt een gestructureerde en veilige benadering van webontwikkeling, waarbij scheiding van belangen tussen content- en presentatielagen wordt afgedwongen.
Ontwikkelaars kunnen schone en onderhoudbare code schrijven met Sightly, waardoor het risico op beveiligingskwetsbaarheden zoals Cross-Site Scripting (XSS) wordt verminderd en de algehele stabiliteit en prestaties van AEM-aangedreven websites worden verbeterd.
GraphQL
GraphQL is een querytaal en runtime voor API’s waarmee clients specifieke gegevens kunnen opvragen van de backend-systemen van AEM.
In tegenstelling tot traditionele RESTful API’s stelt GraphQL clients in staat om de structuur van de benodigde gegevens te definiëren, wat overmatig ophalen (over-fetching) en te weinig ophalen (under-fetching) van informatie vermindert.
Door clients de mogelijkheid te geven alleen de noodzakelijke gegevens op te vragen, optimaliseert GraphQL de netwerkefficiëntie en verbetert het de responsiviteit van AEM-gestuurde applicaties, wat de algehele gebruikerservaring verbetert.
AEM-modules (kerncomponenten)
De auteurinterface van AEM is gebouwd met het oog op gebruiksgemak, robuuste functionaliteit en aanpasbaarheid. Wanneer auteurs druk bezig zijn met het maken of bewerken van webpagina’s in AEM, werken ze niet met een kaal, leeg platform.
Er zijn dertig kerncomponenten binnen de auteurinterface van AEM, die allemaal zijn ontworpen voor betrouwbaar gebruik en aanpasbaarheid. Hier is een kort overzicht van enkele van de grootste voordelen van alle componenten:
- Cloud-mogelijkheid, waardoor componenten betrouwbaar werken.
- Veelzijdigheid, waarmee contentauteurs onbeperkte lay-outs kunnen creëren.
- SEO-vriendelijkheid, die websites versterkt met semantische HTML-output.
- Versiebeheer, dat uw site beschermt tegen storingen wanneer componenten worden bijgewerkt.
- Open-sourcing, wat ontwikkelaars de mogelijkheid geeft om te verbeteren wat er al is.
Als dit u enthousiast maakt om de auteurinterface van AEM uit te proberen, dan begrijpen we dat. Het is een krachtige toolkit die het creëren van pagina’s naar een hoger niveau tilt en AEM zo eenvoudig of zo complex maakt als u het nodig heeft.
Conclusie
Inmiddels zou u een overzicht moeten hebben van elk van de vier vitale architecturale onderdelen van AEM, evenals de tech-stack die de hoeksteenfuncties van AEM omvat.
Vooral wanneer bedrijven groeien, uitbreiden naar meerdere locaties en hun horizon verbreden, is AEM gebouwd om mee te groeien. Dus, of u nu veel auteursbehoeften tegelijkertijd heeft, veel paginaverzoeken, of een schat aan middelen om op te slaan, de CMS-oplossing aangedreven door Adobe Experience Cloud past zich zonder aarzelen aan.
En, in het ingewikkelde en snel veranderende online landschap van vandaag de dag, is dat precies wat marketeers en UI-ontwerpers het meest nodig hebben.
Veelgestelde vragen
In welke taal is AEM geschreven?
AEM is gebouwd op Java.
Welke Java design patterns worden gebruikt in AEM?
Vanwege de modulaire mogelijkheden van OSGi worden veel Java design patterns ondersteund, waaronder (maar niet beperkt tot): Singleton, Whiteboard, Adapter, Resource Adapter, Decorator en Observer.
Heeft AEM een API?
Ja, AEM gebruikt verschillende API’s, waaronder (maar niet beperkt tot): JCR API, Apache Sling API, RESTful API’s en Javascript API’s.
Gebruikt AEM Spring?
AEM is niet inherent gebaseerd op het Java Spring framework; het kan echter wel geïntegreerd worden met door Spring gebouwde maatwerkcode of maatwerkextensies.
Waar slaat AEM content op?
Content wordt opgeslagen in AEM’s Java Content Repository, die gebruikmaakt van Apache Jackrabbit Oak.
