Liferay Portal Introduction

© Copyright 2011 FPT Software 1
FPT Software
LIFERAY PORTAL
PLATFORM
Tung.Nguyen
tungnq@fsoft.com.vn

Agenda
• Review Liferay Portal
– Enterprise Layer
– Extensions Framework
– Logical Architecture of
Liferay
– Service layer
– Service Builder
– Web services
– Persistence Layer
– User Management
• Organization, Site, User, Roles,
Groups
• Out of the box features
– Document and Media
Library
• Image Management
• Document Management
– Web Content
Management
– Asset, Tagging, and
Categorization

What is Liferay Portal?
• Liferay Portal is a Portlet Container and
Portal Server:
– Platform and Environment to
run/administer web sites and integrate
portlets.
– A content management system with
publishing, workflow, staging area and
content-templating features
– A set of portlets provided Out Of The Box
feature (for collaboration, social media and
more)
• Liferay Portal is based on widely used,
standard ways of doing things, aiming to
keep the code free:
– Adheres to the JSR-286 standard
(Portlet2.0)
– Takes advantage of Spring, Hibernate and
Velocity (for things not standardized in
official Portlet Specifications)

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 and Tunneling Servlets.

Enterprise Layer cont…
• 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.
• 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.

Extensions Framework
• Liferay Portal is a Portlet
Container and Portal
Server Platform.
• Liferay provides
extensions framework by
use of an Extension
Environment and Plugins
Framework
 Ext Plugin
 Hooks
 Portlet
 Theme
 Layout

Theme Plugin
• Themes customize the overall structure and look and feel of the
Portal pages and are based on HTML, CSS and Velocity/FreeMarker
• Theme Plugins are based on a pre-made theme which gives the site
minimal structure (either un-styled or styled)
– Customizations are overlaid against the “base theme” with a overwriting mechanism
and differentiation scheme.
– Provide control over everything: HTML, CSS and images inside portlets (box) and
outside (page) and positioning/behavior of the top navigation elements.
• Deployed Themes can be used at level different levels: the overall site, a
community/organization or a single page.

Layout Template Plugin
• Layout Templates control how portlets are
arranged on a Portal page and are created with a
combination of HTML, CSS and Velocity
• They make up the body of the page, the large area
where portlet scan be dragged and dropped into
• Allow portlets to be embedded into templates
• Deployed Layout Templates are used at page level

Hooks
• Hooks allow to hook custom code at
different extension points in order to
either change, override or extend:
– Display: JSPs and Language Properties
– Behavior: Portal Server Lifecycle Events,
Services, Model Listeners and Portal Properties.
• Hook Plugins are Java code – based and
they are hot deployable.

Potlets
• Portlets are componentized
user-facing applications
that generate a fragment of
the Portal page.
• Portlet is a small web
application.
• Portlet development types:
– Liferay MVC + Alloy UI
– JSF 2x (RichFaces,…)
– Vaadin

Ext Plugin
• Ext allow to extend/override built-in code in special
scenarios that can not be met by another plugin types:
– Easily extensible: Liferay Portal is implemented on top of Spring,
Hibernate and Struts/Tiles, so custom code can be plugged in
very easily.
– Complete control: It allows access to internal APIs or even
overwriting files/classes provided in the Liferay core.
– To be carefully used: it is a powerful tool that comes with a cost
in terms of complexity and maintenance (e.g. upgrade Liferay
portal platform,…)
• Ext Plugins are NOT hot-deployable:
– Require server restart
– Can not be un-deployed

Ext Plugin
• ext-impl: Portal implementation extension
• ext-lib: Portal and global dependencies extension.
• ext-service: Portal service extension.
• ext-util-bridge: Utility bridge extension.
• ext-util-java: Utility Java extension.
• ext-util-taglib: Utility taglib extension
• ext-web: Portal web extension – including folder
html/common, /portal, /portlet, /icons, /js, /taglibs, /themes,
and so on
• sql: SQL scripts extension.

Liferay Logical Architecture

Liferay Logical Architecture cont…
• 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.

• 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 provides 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.

• 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 includes many transversal frameworks that
are used inside Liferay but also made available for
applications built on top of it.

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

Service Layer cont…
• 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 cont…
• 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.

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 cont…
• JSON Web Services: This is a new way of accessing
Liferay's web services. 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).
• One final important aspect is that all of these cache's use an
underlying cache provider to manage the objects in memory.
• Fine tunning these configuration files is a very important task
for any high-profile site.
• 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
• Portals are accessed by Users.
• Users can be collected into User Groups.
• Users can belong to Organizations and join/leave Communities.
• Roles are collections of permissions on portal objects that can be assigned
to Users.
• Organizations can be grouped into hierarchies. Communities are not
hierarchical.
• Users, Groups, and Organizations can belong to Communities that have a
common interest.

User
• Users are directly associated with Organization, User Groups
and Site.
• User can have personal and private pages using page
templates.
• 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

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 sit e.
• 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

Organization
• 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.

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.

Liferay Out Of The Box Features
Page Development

