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

Aspect	Traditional Web App	Liferay Portal
Deployment	Monolithic	Modular (OSGi)
UI	Custom-built	Portal-based
Workflow UI	Custom	Built-in
User mgmt	Custom	Built-in
CMS	Optional	Built-in
SSO	Custom	Built-in
Scalability	App-level	Platform-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-services.html

📩 Email: ishikhanirankari@gmail.com | info@realtechnologiesindia.com
🌐 IT Trainings | Digital metal podium

✔ Available for quick consulting calls and project-based support
✔ Response within 24 hours

🎥 Learn IT with Shikha on YouTube

Prefer learning through videos? Watch practical tutorials on Kafka, Camunda, Alfresco, Java, Spring Boot, Microservices and Enterprise Architecture.

▶ Subscribe to Learn IT with Shikha on YouTube

Search This Blog

Learn IT with Shikha Blogs

Liferay Portal Architecture