Liferay Portal Architecture

Navin Agarwal
LIUG @ Bangalore
29-06-2013
Content
Liferay Architecture
Enterprise Layer
Extensions Framework
Logical Architecture of Liferay
Service layer
Service Builder
Web services
Persistence Layer
Portal Architecture
Users Management
User Groups
Roles
Organizations
Sites
Team

Enterprise Layer
Its the top layer of services and components : grouped
into taxonomies which support and realize enterprise
functions such as
Portal Management,
Content Management,
Workflow Management,
Document Management,
User Management and Security Management.
It is also comprised of inter related service components
and features such as
Personalization,
Collaboration,
Social Networking,
Delivery Channels,
Virtualization and Tunneling Servlets.
These form the basic backbone or core enterprise features of Liferay.
Enterprise Layer cont
Traditional sense Platform Independent Model (PIM) from
which we derive a Platform Specific Model (PSM) and
subsequently generate implementation logic.

Liferay follows a Model Driven Architecture approach.
Domain Specific Model (DSM) since the root model is
only specific to Liferay domain.
Enterprise Layer
Service Layer The implementation of
Service Builder which is
the most integral tool
provided by Liferay and
enforces the same
standards throughout.
The services builder is the
Model Driven
Transformation (MDT)
Tool in this context.
Extensions Framework
Liferay provides extensions framework by use of an
Extension Environment and Plugins Framework.
The extension environment has the same directory structure of the Liferay
and was implemented by overriding the existing source files by placing
them in the same path.
The design also incorporated multiple ext.properties file to change
default settings of the portal by overriding desired properties in the
ext.properties file.
The hooks are basically interceptors that can be categorized into
model hooks, JSP hooks, properties hook and event hooks.
Logical Architecture of Liferay
Liferay supports Windows, Mac and Linux OS.
JRE is installed on the supported OS to host the JVM.
The officially supported servers include, Apache Tomcat, Glassfish,
Geronimo, Jetty, JOnAS, JBoss, and Resin.
The server provides connectivity and interoperability using an Enterprise
Service Bus (ESB).
Liferay provide multiple services : JNDI, JDBC, JTS, JMS, JAAS, JDO, JWS,
JSP/Servlets, and JavaMail.
Liferay uses EJB, Hibernate, Spring and JBPM, Activiti.
Liferay implements Lucene Search Engine by default and can be configured
to extend the SOLR Search Engine.
Solr search is built on Lucene to extend capabilities to provide clustering, faceted search,
filtering with additional enhancements and scalability.
A Portlet Bridge is provided to deploy JSR 168/286 portlets and supports
RIA applications. JSR 362 i.e Portal 3.0.
Logical Architecture of Liferay cont
The Administration Kernel provides the base framework
for integration and support of all
modules,
with tooling support,
wizards, service providers,
listeners and
runtime configuration parameters to tweak the application server in runtime
mode.
The services builder provides the basic framework to
construct and deploy the services using a Model Driven
Development (MDD) approach.
The portlet plug-in leverages on the portlet bridge to
provide dynamically generated portlets to the end users
and enhanced RIA integration.
Logical Architecture of Liferay cont
The hooks plug-in provide convenient access to intercept
and alter the services and functionality of the Liferay
instance in a standardized approach.
A robust Enterprise Services layer resides on top of this
providing extended solutions ranging from
Portal Management,
Web Content Management,
Enterprise Content Management,
Document Management,
User Management,
Workflow Management, and Security Management.
These in turn provide features such as
Personalization, Collaboration, Virtualization, Social Networking and
integrates Dynamic Delivery Channels, and Tunneling Services.
Logical Architecture of Liferay cont
Liferay is very flexible in terms of accessing external
systems as well as being accessed by all sorts of external
"clients" from regular desktops to third party apps going
through mobile apps and browsers.
Liferay is buzzword compliant with terms such as SOA,
WOA, ... even since before the terms existed ;)
Liferay includes many transversal frameworks that are
used inside Liferay but also made available for applications
built on top of it.

Logical Architecture of Liferay cont
Service layer
The Services layer contains the great majority of the
business logic for the portal platform and all of the
portlets included out of the box.
The services are organized in two sets:
Portal services (com.liferay.portal.service)
Portlet services (com.liferay.portlet.*.service)
Portal services : Contains the services for the portal level
entities.
Portlet services : Contains the services used by the
different portlets in Liferay.

