Liferay Portal Architecture

How It Really Works (For Enterprise Java & BPM Developers)

Introduction

If you are evaluating Liferay DXP or already using it for portals, one question always comes up:

❓ What is actually inside Liferay?

Most tutorials focus on how to create a portlet,
but very few explain how Liferay really works internally.

Understanding the architecture is critical when you:

  • Integrate Liferay with Camunda / jBPM

  • Call Spring Boot APIs

  • Build workflow portals

  • Debug production issues

  • Scale Liferay in enterprise environments

This blog explains:

  • The core building blocks of Liferay

  • How requests flow through the portal

  • The role of OSGi

  • How portlets, services, and APIs fit together

  • How Liferay integrates into BPM & microservices

High-Level Architecture of Liferay Portal

At a high level, Liferay looks like this:

User Browser
     ↓
Web Server / Load Balancer
     ↓
Liferay Portal (Tomcat / JBoss)
     ↓
OSGi Runtime
     ↓
Portlet / Modules
     ↓
Services Layer
     ↓
Database

Core Layers Explained

1️⃣ Presentation Layer (UI Layer)

This is what users interact with.

Components:

  • Pages & layouts

  • Themes

  • Widgets

  • Portlets

  • Forms

  • Dashboards

This layer is responsible for:

  • Rendering HTML

  • Handling user actions

  • Displaying workflow tasks

  • Showing content

2️⃣ Portlet Layer (Application Modules)

A Portlet is the core UI building block in Liferay.

Each portlet:

  • Is a Java application

  • Runs inside the Liferay container

  • Is deployed as an OSGi module

  • Can be developed and deployed independently

Examples:

  • Task inbox

  • Approval dashboard

  • Data entry form

  • Reports module

3️⃣ OSGi Runtime Layer (The Heart of Liferay)

This is what makes Liferay a platform, not a monolith.

Liferay uses an OSGi container to manage modules.

What OSGi gives you:

  • Hot deployment

  • Module isolation

  • Versioned services

  • Dynamic dependency resolution

This means:

You can deploy, upgrade, and remove features without restarting Liferay.

4️⃣ Services Layer (Business & Platform Services)

Liferay provides hundreds of built-in services:

  • User management

  • Roles & permissions

  • Organizations

  • Sites

  • Content management

  • Workflow APIs

  • Search

  • Notifications

  • Document library

You can also create your own services using:

  • Service Builder

  • Custom APIs

  • REST endpoints

5️⃣ Integration Layer (REST, Headless, APIs)

Modern Liferay exposes:

  • REST APIs

  • Headless services

  • GraphQL

  • OAuth2

This allows Liferay to integrate with:

  • Spring Boot

  • BPM engines (Camunda / jBPM)

  • Kafka

  • External UIs

  • Mobile apps

6️⃣ Persistence Layer (Database)

Liferay stores:

  • Users

  • Content

  • Permissions

  • Workflow state

  • Configuration

  • Custom entities

Supported databases:

  • MySQL

  • PostgreSQL

  • Oracle

  • SQL Server

How a Request Flows Through Liferay

Let’s say a user opens a portal page.

Browser
   ↓
Load Balancer
   ↓
Liferay Portal
   ↓
Theme Renderer
   ↓
Portlet Dispatcher
   ↓
OSGi Module
   ↓
Services Layer
   ↓
Database
   ↓
HTML Response

Each portlet:

  • Processes its part of the page

  • Fetches data

  • Calls APIs

  • Renders HTML

Where OSGi Fits In

OSGi is not optional in Liferay.

It is the backbone of:

  • Portlet deployment

  • Service wiring

  • Plugin isolation

  • Module lifecycle

Everything in Liferay is an OSGi bundle:

  • Portlets

  • Services

  • REST APIs

  • Workflow connectors

How Liferay Fits Into BPM Architecture

Here’s a real-world enterprise stack:

User Portal (Liferay)
        ↓
Spring Boot Services
        ↓
BPM Engine (Camunda / jBPM)
        ↓
Kafka / DB / External Systems

Typical BPM Use Cases

  • Approval workflows

  • Task dashboards

  • Case management portals

  • HR onboarding portals

  • Customer onboarding

  • Document approval

Liferay vs Traditional Web Apps

