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

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