Service layer
Services layer is divided in two sub-layers:
Local Services (<Entity>LocalService.java)
Remote Services (<Entity>Service.java)

Service Layer
Local Services :This is the ones that contain the business
logic and communicate with the persistence layer.
Remote Services : The main goal is to perform security
checks before invoking the equivalent method in the local
service. In some cases the remote services are also
responsible for converting the Java objects returned by
the local services layer to other formats.
Each persisted entity has an associated service. For
example, the User entity has UserService, DLFileEntry
(the entity used to store documents of Documents &
Media) has the DLFileEntryService.
The services methods are executed in a transaction.
Service Builder
Service Builder is the tool that glues together all of
Liferay's layers and that hides the complexities of
using Spring or Hibernate under the hood.
Service Builder was originally built when Liferay used EJBs
for everything.
Service Builder helps us generates the necessary
persistence, service layer, web services, ... infrastructure
around it.
Service Builder will generate there is a Freemarker (.ftl)
file associated with it.
For example, do you want to find out how a *ServiceImpl.java file is generated,
you just have to look at service_impl.ftl within
com/liferay/portal/tools/servicebuilder/dependencies
Web services
This layer is built automatically by that wonderful tool
called Service Builder based on the remote service
interface and annotations left in the implementation by its
developers.
The layer have two most significant and used protocols:
JSON Web Services
SOAP
Web services
JSON Web Services: This is a new way of accessing
Liferay's web services that was added in 6.1. It provides a
lightweight RPC-based protocol that uses JSON as the
data exchange format.

SOAP: The good old XML-based protocol that has
declined in popularity lately but is here to stay. One of the
main benefits of SOAP is the amount of tooling available
as well as the out of the box integration offered by some
software packages.

Persistence layer
At the persistence layer Liferay relies on Hibernate to do
most of its database access. Hibernate has two cache layers
called Level 1 (L1) and Level 2 (L2).
Level 1 is used to cache objects retrieved from the database within the current
databases session. In the case of Liferay a session is tied to an invocation to a
service layer.
Hibernate's cache Level 2 is able to span across database session and stores
database objects (Entity Cache) and results of queries (Query Cache). For
example if any logic retrieves from the database all users that belong to a
certain organization, the result will be stored in the cache.
One final important aspect is that all of these cache's use an
underlying cache provider to manage the objects in memory.
By default Liferay uses ehcache to do that, but it is also possible to change the caching
provider through portal.properties. The configuration is done within hibernate-
clustered.xml which defines and configures several cache areas.
Fine tunning these configuration files is a very important task
for any high-profile site.

Persistence Layer
The persistence layer is always accessed from local
services.
The local services are very strict with the return types of
its methods.
The return type should be one of the following:
void
<Entity>
List<Entity>
primitive type (this is not used often)

User Management
Liferay 6.1 manages the user with respect to organization
structure.
Organization
Site
User
Roles
Groups
Of course Team in every Site/Community . Which hardly use
in real time.
Users
Users represent physical users of the system. These are the
user accounts that people use to log into the system.
By default, users get their own public and private
Users can be collected in multiple ways.
They can be members of organization hierarchies, such as Liferay, Inc.
Security Internet Security.
They can be collected into arbitrary user groups, such as Bloggers,
which could be used to set apart users who get a Blog page in their
personal space from users who do not.
They can be members of site which draw together common
interests.
And they can have roles which define their permissions in the
system, and these roles can be scoped by Portal, Organization, or
Site.
Users
Users are directly associated with Organization, User Groups
and Site.
User can have personal and private pages using page templates.
User Group
User Groups are simple,
arbitrary collections of users,
created by administrators.
They can be members of site
or roles.
Permissions cannot be
assigned to User Groups.
Though User Groups do not
have pages like some of the
other collections of users.
Roles
There are three kinds of roles:
Portal Roles (Regular)
Organization Roles (Organization)
Site Roles (Site)
These are called role scopes. Roles are
used to define permissions across their
scopes: across the portal, across an
organization, or across a site.
For example, consider a role which grants
access to create a Message Board
category. A Portal role would grant that
access across the portal, wherever there
was a Message Board portlet.
A Site role would grant that access only
within a single sit.
An Organization role would grant that
access only within an Organization. .