AspectTraditional Web AppLiferay Portal
DeploymentMonolithicModular (OSGi)
UICustom-builtPortal-based
Workflow UICustomBuilt-in
User mgmtCustomBuilt-in
CMSOptionalBuilt-in
SSOCustomBuilt-in
ScalabilityApp-levelPlatform-level

👉 Liferay is a platform, not just a web app.

Common Architecture Mistakes 🚨

❌ Treating Liferay as a simple CMS
❌ Putting heavy business logic in portlets
❌ Ignoring OSGi dependency rules
❌ Tight coupling to database tables
❌ Using synchronous REST calls everywhere
❌ Not externalizing long-running logic

Best Practices (Production-Proven)

✔ Keep portlets thin (UI only)
✔ Put business logic in Spring Boot
✔ Use REST APIs for integration
✔ Use BPM for orchestration
✔ Use Kafka for events
✔ Use headless APIs
✔ Monitor OSGi bundles
✔ Tune database & caches

Interview Question (Very Common)

Q: What is the core architectural concept behind Liferay?
A: A modular portal platform built on OSGi with portlets, services, and headless APIs.

Final Takeaway

❗ Liferay is not “just a CMS”.
❗ It is a full enterprise portal platform.

If you are building:

  • Workflow portals

  • BPM-driven apps

  • Enterprise dashboards

  • Digital experience platforms

Then Liferay’s architecture makes it the perfect UI layer on top of:

  • Camunda

  • jBPM

  • Spring Boot

  • Kafka


💼 Professional Support Available

If you are facing issues in real projects related to enterprise backend development or workflow automation, I provide paid consulting, production debugging, project support, and focused trainings.

Technologies covered include Java, Spring Boot, PL/SQL, Azure, CMS and workflow automation (jBPM, Camunda BPM, RHPAM).



Comments

Post a Comment

Popular posts from this blog

jBPM Installation Guide: Step by Step Setup

  jBPM Installation Guide – Step by Step for Beginners If you are starting with jBPM (Java Business Process Management) , the first step is to set up your environment. In this guide, we’ll walk through how to install jBPM, configure it, and run your first business process. 🔎 What is jBPM? Before we dive into installation, a quick recap: jBPM is an open-source Business Process Management (BPM) suite , written in Java, that allows you to model, execute, and monitor workflows using BPMN 2.0 standards. It can run standalone , embedded in applications , or deployed on a Java EE server . 🖥️ Prerequisites Before installing jBPM, make sure you have: Java JDK 11 or later (Java 17 is commonly used) Maven 3.x (for building and managing dependencies) Git (optional, if you want to clone sample projects) A Database (H2, MySQL, PostgreSQL, or Oracle) – jBPM ships with H2 for testing At least 4GB RAM (8GB recommended for Workbench & KIE Server) 📦 Download ...
Read more

Scopes of Signal in jBPM

Image
💡 Introduction Signals in jBPM 7 are a core part of event-driven workflow design. They allow asynchronous communication between process instances, making it possible to start , interrupt , or coordinate processes without direct linking. However, signals can have different scopes , which define how far the signal travels and who receives it . Let’s explore the four available scopes in detail: 🔹 Process Scope 🔹 Default Scope 🔹 External Scope 🔹 Project Instance Scope 🧩 1️⃣ Process Scope 📘 Definition Process scope signals are local to a single process instance or its child subprocesses . They are not visible outside that instance hierarchy. 📋 Use Case Used for communication inside the same process , like triggering subprocesses or event sub-processes. 🖼️ Process Scope Example Below is an example of a simple process-scoped signal. Only this process (or its subprocess) will catch this signal. ⚙️ 2️⃣ Default Scope 📘 Definition The default scope ...
Read more

OOPs Concepts in Java | English | Object Oriented Programming Explained

Image
🔹OOPS (Object Oriented Programming System) in Java Object-Oriented Programming (OOPS) is a programming paradigm that uses classes and objects to design software. It simplifies development and maintenance by applying key concepts: 📌 Class: Class   is a user-defined data type which defines its properties and its functions. Class is the only logical representation of the data. For example, Human beings in an organisation is a class like Employee. The age, name, department, salary etc. of a human being/employee are its properties, and the jobs performed by the employees in an organisation are known as functions.  The class does not occupy any memory space till the time an object is instantiated. A class is a user-defined data type that defines properties and functions. For example: Class: Employee Properties: name, age, salary Functions: work(), attendMeeting() A class does not occupy memory until an object is created. ...
Read more