Let’s say your site just launched a huge international promotion. Pages need to be created, new assets need to be stored, and customers are clamoring around your site. And then…your site gives up. That’s the last thing you need.
For your site management system to handle things smoothly no matter the load, it needs an architecture that runs like a well-oiled machine. But if you’re not sure what your site’s architecture looks like, then it’s hard to tell how resilient it is.
AEM features an architecture capable of growing with you, and it’s an excellent example of that well-oiled machine. So, let’s put it under a microscope and see what makes it tick!
AEM Architecture: A Basic Overview
Looking at the Adobe Experience Manager architecture with a wide lens, the platform is composed of four basic architectural components:
- Author
- Publisher
- Dispatcher
- Load balancer
These components work together to ensure smooth launches of new site content and seamless, speedy loading for your site users.
We won’t delve into technical details, but let’s take a high-level look at what each of these components is responsible for.
Author
AEM’s author tier is where your content production team works. Essentially, this is the playground where all of your web pages will be built, organized, and updated. This is also where they’ll upload all the media you plan to use for your site, like images, videos, etc.
The author tier is never visible to your end users, meaning that whatever you’re working on here is invisible until you decide to approve and publish it. This gives your content creators free rein to mold and re-mold, write and re-write, design and re-design until they’ve created a page they’re ready to show off to your customers.
Publish
If you’re looking for the part of AEM that your site visitors see, this is it. The publish tier is where all of your approved and finished site content exists, live to the public.
Once you’ve approved something for publication in the author tier, it will move to the publish tier and be accessible to anyone and everyone.
Dispatcher
Possibly one of the most essential features of AEM’s architecture, dispatchers are responsible for directing your site traffic down routes that enable the fastest site experience.
Dispatchers accomplish two primary tasks that help your site run as fast as possible: Caching and load balancing.
The dispatcher caches a page after the first user visits it. Subsequent visitors receive the cached version. It’s done to speed up your site and reduce the direct load on the servers.
Additionally, the dispatchers will evenly distribute network traffic that’s directed toward the servers, so that no one server becomes overloaded with requests.
Load balancer
In addition to the load-balancing duties of the dispatcher, another load balancer exists to disperse content creator and end-user traffic evenly among author, publish, and dispatcher instances (when there are multiple).
AEM as a Cloud Service Architecture Differences
AEM Cloud Service architecture shares similarities with AEM 6.5 (on-premise) but also has notable differences.
These differences can be observed across both AEM’s runtime architecture (the internal behavior of the software with its components) and its deployment architecture (how the software’s code is changed).
Let’s take a quick look at how the runtime and deployment architectures are set up within AEM as a Cloud Service specifically.
Runtime architecture
Within AEMaaCS, there exist author, publisher, and dispatcher “tiers,” just like there are in AEM classic. Multiple author, publish, and dispatcher instances can exist in each tier. Typically, each tier has a minimum of two instances.
One of the major differences and benefits of the AEM Cloud architecture is that these author, publish, and dispatcher instances can all infinitely scale with the demand of your site’s traffic.
Another significant difference in the architecture of AEMaaCS is the inclusion of a dedicated “preview tier.” This is where all the content your creators produce in the author tier can be previewed before the final publication. Having a separate tier for this process makes reviewing site changes and new pages easier and faster.
Deployment architecture
The deployment architecture of AEMaaCS functions very differently than that of AEM classic. This utterly new functionality lends itself to another of AEMaaCS’s biggest benefits: No downtime.
Whether you’re making updates to the code of your AEMaaCS application, or whether Adobe is the one rolling out automated updates, the process is the same:
- Cloud Manager will create a new (non-published) version of your application.
- Code changes will be made to this new version.
- Rigorous testing will run automatically in the background to ensure everything works properly in the updated version.
- Cloud Manager then switches to the new version.
When switching to the new version of your AEM application, Cloud Manager uses a rolling update pattern. This means that it’s updating a few parts of your application at a time so that the majority of the remaining parts stay active and functional.
This is distinctly different from AEM 6.5, wherein code updates must be made manually and are often involved tasks for your tech team. Moreover, updates to AEM 6.5 usually require a certain amount of downtime to get rolling. As you can imagine, this makes it difficult to ensure you’re always running on the latest version.
The deployment architecture of AEMaaCS specifically ensures that you always have the latest version of the software, because Cloud Manager can automatically install updates to the software in the background with no interruptions.
AEM Technology Stack
Every great platform is powered by a robust stack of frameworks and tools that help it run seamlessly, and AEM is no different.
AEM required a specific set of champion technologies working hard to ensure consistent site speed, site reliability, and smooth authoring and publication.
So, without further ado, we’ll shine a light on some of the major players behind the scenes.
Apache Sling Framework
Apache Sling’s main responsibility within AEM is to handle how your site content is delivered to the public. This consists of a handful of key functionalities:
- Serving users the webpage they’re trying to access.
- Matching the correct URL with the correct webpage.
- Loading the correct content (images, text, etc.) onto the page it’s designed to exist on.
- Making changes to existing content (as authored by your team).
- Keeping unauthorized users away from specific-eyes-only pages.
- Adding custom features to the AEM platform.
Without Apache Sling, there would be no way for AEM to show the correct pages, content, or matching URLs to anyone who visits your site, making it an integral component of AEM’s overall functionality.
OSGi Framework
Whereas Apache Sling deals with the delivery of your content, OSGi deals with the code and resources that enable AEM’s applications to run overall.
It groups AEM’s core components into smaller, easier-to-manage bundles, which, in this context, are Javascript Archive files. It also maintains the organization and order between these bundles.
OSGi keeps the order of AEM’s code by:
- Isolating bundles from one another, so that changes to one don’t disturb any others.
- Facilitating the addition and removal of bundles while AEM is running, without restarting.
- Keeping tabs on what services certain bundles provide, so that it’s easier for AEM to find and use those services for functionalities as needed.
- Storing alternate versions of the same bundle so that AEM maintains backward compatibility.
- Overseeing the dependencies bundles have on each other, and ensuring that codependent bundles are used together.
- Managing when bundles need to be activated and deactivated throughout their lifecycle.
Granite UI
In AEM, Granite UI is the technology through which your team will build your various user interfaces within your site. It lays the groundwork within your author tier, and is responsible for things like:
- Providing the tools needed for content authors to create custom components in AEM.
- Structuring, defining, and interpreting data inputs from forms built into your site.
- Setting up and managing dialogs, which are components that interact with or request input from your site users.
- Allowing extensive customization of the UI, for easy tailoring to unique projects.
- Streamlining the authoring process by providing a more user-friendly interface.
Java Content Repository
Within their websites, most large companies can expect to have a near-endless library of assets and resources. And when you’re uploading these assets into AEM, they’ve all got to go somewhere.
Thankfully, that’s what Java Content Repository (JCR) is there for. Adobe Experience Manager Java Content Repository functions as your go-to storage and organization system for any type of asset you might need to use on your site. That includes images, videos, text, audio, and more.
JCR is the powerhouse behind:
- Storing and cataloging all content.
- Organizing your content in a hierarchy.
- Tracking of the different versions of your content.
- Assigning metadata to your content.
- Robust search query capabilities that enable you to find content fast.
- Ensuring that only users with access to content can see it.
Apache Jackrabbit Oak
Working in tandem with JCR, Apache Jackrabbit Oak is responsible for the correct implementation of JCR within AEM. While JCR itself is like an overarching list of guidelines for the functionalities of the content repository, Apache Jackrabbit Oak is responsible for making those functionalities happen.
Apache Jackrabbit Oak also adds some additional capabilities to AEM’s content repository.
Most importantly, it’s the key driver of increased scalability in JCR, and makes it possible to store, organize, and interpret larger volumes of content at once.
Apache Jackrabbit Oak also enables better customizability of JCR to meet unique content management needs.
Apache Felix OSGi Container
The Apache Felix OSGi Container serves as the underlying framework that supports the modular architecture of Adobe Experience Manager (AEM).
It allows AEM to be highly adaptable by enabling developers to add or remove functionalities, known as “bundles,” without needing to restart the entire system.
This flexibility ensures that AEM can evolve with your organization’s needs, allowing for seamless updates and scalability without disrupting ongoing operations.
Sling Request Processing
Sling Request Processing is the component responsible for managing incoming requests from web browsers and directing them to the appropriate content within AEM.
It uses a mapping mechanism to locate requested content based on URLs and translates these requests into dynamic web pages using AEM’s content repository.
By dynamically assembling content, Sling ensures that users receive personalized and responsive web experiences, tailored to their specific requests and preferences.
Sightly (HTL)
Sightly, also known as HTML Template Language (HTL), is the templating language used in AEM for creating web pages and components.
It provides a structured and secure approach to web development, enforcing separation of concerns between content and presentation layers.
Developers can write clean and maintainable code using Sightly, reducing the risk of security vulnerabilities such as Cross-Site Scripting (XSS) and enhancing the overall stability and performance of AEM-powered websites.
GraphQL
GraphQL is a query language and runtime for APIs that allows clients to request specific data from AEM’s backend systems.
Unlike traditional RESTful APIs, GraphQL enables clients to define the structure of the data they need, reducing over-fetching and under-fetching of information.
By empowering clients to request only the necessary data, GraphQL optimizes network efficiency and improves the responsiveness of AEM-powered applications, enhancing the overall user experience.
AEM Modules (Core Components)
AEM’s authoring interface was built with easy usability, robust capability, and customizability in mind. When authors are hard at work creating or editing webpages in AEM, they won’t be working with a bare-bones, empty platform.
There are thirty core components within AEM’s authoring interface, all of which are designed for reliable use and customizability. Here’s a brief snapshot of some of the biggest benefits of all components:
- Cloud-capability, which enables components to work reliably.
- Versatility, which allows content authors to create limitless layouts.
- SEO-friendliness, which strengthens sites with semantic HTML output.
- Versioning ability, which protects your site from breakage when components update.
- Open-sourcing, which opens the floor for developers to improve on what’s there.
If that leaves you itching to give AEM’s authoring interface a test drive, we feel that. It’s a powerful toolbox that takes page authoring to the next level and enables AEM to be as simple or as complex as you need it to be.
Conclusion
By now, you should have a bird’s eye view of each of AEM’s four vital architectural pieces, as well as the tech stack that comprises AEM’s cornerstone functions.
Particularly when companies grow, expand to multiple sites, and broaden their horizons, AEM is built to grow right alongside. So, whether you’ve got a lot of authoring needs happening at once, a lot of page requests, or a treasure trove of assets to store, the CMS solution powered by Adobe Experience Cloud adapts without hesitation.
And, in today’s convoluted and fast-changing online landscape, that’s what marketers and UI designers alike need most.
FAQ
What language is AEM written in?
AEM is built on Java.
What are the Java design patterns used in AEM?
Because of OSGi’s modular capabilities, many Java design patterns are supported, including (but not limited to): Singleton, Whiteboard, Adapter, Resource Adapter, Decorator, and Observer.
Does AEM have an API?
Yes, AEM uses a variety of APIs, including (but not limited to): JCR API, Apache Sling API, RESTful APIs, and Javascript APIs.
Does AEM use Spring?
AEM isn’t inherently based on the Java Spring framework; however, it can be integrated with Spring-built custom code or custom extensions.
Where does AEM store content?
Content is stored in AEM’s Java Content Repository, which utilizes Apache Jackrabbit Oak.
