Jahia Enterprise Portal - Architecture Overview (Part 1)
The article presents a high-level overview of the enterprise portal architecture Jahia .
Jahia is one of the few open source systems that integrates the Java EE portal and management.
content in one product. CMS is a complete solution, representing an alternative to portals.
from large companies.
The review is intended to help the reader understand the various components of the system and the links between them.
This review can also serve as a basis for understanding the source code of a system that is
freely available.
')
The article is large, therefore, divided into two parts. It is also available in pdf-format .
Your comments, comments and corrections are welcome.
I would be glad if my translation would be useful.
Part 1:
Part 2:
Jahia has in its composition a rich arsenal of various functions and subsystems. main idea
Portal operation is to integrate them efficiently so that it is convenient for users.
The figure below shows the main subsystems of the portal:
Briefly consider them from top to bottom:
Subsequent low-level subsystems are not part of the portal, but their use provides
storing and accessing information that Jahia processes.
This figure shows the various components of the user interface that
provides jahia.
Starting with Jahia 6.0, the basis for all components is the Google Web Toolkit . Using
GWT, developers can quickly write and debug AJAX user interface components. AT
Jahia uses the GXT component library with pre-built components to work with
tables, trees and other standard interface elements.
The tri-panel component is a standard Jahia user interface component,
displaying a panel of hierarchical links with a list of descendants and an information window.
The toolbar component is used for quick access to tools
switch navigation modes / edit content. The toolbar is similar to the ones that
used in standard desktop applications, except that the tools on it are displayed
depending on the context (viewing and editing rights for the current user, current user
view mode).
On top of these components, Jahia has a complete set of custom elements.
interface: from file management components to category management, including components
browsing and navigating breadcrumbs and bookmarks .
Jahia allows you to use the following authentication mechanisms:
After the user is identified once, the system continues.
delineation of rights. The composition of the system of delineation of rights:
The figure above shows how the various levels of the subsystem (including plug-in interfaces)
interact with each other. Routing service allows using unified access interfaces.
to DB and LDAP-storage of user base. By implementing the service provider interfaces you can
add additional services.
The system of Jahia templates depends on how the information will be displayed on the page. Templates
registrations are grouped into a set . The set of templates is subsequently uploaded to the server. External
the type of site will depend on which template set you choose. One set can expand
another, "inheriting" it.
The composition of the set of templates:
When Jahia starts, it will determine all the templates available in the system (the WEB folder
INF / var / shared_templates ) and deploy them to the server. In development mode
Any changes to the deployment descriptor will cause the template set to reload, thereby
allowing instantly see changes in the design on the server.
As was shown above in the figure, you can apply
many different technologies:
For high-performance web systems like Jahia, caching is necessary for
avoid re-generation of dynamic content under high loads . On the picture
The caching subsystem architecture is shown.
All high-level caches are based on the cache service (cache service) , representing
cache implementation Below this service, various cache implementations can be used, some of them
may depend on other Jahia services. For example, the reference cache (Reference Cache) depends on
cluster services (Cluster service) , which allows to exchange messages in a cluster Jahia.
All types of high-level caches use the same caching service that represents
cache implementation Starting with Jahia 5.0SP4, the system has the opportunity to apply various
cache implementations for different types of cache, making the system flexible for configuration. For example,
you can use EHCache to cache custom html pages and use
ReferenceCache for other types of caches. This is the default configuration for Jahia.
5.0SP4 and Jahia 6.0. Naturally, it is also possible to integrate other cache implementations with
using the service provider interface (SPI) , which
provides jahia.
To optimize web page delivery performance, Jahia uses several cache levels:
Each of these levels solves its problem, pursuing a single goal: so that the values are calculated
only once.
Despite the fact that this cache is not part of the Jahia portal, but is part of the browser,
it is he who plays a critical role in ensuring good system performance for
end user. For example, the use of the GWT framework in Jahia has allowed
cache the AJAX code in the browser cache, thereby freeing the portal from having to overload
scripts that have not changed. Jahia works correctly with the cache of those pages that have been changed.
and controls the lifetime of the page cache, so as not to update without need rarely changing
content.
Historically, Jahia has many implementations for the html page cache. First
The implementation was a full-page html cache (full-page HTML cache) . This cache is very
effective for simple pages if they are already in the cache; and it is not very suitable for pages with
different fragments (for example, displaying user information on the page).
In Jahia 5, we introduced the ESI cache server (ESI cache server) , which added the ability to
cache fragments of html pages. To effectively use this technology requires
a separate cache server that will run on a separate virtual machine. Being over
efficient technology for generating dynamic pages compared to full page cache,
The ESI system suffers from problems with server-to-server communications that are very cunningly needed.
configure for normal operation. Also, the use of the ESI cache requires good integrators
knowledge of the fragmentary caching model (fragment caching model) , which is not always
like.
Jahia 6 took the best from both approaches, combining the efficiency of the embedded full-page
cache with fragment cache support from ESI cache server. This cache implementation was named
“Container Cache” , it applies level-level fragment caching
container, making interaction with templates very simple. Template developers will not have to
add special markup to configure the correct fragmentary caching. Even
there will be a need to manage the generation of fragments, it will be much easier to do this
than in previous versions of Jahia.
Skeleton Cache - another html page cache implementation that caches everything
the rest (except fragments) content. By grouping two caching subsystem data by
performance, you can get the equivalent of a full-page html-cache, but with the ability to
cache fragments.
The object cache lies below the html page cache subsystem. This cache level serves all Java
System entities : content objects, user objects, groups, categories, descriptions
content, etc. An object cache exists above the database cache to avoid reconstructing
objects with each request to the model. The level is transparent to developers,
it is only necessary to interact with it through the Jahia API if changes to objects are not
entail automatic cache refresh.
The last level of the cache is the database level, which minimizes queries to the database .
He is very important. When working with a database, objects are serialized / deserialized,
load network and system resources so that the overhead of queries to the database can be
very significant. This cache level is fully implemented by means of the Hibernate ORM .
List of content objects in Jahia:
All these objects have common features:
The description file format conforms to the Java Content Repository (JCR) standard for CND files with
adding the following features:
Content objects are loaded from a database and various cache levels. They are then transmitted to
a template subsystem in which integrators can finally render a page using
Jahia tag libraries .
Jahia includes a portal server based on Apache Pluto - a reference implementation.
Java portlet specifications (JSR-286 Portlet API). The purpose of Apache Pluto is
enabling integrators to use portlets on pages . Any portlet,
following standards, can be easily embedded in the Jahia portal. The figure above shows
various types of portlets that can be used in Jahia.
One of the fields of the content object is the application field , which refers to
portlet This field allows integrators to define a place in a structured web tree.
content where the application may appear. Portlets can also be categorized and
access to them can be controlled using access control lists.
Jahia 6 also uses portlets internally. Internal portlets can include descriptions
content, they are used to generate different layers of content objects. Layers in
The portal is used as functional blocks for building web pages. They can
reused on different pages.
This mechanism is called Mashap - the concept of building web applications by
combining the functionality of various software interfaces and data sources. For
building blocks in the portal server Jahia uses a mashap server (Mashup Server) .
In the latest versions of Jahia, Javascript has been used more frequently in the system, so to
to identify and reuse mashup on Jahia websites in the portal have included a new
mashap server.
Mashup server is built on the portal server, it makes it easy to connect new ones
data sources (mashup types) , simply uploading new portlets to the system. The picture above
we showed various data sources - mashups: Google Gadgets, YouTube videos, html snippets and
Javascript. These sources are actually portlet types that include descriptions.
content.
According to the description of the content, the user interface will automatically configure and draw
mashup Site administrators will be able to build mashaps, break them into categories,
restrict access using access control lists and allow content authors to use
them in their sections and in the measures of their competence in the system. Developers can group mashups
into packages (like ordinary Java portlets) or simply reuse existing ones
portlets, if they meet the needs (for example, the html-mashap is quite common and can be suitable for
many cases). Mashups can also be imported into the system using import / export functions.
Jahia
To improve the system, Jahia developers always look at new technologies with interest. Standards
for mashaps, they are still being developed, so Jahia will integrate new features
this technology as it develops.
Prododdzha read in the second part .
Jahia is one of the few open source systems that integrates the Java EE portal and management.
content in one product. CMS is a complete solution, representing an alternative to portals.
from large companies.
The review is intended to help the reader understand the various components of the system and the links between them.
This review can also serve as a basis for understanding the source code of a system that is
freely available.
')
The article is large, therefore, divided into two parts. It is also available in pdf-format .
Your comments, comments and corrections are welcome.
I would be glad if my translation would be useful.
Table of contents
Part 1:
- The overall picture.
- Components of the user interface.
- Authentication and authorization.
- Design Templates.
- Caching
- Content objects.
- Portal.
- Mashup server.
Part 2:
- File storage
- Tools and tools (engines).
- Search and indexing subsystem.
- Administration.
- Integration with Spring.
- Event listeners and rules.
- Request Processing in Jahia.
- Conveyors
- Import and export.
- Clustering
Overall picture
Jahia has in its composition a rich arsenal of various functions and subsystems. main idea
Portal operation is to integrate them efficiently so that it is convenient for users.
The figure below shows the main subsystems of the portal:
Briefly consider them from top to bottom:
- User Interface Components (UI Components) : starting from version 6.0,
Jahia began to use the GWT (Google Web Toolkit) AJAX framework, which provides wide
reusability features of interface components. The use of the framework has made it easier
system developers and integrators to write friendly user interfaces correctly
working in major browsers. - Caching : for fast page generation, Jahia supports
multi-level cache, starting with the database level and up to the level of html-pages. Cache is a cluster
compatible and helps make the system scalable and productive. Cache implementations are
pluggable. - Single sign-on (SSO) or single sign-on technology : Jahia is compatible with
all major implementations of the SSO (Single Sign-On) mechanism, including NTLM, CAS, authentication
jee container, etc. The subsystem is connected using the mechanism of conveyors (pipeline
mechanism), which will be described later in this document. - Content Management System (WCM) : Jahia was first developed as a system
Web Content Management System, and therefore this component is
most mature. Starting from version 2.0, the content management system has the capabilities
content editing right on the page, incorporates typical content objects and
allows you to use portlets. - Portal (Portal) : Jahia is not a portal server in its strict sense,
as it provides a much more customizable environment than traditional
servers. The back-end of the system fully complies with the JSR-286 standard, so there is a possibility
Easily integrate portlets on system web pages for sharing with regular
content objects. - File repository (File repository) : Portal integrated with file repository
JCR (Java Content Repository), which allows system users to publish binary data
access the repository through various interfaces (for example, WebDAV or
Windows Shared Folders). - Access Control Lists (ACLs) : Jahia is modular
system widely using access control subsystem. Its use makes it possible
effectively differentiate user access to various subsystems and services of Jahia. Subsystem
Access control is available throughout the portal. - Clustering : Jahia allows for system deployment on a cluster,
thus providing redundancy and load sharing. This article will
reviewed the overall architecture of the Jahia cluster. - Search and Indexing System : in the list of main
The capabilities of most content management systems are search and index support.
Jahia makes it possible to search and index not only by content, but also in the embedded
file storage. The portal allows you to search for a specific family of objects.
content, and distribute indexing tasks across multiple servers. - Administration (Administration) : The system presents two separate
portal management interface: for server administrators and site administrators. it
separation allows you to distribute tasks for portal support by roles. Interfaces give
users the ability to manage all subsystems Jahia, including administration
users and groups, permissions, loaded design templates, portlets, categories and so
Further…
Subsequent low-level subsystems are not part of the portal, but their use provides
storing and accessing information that Jahia processes.
- Database (Database) : Jahia supports all major DBMS, including DBMS with
open source (MySQL, PostgreSQL). Portal architecture is not tied to a specific
DBMS implementations as Jahia uses Hibernate ORM technology. - File system (Filesystem) : the file system is needed for storage
search index, binary data array (BLOB) or character data array (CLOB). (By
By default, the portal stores binary and character data in the database). The file system must be
distributed, if you plan to use a cluster, with responsibility for the correct
the work of distributed functions is assigned to the file system itself. - Lightweight Directory Access Protocol (LDAP) : Jahia does not require
advanced configuration to work with most LDAP servers (Lightweight Directory Access
Protocol), including OpenLDAP and ActiveDirectory. Together with LDAP single sign-on technology is
The main tool to ensure comfortable access to content to end users.
For example, by applying NTLM authentication and ActiveDirectory, Jahia will be able to use authentication
in a domain that Windows users go through when they start working with a computer.
UI Components
This figure shows the various components of the user interface that
provides jahia.
Starting with Jahia 6.0, the basis for all components is the Google Web Toolkit . Using
GWT, developers can quickly write and debug AJAX user interface components. AT
Jahia uses the GXT component library with pre-built components to work with
tables, trees and other standard interface elements.
The tri-panel component is a standard Jahia user interface component,
displaying a panel of hierarchical links with a list of descendants and an information window.
The toolbar component is used for quick access to tools
switch navigation modes / edit content. The toolbar is similar to the ones that
used in standard desktop applications, except that the tools on it are displayed
depending on the context (viewing and editing rights for the current user, current user
view mode).
On top of these components, Jahia has a complete set of custom elements.
interface: from file management components to category management, including components
browsing and navigating breadcrumbs and bookmarks .
Authentication and Authorization
Jahia allows you to use the following authentication mechanisms:
- CAS SSO (Single Sign-On with CAS, Central Authentication Service);
- NTLM (NT LAN Manager from Microsoft for Windows NT);
- JEE container authentication;
- a pluggable authentication pipeline, with which you can easily add
support for one-time registration technologies.
After the user is identified once, the system continues.
delineation of rights. The composition of the system of delineation of rights:
- access control lists for content objects;
- permissions for all user actions;
- connected services for users (user services);
- Plug-in services for groups (group services);
- LDAP compatibility;
- storage of user database in the database (in the default settings).
The figure above shows how the various levels of the subsystem (including plug-in interfaces)
interact with each other. Routing service allows using unified access interfaces.
to DB and LDAP-storage of user base. By implementing the service provider interfaces you can
add additional services.
Design Templates
The system of Jahia templates depends on how the information will be displayed on the page. Templates
registrations are grouped into a set . The set of templates is subsequently uploaded to the server. External
the type of site will depend on which template set you choose. One set can expand
another, "inheriting" it.
The composition of the set of templates:
- content definition files (CND);
- JSP pages;
- themes and skins;
- deployment descriptor for a set of templates
(required); - resources (resource bundles);
- Java classes.
When Jahia starts, it will determine all the templates available in the system (the WEB folder
INF / var / shared_templates ) and deploy them to the server. In development mode
Any changes to the deployment descriptor will cause the template set to reload, thereby
allowing instantly see changes in the design on the server.
As was shown above in the figure, you can apply
many different technologies:
- Tag Libraries : in order to facilitate support and update templates in Jahia
decided to abandon the use of scripts. To do this, the system included the rich
tag libraries that work fine with the standard JSTL tag set. Library data
provide functions for working with user interface elements (for example, working with
toolbar), the ability to query content objects, connection mechanisms
parent template tag include (support inheritance). Detailed Library Information
tags can be found in the Template developer guide. - The mechanism of inheritance : to facilitate the development of new sets in the templates can
use an inheritance mechanism similar to inheritance in the Java language. In the case of developing a new
set using the inheritance mechanism, you need to override only those templates in which
there are changes, and the rest will be inherited from the parent template. All this also applies to
files that are included in the include tag (the parent template is scanned for the presence of a file,
to be connected if it has not been redefined locally). Inheritance mechanism will allow
administrators to ensure consistency of design on a large number of portal sites, with
This preserves the ability to use completely different sets of templates for each specific
site. - Deployment : As mentioned earlier, template sets can be deployed in
Jahia at server startup. Therefore, it is necessary to simply add new sets to the Jahia installation.
Once you download a set, you make it available in the system. Well, site administrators in their
the queue will already define the sets that will be used on the portal sites: either this
there will be different sets of templates for each site, or there will be one parent set in the system, from
which all other patterns will inherit design. - Skins themes and skins : themes are used to give to one
a set of templates of different types. As an example, a set in which there are topics on
Seasons: winter theme, spring, summer and autumn themes. Subject can be set
administrator, or given the choice of the user. Shells allow content creators
make different content objects of the same type in different ways. - Content definitions : Jahia uses a standard format.
JCR content descriptions that have been extended (by internationalization, strong typing of elements
content) for more powerful content management.
Caching
For high-performance web systems like Jahia, caching is necessary for
avoid re-generation of dynamic content under high loads . On the picture
The caching subsystem architecture is shown.
All high-level caches are based on the cache service (cache service) , representing
cache implementation Below this service, various cache implementations can be used, some of them
may depend on other Jahia services. For example, the reference cache (Reference Cache) depends on
cluster services (Cluster service) , which allows to exchange messages in a cluster Jahia.
CASH TYPES
All types of high-level caches use the same caching service that represents
cache implementation Starting with Jahia 5.0SP4, the system has the opportunity to apply various
cache implementations for different types of cache, making the system flexible for configuration. For example,
you can use EHCache to cache custom html pages and use
ReferenceCache for other types of caches. This is the default configuration for Jahia.
5.0SP4 and Jahia 6.0. Naturally, it is also possible to integrate other cache implementations with
using the service provider interface (SPI) , which
provides jahia.
To optimize web page delivery performance, Jahia uses several cache levels:
- browser cache
- custom html pages cache (front-end HTML caches),
- object cache
- database cache.
Each of these levels solves its problem, pursuing a single goal: so that the values are calculated
only once.
BROWSER CASH
Despite the fact that this cache is not part of the Jahia portal, but is part of the browser,
it is he who plays a critical role in ensuring good system performance for
end user. For example, the use of the GWT framework in Jahia has allowed
cache the AJAX code in the browser cache, thereby freeing the portal from having to overload
scripts that have not changed. Jahia works correctly with the cache of those pages that have been changed.
and controls the lifetime of the page cache, so as not to update without need rarely changing
content.
CUSTOM USER HTML PAGES
Historically, Jahia has many implementations for the html page cache. First
The implementation was a full-page html cache (full-page HTML cache) . This cache is very
effective for simple pages if they are already in the cache; and it is not very suitable for pages with
different fragments (for example, displaying user information on the page).
In Jahia 5, we introduced the ESI cache server (ESI cache server) , which added the ability to
cache fragments of html pages. To effectively use this technology requires
a separate cache server that will run on a separate virtual machine. Being over
efficient technology for generating dynamic pages compared to full page cache,
The ESI system suffers from problems with server-to-server communications that are very cunningly needed.
configure for normal operation. Also, the use of the ESI cache requires good integrators
knowledge of the fragmentary caching model (fragment caching model) , which is not always
like.
Jahia 6 took the best from both approaches, combining the efficiency of the embedded full-page
cache with fragment cache support from ESI cache server. This cache implementation was named
“Container Cache” , it applies level-level fragment caching
container, making interaction with templates very simple. Template developers will not have to
add special markup to configure the correct fragmentary caching. Even
there will be a need to manage the generation of fragments, it will be much easier to do this
than in previous versions of Jahia.
Skeleton Cache - another html page cache implementation that caches everything
the rest (except fragments) content. By grouping two caching subsystem data by
performance, you can get the equivalent of a full-page html-cache, but with the ability to
cache fragments.
OBJECT CACHES
The object cache lies below the html page cache subsystem. This cache level serves all Java
System entities : content objects, user objects, groups, categories, descriptions
content, etc. An object cache exists above the database cache to avoid reconstructing
objects with each request to the model. The level is transparent to developers,
it is only necessary to interact with it through the Jahia API if changes to objects are not
entail automatic cache refresh.
DATABASE CASH
The last level of the cache is the database level, which minimizes queries to the database .
He is very important. When working with a database, objects are serialized / deserialized,
load network and system resources so that the overhead of queries to the database can be
very significant. This cache level is fully implemented by means of the Hibernate ORM .
Content Objects
List of content objects in Jahia:
- pages (pages), including content pages, internal and external links;
- lists of containers of the same type (container lists);
- containers (contain fields of different types);
- simple fields and metadata fields (metadata fields can be of various types:
SmallText, BigText, Integer, Date, File reference, etc.).
All these objects have common features:
- they can be divided into categories;
- access to them can be regulated using access control lists (ACLs);
- they are described using content description files (content definitions files, cnd-
files);
The description file format conforms to the Java Content Repository (JCR) standard for CND files with
adding the following features:
- multilanguage field values;
- more accurate input of field types (property types);
- the ability to specify resources (resource bundle support);
- choice lists (choice lists);
- much more ...
Content objects are loaded from a database and various cache levels. They are then transmitted to
a template subsystem in which integrators can finally render a page using
Jahia tag libraries .
Portal
Jahia includes a portal server based on Apache Pluto - a reference implementation.
Java portlet specifications (JSR-286 Portlet API). The purpose of Apache Pluto is
enabling integrators to use portlets on pages . Any portlet,
following standards, can be easily embedded in the Jahia portal. The figure above shows
various types of portlets that can be used in Jahia.
One of the fields of the content object is the application field , which refers to
portlet This field allows integrators to define a place in a structured web tree.
content where the application may appear. Portlets can also be categorized and
access to them can be controlled using access control lists.
Jahia 6 also uses portlets internally. Internal portlets can include descriptions
content, they are used to generate different layers of content objects. Layers in
The portal is used as functional blocks for building web pages. They can
reused on different pages.
This mechanism is called Mashap - the concept of building web applications by
combining the functionality of various software interfaces and data sources. For
building blocks in the portal server Jahia uses a mashap server (Mashup Server) .
Mashup server
In the latest versions of Jahia, Javascript has been used more frequently in the system, so to
to identify and reuse mashup on Jahia websites in the portal have included a new
mashap server.
Mashup server is built on the portal server, it makes it easy to connect new ones
data sources (mashup types) , simply uploading new portlets to the system. The picture above
we showed various data sources - mashups: Google Gadgets, YouTube videos, html snippets and
Javascript. These sources are actually portlet types that include descriptions.
content.
According to the description of the content, the user interface will automatically configure and draw
mashup Site administrators will be able to build mashaps, break them into categories,
restrict access using access control lists and allow content authors to use
them in their sections and in the measures of their competence in the system. Developers can group mashups
into packages (like ordinary Java portlets) or simply reuse existing ones
portlets, if they meet the needs (for example, the html-mashap is quite common and can be suitable for
many cases). Mashups can also be imported into the system using import / export functions.
Jahia
To improve the system, Jahia developers always look at new technologies with interest. Standards
for mashaps, they are still being developed, so Jahia will integrate new features
this technology as it develops.
Prododdzha read in the second part .
Source: https://habr.com/ru/post/81786/
All Articles