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.
As you can see in the diagram the Liferay architecture has 3 tiers, which is a pretty standard architecture.
Tier 1 of the Liferay architecture: the front-end
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)
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.