Liferay architecture By Navin Agarwal

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
 It’s 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 andTunneling 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 supportsWindows, 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.

 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,andTunneling Services.

Liferay architecture By Navin Agarwal

 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.

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:
 JSONWeb 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.

User’s
 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.

User’s
 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

Liferay architecture By Navin Agarwal

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Liferay architecture By Navin Agarwal (20)

Recently uploaded (20)

Liferay architecture By Navin Agarwal