If you’ve ever tried to explain Adobe Experience Manager to a non-technical stakeholder, you’ve probably said something like “it’s our CMS.” But under the hood, AEM is much more than a traditional CMS. Its power comes from three core building blocks, OSGi, JCR, and Sling, that together make the platform modular, scalable, and highly extensible.

For architects and developers, understanding how these three layers fit together is crucial. It not only helps in debugging and performance tuning, but also in designing solutions that actually align with how AEM is meant to work. Instead of fighting the platform, you can start leveraging it.

In this article, I’ll walk through these three pillars in plain language and connect them to what you experience every day as an AEM practitioner.

OSGi Framework and Bundles

AEM relies on OSGi (Open Services Gateway Initiative) as its foundation for modularity. In practice, every AEM feature (components, services, workflows, etc.) is packaged as an OSGi bundle: essentially a JAR file with metadata about its dependencies. The Apache Felix container in AEM dynamically loads these bundles at runtime. This design solves the classic “JAR Hell” by isolating each component’s dependencies. Bundles can be installed, started, stopped, updated, or uninstalled on the fly without restarting AEM. For example, you could install a new image transformation bundle or update a business logic bundle while the server is running, with OSGi handling dependency resolution.

Key points of OSGi in AEM context

OSGi makes AEM extensible and maintainable, and new features can be plugged in as bundles, and existing bundles can evolve independently.

• Dynamic Modules

  • Developers write code as discrete bundles with a manifest that declares imports/exports. The OSGi framework automatically wires these bundles together.

• Service Registry

  • OSGi provides a registry of services (Java interfaces). Bundles can register services or consume other bundles’ services without tight coupling.

• Runtime Flexibility

  • AEM loads bundles at runtime so admins can update parts of the application on the fly. This means patching or adding functionality without full-system downtime.

Java Content Repository (JCR)

Beneath Sling and OSGi, AEM’s content is stored in a Java Content Repository (JCR). AEM specifically uses Apache Jackrabbit Oak, a scalable, hierarchical content store, as its JCR implementation. Think of JCR as a database that looks like a filesystem: content is organized in a tree of nodes and properties. Oak supports versions, transactions, full-text search, observation (event listeners), and access control out of the box.

How JCR works in AEM

JCR (Oak) is AEM’s persistent content layer. All content authors and workflows ultimately read/write to this shared repository. Because Oak is designed for high throughput and can scale out (with MongoDB), it supports the demanding read/write patterns of large websites and media libraries.

• Hierarchical Storage

  • Every page, asset, image, etc. is a node in the repository (under paths like /content/my-site or /etc). AEM’s UI and templates read and write these nodes.

• TarMK vs. MongoMK

  • Under the hood, Oak can use TarMK (local TAR file store) for single-node setups, or MongoMK (MongoDB) for clustered, large-scale needs. TarMK writes data to TAR files optimized for reads, whereas MongoMK shards content across multiple database nodes. This abstraction lets developers use standard JCR APIs without worrying about storage details.

• Services Provided

  • AEM builds upon JCR to offer versioning (every page update can be versioned), queries (JCR-SQL2 to find content), and events (listen to repository changes). This means developers can search content, roll back to older versions, or trigger processes when content changes.

Apache Sling Framework

On top of OSGi and JCR lies Apache Sling, the web framework that gives AEM its URL-to-content behavior. Sling treats the content repository itself as the HTTP content tree: every incoming URL is mapped to a node in the JCR and processed accordingly.

Key Sling concepts

Sling makes AEM a content-centric web server. It provides features like caching, authentication, and scripting support (HTML Template Language, JavaScript, etc.) to simplify building web UIs on repository data. For example, Sling lets authors create a JCR node for a “Text” component and author some text; the system automatically knows which component script to use when that node is requested.

• Resource Resolution

  • When a request arrives (e.g. GET /content/my-site/page.html), Sling looks up the corresponding JCR node (/content/my-site/page). We can't talk about Sling resource resolution, without adding this iconic illustration.

  

• Resource Types & Scripts

  • Each node has a sling:resourceType property (e.g. my-site/components/page), which tells Sling which rendering script or servlet to use. Sling will find the script (e.g. an HTL/Sightly or JSP file) under /apps or /libs that matches the resource type, and execute it to generate the HTML.

• Selector & Extension Handling

  • Sling also parses parts of the URL (selectors, suffix, extension) to determine exactly how to render. For example, /content/my-site/page.print.a4.html might mean “render the page in an A4 print-friendly format.” Sling’s RESTful, content-centric model means developers rarely write explicit servlet mappings – the framework handles it based on the repository structure.

Conclusion

By combining these three components, OSGi for modular services, JCR (Oak) for content storage, and Sling for web rendering, AEM delivers a flexible platform. Developers benefit from loose coupling (via OSGi), a powerful repository (with versioning and search), and a friendly content API (via Sling’s RESTful model).