Liferay Out Of The Box
Control Panel

Document and Media Library (DL)
• Document and Media Library (DL) provides a centralized
repository to store document type Basic Document, Image,
and Video.

DL – Image Management
Model (1/2)
• Document imaging is a process to capture, store,
scale, and reprint images
• Model:
 DLFolder: stores folder metadata.
 DLFileEntry: stores image metadata.
 Image: stores real image.
Note: Image also is used to store images from other entities e.g.
JournalArticleImage, Journal Article(web content), small image, page's icon
image, and so on.

Model (2/2)
Model Interface Implementation Description
DLFolder DLFolderModel extends
BaseModel<DLFolder>
DLFolderImpl,
DLFolderModelImpl
Document and Media
Library folder model and its
metadata
DLFileEntry DLImageModel extends
BaseModel<DLFileEntry>
DLFileEntryImpl,
DLFileEntryModelImpl
Document and Media
Library File Entry model
and its metadata
Image ImageModel extends
BaseModel<Image>
ImageImpl,
ImageModelImpl
Global image model and its
metadata like type, height,
weight, size, and so on.

Services
Service Utility Implementation
DLFileEntry(Local)Service DLFileEntry(Local)ServiceUtil DLFileEntry(Local)ServiceImpl
DLFolder(Local)Service DLFolder(Local)ServiceUtil DLFolder(Local)ServiceImpl
Image(Local)Service Image(Local)ServiceUtil Image(Local)ServiceImpl
 {XXX}LocalService: contains methods with no permission check.
 {XXX} Service: contains methods with permission check on the entity
instance {XXX}.
 There are two ways to use images from the Document and Media Library
that are as follows:
 Call DLFileEntryLocalServiceUtil, DLFolderLocalServiceUtilor DLFileEntryServiceUtil,
DLFolderServiceUtil
 Call ImageLocalServiceUtilor ImageServiceUtil

DL - Document Management
Model (1/3)
• The Document Library provides one central place to
aggregate and manage documents, images, videos,
and any other document types.
• Model:

Model (2/3)
• DLFolder: stores folder metadata.
• DLFileEntry: stores document
metadata.
• DLFileVersion: stores document
version information.
• Repository: represent a repository. It is associated with the
DLFolder folder, and it may contains many documents.
Document Library has a set of folders called DLFolder.

Model (3/3)
DLFileEntryType DLFileEntryTypeModel extends
BaseModel<DLFileEntryType >,
GroupedModel
DLFileEntryTypeImpl,
DLFileEntryTypeModelImpl
Document and Media Library
document type model and its
metadata
DLFileEntryMet
adata
DLFileEntryMetadataModel
extends
BaseModel<DLFileEntryMetadata>
, GroupedModel
DLFileEntryMetadataImpl,
DLFileEntryMetadataModelI
mpl
Document and Media Library
file entry metadata model and
its metadata
DLFileVersion DLFileVersionModel extends
BaseModel<DLFileVersion>
DLFileVersionImpl,
DLFileVersionModelImpl
Document Library portlet file
version model and its
metadata
DLFileShortcut DLFileShortcutModel extends
BaseModel<DLFileShortcut>,
GroupedModel
DLFileShortcutImpl,
DLShortcutModelImpl
shortcut model and its
metadata
DLFileRank DLFileRankModel extends
BaseModel<DLFileRank>
DLFileRankImpl,
DLFileRankModelImpl
rank model and its metadata
Repository RepositoryModel extends
BaseModel<Repository>
RepositoryImpl,
RepositoryModelImpl
Global repository model and
its metadata
RepositoryEntry RepositoryEntryModel extends
BaseModel<RepositoryEntry>
RepositoryEntryImpl,
RepositoryEntryModelImpl
Global repository entry model
and its metadata

Services
Service Utility Implementation
DLApp(Local)Service DLApp(Local)ServiceUtil DLApp(Local)ServiceImpl
DLRepository(Local)Service DLRepository(Local)Service
Util
DLRepository(Local)ServiceImpl
DL(Local)Service DL(Local)ServiceUtil DL(Local)ServiceImpl
 {XXX}LocalService: contains methods with no permission check.
 {XXX} Service: contains methods with permission check on the entity
instance {XXX}.

Features
• Document Versioning
• Converting Documents (PDF, ODT, RTF, DOC, DOCX,
etc.)
• Comparing Versions
• Previewing a Live Document
• Document Check-in and Check-out
• Moving Document
• Document Indexing
• …

Web Content Management
Overview
• Web content is text, images, sounds, videos, and
animations, etc.
• The Web Content Management (WCM) portlet
manages the structured and unstructured content to
be published in a website.

Model (1/3)
• Web content has a set of resources, called
JournalArticleResource.
• JournalArticleResource may have many versions of
journal articles, called JournalArticle.

