Documente Academic
Documente Profesional
Documente Cultură
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.
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.
Page 2
Created on 2015-04-30
Architecture Overview
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.
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:
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:
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:
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.
The publish environment generates your websites content pages dynamically in real-time and the content
can be personalized for each individual user.
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
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.
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.
Page 7
Created on 2015-04-30