Technical overview of DX

  Written by The Jahia Team
   Estimated reading time:

This section presents a global overview of the elements of a Digital Experience Manager system.

What is Digital Experience Manager?

Digital Experience Manager can be many things to many people. Most projects will use it as a Web Content Management (WCM) solution, or whatever the moniker is at the time of reading, while others will use it as a portal server, a web integration platform, or even a full-fledged content integration solution.

What Digital Experience Manager really is, is software listening to HTTP requests with the ability to produce responses using HTML, any markup or even binary data that users might need. In its core, it uses a content repository to store and retrieve content, as well as multiple ways of deploying custom logic to operate on the content or to interface with third party systems. That's the million-mile view of Digital Experience Manager, and should give you a good idea of the flexibility of the system.

The closer view

If the previous description of Digital Experience Manager was a bit too abstract, the following description should be more helpful. Digital Experience Manager is basically composed of the following layers:

  • A servlet container (Apache Tomcat, Oracle WebLogic, IBM WebSphere or others)
  • A set of filters and servlets that form the "outer layer" of Digital Experience Manager
  • A set of Spring beans that make up the main architecture of Digital Experience Manager
  • A set of modules that extend the basic functionality
  • A JCR implementation for storage of content (Apache Jackrabbit 2.x)
  • A portal container (Apache Pluto 2.x)
  • A scheduler (Quartz)
  • A workflow engine (jBPM)
  • A rules engine (Drools)

Of course, this is a much-simplified view of the elements that Digital Experience Manager is made of, but it should help identify the type of technologies involved.

Technical requirements

Digital Experience Manager has the following minimum requirements:

  • Oracle JDK 8 or OpenJDK 8
  • A servlet API 3.0 / JSP 2.1 container
  • 4GB RAM
  • Windows, Linux (RedHat, Ubuntu), Mac OS X operating systems

Recommended requirements:

  • Apache Tomcat 8.0.x
  • 8GB RAM
  • Ubuntu or RedHat Linux 64-bit kernel

"Everything is content"

Another way of presenting Digital Experience Manager is what we call the "everything is content" concept. Since the very beginning, Digital Experience Manager has been aggregating all kinds of content on pages, including dynamic content such as portlets. Digital Experience Manager has always been able to mix applications and content on the same web pages. Digital Experience Manager takes this notion even further by easily allow the building of "content-based applications", also known as "composite applications" that make it easy to build powerful applications that share a content store as a back-end.

In other words, working with Digital Experience Manager means manipulating content and defining views as well as rules to be executed when an event is triggered on the content (manually or programmatically). Any content element stored in the repository (texts, images, PDF documents, portlets, OpenSocial or Google gadgets) is considered content and therefore shares:

  • Common properties (name, UUID, metadata, etc.)
  • Common services (editing UI, permissions, versions, etc.)
  • Common rendering and handling systems

Content is stored in a hierarchical structure (using Java Content Repository aka JCR standard), but as you will see it is possible to query or operate on it in other ways.

Developer and integrator customization

End users may see Digital Experience Manager as a product, but for developers and integrators it is before all a powerful integration platform that may be configured and extended to fit a wide variety of needs.

Here is a sample of the different type of customization tasks:

  • Integration and personalization
    • Of templates
    • Of default Digital Experience Manager modules and components
  • Development
    • New modules usable in pages
    • New logic parts (rules, filters, actions, classes)
    • New functionalities that add features to Digital Experience Manager
  • Configuration
    • Of workflows
    • Of roles and permissions
    • Of the user interface

Integrated technologies

Digital Experience Manager integrates a lot of different technologies and frameworks, and this section will give you an overview of what's included and how it is used.

  • Digital Experience Manager stores all of its data in a Java Content Repository (JCR) (Apache Jackrabbit 2.x):
    • Two workspaces are used in the JCR, one for the staging content (called "default") and one for the live content (called "live")
    • JCR content is stored in an SQL database (MySQL, PostgreSQL, Oracle, MSSQL, and more). Node data is stored in serialized form for performance reasons
  • Digital Experience Manager integrates the following services and frameworks (most important ones)
    • Apache Lucene as the indexing/search engine
    • Apache Solr for advanced search features (only some classes)
    • Apache Camel as an enterprise integration engine
    • Spring Framework as the dependency injection and bean configuration technology (as well as much more)
    • Google Web Toolkit with Sencha GXT extensions for the UI in Edit mode, Contribute mode, User dashboard and Studio mode
    • JQuery and extensions for the contribute and live modes
    • JBoss Drools as a rule engine
    • JBoss BPM as a workflow engine
    • OSGi
    • Karaf and Felix
    • Spring MVC for building complex interactions and form processing
  • Digital Experience Manager is extended by frameworks included in modules like
    • XWiki as the wiki engine
    • Apache Shindig (OpenSocial implementation)
    • LDAP connectors
    • Search Engine Optimization (SEO)
    • Tags and tag clouds

