Liferay Portal Systems Development: Build dynamic, content-rich, and social systems on top of Liferay with this book and ebook

Document and Media Library is a useful tool to manage any media such as basic documents, images, records, videos, and audios with built-in features, for example, dynamic data list, dynamic data mapping, dynamic document type and metadata runtime creation, authoring, versioning, imaging, check-in / check-out, archiving, access control, and indexing. In particular, multiple repositories are supported as well as CMIS. For example, in the document and media library, you can add document types and metadata sets as well as folders and subfolders to manage and publish documents. The document and media library make up the Content Management Systems (CMS) available to power both intranets and extranets. The CMS is equipped with customizable document types and folders, and acts as a web-based shared drive for all your team members, no matter where they are. As content is accessible only to those authorized by administrators, each individual file is as open or as secure as you need it to be.

Your company may have a lot of HTML text, audio, videos, images, records, and documents using different structures and templates, and you may need to manage all of these as well. Therefore, you require the ability to manage a lot of web content, and then publish that web content to intranets or Internets.

We will see how to manage and publish web content within Liferay. Liferay Journal (renamed as Web Content) not only provides the ability to publish, manage, and maintain web content and documents, but it also separates content from layout. WCM allows us to create, edit, and publish web content (formerly called Journal articles) as well as article templates for one-click changes in layout. It has built-in workflow, article versioning, search and metadata.

The portal also provides dynamic data lists (DDL) and dynamic data mapping (DDM). Through DDL and DDM, we can define web forms, document types, metadata sets, and columns of various input styles, such as free form, drop-down lists, combo boxes, date, number, text, and pre-defined list values such as lists of users, order types, inventory types, and more.

All users get a personal space that can be either made public (published as a website with a unique, friendly URL) or kept private. In fact, users can have both private and public pages at the same time. You can also customize how the space looks, what tools and applications are included, what goes into the document and media library, and who can view and access any of this content.

In addition, you can use your own language. Multilingual organizations get out-of-the-box support for up to 42 languages (such as Hindi, Hebrew, Ukrainian, and Romanian), and new languages can be added easily within the portal framework. Users can toggle between different language settings with just one click and produce/publish multilingual documents and web content. You can also easily add other languages in your public pages, private pages, or other organizations.

You can use workflows to manage definitions, instances, and tasks. There are many workflow engines such as jBPM workflow, Kaleo workflow, Activiti BPM, and Intalio | BPMS, and all of these can be integrated easily with Liferay. And then, with a workflow engine as the backend, a portal user can add workflow functionality to any activity such as CMS content approval and the like. In addition, Liferay Portal allows you to define publishing workflows that track changes to web content as well as the pages of the site in which they live.

Staging is a major feature of Liferay Portal. The staging environment allows us to make changes to the site in a specialized staging area, and then publish the whole site to Live when you are done, either locally or remotely. Scheduling is another major feature of Liferay Portal, using a built-in Quartz job scheduling engine. Before going live, you are able to schedule events to publish selected pages with all included content.

The Site snapshot feature means that branching and versioning of staged layouts are supported as well. Thus at the end of a workflow, you would be able to keep the current version of the layout as history; this is done in case the users want to use an old version of the layout at a later time.

Liferay Portal supports social network— you can easily connect your accounts in Liferay with Facebook, MySpace, Google+, Twitter, and more. Of course, you can also manage your instant messenger accounts in Liferay Portal, such as AIM, ICQ, Jabber, MSN, Skype, and YM. In addition, you are able to track social activities and social equity as well.

Social office gives us social collaboration on top of the portal a full virtual workspace that streamlines communication and builds up group cohesion. All components in social office are tied together seamlessly, getting everyone on the same page by sharing the same look-and-feel. More importantly, the dynamic activity tracking gives us a bird's-eye view of who has been doing what and when within each individual site.

The portal provides abilities to monitor portlets and portal transactions. This includes— but is not limited to— average transaction time per portlet for each phase of the portlet life cycle, minimum and maximum transaction time for each portlet transaction, average time for portal requests (inclusive of all portlets), and minimum and maximum time for each portal request. By the way, statistics are exposed using JMX MBeans.

An audit trail of user actions is required by many organizations. Fortunately, the portal provides audit service, which is a method for storing the audit trail from the portal and plugins. Then the information processed by the audit service plugin can be stored in a log file or database. Note that audit services employ Liferay Lightweight Message Bus and Plugin architecture. The audit service itself is a plugin, handling the processing and logging of the audit messages sent through the Message Bus. Therefore, any plugin can produce audit messages to the audit Message Bus destination.

The Liferay JasperReports Report Engine provides an implementation of Liferay BI using Jasper. JasperReports is an open source Java reporting tool that can write to screen, a printer, or to PDF, HTML, Microsoft Excel, RTF, ODT, CSV (Comma Separated Value) formats, and XML files. The portal provides full integration of JasperReports with its reporting framework. The portal provides the ability to schedule reports and deliver them using document and media library and e-mail. In addition, the portal supports Jasper XLS data sources in its reporting framework.

