Liferay 61   liferay architecture By Navin Agarwal
Upcoming SlideShare
Loading in...5
×
 

Liferay 61 liferay architecture By Navin Agarwal

on

  • 5,486 views

This Presentation was shown by Navin Agarwal.

This Presentation was shown by Navin Agarwal.

Statistics

Views

Total Views
5,486
Views on SlideShare
5,482
Embed Views
4

Actions

Likes
10
Downloads
299
Comments
0

1 Embed 4

http://localhost 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Liferay 61   liferay architecture By Navin Agarwal Liferay 61 liferay architecture By Navin Agarwal Presentation Transcript

  • 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.
  • 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,andTunneling 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:  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