Architecture overview

As you can see, the top layers are basic rendering and communication layers, while the underlying services are more modular. The boxes with blue outlines covered what is offered in the core services, either as core modules or framework, while the blue-filled boxes represent additional modules that may provide custom content definitions as well as custom logic or much more (rules, Spring descriptors, etc…)

Digital Experience Manager introduced modules to the architecture. Prior to this version, extensions to Digital Experience Manager would be integrated through Spring beans being deployed, but no specific packaging was possible. Since Digital Experience Manager 70 modules must be packaged as OSGi jar bundles that can then be deployed to extend or complement platform scope of functionalities. A lot of functionalities available by default in Digital Experience Manager are in fact built and deployed using modules, including, for example, the contribute mode or template sets.


Modules are a very important part of Digital Experience Manager, and may be thought of as Digital Experience Manager's plug-in infrastructure. Basically, they are composed of directory and files that are packaged as an OSGi bundle JAR file and then copied into Digital Experience Manager's digital-factory-data/modules directory for deployment. Upon detection of the new file, Digital Experience Manager will start the module and make it available to the whole system. Modules may range from very simple ones, such as only defining new views for existing content types, to very complex implementation of new communication layers such as a REST API, or implementing back-end LDAP user and group providers.

Template sets (see the Studio section below) are also packaged as modules, which make them easy to deploy and update.

Advantages of modules include:

  • Re-usability: as they are autonomous, it is easy to move them from development to staging or to production environments. It is also easy to re-use them across projects or share them with others. Also, as it is possible to inherit from existing modules, it makes it nice and easy to extend a default module.
  • Maintenance: as they are autonomous blocks, they can focus on a specific use case (like in the case of a forum module), which makes maintenance and evolution easy.
  • Reliability: if a module fails, only that part of the system will be unavailable, the rest of the platform will continue to serve requests.
  • Separation of concern: as the modules may be integrated at a later time, this makes it easier to split work among members of a team.
  • Hot-deployment: as modules are basically OSGi bundles, it is possible to hot deploy them or even remove them without shutting down the whole system, even if they include Java code or even workflow definitions
  • Isolation: with the introduction of OSGi as a module framework in Digital Experience Manager 7, modules are now executed each in their own class loader which makes it possible for them to embed their own dependencies, even if they differ in version from the ones used by Digital Experience Manager or another module.

A developer will therefore mostly work on modules, either creating new ones or extending the out-of-the-box ones. He may also share his work (or re-use others' contributions) on Digital Experience Manager's App Store (, therefore making the module available at large, gathering feedback and maybe even community contributions.

A module may contain: 

  • Content definitions
  • View scripts (JSP, JSR-286 compatible languages such as Velocity or Freemarker, or even PHP*)
  • Static resources (text file, images, CSS files, JavaScript files)
  • Resource bundles or other property files
  • Java classes or JAR libraries
  • Filters
  • Permission and role definitions
  • Rules
  • jBPM workflow definitions
  • Tag libraries
  • Spring Framework configuration files
  • Content import files (in XML format)
None of these files are required and you may create an empty module, although it won't be very useful.

* Through the integration of Caucho's Quercus PHP engine, which may require a commercial license depending on deployment needs. The Jahia-Quercus module is provided in the context of a community effort and is not supported by JSG.

Digital Experience Manager actors

In this section, we will present the different types of actors that may interact with a Digital Experience Manager system, and how they relate to different activities.

Developers, integrators and webmasters will mostly interact with the studio as well as modules to create templates, modules so that the other users may use a system that has been customized to their needs. In this role, this will enable them to "lock" the look and feel of the web site, as well as the content definitions, rules or any other custom logic needed. Webmasters and/or editors will then use the output of the previous work to populate the site with content, using the edit mode and/or the contribute mode. The Edit Mode is a very powerful content editing interface, mostly targeted at advanced users, while the Contribute Mode is an easy-to-use content editing interface aimed at basic content editors. It should also be noted that integrators are free to customize the Contribute Mode to their requirements, to tailor the experience for the editors. Once the editors are happy with the content, they may use the workflow to publish the modifications to the live workspace (or if they are not directly allowed to do so, they may start the review process), at which point it will be available to site visitors. Site visitors may then browse the site, and if allowed, also input user-generated content in modules such as the forum, wiki or other components deployed in the site.