Architecture Guide Jahia EE v6.1 - Jahia Academy

 
Documentation

                        Architecture Guide
                        Jahia EE v6.1

                        Jahia delivers the first Web Content Integration Software
                        by combining Enterprise Web Content Management with
                        Document and Portal Management features.

Jahia                   April 2010

9 route des Jeunes,
CH-1227 Les acacias
Geneva, Switzerland

www.jahia.com
The Company website

www.jahia.org
The Community website
Summary
1    Overview..........................................................................................................................................................3
    1.1    Introduction ...............................................................................................................................................3
    1.2    What’s in this documentation? ..................................................................................................................3
2    The big Picture ................................................................................................................................................4
3    UI Components................................................................................................................................................7
4    Authentication and Authorization.....................................................................................................................9
5    Templates......................................................................................................................................................11
6    Caches ..........................................................................................................................................................14
    6.1    CACHE TYPES.......................................................................................................................................15
    6.2    THE BROWSER CACHE LAYER...........................................................................................................16
    6.3    THE FRONT-END HTML CACHE LAYER .............................................................................................16
    6.4    OBJECT CACHES..................................................................................................................................17
    6.5    DATABASE CACHES.............................................................................................................................17
7    Content Objects.............................................................................................................................................18
8    Portal .............................................................................................................................................................20
9    Mashup Server ..............................................................................................................................................22
10    File Repository.............................................................................................................................................24
11    Engines........................................................................................................................................................26
12    Search and Indexing....................................................................................................................................28
13    Administration..............................................................................................................................................30
14    Spring Integration ........................................................................................................................................31
15    Event Listeners and rules ............................................................................................................................33
16    Jahia request flow........................................................................................................................................35
17    Pipelines ......................................................................................................................................................37
18    Import / Export .............................................................................................................................................39
    18.1     RELATION TO COPY & PASTE...........................................................................................................39
19    Clustering ....................................................................................................................................................40
    19.1     JAHIA “BROWSING” NODES...............................................................................................................41
    19.2     JAHIA “AUTHORING” NODES .............................................................................................................41
    19.3     PROCESSING NODES ........................................................................................................................41
    19.4     INDEXING SERVER.............................................................................................................................41

www.jahia.com > The Company website                                                                                                                      Page 2 of 42
www.jahia.org > The Community website
1 Overview
1.1 Introduction
Jahia delivers the first Web Content Integration software by combining Enterprise Web Content Management
with Document Management and Portal features.

By leveraging state of the art Open Source frameworks and libraries, Jahia offers a complete solution for
developing, integrating, delivering, and managing content across intranets, extranets, and internets with a
much lower total cost of ownership than proprietary systems.

1.2 What’s in this documentation?
This document provides a high-level view of Jahia’s architecture, and should help the reader understand the
various components of the software, and how they fit together. It may also serve as a basis to understand the
source code, as it is available for free.

We will present a lot of architectural diagrams in this document, and every attempt has been made to make
them both understandable and logical, but it is clear that it is possible to view the sub-systems in different
ways.

