Liferay Architecture – a Simplified View

Liferay Architecture Diagram

 

Let’s do a very brief analysis of the Liferay portal architecture. The best way to do that get an overview of Liferay portal architecture is through a visual representation, so here is a diagram of the Liferay architecture.

Liferay Architecture Diagram
3 Tier Liferay Architecture Diagram

As you can see in the diagram the Liferay architecture has 3 tiers, which is a pretty standard architecture.

[googleAd]

Tier 1 of the Liferay architecture: the front-end

Liferay front-end is based on the implementation of JSR-268, which is the specification for Java Portlets 2.0. As pointed out in the diagram Liferay’s UI uses Velocity for templating in its views, HTML, CSS and an extension of the YUI JavaScript library, called AUI. One other important technology used in the Liferay architecture for front-end is Vaadin. A very loose description for Vaadin would be a precompiled GWT UI framework.

Tier 2 – the services layer

Here is where all the business logic resides. What I tried to depict in the diagram was that Liferay services can be one of two types. They can be either secured or not secured.

Liferay uses an ACL authorization system and all secured services will do a check against that authorization scheme. The non-secured services are used internally.

The most important operations that the services facilitate relate to:

  • management of portal assets (users, portal organizations, sites, pages, etc.)
  • document management (the portal uses an abstraction of a document management system and also comes with a default implementation based on Apache Jackrabbit)
  • Liferay workflow engine (the portal uses an abstraction of a workflow engine interactions and comes with an implementation for Kaleo workflow, but also the JBPM workflow engine from JBoss can be used; the workflow is used for assets approval workflows)
  • etc.

 

Tier 3 – the persistence layer

Liferay’s persistence layer uses Hibernate ORM to store data managed by the portal (portal assets). Hibernate offers a lot of flexibility in that it makes Liferay totally independent from the database engine (it can run without problems on MySQL, Oracle or even HSQL).

If you are interested in specifics for the persistence layer, and especially the way that Liferay handles a multi-tenant architecture here’s a post that discusses Liferay multi-tenancy configuration.

Besides the persistence of Liferay assets, the persistence tier manages the persistence for other components like:

  • the document management module – through Apache Jackrabbit which can be configured to run on any RDBMS or can be filebased
  • the search index which by default works on Apache Lucene, but can be made to work with SOLR
  • the workflow engine which by default is Kaleo, but can be made to work with jBPM on any RDBMS

Hope you found this post insightful regarding and overview of the Liferay Architecture. In the future I will create some posts about various areas of Liferay, but if you have questions on any specific subject related to this please leave me a comment and I will give that higher priority.

John Negoita

View posts by John Negoita
I'm a Java programmer, been into programming since 1999 and having tons of fun with it.
[jetpack-related-posts]

1 Comment

  1. […] deep in the liferay architecture, in the persistence layer service namely, you can find that Liferay portal instances are called […]

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top