AEM Architecture ExplainedCategory: Adobe Experience Manager (AEM) Posted:Apr 15, 2020 By: Alvera Anto
Today in this blog post, we will explore the technical aspect and speak about the architecture or the fundamental building blocks of AEM. Without consuming any additional time, let’s plunge into the AEM design.
Java Runtime Environment (JRE)
AEM is a Java-based web application and thus the application needs a server-side Java Runtime Environment (JRE) for it to function.
It is Adobe’s open web stack and it acts as the technical foundation on which AEM is built. It additionally gives the base UI system and its significant objectives are to:
- Provide granular UI widgets
- Employ the best UI practices
- Give an extensible UI
The OSGi framework is a collection of specifications. Its core command explains a component and the model for Java. One of the functional benefits of OSGi is that each product segment can characterize its API with a group of exported Java bundles and that each segment can indicate its necessary conditions.
The segments and administrations can be progressively introduced, activated, de-activated, refreshed, and uninstalled.
The OSGi specifications (KW) have numerous implementations, for instance, Eclipse Equinox, Knopflerfish OSGi, or Apache Felix. AEM utilizes Apache Felix in its tech stack.
Java Content Repository (JCR)
This consolidates the properties of document frameworks and RDBMS and attempts to give the best of the two worlds. As per JSR 283, “the Java Content Repository API characterizes a theoretical model and a Java API for information storage and related services that are mostly used by content-oriented applications.”
Click here to learn more
The JCR stockpiling model is a tree of nodes and properties: nodes are used to sort out the content and named properties store the genuine information, either as genuine data (string, boolean, number, and so on.) or as paired streams for storing records of subjective size.
AEM 6.x uses Apache Oak as the JCR implementation.
AEM is created using Sling. This is a Web application structure dependent on REST principles that facilitates hassle-free development of content-oriented applications.
Sling utilizes a JCR storehouse, for example, Apache Jackrabbit, or on account of AEM, the CRX Content Repository, as its information store.
From Apache Sling’s authentic documentation, Sling maps HTTP request URLs to content assets based on the request’s path, extensions, and selectors. Choosing convention over configuration, requests are handled by contents and servlets, progressively chosen, considering the present asset. This encourages significant URLs and asset-driven request handling, while the modular aspect of Sling allows specific server occasions that include relevant information.
Along these lines, anything present in the JCR can be accessed in a RESTful manner through HTTP requests.
Want to learn about AEM? Click here
Above the technology stack, there are AEM explicit modules that run. These modules are AEM Sites, AEM Assets, Workflows, and others.
Above all, the organization’s explicit code runs considering the specific needs.
So far we have understood the basic building blocks of AEM. Hope this post cleared all your doubts about the AEM architecture and related topics. Stay tuned with us for more such posts related to AEM!!
That’s all for today. If you’re interested to read more articles on this topic, feel free to visit ZaranTech Blog.