Technical overview of DX

  Written by The Jahia Team
   Estimated reading time:

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

What is Digital Experience Manager (DX)?

Digital Experience Manager (DX) is many things to many people. Most projects will use it as a Web Content Management ( WCM ) solution, while others will use it as a portal server, web integration platform, or even a full-fledged content integration solution.

Digital Experience Manager listens to HTTP requests and produces responses using HTML, any markup, or even binary data for users. DX uses a content repository to store and retrieve content, and deploys custom logic to operate on the content or 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 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)

This is a simplified view of the elements that make Digital Experience Manager but should help to 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
  • 4 GB RAM
  • Windows, Linux (RedHat, Ubuntu), Mac OS X operating systems

Recommended requirements:

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

Everything is content

Since the very beginning, Digital Experience Manager has aggregated all kinds of content on pages, including dynamic content such as portlets. DX has always been able to mix applications and content on the same web pages. DX allows you to build 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.

When you work with Digital Experience Manager, you manipulate content, define views, and create rules that execute when events trigger on the content (manually or programmatically). Any content element stored in the repository (text, images, PDF documents, portlets, OpenSocial or Google gadgets) is considered content and shares common:

  • properties (for example, name, UUID, and metadata)
  • services (for example, editing UI, permissions, and versions)
  • rendering and handling systems

Content is stored in a hierarchical structure using a Java Content Repository (JCR) standard, but as you will see you can 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 a powerful integration platform that they configure and extend to fit a wide variety of needs. Here is a sample of different types of customization tasks.

Integration and personalization of:

  • templates
  • default DX modules and components

Development of new:

  • modules usable in pages
  • logic parts (rules, filters, actions, and classes)
  • functionality that adds features to DX

Configuration of:

  • workflows
  • roles and permissions
  • the user interface

Integrated technologies

Digital Experience Manager integrates many different technologies and frameworks. This section gives you an overview of what's included and how it is used.

DX 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:

  • Apache Lucene as the indexing and 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
  • TWO REST API

Digital Experience Manager is extended by frameworks included in modules such as:

  • XWiki as the Wiki engine
  • Apache Shindig (OpenSocial implementation)
  • LDAP connectors
  • Search Engine Optimization (SEO)
  • Tags and tag clouds

Architecture overview

In the diagram below, the top layers are basic rendering and communication layers, while the underlying services are more modular. The boxes with blue outlines show what is offered in the core services, either as core modules or framework. The solid blue boxes represent additional modules that may provide custom content definitions, custom logic, or much more, for example, rules and Spring descriptors.

Digital Experience Manager 7.0 introduced modules to the architecture. Prior to this version, extensions to Digital Experience Manager were integrated through Spring beans that were deployed, but no specific packaging was possible. Since DX 7.0, modules are packaged as OSGi JAR bundles that are deployed to extend or complement platform scope of functionality. Much of the functionality available by default in DX is built and deployed using modules, for example, Contribute mode or template sets.

Modules

Modules are an important part of DX and can be considered DX's plug-in infrastructure. Modules are composed of directories and files that are packaged as an OSGi bundle JAR file and then copied into DX's digital-factory-data or modules directory for deployment. When DX detects a new file, DX starts the module and makes it available to the whole system. Modules range from very simple, that only define new views for existing content types, to very complex implementations of new communication layers such as a REST API, or that implement back-end LDAP user and group providers.

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

Advantages of modules include:

  • Reusability
    Because modules are autonomous, it is easy to move them from development to staging or production environments. You can also reuse them across projects or share them with others. Modules can also inherit from other modules, making it easy to extend a default module.
  • Maintenance
    Because modules are autonomous, they can focus on specific use cases, as with a forum module, which makes maintenance and evolution easy.
  • Reliability
    If a module fails, only that part of the system is unavailable and the rest of the platform continues to serve requests.
  • Separation of concern
    As modules may be integrated at any time, it is easier to split work among team members.
  • Hot deployment
    As modules are OSGi bundles, you can hot deploy them or even remove them without shutting down the whole system, even if they include Java code or workflow definitions.
  • Isolation
    With the introduction of OSGi as a module framework in DX 7.0, modules are executed in their own class loaders. This makes it possible for modules to embed their own dependencies, even if they differ in version from the ones used by DX or another module.

Developers work mostly on modules, either creating new ones or extending out-of-the-box modules. Developers can also share their work (or reuse contributions from others) on Digital Experience Manager's App Store (http://www.jahia.com/store) to make modules available at large, get feedback and potentially 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)

* 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.

Note: None of these files are required and you may create an empty module, although it won't be very useful.

Digital Experience Manager actors

This section presents the different types of actors that interact with a Digital Experience Manager system and describes how they relate to different activities.

Developers, integrators and webmasters create templates and modules in Studio to build a system that is customized for the needs of users. They style the look and feel of the website, and create content definitions, rules and custom logic.

Webmasters and editors then populate the site with content in Edit or Contribute mode in DX. Edit mode is a content editing interface targeted at advanced users. Contribute mode is an easy-to-use content editing interface aimed at basic content editors. Note that integrators are free to customize the Contribute mode to their requirements or to improve the experience for editors. Once editors are happy with their content, they use a workflow to publish changes to the live workspace (or if not permitted, they start a review process) and make it available to site visitors.

Site visitors then browse the site, and if allowed, also input user-generated content in modules such as the forum, wiki or other components deployed on the site.