Skip to main content

We have all deployed AEM Technology stack in our projects, picked the right modules to deliver the functionality we require and customize its various components.

To provide an excellent solution on AEM, we need a reasonable understanding of how AEM architecture stack works and the various components that make up the AEM technology stack. This article will take you through the AEM architecture stack from version 6 of AEM.

Before we deep dive in, we’d like to cover some of the terminologies we will be using freely in our architecture explanation below:

OSGI

OSGI stands for Open Services Gateway Initiative, a set of specifications that define a dynamic component system for Java. It enables a development model where an application is composed of several components packaged in bundles. These components communicate locally and across the network through services.

There is also a service registry to list components and discover other components in the ecosystem. The AEM uses a OSGI container called Apache Felix to manage these AEM bundles.

JCR

JCR is the Content Repository API for Java (JCR), a Java API specification for unified access to content repositories. AEM uses the Apache Jackrabbit Oak as its content storage repository. This repository is where all the content authored in AEM resides, forming an integral part of the AEM technology stack.

AEM Stack

The AEM technology stack enables users to author, manage and share content with various other applications within the enterprise. It furthers provides a way to store and expose content to other applications and users.

A key feature of the AEM framework is its REST-based API that clients can consume programmatically to access the various capabilities of AEM. This API layer exists on top of the AEM content repository and exposes the content.

Open source Stack employed

The content repository is built on top of the Apache JackRabbit and the API layer is built on top of Apache Sling. Jackrabbit Oak further supports two main storage methods, TarMK and MongoMK, for storing content data at rest.

TarMK is a set of tar files that stores the content as diverse types of records within larger segments. To track the latest state of these repositories, Journals are used.

On the other hand, MongoMK is built on top of MongoDB the opensource NoSQL database. A MongoMK is usually deployed in a larger site, where data has to be sharded and clustered to manage the huge volumes of data.

AEM Implementation

The API layer of the AEM framework exposes a set of standard interfaces available for consumption by the various functional blocks of AEM – Sites, Assets and Forms. These are well-known functionalities of AEM that end users are familiar with.

To comprehend these functionalities, AEM internally exposes a set of standard interfaces built using Apache Sling API to the functional blocks. In addition, it also exposes horizontal capabilities required across all functional areas such as security and access management through SAML and oAuth support, workflow and authorization for various content workflows.

It has a fully-featured UI framework called Granite/Coral framework, which provides strong support for Assets and asset metadata management.

Understanding Storage in AEM

Jackrabbit Oak, the underlying content engine of AEM supports two storage methods. The Oak framework is layered in a way that the storage mechanisms are abstracted in their respective microkernels so that the JCR implementation layer is storage independent, by using the microkernels as configurable plugins for storage. The two types of storage that Jackrabbit oak supports are Tar Storage and Mongo Storage.
They are also referred to as the TarMK (Tar microkernel) and MongoMK (mongo Microkernel) storage layers. The default configuration of AEM uses Tar Storage.

The AEM storage classes are raw storage of data. AEM at a higher level of abstraction supports the concept of versioning of pages and nodes. AEM creates a new version of a page or node when we activate a page after updating the content. These versions are never purged, so the AEM content repository will grow over time and cause performance issues. To manage the content repositories, AEM supports the concept of content purging with a set of content retention options that can be configured to determine the versions that are to be retained.

To ensure that disk space and performance of AEM is well managed, one such configuration must be set up in any production repository.

Summary

The AEM architecture stack is built on top of a robust open-source stack and its adherence to various global Java standards makes the AEM application stack, a powerful and extensible platform for content authoring and distribution. We hope that the inside view of AEM will help you understand how best to leverage AEM for all your content authoring and management needs.

Frequently asked Questions

What technology is used in AEM?

AEM uses Java for backend development, OSGi (Open Services Gateway Initiative) for modular component management, Apache Sling for web framework, and Apache Jackrabbit Oak as its content repository. Additional technologies include Apache Felix for OSGi container management and Granite/Coral UI framework. These technologies enable robust, scalable, and extensible content management architecture for enterprise digital experiences.

What is the architecture of AEM?

AEM architecture consists of a layered structure, including the Content Repository built on Jackrabbit Oak, Apache Sling Web Framework, OSGi dynamic module system, and Application Layer exposing RESTful APIs. This design supports content authoring, management, delivery, and integration capabilities. The architecture enables modular development, where components communicate through services across local and network environments.

What framework does AEM use?

AEM uses the Apache Sling framework, which maps HTTP request URLs to content resources based on the Java Content Repository (JCR). Sling's RESTful approach simplifies development and content delivery. Additionally, AEM employs the OSGi framework for dynamic component management and the Granite/Coral framework for comprehensive UI development and asset metadata management functionality.

What database does AEM use?

AEM uses Apache Jackrabbit Oak as its content repository to store content and binary assets. Oak supports multiple storage modes, including TarMK (Tar Microkernel) using tar files and MongoMK (Mongo Microkernel) built on MongoDB for larger deployments requiring data sharding and clustering capabilities.

What are AEM Modules?

AEM Modules are functional building blocks that provide distinct capabilities, such as sites for web content management, assets for digital asset management, forms for document workflows, and communities for social collaboration. Each module addresses specific content management and digital experience needs, enabling scalable and flexible solutions within AEM's modular ecosystem architecture.

Is AEM cloud based?

Yes, AEM can be deployed as Adobe Experience Manager as a Cloud Service, offering scalable, flexible, and continuously updated CMS infrastructure managed by Adobe. AEM also supports on-premise and hybrid deployments. Cloud deployment provides automatic updates, enhanced security, global content delivery, and reduced infrastructure management overhead for organizations.

What is the application layer of AEM?

The application layer exposes RESTful APIs built on Apache Sling, enabling clients and functional modules like Sites, Assets, and Forms to interact with content efficiently. This layer sits above the content repository and provides standardized interfaces for content access, workflow management, security, and authorization across all AEM functional areas.

How many components are in AEM?

AEM consists of numerous components , including OSGi bundles for modular features, UI components for authoring and presentation, and backend services. The exact number varies with version and customization, typically including hundreds of modular components. These components communicate through OSGi services and can be dynamically loaded, updated, or removed without system restart.

Leave a Reply

  • SHARE