Adobe Experience Manager (AEM) vs BloomReach
We compare the architectures of two Java-based CMS platforms: Adobe Experience Manager (AEM) and BloomReach.
We compare two Java-based CMS platforms: Adobe Experience Manager (AEM) and BloomReach. By definition, Java-based platforms are much more “heavy-duty” than their PHP counterparts WordPress and Drupal. They power < 1% of global sites but have a much larger representation in the Fortune 1000 companies. Because they run on Java — a much more robust programming language than PHP — they are able to deliver more sophisticated functionality.
We do a deep dive to compare the technical architectures of AEM and BloomReach.
Overview
Architecture ComponentAEMBloomreachWeb Application Server
- Standalone Jetty web server
- WebLogic
- Websphere
- Tomcat
TomcatContent Repository
- Adobe CRX
- Apache Jackrabbit
- MongoDB
- Apache Jackrabbit
- MySQL
- PostgreSQL
- Oracle Database
- Microsoft SQL Server
- H2 database
Web Service Sling API
- REST Api
- JAX-RS Service
Service Container OSGI Container
- Cargo Container
- Docker
Request Processing Apache Sling Request Processing HST Request HandlingUI Architecture
- Classic UI (EXTJS Framework)
- Touch UI (Coral UI + Granite UI)
Apache Wicket Templating Language
- Sightly
- JSP
- JSTL
- Freemaker
- JSP
Web Application Server
AEM has its own integrated application server. So you can install it as a standalone server. The AEM stack also permits the usage of different web servers such as enterprise-grade Oracle WebLogic, IBM Websphere or more simpler options such as Tomcat and an Integrated Jetty server.
BloomReach recommends and supports Tomcat 9 as its application server.
Content Repository
Being Java based, both products use the core Java Content Repository (JCR) for their content storage and retrieval. Adobe uses its own implementation of JCR called CRX and also supports Apache Jackrabbit which is an open-source implementation of the JCR specification.
You can integrate AEM with databases like MongoDB to handle complex use cases such as extremely high concurrent users or high volumes of page edits.
The default BloomReach approach is to use an embedded H2database for storage. For more complex use cases, you can configure it to work with relational databases such as Oracle, mySQL and others.
Web Services
Bloomreach supports many more web services protocols than AEM in general. There is a generic REST API that automatically exposes all published content.
Should the generic REST API not meet your requirements, you can create your own custom services using the platform’s support for JAX-RS. These services come in two flavors. First is the Context-aware JAX-RS services that are used to dynamically expose site content mapped to a content type. Second is the more Plain JAX-RS services that expose preconfigured functionality which is not directly mapped to content but can make use of it.
Other methods include Repository JAX-RS services that are used to expose REST APIs which interact with internal components such as repository-managed daemon modules. Finally, SPA++ exposes channel manager functionality and the HST page model through JSON REST APIs, enabling seamless integration with Single Page Application (SPA) frameworks..
In contrast, the primary method to implement Web Services in AEM is to use Apache Sling. Sling is a Web application framework based on REST principles that provides easy development of content-oriented applications. It uses a JCR repository, such as Apache Jackrabbit, or in the case of AEM, the CRX Content Repository, as its data store.
Service Container
OSGi is an industry specification to build modular and extensible applications. The OSGi module system allows building applications as a set of reloadable and strongly encapsulated services. OSGi “bundles” run inside an OSGi “container” which manages relations among them. AEM uses Apache Felix as its OSGI container.
You can deploy BloomReach within a Cargo container. Cargo is a thin wrapper that allows you to control Java EE containers in a standard way. It provides APIs and tools to start/stop containers, deploy containers to a server farm, merge J2EE modules, perform ANT tasks etc.
UI Architecture
BloomReach Experience Manager provides a plugin architecture to facilitate a customizable UI. The visual rendering is based on Apache Wicket. You can write all standard UI components as plugins. The application offers a default configuration for these plugins and customizing it comes down to editing this configuration, extending it with extra plugins or writing your own.
AEM offers two options for authoring: Classic UI and Touch UI. The Classic UI is a desktop-oriented user interface built on the Extjs framework. Adobe designed the latest touch-enabled UI to provide UX consistency across multiple products. It is based on Coral UI (CUI) which is an implementation of Adobe’s visual style for the touch-enabled UI. Furthermore you can build Granite UI components with Coral UI.
Templating Language
BloomReach uses standardized templating technologies: Freemaker and JSP. These allow you to build custom components freely using Java or scripting technologies. Their Site Toolkit supports Freemaker templates as the default templating engine.
AEM has traditionally leveraged JSP for component development. The latest technology however, is Sightly and it is recommended that all new AEM projects use the HTML Template Language (HTL) on which it is based. AEM 6.0 introduced the HTML Template Language (HTL) and it takes the place of JSP (JavaServer Pages) as the preferred and recommended server-side template system for HTML.
Request Processing
AEM leverages Apache Sling for request processing. It is a framework for RESTful web-applications based on an extensible content tree. In a nutshell, Sling maps HTTP request URLs to content resources based on the request’s path, extension and selectors. Using convention over configuration, requests are processed by scripts and servlets, dynamically selected based on the current resource. This fosters meaningful URLs and resource driven request processing, while the modular nature of Sling allows for specialized server instances that include only what is needed.
BloomReach leverages HST container for request processing. The HST Container is largely driven by a request/response processing data flow, much like the servlet or HTTP request/response paradigm. Requests are made by client agents such as web browsers and the HST Container processes the request on the thread provided by the application server. Request processing is achieved in a workflow like pipeline, where valves are plugged into the request pipeline.
To check out some of our Adobe Experience Manager work, you can hop over here.