The portal tagging system allows us to tag web content, documents, message board threads, and more, as well as to dynamically publish assets by tags. Tags provide a way of organizing and aggregating content. Folksonomies are a user-driven approach to organizing content through tags, cooperative classification, and communication through shared metadata. The portal implements folksonomies through tags. Taxonomies are a hierarchical structure used in scientific classification schemes. The portal implements taxonomies as vocabularies and categories, which includes category hierarchy, in order to tag contents and classify them.

In particular, the portal provides a framework so that you can integrate external applications easily. For example, you could integrate external applications such as Alfresco, Documentum, SharePoint, OpenX, LDAP, SSO CAS, Facebook, NTLM, OpenSSO, SiteMinder, SAML 2.0, Orbeon Forms, KonaKart, PayPal, Solr, Coveo, Salesforce.com, SugarCRM, JasperForge, Drools, jBPM, and more. With the portal, integrating standalone Java web applications into the portal is not an easy task. However, Liferay makes it possible to achieve near-native integration with minimal effort using the WAI (Web Application Integrator) portlet or the IFrame portlet.

In addition, the portal uses the OSGi framework, that is, the portal supports a module system and service platform for the Java programming language that implements a complete and dynamic component model. Please refer to http://www.osgi.org for more information.

In a word, the portal offers compelling benefits to today's enterprises— reduced operational costs, improved customer satisfaction, and streamlined business processes.

Liferay Portal uses Service Oriented Architecture (SOA) design principles throughout, and provides the tools and framework to extend the SOA to other enterprise applications. Under the Liferay enterprise architecture, not only can the users access the portal from traditional and/or wireless devices, but the developers can also access it from the exposed APIs using REST, SOAP, RMI, XML-RPC, XML, JSON, Hessian, Burlap, and custom-tunnel classes.

In addition, Liferay Portal is designed to deploy portlets that adhere to the portlet API, which is compliant with both JSR-168 and JSR-286. A set of useful portlets built on top of Struts 1.2.9 are bundled with the portal, such as document and media library, calendar, message boards, blogs, wikis, and so on. They can be used as examples for adding custom portlets.

The Enterprise Service Bus (ESB)  is a central connection manager that allows applications and services to be added quickly to an enterprise infrastructure. When an application needs to be replaced, it can be easily disconnected from the bus at a single point. Liferay Portal can use either Mule or ServiceMix as the ESB.

Through the ESB, the portal can integrate with SharePoint, BPM (such as jBPM workflow engine, Intalio | BPMS engine), a rule engine (Drools), BI Xforms reporting, JCR repository, and so on. It adds another layer like JSR-170, where the repository can be abstracted. Furthermore, it supports events' system with asynchronous messaging and Lightweight Message Bus.

Liferay Portal uses Spring framework for its business and data services layers. It also uses Spring framework for its transaction management. Based on service interfaces (Spring framework), portal-implementation (portal-impl) is implemented and exposed only for internal use — for example, they are used for the extension environment or Ext plugins. Both portal-kernel and portal-service (these two packages are merged into one known as portal-service) are provided for both external and internal use — for example, they are used for the Plugins SDK environment. Custom portlets, both JSR-168 and JSR-286, and web services can be built based on portal-kernel and portal-service.

In addition, the Web 2.0 Mail portlet and Chat portlet are supported. More interestingly, scheduled staging and remote staging and publishing serve as a foundation via tunnel web for web content management and publishing.

Liferay Portal supports web services to make it easy for different applications in an enterprise to communicate with each other. Java, .NET, and proprietary applications can work together easily because its web services use XML standards. It also supports REST-style JSON web services for lightweight, maintainable code, and it also supports AJAX-based user interfaces.

Liferay Portal uses industry-standard, government-grade encryption technologies, including advanced algorithms such as DES, MD5, and RSA. Liferay was benchmarked as one of the most secure portal platforms using LogicLibrary's Logiscan suite. Liferay offers customizable single sign-on with Yale CAS, JAAS, LDAP, NTLM, Netegrity, Microsoft Exchange, Facebook, and more. Open ID, OpenAuth, Yale CAS, Facebook, Siteminder, and OpenSSO (renamed as OpenAM) integration are offered by the portal out-of-the-box.

In short, Liferay Portal uses the ESB in order to provide an abstraction layer on top of an implementation of an enterprise messaging system. It allows integration architects to exploit the value of messaging without having to write the code. As you can see, understanding the framework and architecture will be helpful if you want to customize the portal correctly.

Liferay Portal runs on existing application servers, databases, and operating systems to eliminate new expenses on infrastructure. Moreover, Liferay Portal is built based around common standards. This is a more technical benefit, however, a very useful one if you ever want to use Liferay in a more specialized way.

Liferay is developed based on standard technologies that are popular with developers and other IT experts. Liferay is standards compliant, namely, open standards for content, portlets, web services, and frontend technologies to reduce development cost. The main features are listed as follows:

Many of these standards are things that you will never need to know much about, so don't worry if you've never heard of them. Liferay is better for using them, but mostly, you won't even know they are there.

Liferay Portal allows us to run more than one portal instance on a single installation. Data used for each portal instance is maintained separately from every other portal instance. Portal data, however, can be kept either in the same database or in different databases. This is called database sharding.

