{
Recently had an opportunity to work on AEM. And we had to use it in a very unconventional way... This led us to explore the inner workings of AEM, to understand its behavior in detail and hook it into the overall system architecture. What made it even more interesting is that this is my first experience with any CMS system :);
Summarizing my learning's in a series of blogs... starting with a simple introduction to AEM (from my pov);
}
Formerly and still popularly (at-least in my view) known as CQ5, Adobe Experience Manager (AEM) is one of its kind content management system.
The fundamental architecture of AEM is very different from many other CMS systems
At the core of it is the JCR repository. This node based simple storage structure forms the backbone of the AEM system. Almost everything in AEM which includes code, content, binaries, resources are stored in this JCR tree.
And sling with its resource oriented architecture forms the UI control layer in AEM. This is very different from the standard MVC paradigm that we have been so used to in web solution architectures. Only 2 factors matter in the sling architecture.
- The resource - is an unambiguous path to the source of information in the JCR tree
- The script that renders the resource - determines the script that is executed on the resource to deliver the response
Both the resource and the script are determined by the url used to access the web page.
And finally the OSGi which forms the back-end component framework, which provides for the heavy lifting business logic layer. All the Java logic we do goes into this layer.
And the interesting thing is, all these three are open source Apache projects.
The integrating factor that binds these three frameworks to provide cohesive functionality is the Adobe's Granite framework.
There are multiple other pieces that adds to the capabilities that AEM provides. One such important piece is the Dispatcher module. The next few articles focuses on this module in detail.
Recently had an opportunity to work on AEM. And we had to use it in a very unconventional way... This led us to explore the inner workings of AEM, to understand its behavior in detail and hook it into the overall system architecture. What made it even more interesting is that this is my first experience with any CMS system :);
Summarizing my learning's in a series of blogs... starting with a simple introduction to AEM (from my pov);
}
Formerly and still popularly (at-least in my view) known as CQ5, Adobe Experience Manager (AEM) is one of its kind content management system.
The fundamental architecture of AEM is very different from many other CMS systems
At the core of it is the JCR repository. This node based simple storage structure forms the backbone of the AEM system. Almost everything in AEM which includes code, content, binaries, resources are stored in this JCR tree.
And sling with its resource oriented architecture forms the UI control layer in AEM. This is very different from the standard MVC paradigm that we have been so used to in web solution architectures. Only 2 factors matter in the sling architecture.
- The resource - is an unambiguous path to the source of information in the JCR tree
- The script that renders the resource - determines the script that is executed on the resource to deliver the response
Both the resource and the script are determined by the url used to access the web page.
And finally the OSGi which forms the back-end component framework, which provides for the heavy lifting business logic layer. All the Java logic we do goes into this layer.
And the interesting thing is, all these three are open source Apache projects.
The integrating factor that binds these three frameworks to provide cohesive functionality is the Adobe's Granite framework.
There are multiple other pieces that adds to the capabilities that AEM provides. One such important piece is the Dispatcher module. The next few articles focuses on this module in detail.