Should you have questions, please do not hesitate to contact us as mentioned on our website
(http://www.jahia.com) or Community website (http://www.jahia.org).

www.jahia.com > The Company website                                                                     Page 3 of 42
www.jahia.org > The Community website
2 The big Picture
Jahia has a lot of features, and the main idea is to integrate them in a way that makes sense for its users.

The following illustration gives a good idea of the categories of features that are included in Jahia:

We will now present all of them, starting from the top, going down:

   •    UIComponents: starting with Jahia EE v6.1, Jahia has moved to use the GWT (Google Web Toolkit)
        AJAX framework, which allows for strong reusability of user interface components. This allows both Jahia
        developers and integrators to build responsive UIs that work in all major browsers.

   •    Caching: in order to serve pages as fast as possible, Jahia includes multiple layers of caches, from the
        database level all the way up to the HTML level. Theses caches are cluster-compatible and allow for
        scalability and performance. Cache implementations are also pluggable.

www.jahia.com > The Company website                                                                      Page 4 of 42
www.jahia.org > The Community website
•    SSO: Jahia is compatible with all the major SSO implementations, including NTLM, CAS, JEE container-
        based authentication, etc. Again this implementation is pluggable through the pipeline mechanism, which
        we will describe later in this document.

   •    WCM: Jahia was born as a web content management system, and therefore this component is the most
        mature. Features such as direct in-the-page content editing; granular content objects which allow
        integration with portlets are features that have been part of the WCM since version 2.0.

   •    Portal: Jahia is not really a portal server is the strictest of senses, since it offers a lot more customizability
        that what is traditionally accepted in this field. The back-end supports the full support of the JSR-286
        standard, and therefore it is possible to integrate portlets on a page managed by Jahia just as easily as
        using a regular content object.

   •    File repository: Jahia also integrates a JCR (Java Content Repository)-based file repository, which
        allows users to both publish binary data on their website, as well as access the file repository through
        various user interfaces or standards (such as WebDAV or Windows Shared Folders).

   •    ACLs or Access Control Lists: Jahia features a very granular content management system, which is
        strongly tied to access control sub-systems. This means that users can finely control who can see what,
        and make sure that only authorized users have access to secured content. This sub-system is available
        throughout Jahia and also offers administrators the possibility to control permissions such as
        administration access, action limitations, etc.

   •    Clustering: Jahia allows for cluster deployment, and therefore allows for redundancy and load
        distribution. This document will look into the communication architecture required for clustering.

   •    Search & indexing: at the basis of most content management systems is strong support for searching &
        indexing. Jahia not only offers this throughout the content management system but also on its embedded
        file repository. Jahia also offer the possibility to search precisely within families of content objects, as well
        as offloading of indexing tasks to separate servers.

   •    Administration: Jahia features a separate user interface for both server and site administrators, which
        allows for a clean separation of administrative tasks. These interfaces allows users to control all of
        Jahia’s sub-systems including user and group administration, permissions, deployed templates and
        portlets, categories, etc… The lower layers are not systems included in Jahia but that are necessary or
        optional and provide the storage and retrieval of information that Jahia processes to work it’s magic.

www.jahia.com > The Company website                                                                          Page 5 of 42
www.jahia.org > The Community website
•    Database: Jahia supports all major database vendors, including the major open source ones such as
        MySQL and PostgreSQL. The code architecture is actually not tied to any database, as it uses the
        Hibernate ORM technology, and integrators or developers could add support for new databases simply
        by adding scripts for database creation.

   •    Filesystem: the file system is required for indexation storage, and optional BLOB and CLOB storage,
        should the administrator configure Jahia to store large content on the file system instead of the database.
        The filesystem must be distributed if the Jahia installation is going to be clustered, and it is the
        responsibility of the file system to properly handle distribution.

   •    LDAP: Jahia supports most LDAP servers right out of the box, including OpenLDAP and ActiveDirectory.
        It is most commonly used with SSO technologies to provide a seamless experience to end-users. For
        example using NTLM authentication and ActiveDirectory, a Jahia installation can then use the domain
        authentication that the Windows user enters when logging onto his machine.

www.jahia.com > The Company website                                                                        Page 6 of 42
www.jahia.org > The Community website
3 UI Components

The above illustration describes the various user interface components that are offered by Jahia, as well as the
frameworks they rely upon.

The basis for all UI components, starting with Jahia EE v6.1 is the Google Web Toolkit. This framework
provides all the modern requirements of AJAX-based user interface, as well as the possibility to build new
components rapidly and easily.

On top of it, Jahia uses the GXT library of GWT components, to avoid re-developing components such as
advanced tables, navigation trees, and so on.

The tri-panel component is a standard Jahia user interface built on top of the previous frameworks that allows
for display of tree-like panels, with children listing and info view.

The toolbar component is used for displaying tools on the page that the user can use to either launch other
components or trigger other navigation/edition modes. They are similar in behavior to standard desktop

www.jahia.com > The Company website                                                                 Page 7 of 42
www.jahia.org > The Community website
application toolbars, except that they are also integrated with the context, such as the user’s permissions and
the current browsing mode.

On top of all these frameworks is a full set of user interface components. They range from file management to
category management, including other browsing components such as breadcrumbs or bookmarks.

www.jahia.com > The Company website                                                                  Page 8 of 42
www.jahia.org > The Community website
4 Authentication and Authorization

www.jahia.com > The Company website     Page 9 of 42
www.jahia.org > The Community website
Jahia offers the following features in terms of authentication mechanisms:

   •    CAS SSO support

   •    NTLM support

   •    JEE container authentication support

   •    Pluggable authentication pipeline that can be easily implemented to add support for more SSO solutions

Once the user is properly identified, the authorization part of the framework is composed of:

   •    Access control lists on content objects

   •    Permissions on any user actions

   •    Pluggable user services

   •    Pluggable group services

   •    Compatibility with LDAP

   •    Default storage in database

The above illustration shows how the different layers interact, especially the pluggable interfaces. The routing
service implementation allows for simultaneous interfaces to both the database and LDAP repositories of
users, and more could be added by implementing the service provider interfaces.

www.jahia.com > The Company website                                                                  Page 10 of 42
www.jahia.org > The Community website
5 Templates

Jahia’s templating system is quite central to how information is displayed on a page.

Templates are regrouped into template sets, which are the basic deployment block. A site can select a
template set to use, and template sets may “inherit” from other sets, much in the same way JARs can contain
classes that may override other classes in separate JARs.

www.jahia.com > The Company website                                                              Page 11 of 42
www.jahia.org > The Community website
Template sets may contain:

   •    Content definition (CND) files

   •    JSP templates

   •    Themes and skins

   •    A template set deployment descriptor (mandatory)

   •    Resource bundles

   •    Java classes

Upon startup, Jahia will detect all the templates that have been deployed into its WEB-
INF/var/shared_templates directory and deploy them in the server. In development mode, any update to the
template descriptor file will trigger an undeployment/re-deployment of the template set and allow for a rapid
development experience for template developers and integrators.

As illustrated above, template sets have quite a lot of services available to them:

   •    Tag libraries: the aim of Jahia template development is to avoid scriptlets as much as possible, in order
        to ease maintenance and especially upgrade paths. So the Jahia taglibs are quite extensive, and interact
        well with the Java Standard Tag Library (JSTL). They provide all kinds of features such as content object
        querying; UI elements such as toolbars or inheritance-compatible include mechanisms (the Jahia Include
        tag). Please refer to the template developer guide for more details on these libraries.

   •    Inheritance mechanism: in order to avoid having to copy all the templates into a new set just to make a
        few changes, templates can benefit from an inheritance mechanism that is quite similar to the Java
        language inheritance. Only the templates that need customizing need to be overridden, all the others can
        be inherited as such. This is also possible for included files when using the Jahia Include tag, which
        allows a file inclusion mechanism that is capable of looking up the parent template tree for the file to
        include if it has not been overridden locally.

   •    Deployment: as mentioned previously, template sets can be deployed into a Jahia installation upon
        startup of the server. It is therefore quite easy to add new template sets when deploying a new
        installation of Jahia. Once deployed, template sets become available to site administrators that can either
        use separate template sets on their sites, or re-use a template set between multiple sets. This allows
        them to guarantee consistency over large number of sites, while still having the possibility to use a
        completely different set of templates for a specific site.

www.jahia.com > The Company website                                                                     Page 12 of 42
www.jahia.org > The Community website
•    Themes and skins: themes are used to give a different look to a template set. An example would be a
        template set that could have seasonal themes: a winter theme, a spring theme, etc. These themes can
        then be either enforced by an administrator or selected by the user. Skins offer the possibility to content
        authors to customize the look of content objects and therefore, while using the same content definition,
        offer a significantly different look when displaying objects of a same type.

   •    Content definitions: Jahia uses the standard JCR content definition format for content definitions, which
        have been augmented to allow more powerful typing on content. All the definitions benefit from the
        standard inheritance of definitions, but also allow for extensions such as internationalization, stronger
        typed content elements, and so on.

www.jahia.com > The Company website                                                                     Page 13 of 42
www.jahia.org > The Community website
6 Caches

Caches are essential to high performing web systems such as Jahia in order to be able to avoid recreating
dynamic content under large system loads. In the graph above, we can see the basic architecture of the cache
sub-system. All the different cache types are on the top layer, sitting on top of the cache service, which is the
provider for cache implementations. Below this service, various cache implementations may be plugged, and
some of these such as the “Reference Cache”implementation may depend on other Jahia services such as the
“Cluster service” that provides messaging throughout the Jahia cluster installation.

www.jahia.com > The Company website                                                                   Page 14 of 42
www.jahia.org > The Community website
6.1 CACHE TYPES

The cache types all use the same cache service that is responsible of providing cache implementations. In
Jahia 5, we have introduced in service pack 4 the possibility to provide different cache implementations for
different cache types, making the system extremely flexible in terms of configurations. For example it is
possible to use the EHCache implementation for the front-end HTML caches and use the ReferenceCache
implementation for the rest of Jahia’s caches. This is the default configuration for Jahia 5.0SP4 and Jahia EE
v6.1. It is also of course possible to integrate other cache implementations by plugging into the service provider
interface (SPI) that Jahia provides.

www.jahia.com > The Company website                                                                  Page 15 of 42
www.jahia.org > The Community website
Jahia uses multiple cache layers to optimize the performance of page delivery:

   •    the browser cache

   •    front-end HTML caches

   •    object caches

   •    database caches

Each of theses cache layers plays a different role in making sure values are only computed once.

6.2 THE BROWSER CACHE LAYER
While not integrated in Jahia but in the browser, the browser cache plays a critical role in guaranteeing good
performance for the end-user. For example, Jahia’s usage of the GWT framework makes it possible for AJAX
source code to be aggressively cached in the browser cache, therefore making sure we don’t reload script
code that hasn’t changed. Jahia also properly manages the browser cache to make sure it doesn’t cache page
content that has changed. It also controls expiration times for cached content, so that the browser doesn’t
request content that is rarely changed.

6.3 THE FRONT-END HTML CACHE LAYER
Historically, Jahia has had many front-end HTML cache layer implementation. The first was the full-page HTML
cache. While very efficient when a page was already available in the cache, it didn’t degrade very well for
pages that had a fragment of the HTML that changed from page to page, or from user to user (for example by
displaying the user name on the page).

In Jahia 5 we introduced the ESI cache server, which added the possibility to cache fragments of HTML. This
technology required a separate cache server that executed in a separate virtual machine to perform it’s magic.
While much better than the full-page cache for dynamic page rendering, the ESI caching system suffered from
problems with inter-server communication, which was very tricky to get to work efficiently. Also, integrating the
ESI cache required good knowledge of the fragment caching model when developing templates, which was an
additional burden on integrators.

www.jahia.com > The Company website                                                                  Page 16 of 42
www.jahia.org > The Community website
Jahia EE v6.1 takes the best of both worlds, by combining the sheer efficiency of the embedded full-page
cache with the fragment handling of the ESI cache server. This new cache implementation is called the «
Container Cache » and integrates fragment caching at a container level, making the interaction with templates
very natural. Template developers usually don’t have to add any markup in order to have their fragments
correctly cached. Even when they need to control the fragment generation, this is much easier to do than in
previous versions of Jahia. The “Skeleton Cache” is also an HTML front-end cache that basically caches
everything “around” the fragments, and by regrouping both cache sub-systems we obtain the equivalent in
terms of performance to the full-page HTML cache that existed in previous versions of Jahia while retaining the
flexibility of a fragment cache.

6.4 OBJECT CACHES
The next layer below the front-end HTML cache sub-systems are the object caches. This layer handles all Java
objects that represent content objects, users, groups, categories, content definitions, etc. It serves as a layer
on top of the database caches in order to avoid reconstructing objects for each model request. This is all
handled internally by Jahia and it is only important to interact with these caches if integrators are directly calling
Jahia’s API to perform object changes that don’t automatically update the caches.

6.5 DATABASE CACHES

The last layer of caches is the database cache layer that makes sure that only minimal interaction with the
database happens. This is important as, database communication requires object (de-) serialization and
network communication so the overhead of a database query can be quite substantial. This layer is, in Jahia,
completely handled by the Hibernate ORM layer.

www.jahia.com > The Company website                                                                     Page 17 of 42
www.jahia.org > The Community website
7 Content Objects

Jahia’s content objects are composed of the following objects:

   •    Pages (either content pages, internal links or external URLs)

   •    Container lists (lists of containers that all have the same structure)

   •    Containers (that contain fields of different types)

www.jahia.com > The Company website                                              Page 18 of 42
www.jahia.org > The Community website
•    Fields and metadata fields (that may be of different types such as SmallText, BigText, Integer, Date, File
        reference, etc…)

All these objects have in common the following:

   •    they may be part of categories

   •    they may have access control defined on them using Access Control Lists (ACLs)

   •    they are defined using content definitions files (*.cnd)

The content definition format is an extension of the Java Content Repository (JCR) standard definition (CND)
file format, that adds support for the following features:

   •    multi-language values

   •    more precise typing of property types

   •    resource bundle support for types

   •    choice lists

   •    and more…

All the content objects are loaded from the database and the various layers of caches that were previously
presented. They are then exposed to the template sub-system so that integrators may build the final rendering
using the Jahia tag libraries.

www.jahia.com > The Company website                                                                  Page 19 of 42
www.jahia.org > The Community website
8 Portal

Jahia includes an embedded portal server, which is based on the Apache Pluto reference implementation of
the JSR-286 Portlet API specification. The goal of this implementation is to offer support for integrators who
need to embed portlets on content pages. This means that any portlet API compliant application may be
integrated with Jahia in a few steps. In the above graph we have illustrated the different types of portlets that
may be deployed in a Jahia installation.

Jahia’s content object fields include an application field type that references a portlet, therefore allowing
integrators to define where an application may appear in the structured web content tree. Portlets may also be

www.jahia.com > The Company website                                                                     Page 20 of 42
www.jahia.org > The Community website
categorized and access to them may be controlled using access control lists. These services are built on top of
the Pluto back-end and are the same as the ones used on top of content objects.

Jahia EE v6.1 also uses portlets internally to perform some of it’s magic. These portlets may now include
content definitions and render content objects layouts. This makes for re-usable building blocks that may be
used to re-use functionality throughout a Jahia installation.

The same mechanism is used to built upon the portal server what is called the “mashup server”.

www.jahia.com > The Company website                                                                Page 21 of 42
www.jahia.org > The Community website
9 Mashup Server

Introduced in Jahia EE v6.1 is the new mashup server. Recognizing the raise in usage of Javascript
integration, Jahia now includes the possibility to define and re-use mashups inside of Jahia-powered websites.

The mashup server is built on top of the portal server, and therefore allows for easy deployment of new
mashup types, simply by deploying new portlets. In the above graph we have illustrated different mashup types
such as Google Gadgets, YouTube videos, HTML & Javascript fragments. These types are actually portlet
types that include a content definition that will automatically customize the user interface for mashup
configuration & rendering. Site administrators may then build mashup instances that they may categorize,

www.jahia.com > The Company website                                                                  Page 22 of 42
www.jahia.org > The Community website
control with ACLs, and offer to content authors to use on the section which they are creating. Developers can
either package mashups as portlets or simply re-use one of the existing portlets if they fit their needs (the
HTML mashup portlet is quite generic and may fit a lot of needs). Mashup instances may also be imported
using Jahia’s import/export feature.

As with any new technology, Jahia will constantly refine this user story to make it even more powerful.
Standards for mashups are still under definition at the time of this writing, and of course Jahia will strive to
integrate the new possibilities, provided of course they fit it well with our users.

www.jahia.com > The Company website                                                                     Page 23 of 42
www.jahia.org > The Community website
10 File Repository

 Jahia’s file repository was completely rewritten for Jahia EE v6.1. In Jahia 5, it was based on a strong
integration with the Apache Slide library, which was the de-facto open source standard file repository at the
time.

Since the rapid rise and strong quality of the Java Content Repository reference implementation (Apache
Jackrabbit), Jahia EE v6.1 has started including it as its standard file repository and build services on top of it.
Actually the integration architecture of Jackrabbit has no strong dependencies to it, but uses the standard JCR
API to offer access to multiple repositories. In Jahia EE v6.1 it is already possible to access CIFS/SMB file
repositories, and a few other implementations are available in the sandbox repositories that will mature as the
need arises (among these are FTP, Alfresco, Exo Platform, Nuxeo connectors).

In the above graph you might also notice that the Jahia Content listed available as a JCR provider. This is also
new to the Jahia EE v6.1. This is initial compatibility work and is not (yet) the most performance optimal content
interface in Jahia EE v6.1, but future versions of Jahia will constantly improve compatibility with the JCR APIs
as they evolve.

www.jahia.com > The Company website                                                                     Page 24 of 42
www.jahia.org > The Community website
On top of the file repository services, different interfaces expose content through various interfaces such as
WebDAV, browsing files in templates and Jahia’s AJAX UI. On the other side of the repository, integration with
a rules engine is used among other things for image thumbnail generation and metadata extraction. This rule
engine is also pluggable and can be extended by integrators to perform other specific logic upon repository
events.

www.jahia.com > The Company website                                                                  Page 25 of 42
www.jahia.org > The Community website
11 Engines

www.jahia.com > The Company website     Page 26 of 42
www.jahia.org > The Community website
Jahia’s engines may be compared to Struts actions. They are blocks of application logic that perform a specific
task. Jahia’s sub-engines are even smaller blocks, and are used to control interactions with small UI elements
such as field editing.

The most important engine is the “core” engine, which is the content page rendering engine, and is called
whenever Jahia is asked to display a content page. Other engines are self speaking such as the Login or
Logout engines, that simply handle authentication UI and processing.

Content editing engines also integrate with the validation framework that allows integrators to define input value
validation rules to limit user input.

Engines also integrate with Jahia’s AJAX UI, and the design goal is that over time all the UI logic will become
more and more re-usable, so that integrators may have access to large component libraries to build solutions
for customers. This work has already started in Jahia EE v6.1, which introduces re-usable GWT components
such as the category picker or the tri-panel file manager.

Sub-engines are used by Jahia to display container edition interfaces. As containers may contain any field
types, the container edition engine dispatches to the specific sub-engines for the corresponding field type
currently being edited. This allows the sub-engine to have control over the UI displayed to edit different types of
content. For example the file field that references a file will present a UI that allows a user to browse directories
and select a file, while the small text field will simply display a text input field.

Jahia resolves the engine to dispatch to by using the /engineName URL parameter. When no value is given,
Jahia defaults to the “core” engine. The string values that are used for engine names are actually declared by
the engines themselves. So in the JahiaEngine class, the getName() method will identify a key for the
/engineName URL resolution mechanism.

www.jahia.com > The Company website                                                                     Page 27 of 42
www.jahia.org > The Community website
12 Search and Indexing

Jahia’s search and indexing subsystem will be presented here only briefly, as it is quite a large sub-system in
itself. We have illustrated above the main building blocks of this system.

New to Jahia EE v6.1 is the integration of the OpenSearch standard. Jahia may act as both a consumer and a
producer of OpenSearch queries. This means that users may for example integrate their browser search box
with Jahia and directly input search queries from their browser toolbar. On the opposite side, Jahia can
consume multiple OpenSearch providers and present aggregated results for searches on Jahia, Google,
MSN,.. all on a single page view.

www.jahia.com > The Company website                                                                 Page 28 of 42
www.jahia.org > The Community website
On the more traditional web search solutions, Jahia offers tag libraries to search Jahia content either in very
basic full text search formats or using advanced search queries. The advanced queries integrate with Jahia’s
UI components to build powerful value selectors that guide the user when building advanced queries. These UI
components are built using Jahia’s AJAX framework and are the same ones used to input values in the
authoring user interface.

Another alternative for querying content objects is to directly build the queries at the template level, which
means that the users will simply be viewing the result of the prepared query. This is called “container queries”,
and may be used for example to retrieve all latest 5 content objects within the “news” content definition, which
will in effect present the latest news on the page.

Below these front-end technologies are the back-end systems that make all this possible. The Jahia search
engine offer the possibility to perform full-text or precise queries on both Jahia and file content, which the
container query sub-system is optimized to perform queries for content objects of similar types.

The underlying open source libraries that power the searching & indexing are the excellent Compass and
Apache Lucene frameworks. They store and retrieve their index information from an underlying file system, but
also have other options to store their data in databases or distributed file systems. The standard file system
implementation is currently the most production-ready and efficient one, so Jahia comes bundled with this
setup.

www.jahia.com > The Company website                                                                    Page 29 of 42
www.jahia.org > The Community website
13 Administration

Jahia’s administration user interface is a one-stop place to control all the various sub-systems targeted at either
site or server administrators. It allows administrators to perform all kinds of tasks such as :

   •    create, update, delete users, groups, virtual sites and categories

   •    setup global permissions

   •    setup categories and permissions on templates and portlets

   •    view internal cache status and flush them

   •    setup password policies

   •    define site languages

   •    setup remote publishing

   •    many other things… Please check the user’s guide for more information.

The administration UI is based on a servlet that acts as a central dispatch to a collection of application logic
classes that control the UI for the various settings of a Jahia server. It also integrates with the AJAX UI
components to offer a consistent experience to Jahia administrators.

www.jahia.com > The Company website                                                                    Page 30 of 42
www.jahia.org > The Community website
14 Spring Integration

Starting with version 5, the Spring framework has gradually been introduced into all parts of Jahia, and is a
very strong foundation for building a really solid, fast, flexible and portable server implementation.

This means that integrators have multiple options to integrate with Jahia’s sub-systems, as they can decide to
plug-in to many services simply by using the well-known dependency injection and configuration mechanisms
that the Spring framework is appreciated for.

The graph above details how the configuration is used to initialize all the various Jahia sub-systems using
Spring. As you can see even external libraries such Apache Pluto, Hibernate or Apache Lucene are integrated
with Spring, which makes for a powerful server architecture and lifecycle.

www.jahia.com > The Company website                                                                      Page 31 of 42
www.jahia.org > The Community website
Jahia’s experience with Spring has been an excellent one, and despite all the integration there is almost no
dependency to this framework that has been introduced, which gives the implementation the freedom to move
to the next great framework should the need arise.

www.jahia.com > The Company website                                                                Page 32 of 42
www.jahia.org > The Community website
15 Event Listeners and rules

www.jahia.com > The Company website     Page 33 of 42
www.jahia.org > The Community website
Actions performed by Jahia users trigger events that may be used to perform custom logic. Jahia allows
integrators to register event listeners to add the desired logic when an action is performed. The above graph
illustrates how events are propagated through the different sub-systems and how they may be used by
developers.

The birth of an event is a Jahia action, which could be directly resulting from a user command, a time-based
event or another background process. This action will call the event generator to create an event object. This
event object will then be passed to the listeners registry, which will in turn call all the registered event listener
classes to perform their specific logic. Some of the event listeners are simply proxies to other implementations
that may use different logic technologies. This is the case of the Groovy event listener that allows integrators to
use the Groovy language to implement event listeners, or the JSP event listeners that does the same for JSP
files.

Another particular listener is the JCR observation manager that actually bridges Jahia’s event mechanism with
the standard JCR observation technology. Below this, is the integration with the JBoss Rules observer, that
allows integrators to use rules to process events.

www.jahia.com > The Company website                                                                       Page 34 of 42
www.jahia.org > The Community website
16 Jahia request flow

www.jahia.com > The Company website     Page 35 of 42
www.jahia.org > The Community website
The above diagram is an overview of the way Jahia processes a browser request. This serves as a map to
orient integrators and developers towards the corresponding sub-systems they may be interested in.

The browser request may be directed either towards the Jahia servlet or the WebDAV servlet (in the case of
requesting a binary file). In the latter case, this request will then access Jahia’s file repository service to
validate access to the desired resource and then stream it back to the navigator.

In the other case, the Jahia servlet will then be called. Jahia will immediately create a context object called the
“ParamBean”. This object contains all the computed request information, including things such as the
requested content page, the current user, the current navigation language, and so on. Internally it uses a
pipeline mechanism to resolve the user, and this pipeline is customizable to integrate new user resolution
mechanisms. For more information, see the “Pipelines” section in this document.

Once the ParamBean object has been created, Jahia then hands over handling to the OperationManager
object, which also uses a pipeline to handle requests. The operation pipeline is also described in the
“Pipelines” section later in this document. The pipeline operations will interact with Jahia services to perform
the desired actions, and the result will depend on which engines have been called in the pipeline.

In the case of the “core” engine, the operation pipeline will have constructed all the necessary contextual
objects that will give the template developer the content he will layout in the JSP file. Therefore Jahia then
dispatches to the corresponding JSP template to perform the layout.

Finally the end result is sent back to the browser, and that’s it. Of course this is a very simplified example of a
request flow but should serve as a good starting point to understand request processing in Jahia. The
interaction with the caches has been omitted in order to simplify the explanation of the request processing, but
it is clear that integrators will have to take them into account when developing solutions.

www.jahia.com > The Company website                                                                       Page 36 of 42
www.jahia.org > The Community website
17 Pipelines

www.jahia.com > The Company website     Page 37 of 42
www.jahia.org > The Community website
As presented in the previous section “Jahia Request Flow”, Jahia uses pipelines to offer customizable chains of
processing logic. A pipeline is an ordered list of valves that are called in succession. What is specific to the
pipeline design pattern is that it is the responsibility of each valve to call the next one. Said another way, this
means that a valve can choose whether or not to pass on execution to the next. This is very useful when
resolving objects, where we want to continue on searching for an object until we have found it.

This is the concept for the authentication pipeline, which is called by the ParamBean object to resolve the user
based on the current context. Users may be found using all kinds of criteria such as looking them up in the
session if they were previously resolved, through integration with a single-sign on system such as CAS, or
using JEE container-based authentication. On the above graph, the lower pipeline is the authentication pipeline
and shows the various valves used to resolve users. We won’t go here into the details of each valve, but it is
interesting to note that this resolution mechanism is customizable through Spring XML files, making it easy for
integrators to integrate their own custom valves.

The operation pipeline (top part in the above graph) is used by Jahia to offer a pluggable request processing
chain. Again the valves may decide to stop processing at any point, which is especially interesting for the front-
end HTML cache valves. If the content may be read in the cache, processing may stop at that point and this
avoids executing unnecessary operations, making the whole process very efficient. The valve responsible for
cache reads in the above graph is called the “Skeleton aggregator”. Other valves such as the URL history
valves are simply used to trace all the URLs requested by a user in order to build up the data for the
breadcrumbs view.

Integrators might also find it interesting to customize the operations pipeline to extend Jahia’s request
processing flow. It should be noted that the ordering and placement of valves is very important, and that it is
not recommend to change it without a good knowledge of how Jahia works.

www.jahia.com > The Company website                                                                     Page 38 of 42
www.jahia.org > The Community website
18 Import / Export

Jahia’s import/export feature is an extremely powerful mechanism for migrating content in very different ways
between Jahia sites, or even between Jahia installations.

It uses the JSR-170 (or JCR) XML format as a basis for content export, along with other specific files such as
file hierarchies for binary data export. All these different files are compressed in a ZIP file that may be used by
the import sub-system.

This makes it possible to export a complete Jahia installation, a set of sites, a single site or even a sub-section
of a site using the same import/export technology. Using these users can migrate content between sites, or
even between sections of sites, or also use it to export content to non-Jahia systems or import from non-Jahia
systems.

Jahia also uses the import/export technology for its “remote site publishing” feature. This is basically an export /
import triggered by a scheduler. The import/export technology is capable of detecting modified content and will
simply update a content object instead of creating a new instance.

18.1 RELATION TO COPY & PASTE

While not obvious, the copy & paste feature also uses the import/export technology behind the scenes. This
also explains why content may only be copy and pasted between compatible content definitions, as Jahia must
know how to map content types between the source and the destination.

Linked copies also use the import/export technology when content is pushed to the destination.

www.jahia.com > The Company website                                                                    Page 39 of 42
www.jahia.org > The Community website
19 Clustering

 Deploying Jahia in a cluster is a very powerful way of distributing CPU and memory load to handle larger traffic
sites.

A typical Jahia cluster installation is illustrated in the above graph. Jahia nodes communicate directly with each
other through direct messaging, but also access shared resources: a shared filesystem and the database. The
filesystem is used for the content indexes, as well as binary content if the server is configured to store it on the
filesystem, or in the database if the default configuration is used. The database stores everything else. It is
therefore very important to have a high-performance database installation, as Jahia will depend on it to scale
well.

Jahia can also differentiate nodes in a cluster setup in order to offer more specialized processing. We will
review here quickly the different node types.

www.jahia.com > The Company website                                                                    Page 40 of 42
www.jahia.org > The Community website
19.1 JAHIA “BROWSING” NODES

Jahia “browsing” nodes are specialized Jahia nodes that only serve as content publishing nodes. They also
interact with portlets to render pages. Using this node specialization allows to separate the browsing load from
authoring and background processing loads.

19.2 JAHIA “AUTHORING” NODES

Jahia “authoring” nodes are cluster nodes that can be used to either browse or edit Jahia content. This is the
most common usage of Jahia nodes, and therefore it is interesting to have multiple instances of these nodes in
order to distribute the load.

19.3 PROCESSING NODES

In Jahia, long-running tasks such as workflow validation operations copy & pasting, content import and
indexing are executed as background tasks. This way while these long operations are executed, other nodes
are still able to process content browsing and editing requests.

19.4 INDEXING SERVER

File and content indexation can be a very expensive operation both in terms of CPU usage and memory load.
For example, in order to index PDF files, the server must actually execute the script instructions that are
contained within the file in order to extract the text content. This requires the execution of a full Postscript-like
language, including its memory management and instruction processing, just to extract text content. Indexing
large files also requires memory that cannot be freed until the actual extraction has been completed.

Indexation is usually considered to be an operation that is not needed in real-time, and therefore can run as a
background task. In order to reduce the load on the Jahia servers doing the actual content editing or
processing, it is strongly recommended to install a separate content indexing server, especially if the content
will contain a lot of typical office files.

It is also possible to install multiple indexing nodes, so that there is no single point of failure for this type of
operation.

www.jahia.com > The Company website                                                                         Page 41 of 42
www.jahia.org > The Community website
9 route des Jeunes,
 CH-1227 Les acacias
 Geneva, Switzerland

   www.jahia.com
The Company website

    www.jahia.org
The Community website
You can also read
Next slide ... Cancel