Architecture Overview

Architecture Overview
Overview / CQ / Adobe Experience Manager 5.6.1 / Exploring /

This page brings together an overview of both the internal architecture of an AEM instance (what is actually
running on the server) and the deployment architecture typically used (how do the multiple AEM instances
in your installation interact with each other.
We begin with a look at the AEM technology stack.

The AEM Stack

This section details the technology stack on whch AEM is built. The stack can be divided as follows, from
lowest to highest level:
Java Platform
Java Runtime Environment (JRE 1.6 minimum. JRE 1.7 recommended)
Granite Platform (runs on JRE)
OSGi Framework (encapsulates all subsequent elements)
CQSE Servlet Engine (optional external application server)
CRX Content Repository
Sling Content Delivery
Granite UI
Abobe Experience Manager (runs on Granite platform, within OSGi framework)
Individual AEM modules (WCM, DAM, Workflow, etc.)
Customer Applications (run on AEM)
Customer specific applications (websites, etc. also run within OSGi framework)

Java Platform
Adobe Experience Manager (AEM) is a Java web application and therefore requires a server-side Java
Runtime Environment (JRE). At least JRE 1.6 is required, though JRE 1.7 is recommended.
AEM is available in two forms:
A quickstart jar file. Simply double-clicking on the jar file will install a standalone instance of AEM
complete with a built-in servlet engine. Apart from the JRE itself, no other software infrastructure
is required. Once installed the server can be started and stopped either via the desktop GUI or the
command line.
A war file to be deployed in an external application server. In this case, in addition to the the JRE, an
application server supporting Java Servlet Specification 2.4 or later is also required.
AEM will run on any OS for which the required JRE is available, this includes Windows, Mac OS X and a
variety of Unix systems. See XX for more details.
For minimum hardware requirements, see XX.
2012 Adobe Systems Incorporated.
All rights reserved.

Page 1

Created on 2015-04-30

Architecture Overview

Granite Platform
Granite is Adobe's open web stack. It forms the technical foundation on which AEM is built. The following
sections discuss each element in more detail.

OSGI FRAMEWORK
AEM includes an OSGi component framework based on Apache Felix, which implements OSGi Service
Platform Release 4.
OSGi is a dynamic software component system for Java. In an OSGi-based system, an application is
composed of an assemblage of components, called bundles in OSGi terminology, which can be dynamically
installed, started, stopped and uninstalled at runtime, without shutting down and restarting the entire
application.
A bundle is a jar file holding Java classes that adhere to the OSGi specification (allowing the classes
to connect to and interact with the framework) and a special metadata file (in the jar file's META-INF
subfolder).
Apart from the OSGi framework itself, all other elements of AEM as well as any additional custom
applications written on top of the AEM platform are implemented as OSGi bundles.
In a running AEM instance, bundle management is provided through the AEM Web Console at
http://<host>:<port>/system/console/bundles

SERVLET ENGINE
In a quickstart installation, the built-in CQSE servlet engineruns as a bundle within the OSGi framework.
In a war file installation servlet handling is delegated to a third-party application server.
AEM includes a built-in servlet engine (CQSE) which runs as a bundle within the OSGi framework when
AEM is deployed via the standalone quickstart jar file.
In order to deploy AEM within a third-party application server, the war file package shoud be downloaded
and deployed as directed by the application server documentation.
In general, AEM requires an application server that supports Java Servlets API 2.4 or later. For details
on which application servers are supported see Servlet Engine and Application Servers. For details on
performing the war file deployment see Installing AEM on an Application Server.

JCR CONTENT REPOSITORY

All data within AEM is stored in the built-in CRX content repository, which is an implementation of the Java
Content Repository Specification (JCR).
All data in AEM is stored in its built-in content repository. The terminology surrounding the repository can
sometimes be confusing, so here is a summary:
The repository built into AEM is called CRX.
CRX is Adobe's implemention of the Content Repository Specification for Java Technology 2.0, an
official standard published through the Java Community Process as JSR-238 (version 1.0 was known as
JSR-170)
The specification is usually referred to as JCR. JCR designates the type of repository; CRX being one
example.
Another example of a JCR repository is Apache Jackrabbit. Jackrabbit serves as the reference
implemention for JCR.
CRX, while techncially a separate implementation of the specification, is based on the Jackrabbit
codebase.
A JCR repository is a specific type of database designed for fine-grained access to hierarchical, unstructured
and semi-structure data. It combines features of a traditional relational database with those of a conventional
file system.
File system-like features supported by JCR include:
Hierarchy: Content in a JCR repository can be addressed by path. This is useful when delivering
content to the web since most websites are also organized hierarchically.
Semi-structured content: JCR can store semi-structured documents, like XML, either as opaque files
(as a file system would) or as structures ingested directly into the JCR hierarchy.
Access Control and Locking: JCR can restrict access to different parts of the content hierarchy based
on policies or ACLs. It also supports locking of content to prevent conflicts.
2012 Adobe Systems Incorporated.
All rights reserved.

Page 2

Created on 2015-04-30

Architecture Overview

Database-like features supported by JCR include:

Query Access: JCR supports querying with languages such as SQL.
Structured Content: JCR can enforce constraints on data structures according to a schema.
Referential Integrity: JCR can enforce referential integrity between content items.
Transactions: Interactions with a JCR repository can be bracketed in transactions and rolled back when
needed.
In addiition, JCR provides the following services that content-centric applications often need, but that neither
file systems nor databases typically provide:
Unstructured Content: JCR can also support arbitrary dynamic data structures without schema
constraints.
Full-Text Search: JCR supports full-text search of content.
Sort Order: Items within the hierarchy can maintain their ordering, if desired.
Observation: API clients can register listeners to react to changes made to the repository.
Versioning: JCR supports an advanced versioning system for repository content.
NOTE

For more information on the JCR content repository model and API you can consult the following:
JCR 2.0 Specification (PDF)
JCR 2.0 API Javadoc
Apache Jackrabbit (JCR reference implementation)
Technology Compatibility Kit
You can also find more information in the CRX section of the documentation: Exploring CRX.

SLING CONTENT DELIVERY

GRANITE UI
AEM FUNCTIONALITY
The AEM platform is composed of a number of modules. Consult the appropriate section of the documention
for more information:
Web Content Managment
Authoring
Tagging
Content Targeting
Multivariate Testing
Campaign Management
Digital Asset Management
Workflow
Media Publisher
Dynamic Media

DEVELOPING ON AEM
Custom applications are packaged and deployed as AEM packages. The Package Manager allows you to
create your own packages and install packages from other sources. The Package Share ingerated into AEM
provides a hub for AEM packages from both Adobe and third party sources.
For details on custom applications, see the Developing section.

Deployment Architecture
Adobe Experience Manager Environments
An Adobe Experience Manager (AEM) deployment usually consists of multiple environments, used for
different purposes on different levels. A production environment often consists of at least one author instance
and one publish instance. Depending on the scale of a project, a production environment may consist of
2012 Adobe Systems Incorporated.
All rights reserved.

Page 3

Created on 2015-04-30

Architecture Overview

several author and/or publish instances, and at a lower level, the CRX repository may be clustered to several
instances as well. Additionally, separate development and test environment levels may also consist of both
author and publish instances, mirroring the production environment to a varying extent.

DEVELOPMENT
Prior to authors creating and editing their content in AEM, the developers are responsible for developing and
customizing the proposed website. They:

develop and customize components

realize the design within the website
develop the necessary scripts to implement the required functionality of the website

Depending on the scale of your system, the development environment can have both author and publish
instances, or the test environment will be used for such functionality.

TEST

After development, it is usual to have a Testing environment where you can access the new system, to
test both design and functionality.

PRODUCTION
As mentioned previously, the production (or live) environment consists of at least both:

an authoring instance for the input of content

a publish instance for content made available to visitors to the website

Between the different environments, any content, design templates, or customized web application
functionality is usually transferred by exporting and importing packages between the different content
repositories. Between different instances, content can be directly replicated (copied from destination to
source) using a HTTP, or HTTPS, connection.
The replication of content between instances can be configured in detail as an automatic process. For
example, content may generally be managed on an author instance and replicated to a publish instance,
while public comments on blogs and form submissions may be reverse-replicated from a publish instance
back to an author instance, for moderation or other possible workflows.
The following diagram gives an overview of typical configurations possible for a AEM environment. It shows
how content flows from the authoring environments until it is available to be accessed by visitors to your
website. It also highlights the fact that to increase performance and availability it is common to combine
several authoring and publishing environments to service a website.

AEM Instances
While different instances in different environments are all installations of the same AEM software installed
in different places in the overall system infrastructure, they differ mainly in the way they are configured. For
example, it is that configuration which determines whether a AEM instance behaves as an author instance or
a publish instance.
2012 Adobe Systems Incorporated.
All rights reserved.

Page 4

Created on 2015-04-30

Architecture Overview

AUTHOR
Author instances are usually located behind the internal firewall. This is the environment where you, and your
colleagues, will perform authoring tasks, such as:

administrate the entire system

input your content
configure the layout and design of your content
activate your content to the publish environment

Content that was activated is packaged and placed in the author environment's replication queue. The
replication process then transports that content to the publish environment.
In order to reverse-replicate data generated in a publish environment back to the author environment, a
replication listener in the author environment will poll the publish environment and retrieve such content from
the publish environment's reverse-replication outbox.

PUBLISH
A publish environment is usually located in the Demilitarized Zone (DMZ). This is the environment where
visitors will access your website and interact with it; be it public, or within your intranet.

holds content replicated from the author environment

makes that content available to the visitors of your website
stores user data generated by your visitors, such as comments or other form submissions
may be configured to add such user data to an outbox, for reverse-replication back to the author
environment

The publish environment generates your websites content pages dynamically in real-time and the content
can be personalized for each individual user.

CLUSTERING AND LOAD BALANCING

To increase availability, and performance, of your Production environment, it is common to combine
multiple author and/or publish instances, by either making them available to different groups of users or by
load balancing them behind a Dispatcher configuration.
It is also possible to combine multiple instances of the CRX content repository to create a high-availability
JCR solution, which can then be integrated with your AEM solution to maximize the protection against
hardware and software failure. Such CRX Clusters are supported for various persistence managers. See the
CRX Clustering documentation for further information.

Load Balancing
The Dispatcher keeps internal statistics about how fast the web servers are processing documents. Based
on this data, the Dispatcher estimates which server will provide the quickest response time when answering
a request, and so it assigns the necessary request, and computational time, to that server.
You gain:
Increased response time
In practice this means that the Dispatcher shares document requests between several web servers. Because
each server now has fewer documents to process, you have faster response times. The Dispatcher keeps
internal statistics for each document category, so it can estimate the server load and distribute the queries
efficiently.
Increased fail-safe coverage
If the Dispatcher does not receive responses from a web server, it will automatically relay requests to
the other server(s). Thus, if a server becomes unavailable, the only effect is a slowdown of the site,
proportionate to the computational power lost. However, all services will continue.
Increased flexibility
You can also manage different websites on the same static web server.
2012 Adobe Systems Incorporated.
All rights reserved.

Page 5

Created on 2015-04-30

Architecture Overview

CACHING, FRYING AND BAKING

Traditionally, the concepts of baking versus frying are an important distinction between different Web
Content Management Systems. In CMS jargon, "baked" refers to the concept of committing data to static
files at publish-time, while "fried" refers to the concept of processing data for final presentation at requesttime.

The dynamic advantage

When generating a response on request from a visitor, a content management server can read content
from a repository, take user preferences and appropriate access rights into account, before transforming
the content into a document that is tailored to the visitor's needs and rights. This allows to provide up-todate content in real-time in a highly flexible way, but can require significant resources, by demanding more
processing power or otherwise causing more computation time, slowing down the response time if many
visitors use the system.

The static advantage

When serving a visitor pre-generated static pages, the web server can return that response very quickly,
as it can usually be taken directly from memory, at worst it is read from the local drive and served without
requiring any further processing. Since these static pages are pre-generated only once, the same content will
be delivered for each request and any visitor. This process is very simple, and thus extremely efficient, but
does not cater for personalization or dynamic content.

Leveraging caching to combine the advantages

In reality, websites often benefit from a mixture of the two approaches. At its core, AEM processes content
dynamically, providing primarily the benefits of a "frying" CMS. By combining this dynamic capability with
highly customizable caching rules in the Dispatcher, AEM based web applications can additionally leverage
most of the benefits of a "baking" CMS.
AEM can also be used to generate entirely static content, that can for example be burned to CD-ROM or
deployed through web servers, which are physically separate from the content management environment.
A limitation of traditional "baked" content management solutions is that the process of generating the
static output can require a lot of time and significant resources. By appropriately configuring the caching
characteristics of AEM, it can be possible to significantly reduce the time required for running the "baking"
process, allowing for shorter turnaround times and more frequent updates of large statically served
websites.

2012 Adobe Systems Incorporated.

All rights reserved.

Page 6

Created on 2015-04-30

Architecture Overview

The Dispatcher allows to take full advantage of caching and load balancing to achieve an environment that is
efficient, fast and dynamic. It works as part of a static HTML server, such as Apache, with the aim of:

storing (or "caching") as much of the site content as is possible, in the form of a static website.
accessing the layout engine to retrieve dynamic content as and when necessary, but as little as
possible.

Which means that:

static content is handled with exactly the same speed and ease as on a static web server; additionally
you can use the administration and security tools available for your static web server(s).
dynamic content is generated as needed, without slowing the system down any more than absolutely
necessary.

The Dispatcher contains mechanisms to generate, and update, static HTML based on the content of the
dynamic site. You can specify in detail which documents are stored as static files and which are always
generated dynamically.
Generally, the Dispatcher works on the principle of:

if the cached document is current, the Dispatcher returns that statically cached version of it immediately
if the cached document is out of date, the Dispatcher retrieves the current version from the appropriate
AEM instance, a step which it can further optimize using Load Balancing

This allows you to take full advantage of a static web server, while retaining the capability to process
dynamic content as and when necessary.

2012 Adobe Systems Incorporated.

All rights reserved.

Page 7

Created on 2015-04-30