Architecture Decisions

There are a few things you should think about before you start building your app.

1. How will it work
2. What infrastructure will it be on
3. What is the security model
4. How is caching handled

How will it work

This is a big subject and every application is different so there is no silver bullet answer to how it should be built, this is dependant on doing an analysis of the requirements.

The following list is a few of what I think you should think about:

• Is it an end-user only system with fixed content pages
  • A fixed page system is the simplest implementation in AEM as all of the content is static
  • This should allow heavy caching at the dispatcher of both the static content (css/js) and the html
• Is there an authoring process
  • Authoring means someone can change the page content on the author and replicate it to the publishers for display,
  • Content pages can still be cached at the dispatcher to save calls to the publishers
• Is the content dynamic and personalized
  • Personalized data shouldn't be cached at the dispatcher
  • Pages should be built as static placeholder's and use ajax to load the data otherwise no pages can be cached
• Can the end-user send data to the system and what happens to it
  • If the data is just stored then you will need to consider setting up publisher tunneling
  • If the data is to be approved/mediated by an author then reverse replication should be setup
  • Data stored in the jcr:repository should be done via a service user
• Is there dynamic data for the users and where will it be stored
  • Storing a lot of data in the jcr:repository is a bad idea as it will slow down standard queries
  • Support of an external database or api server would be recommended
  • Api calls and database calls can be made via AEM to hide any other infrastructure but add overhead

What infrastructure will it be on

As mentioned in the how will it work section, there are lots of different application types that can be built on AEM so the infrastructure needs to be put in place to support it.

AEM Server layout

As mentioned previously there are multiple ways of configuring the AEM stack and the needs of the application dictate what the stack will be.

If you are a pure front end application with a bit of storage, while you will only ever use the aem publisher and dispatcher, an author should still be added to the stack to allow administration and tunneling if needed. This is the worst-case application for AEM as it doesn't utilize any of the main AEM facilities and could have been built on any web server.

The main considerations in a multi-server stack are where is the data stored. If it is in the jcr:repository you will need to enable either replication between the publishers and the author, or tunneling between the publishers.

While sticky sessions can be enabled on most load balancers, you can't rely on the user always arriving at the same publisher so data storage has to be your biggest consideration. 

It is possible to add a database into the stack for data storage, however, you should consider concurrency of the data and how the data is used on the publishers over the author.

If your application is running across multiple regions you may well have your publishers in disparate areas so replication of data from the authors or other publishers may be slow and will need to be considered, this will also affect databases, you will need to consider whether to shard your database or have multiple instances for different regions.

What is the security model

It may be that your application doesn't use any security in which this section will be negated, however, if your users do have to log in what is the method?

If the users will be presented with specific data based on their user then you will need to pass the user credentials to the service layer. 

AEM comes with a few built-in models for user access via AEM itself. By default you can use the built-in user manager and authentication method, this allows you to create users and add them to groups that will control what content is available to the user.

AEM also has an authentication handler structure which by default has handlers for a client certificate, oauth (v1/v2), and saml.

Each of the authentication handlers can be configured to support a path including the hostname so that you can have multiple ways of logging into your application.

Once logged in the user details are passed with every request to the application services.

Application structure

In the following pages, you will get a better understanding of the types of components both java and html based. The following diagram shows a basic representation of how components and services interact in an AEM component 

Page Generation

As you can see there are a lot of parts that make up the display of a page within AEM.

While a page is a piece of HTML, in AEM you generally make the page a template with a parsys (an AEM component that allows the addition of other components)

Each of the components is a piece of HTML in their own right, however, they only render the html piece to display the component. A component can have one or many java models or wcm use classes that can also access one or more OSGI services or components.

While it is possible to have a page that is just pure html, this doesn't really utilize the power of AEM.

What is the user experience

For this, I am not thinking of just the end-user, which is an important decision, and will decide how you build the application, but also how the editorial user's experience is. Do your editors understand AEM? do they know all the quirks (and there are many) of the editorial process? Do you want to change how the standard process works, for instance, do you want a workflow for approval of changes to editorial pages or do you want anyone to be able to publish pages? Do you want to add extra buttons to the menu's that are specific to the application? You should always think about the administrative functions of the platform as well as the end-user.