AEM Developer Series
- Day 00: AEM Developer Series
- Day 01: Introduction to AEM
- Day 02: AEM Architecture
- Day 03: Setting up AEM Development Environment
- Day 04: Developing First OSGi Bundle
- Day 05: Working with Sling Servlets in AEM
- Day 06: Playing with Sling Post Servlet
- Day 07: Creating your first component in AEM
- Day 09: Dueling with Java User API
- Day 10: Getting to know Sling Models
- Day 11: Client Libraries in Action
- Day 12: Creating your custom OSGi Configuration
- Day 13: Schedulers in AEM
- Day 14: Eventing in AEM
- Day 15: Custom Workflows in AEM
- Day 16: Creating JMX Beans in AEM
- Day 17: Working with QueryBuilder API
- Day 18: Working with Granite Datasources in AEM
- Day 19: Replication API in Action
- Day 20: Working with Users and Groups in AEM
Hence, without wasting more time, let's dive into the AEM architecture.
|image source: https://prezi.com/i97-ptdowxfi/aemcq-architecture/|
Java Runtime Environment (JRE)AEM is a Java based web application hence it requires server-side Java Runtime Environment (JRE).
It is Adobe's open web stack and it forms the technical base on which AEM is built. It also provides the foundation UI framework and its major goals are to -
- provide granular UI widgets
- implement best UI practices
- provide an extensible UI
|image source: aemstack|
|image source: OSGi org|
It is a set of specifications. Its core specification defines a component and service model for Java. A practical advantage of OSGi is that every software component can define its API via a set of exported Java packages and that every component can specify its required dependencies.
The components and services can be dynamically installed, activated, de-activated, updated and uninstalled.
The OSGi specification has several implementations, for example, Eclipse Equinox, Knopflerfish OSGi or Apache Felix. AEM uses Apache Felix in its tech stack.
For more details see this post.
Java Content Repository (JCR)
This combines the attributes of file systems and RDBMS and tries to provide the best of both worlds. According to JSR 283, "the Java Content Repository API defines an abstract model and a Java API for data storage and related services commonly used by content-oriented applications."
The JCR storage model is a tree of nodes and properties: nodes are used to organize the content and named properties store the actual data, either as simple types (string, boolean, number, etc.) or as binary streams for storing files of arbitrary size.
AEM 6.x uses Apache Oak as the JCR implementation.
AEM is built using Sling, a Web application framework based on REST principles that provide easy development of content-oriented applications.
Sling uses a JCR repository, such as Apache Jackrabbit, or in the case of AEM, the CRX Content Repository, as its data store.
From Apache Sling's official documentation, Sling maps HTTP request URLs to content resources based on the request's path, extension and selectors. Using convention over configuration, requests are processed by scripts and servlets, dynamically selected based on the current resource. This fosters meaningful URLs and resource-driven request processing, while the modular nature of Sling allows for specialized server instances that include only what is needed.
Thus, anything present in the JCR can be accessed in a RESTful way using HTTP requests.
On top of the above technology stack, there are AEM specific modules that run. These modules are AEM Sites, AEM Assets, Workflows etc.
On top of everything, the organization-specific code runs which is according to their specific needs. In the upcoming posts, we will be learning to do this only - creating custom code on top of AEM.
In this post, we tried to look into the basic building blocks of AEM. From the next post onwards, we will get our hands dirty by learning and writing custom code on AEM. Stay tuned!! 🌝
I would love to hear your thoughts on this post and would like to have suggestions from you to make this post better.
Happy Learning 😊