Model (2/3)
JournalArticle JournalArticleModel extends
BaseModel<JournalArticle>,
GroupedModel,
ResourcedModel
JournalArticleImpl extends
JournalArticleModelImpl
Journal article model
JournalArticleDisplay Serializable JournalArticleDisplayImpl Journal article display model
JournalArticleImage JournalArticleImageModel
extends BaseModel
<JournalArticleImage>
JournalArticleImageImpl
extends
JournalArticleImageModel
Impl
Journal article image model
JournalArticleResource JournalArticleResourceModel
extends
BaseModel<JournalArticleRes
ource>
JournalArticleResourceImp
l extends
JournalArticleResourceMo
delImpl
Journal article resource model,
for versioning
JournalContentSearch JournalContentSearchModel JournalContentSearchImpl
extends
JournalContentSearchMod
elImpl
Journal content search model,
for web content search
capabilities
JournalFeed JournalFeedModel JournalFeedImpl extends
JournalFeedModelImpl
Journal article RSS feed model

Model (3/3)
JournalStructure JournalStructureModel JournalStructureImpl extends
JournalStructureModelImpl
Journal article structure model
JournalTemplate JournalTemplateModel JournalTemplateImpl extends
JournalTemplateModelImpl
Journal article template model

Services
Service Utility/Wrapper Implementation
JournalArticle(Local)Service JournalArticle(local)ServiceUtil
JournalArticle(local)ServiceWrapper
JournalArticle(Local)ServiceImpl extends
JournalArticle(Local)ServiceBaseImpl
JournalArticleResource(Local)S
ervice
JournalArticleResource(Local)Service
Util
JournalArticleResource(Local)Service
Wrapper
JournalArticleResource(Local)ServiceImpl
extends
JournalArticleResource(Local)ServiceBaseImpl
JournalStructure(Local)Service JournalStructure(Local)ServiceUtil JournalStructure(Local)ServiceImpl extends
JournalStructure(Local)ServiceBaseImpl
JournalTemplate(Local)Service JournalTemplate(Local)ServiceUtil JournalTemplate(Local)ServiceImpl extends
JournalTemplate(Local)ServiceBaseImpl
JournalFeed(Local)Service JournalFeed(Local)ServiceUtil JournalFeed(Local)ServiceImpl extends
JournalFeed(Local)ServiceBaseImpl
JournalArticleImage(Local)Serv
ice
JournalArticleImage(Local)ServiceUtil JournalArticleImage(Local)ServiceImpl
extends
JournalArticleImage(Local)ServiceBaseImpl
JournalContentSearch(Local)Se
rvice
JournalContentSearch(Local)ServiceU
til
JournalContentSearch(Local)ServiceImpl
extends
JournalContentSearch(Local)ServiceBaseImpl

Asset, Tagging, and Categorization
Overview
• The Lirefay portal uses Assets to present any kind of entities, either core
entities, such as, DLFileEntry, JournalArticle, BookmarkEntry, MBMessage,
BlogsEntry, and so on, or custom entities, such as, KBArticle,
MicroblogsEntry, PMUserThread, and so on.
• Folksonomies are a user-driven approach to organizing content through
tags, cooperative classification, and communication through shared
metadata.  The portal implements folksonomies through tags. A tag may
be associated with content.
• Taxonomies are a hierarchical structure used in scientific classification
schemes.  The portal implements taxonomies as vocabulary, category,
and category hierarchy, in order to tag contents and classify them.

Asset, Tagging, and Categorization
Model & Services
Service Utility/Wrapper Implementation
AssetEntry(Local)Service AssetEntry(Local)ServiceUtil
AssetEntry(Lolcal)ServiceWrapper
AssetEntry(Local)ServiceImpl extends
AssetEntry(Local)ServiceBaseImpl
AssetLink(Local)Service AssetLink(Local)ServiceUtil
AssetLink(Local)ServiceWrapper
AssetLink(Local)ServiceImpl extends
AssetLink(Local)ServiceBaseImpl

Liferay Role-Based Access Control
RBAC Overview
• Portals are accessed by Users.
• Users can be collected into User Groups.
• Users can belong to Organizations and join/leave Communities.
• Roles are collections of permissions on portal objects that can be assigned to
Users.
• Organizations can be grouped into hierarchies. Communities are not hierarchical.
• Users, Groups, and Organizations can belong to Communities that have a
common interest.

RBAC Model

RBAC Model
• Resource: is a base object. It can be a portlet, a file, a user, a
role, a group, a page, and so on.
• User: are individuals who perform tasks within the portal.
• User Group: is loose groups of users, regardless of community
or organization membership.
• Role: is collection of permissions. Roles can be assigned to a
user, user group, community, location, or organization.
• Team: is a group of users under a community or an
organization.

RBAC Model
• Permission is an action on a resource.
– Portal-level: permissions can be assigned to the portal through roles.
– Group-level: permissions can be assigned to groups such as
organization and communities.
– Page-level: permissions can be assigned to page layouts.
– Portlet-level: permission can be assigned to different modes of
portlets such as View, Edit, or Configuration.

Liferay Portal Introduction

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Liferay Portal Introduction

Similaire à Liferay Portal Introduction (20)

Dernier

Dernier (20)

Liferay Portal Introduction