AEM - Overview

AEM - Core Concepts

1-Sling

2-JCR 

3-OSGi

4-HTL / Sightly

Java Content Repository

The Java Content Repository (JCR) standard, JSR 283 , specifies a vendor-independent and implementation-independent way to access content bi-directionally on a granular level within a content repository.

Sling Request Processing

Introduction to Sling

AEM is built using Sling , a Web application framework based on REST principles that provides 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. Sling has been contributed to the Apache Software Foundation - further information can be found at Apache.

Using Sling, the type of content to be rendered is not the first processing consideration. Instead the main consideration is whether the URL resolves to a content object for which a script can then be found to perform the rendering. This provides excellent support for web content authors to build pages which are easily customized to their requirements.

The advantages of this flexibility are apparent in applications with a wide range of different content elements, or when you need pages that can be easily customized. In particular, when implementing a Web Content Management system such as the WCM in the AEM solution.

Sling is Content Centric

Sling is content-centric . This means that processing is focused on the content as each (HTTP) request is mapped onto content in the form of a JCR resource (a repository node):

the first target is the resource (JCR node) holding the content

secondly, the representation, or script, is located from the resource properties in combination with certain parts of the request (e.g. selectors and/or the extension)

RESTful Sling

Due to the content-centric philosophy, Sling implements a REST-oriented server and thus features a new concept in web application frameworks. The advantages are:

very RESTful, not just on the surface; resources and representations are correctly modelled inside the server

removes one or more data models

previously the following were needed: URL structure, business objects, DB schema;

this is now reduced to: URL = resource = JCR structure

OSGI

OSGi defines an architecture for developing and deploying modular applications and libraries (it is also known as the Dynamic Module System for Java). OSGi containers allow you to break your application into individual modules (are jar files with additional meta information and called bundles in OSGi terminology) and manage the cross-dependencies between them with:

services implemented within the container

a contract between the container and your application

These services and contracts provide an architecture which enables individual elements to dynamically discover each other for collaboration.

An OSGi framework then offers you dynamic loading/unloading, configuration and control of these bundles - without requiring restarts.