AEM - An overview of the basic building blocks

In the sections below we will break down the architecture of a aem deployment, into bite sized chunks so that you can get familiar with how it all fits together

The Base (Server infrastructure required / minimum requirements)

AEM can run on any system that supports Java standard edition 8. 

There are however a list of operating systems that are officially supported: https://docs.adobe.com/docs/en/aem/6-2/deploy/technical-requirements.html

In the case of a local install used for development, AEM can be installed directly so long as the development machine has a supported Java platform installed.

Bare Minimum requirements (AEM 6.2): 

• Installed Java Platform, Standard Edition JDK
• 5GB free disk space
• 2GB memory

You will want to have Much better specs than that for a development or production environment.

The Software Layers

Software Layers of an individual AEM instance

OSGI

OSGi is a dynamic module system for Java. It defines means to install, uninstall, update, start and stop modules. Those modules are called bundles, but are, in their simplest form, actually Java jar files with a special Manifest. Modules can be installed, uninstalled etc without stopping or restarting the Java VM.

An OSGi framework manages the described lifecycle of and dependencies between the bundles in a secure way. A bundle needs to state which Java packages it exports and which it imports. The import and export statements can be annotated with version information, so that you even can have more than one version of the same package in the same Java VM.

Source: http://stackoverflow.com/questions/4578850/what-is-osgi-and-what-are-some-examples-of-its-use

JCR

A JCR (Java Content Repository) is a type of object database tailored to storing, searching, and retrieving hierarchical data. The JCR API grew out of the needs of content management systems, which require storing documents and other binary objects with associated metadata; however, the API is applicable to many additional types of applications. In addition to object storage, the JCR provides: APIs for versioning of data; transactions; observation of changes in data; and import or export of data to XML in a standard way.

The data in a JCR consists of a tree of nodes with associated properties. Data is stored in the properties, which may hold simple values such as numbers and strings or binary data of arbitrary length. Nodes may optionally have one or more types associated with them which dictate the kinds of properties, number and type of child nodes, and certain behavioral characteristics of the nodes. Nodes may point to other nodes via a special reference type property. In this way nodes in a JCR offer both referential integrity and object-oriented concept of inheritance.

Source: https://en.wikipedia.org/wiki/Content_repository_API_for_Java

CRX

CRX is short for Content Repository eXtreme, Day's JCR-compliant repository. CRX allows you to store, manage, and access data using a standardized Java interface.

The Authors

The instances of AEM are effectively all the same, with configuration changes determining each instances role. 

The first of these roles is the Author instance. This is the environment where you, and your colleagues, will input your content and administrate the system.

Individuals with Designer, Administrator and Content Author functions will use these instances to create, configure and administrate the AEM system.

Asset Storage (the DAM)

The Digital Asset Management system is used by AEM to store and manage assets (images / other media). It forms part of each instance by default, but you would generally point all instances to the a single instances dam, or set up an external dam. 

This can get quite complex, as you could if you wanted to set up replication from each author instances dam to every other author instances dam.

For purposes of simplicity we will illustrate this using a dam that is set up external to each author server, that each server syncs to: 

The Publish Layer

The instances of AEM that form the Publish layer are effectively AEMs equivalent of the 'Production' system. This is the layer that will present published content to the end user. 

But, given the above system, how does content move from the Author environment, to the Publish environment? What is the mechanism or process that achieves this?  

Enter the Replication agent. 

Replication Agents

The Replication agent is central to the workings of AEM. It is used to: 

• activate content from the Author to the Publish environment
• explicitly clear the Dispatcher cache 
• return user input from the Publish environment back to the Author environment (reverse replication)

The replication agents are either set up on the Author environment (standard replication) or the Publish environment (reverse replication). 

The diagram below shows 1 to 1 replication from Author instances to Publish instances. This is purely to illustrate the concept. In a production system this could look far more complex, with replication possibly happening from each Author instance to every Publish instance, and back. 

Additional Reading: https://docs.adobe.com/docs/en/aem/6-2/deploy/configuring/replication.html

The Dispatchers

The final piece of the puzzle is the Dispatcher. This is Adobe Experience Manager's caching and/or load balancing tool.

For caching, the Dispatcher works as part of an HTTP server, such as Apache, with the aim of storing (or "caching") as much of the static website content as possible and accessing the website's layout engine as infrequently as possible.

In a load balancing role, the Dispatcher distributes user requests (load) across different clustered CQ instances.

Additional Reading:

• https://docs.adobe.com/docs/en/dispatcher.html
• https://helpx.adobe.com/experience-manager/using/dispatcher-faq.html

Our final architecture, with all of these pieces in place, would look something like this:

Hopefully this will have helped you get a better understanding (high level) of an AEM deployment. 

Happy Architecting!