Adobe Experience Manager (AEM) is a content management platform which is the main part of the Adobe Marketing Cloud.
The following pages will describe the architecture of AEM and how it is used for projects i have worked on including how an AEM based web application can be built.
While the latest version of AEM is 6.3, This article is currently for version 6.2. Functionally there are not a lot of changes in the versions that will affect most developers.
"Adobe Marketing Cloud gives you the most complete set of integrated digital marketing solutions available. It provides everything you need to organise, access, and personalise your marketing content. It gives you deep insights into what’s working with your customers and the ability to consistently deliver the best experiences to every customer across every channel."
While AEM (Experience Manager) is only a small part of the adobe marketing cloud, it is the only part that these pages will discuss.
One thing to note about the following pages is that they are an introduction to AEM and how to build applications, and far from being an intensive instruction on how to build AEM applications
This article does not go into AEM maintenance or the low-level structure of supporting an AEM instance
AEM Structure:
When we talk about AEM we talk about the entire eco system that goes to make up a working system.
AEM is a highly scalable system and can be configured in a number of ways.
AEM Server Layout
As you can see in the above diagram, there are multiple layers available as part of an AEM system. The diagram above shows a highly scalable option, while possible is generally not used and is not good practice.
The following pages will describe the architecture of AEM and how it is used for projects i have worked on including how an AEM based web application can be built.
While the latest version of AEM is 6.3, This article is currently for version 6.2. Functionally there are not a lot of changes in the versions that will affect most developers.
"Adobe Marketing Cloud gives you the most complete set of integrated digital marketing solutions available. It provides everything you need to organise, access, and personalise your marketing content. It gives you deep insights into what’s working with your customers and the ability to consistently deliver the best experiences to every customer across every channel."
While AEM (Experience Manager) is only a small part of the adobe marketing cloud, it is the only part that these pages will discuss.
One thing to note about the following pages is that they are an introduction to AEM and how to build applications, and far from being an intensive instruction on how to build AEM applications
This article does not go into AEM maintenance or the low-level structure of supporting an AEM instance
AEM Structure:
When we talk about AEM we talk about the entire eco system that goes to make up a working system.
AEM is a highly scalable system and can be configured in a number of ways.
AEM Server Layout
As you can see in the above diagram, there are multiple layers available as part of an AEM system. The diagram above shows a highly scalable option, while possible is generally not used and is not good practice.
Author
The author is where the editorial staff create and manage page content. It is also the central hub of AEM, while in the above configuration it is shown as a cluster, and this is possible using the MongoMK file system, it is not recommended unless your system has a high number of editorial users, this is due to the overheads that MongoMK has on AEM. For more information about the deployment options and their recommendations go to Recommended Deployments.
In all of the following pages I will assume a single author instance which is the norm for most AEM instances.
The author is where the editorial staff create and manage page content. It is also the central hub of AEM, while in the above configuration it is shown as a cluster, and this is possible using the MongoMK file system, it is not recommended unless your system has a high number of editorial users, this is due to the overheads that MongoMK has on AEM. For more information about the deployment options and their recommendations go to Recommended Deployments.
In all of the following pages I will assume a single author instance which is the norm for most AEM instances.
Publisher
The publisher can be thought of as the main server that the end user will see, while it is hidden behind the dispatcher it holds the latest versions of the content that the editorial staff have decided to activate and any content loaded by the end user will have come from a publisher.
As can be seen in the diagram above the publishers can be clustered, each running independently of the others.
The publisher can be thought of as the main server that the end user will see, while it is hidden behind the dispatcher it holds the latest versions of the content that the editorial staff have decided to activate and any content loaded by the end user will have come from a publisher.
As can be seen in the diagram above the publishers can be clustered, each running independently of the others.
Dispatcher
The dispatcher is the caching layer of AEM. While it has been shown as clustered to multiple publishers, and this is possible it is generally setup in a one to one relationship with a publisher and the load balancing is handled by an external load balancer (not part of the AEM stack)
The dispatcher controls what content can and can't be seen from the dispatcher as well as caching static content.
While it has been shown running on it's own server, in smaller installations the dispatcher will be installed on the same server as the publisher.
while the above image shows a possible combination there are many ways AEM can be configured, from a single author, publisher, dispatcher setup to a highly scalable, multi region setups as shown in the next image.
AEM Server Layout - Complex
The dispatcher is the caching layer of AEM. While it has been shown as clustered to multiple publishers, and this is possible it is generally setup in a one to one relationship with a publisher and the load balancing is handled by an external load balancer (not part of the AEM stack)
The dispatcher controls what content can and can't be seen from the dispatcher as well as caching static content.
While it has been shown running on it's own server, in smaller installations the dispatcher will be installed on the same server as the publisher.
while the above image shows a possible combination there are many ways AEM can be configured, from a single author, publisher, dispatcher setup to a highly scalable, multi region setups as shown in the next image.
AEM Server Layout - Complex
No comments:
Post a Comment
If you have any doubts or questions, please let us know.