A site role grand access only within specific site.
A organization role will only grand access with
in Organization.
A portal role grand access across portal.
Roles
Because Roles are used
strictly for portal security,
they also do not have pages,
like Sites and Organizations.
Users, User Groups, Sits, or
Organizations can be
members of a role
Organizations
Organizations are
hierarchical collections of
Users. They are one of the
two types of portal
resources that can have
pages.
There is also a special type
of Organization called a
location, which can define
where users are specifically
located.
Organization Do not have Pages.
Organization need to attached site to
have pages.
Organization
Organizations can be members
of Sites.
Organizations and sub
organizations can be created in
a hierarchy to unlimited levels
and users can be members of
one or many organizations.
These organizations can all
reside in a single hierarchy or
cut across different
hierarchies.

Organizations cont.
Now say that you have placed an Asset Publisher portlet as a
static portlet on every user's home page (via a User Group
page template) so that you can inform employees of various
announcements via the content management system. If you
tagged your content appropriately, you could ensure that Joe
Smith gets any announcements that are meant for Sales, the
North East Division, or the New Jersey location.
Organizations are handy for defining where a user belongs in a
particular hierarchy.
For example, if you are implementing Liferay for a large organization,
it may help to define user Joe Smith via his position in the
organization chart. If Joe Smith is a Sales Engineer located in the New
Jersey office, working in the North East division of the Sales
department, he might be a member of the following organizations:
Sales
North East Division
New Jersey Location

Site
Sites are collections of Users who have a common
interest. There are three types of Site:
Blank Site
Community Site
Internet Site
Sites can be associated to an organization at any
time.
All users of the organization will be members of the site
automatically.
The Site name and description will be automatically
synced with those of the organization.
Site Admin and Organization Admin cannot create a new
Role, they can create Team.
Teams
Teams are unique within a context of a Sites or Organization.
Teams are essentially sets of users that can be created within a
Sites. This makes teams different from the Site and
Organization Roles because teams appear only in the specific
site in which they are created.
This is very useful if you need to create a team of users for a
specific purpose within a Site and not for each Site in the
portal.
Teams can also be essential for some use cases, because they
can be created by Site Administrators.
Team is similar to site and organization Role, so the ability to
have teams empowers them to manage permissions at a level
they weren't capable of previously.
Configuring portal paths
Before customizing the configuration files in a server level, it is better to review and adjust the
values of the following properties, shown with their default values at the time of writing.
auto.deploy.deploy.dir=${liferay.home}/deploy for auto-deploy
jdbc.default.url=jdbc:hsqldb:${liferay.home}/data/hsql/ for Hypersonic SQL scripts
lucene.dir=${liferay.home}/data/lucene for search and indexing
jcr.jackrabbit.repository.root=${liferay.home}/data/jackrabbit for JCR jackrabbit
dl.hook.file.system.root.dir=${liferay.home}/data/document_ library for Document Library and

What's the variable liferay.home? What are the folders /data and /deploy used for? By default,
the portal has the following settings:
liferay.home=$LIFERAY_HOME
For this reason, after installing the portal, you will see following folders under
$LIFERAY_HOME:
deploy: A folder for hot deploy
data: A folder for runtime data
license: A folder for license information, used only for Community Edition (CE)
$APPLICATION_SERVER_DIR: A folder for the application server
As shown in the previous code, you will have the default folders /deploy and /data for the
properties such as auto.deploy.deploy.dir, lucene.dir, and so on. Of course, you can set
the liferay.home variable to any folder you desire.
Properties files
The Loading of the properties files:
The default read order is:
portal.properties, then
portal-bundle.properties,
portal-ext.properties and then
portal-setup-wizard.properties.
References
http://www.liferay.com/web/jorge.ferrer/blog/-/blogs/liferay-s-architecture-the-
service-layer
http://www.liferay.com/web/jorge.ferrer/blog/-/blogs/liferay-s-architecture-service-
builder
http://www.liferay.com/web/jorge.ferrer/blog/-/blogs/liferay-s-architecture-web-
services
http://www.liferay.com/web/jorge.ferrer/blog/-/blogs/liferay-s-architecture-the-
beginning-of-a-blog-series
http://www.liferay.com/community/wiki/-/wiki/Main/Logical+Architecture
Thanks

Navin Agarwal
www.navinagarwalmca.wordpress.com