This feature should be useful for Multi-tenancy, which is a principle in software architecture where a single instance of the software serves multiple client organizations (called tenants). With a multi-tenant architecture, the portal is designed to virtually partition its data and configuration and each client organization works with a customized virtual portal instance.

Let's have a brief look at multi-tenant capabilities. As shown in the previous diagram, a portal instance is implemented as a set of database tables such as Company, Account_, Shard, and VirtualHost. As you can see, portal instances are presented as different values of companyId; each portal instance has its own account information (presented as database table Account_), possible database (implemented as database table Shard_), and virtual host settings (presented as database table VirtualHost).

Traditional membership security models address two basic criteria: authentication (who can access) and authorization (what they can do):

The portal extends the security model by terminologies: resources, users, organizations, locations, user groups, communities, teams, roles, permissions, and so on. The portal provides a fine-grained, role-based permission security model (known as RBAC) - a full access control security model:

The Extension environment provides the capability to customize Liferay Portal completely. As it is an environment which extends Liferay Portal development environment, it has the name "Extension", (called "Ext"). With Ext, we could modify internal portlets which are also called by the out-of-the-box portlets. Moreover, we could override the JSP files of the portal and out-of-the-box portlets. This kind of customization is kept separate from the Liferay Portal source code. That is, the Liferay Portal source code does not have to be modified, and a clear upgrade path is available in the Ext.

Starting with version 6, Ext environment is available as a plugin called Ext plugin. As shown in the following diagram, custom code will override Liferay Portal source code in the Ext plugins only. In the deployment process, custom code is merged with Liferay Portal source code. That is, developers can override the Liferay Portal source code. Moreover, custom code and Liferay Portal source code will be constructed as a customized Liferay Portal first, and then the customized Liferay Portal will be deployed to an application server. In addition, both direct deploy (ant direct-deploy) and standard deploy (ant deploy) are available.

Hooks are a feature to catch hold of the properties and JSP files into an instance of the portal, as if we were catching them with a hook. Hook plugins are more powerful plugins that complement portlets, themes, layout templates, and web modules. A hook plugin can, but does not have to, be combined with a portlet plugin or a web plugin. For instance, the portlet called so-portlet is a portlet plugin for social office with hooks; a hook plugin can simply provide translation or override a JSP page.

In general, hooks are a very helpful tool to customize the portal without touching the code of the portal, as shown in the following diagram. In addition, you could use hooks to provide patches for portal systems or social office products.

In general, there are several kinds of hook parameters:

As you can see, JSPs hooks can set a custom-jsp-dir that will overwrite portal JSPs. You can also add<custom-jsp-global>false</custom-jsp-global> (default to true) so that JSPs hooks will not apply globally but only to the current scope. Each site (or organization) can choose to have that hook apply just for that site (or organization).

In addition, Liferay allows portal JSPs to be overloaded by theme templates this pattern will require that within the theme's templates folder, the complete path to the original JSP be maintained with the file extension replaced to match that of the theme's chosen template language.

As you can see, the Plugins SDK is a simple environment for the development of Liferay plugins, including portlets, layout templates, and webs (that is, web applications). It provides the capability to create hot-deployable hooks, themes, layout templates, portlets, and webs.

How does it work? As shown in the following diagram, the Plugins SDK provides an environment for developers to build portlets and webs. Later, it uses the Ant Target Deploy or Maven to form a WAR file and copy it to the Deploy directory. Then, Liferay Portal together with the application server will detect any WAR files in the Deploy (auto deploy, hot deploy, or sandbox deploy) folder, and automatically extract the WAR files into the application server deployment folder. Note that the portal is able to recognize the type of the plugin and enhance it appropriately before hot-deploying it. For example, for portlets it will modify web.xml by adding required listeners and filters.

During customization, you could use the Service-Builder to generate models and services in portlets and/or web plugins. In general, the Service-Builder is a code generator using an XML descriptor. For a given service.xml XML file, it will generate SQL for creating tables, Java Beans, Hibernate configuration, Spring configuration, Axis Web Service, and JSON JavaScript Interface. Of course, you can add hooks in portlets and/or webs plugins.

A theme specifies the styles of all major global portlets and content; therefore, it controls the way the portal will look. In general, a theme uses CSS, images, JavaScript, and Velocity (or FreeMarker) templates to control the whole look-and-feel of the pages generated by the portal.

As shown in the following diagram, the theme plugin can use default themes as a basis, building differences on top.

As mentioned earlier, there are at least three development environments: portal core source code, Ext plugin, and normal plugins. Thus, you may ask: Which kind of development environment is suitable for our requirements? When should we use the Ext plugin? And when should we use other plugins, or even Liferay Portal source code? Let's take a deep look at the development strategies.

As shown in the following diagram, Liferay Portal is extensible on at least three levels, for example the Plugins SDK Environment (Level I), Ext plugin (Level II), and Liferay Portal source code (Level III). As you can see, each level of extensibility offers a different compromise of flexibility with different migration requirements to future versions. Thus we need to choose the appropriate level for the requirements at hand ; one which allows for the easiest future maintainability.