“Liferay Enterprise Portal.”  Sure, Liferay packs all the features that make it a strong “Portal.”  In partnership with Sun, Liferay has a large and experienced team behind their portal capabilities including their implementation of the latest JSR-286 portlet specification / industry standard.

The JSR-286, for its part expands the existing portlet specification in meaningful ways:

• Portlet filters
• Portlet Event support
• Public Render Parameters
• Resource serving

With the strength of its support for the portlet specification one might be tempted to think of Liferay as “just another portal.”  That classification would be misguided. 

Liferay is a platform and a framework for developing collaborative and social applications and services.  Portal is just the mechanism for aggregating and distributing these capabilities.

At the heart of Liferay is a service oriented architecture. Liferay ships with a host of out-of-the-box services for creating collaborative applications.  To cite a few (but not all) examples:

• Profile Service
• Search Services
• Group Services
• Calendar Service
• Friend Services
• Activity Services
• Forum Services
• Blog Services
• Rating Services
• Tagging Services

If the out of the box services do not provide the functionality coverage you’re application requires or you need to create your own domain specific or composite services; Liferay provides a capability called Service Builder.  Service builder makes it very easy to create services.  With the modification of a simple XML file and the execution of a code generation script you can quickly create all the basic plumbing for your services.  If you need persistence, all the Hibernate work is created for you.  If your service needs to be remoted through interfaces like SOAP, all that plumbing can be generated for that as well.  The only code you need to write is the code that is custom to your service.  All the machinery is quickly taken care of by Liferay; the framework.

Liferay makes use of Hibernate to handle data persistence.  Service builder does all the work of configuring and coding against Hibernate for you making this somewhat transparent to you.  There is real world value here. You deal directly with your model not low level JDBC code.  You can configure read / write separation (a special thanks to a community contribution for this. – community matters) and your application is immediately enabled for several mainstream / popular relational databases.

In addition to a rich services framework, Liferay also enables application developers with powerful eventing and lifecycle capabilities called Hooks.  Applications can register to receive and act upon portal and portlet start up and shutdown events, user activities, persistence level CRUD (create, read, update, delete) events, CMS activities and many other out of the box events.  It’s also possible for applications to register and fire their own events for consumption by sibling applications.

To support your presentation tier Liferay has developed a host of tag libraries that work in concert with standard tag libraries.  This makes it very easy to create standards based, lightweight presentations on top of your application and services code.  In addition to server side libraries, Liferay is designed to work extremely well with JQuery, a leading JavaScript / AJAX library for rich application UIs.  The Liferay team even hired a JQuery committer in order to drive home the integration and to help emphasize the importance of strong user experience and quality of UI within the platform.

Is Liferay a Portal?  Yes of course it is.  Liferay has a strong implementation of the industry standards and is the most popular open source JSR-286 portal in the space today. However Liferay is much, much more.  If you need to build a collaborative or social application: Liferay takes care of all the boilerplate coding and provides the fundamental capabilities out-of-the-box allowing you to focus your time, attention and money on your business problem. 

If you’re a web application developer you know that today’s market demands that web applications make use of Web 2.0 features and a rich user experience on the web is becoming more and more the “expectation” rather than a nice-to-have.  The applications I’ve design recently adopt some powerful development frameworks like JBoss Seam and rich JSF component suites like RichFaces and ICEFaces and the results have been quite good.  So what about portals?  Do the same expectations exist?  The answer is yes, and the question on many portlet developers’ minds is; “can I build rich Web 2.0 portlets, and if so, what are the tools at my disposal?”

Well, we know that for quite some time now we have been able to build portlets that are AJAXable (if that is really a word) using RichFaces, ICEFaces and other JSF component suites.  What didn’t use to be doable (not easily anyway) was to have those rich portlets communicate with one another in a standard way that is portal agnostic.  Some might say “who cares?” or “why would you want them to communicate in the first place?”

Imagine this; what if you had a series of rich Web 2.0 portlets that are nothing more than wrappers of one or more rich UI components that did something and did it quite well.  For example, let’s say I decided to build a CMS client using a data table to display contents of a folder, a tree sructure to represent an Explorer like view of folders, and a preview panel to preview the selected document.  Let’s say that I also wanted to build a search capability within this client.  I can do all this in a web app.  I can also do all this in a portlet.  But wouldn’t it be nice (and powerful) if I was able to break each one of these UI components into different portlets that communicate with one another?  Wouldn’t it be even nicer if each one of those portlets was a standalone portlet with a published interface describing how to make it do things?  Let’s say you see the potential in this approach to building portlets, how can it be done?

JSR 286 defines how portlets should communicate, and Liferay portal is one of the leading open source portals that support JSR 286.  For the sake of the point I’m trying to make in this post I’ll just mention that JSR 286 allows portlets to communicate using events that are triggered and consumed during the portlet lifecycle.  So if I had a data table portlet that listened on a predefined event and expected certain arguments to tell it what to do, I can build it to be independant of who is using it. Just give it a list and it will display it.  Using the same approach I can have a tree and a preview panel.  Now here’s the kicker; I could then use another instance of the same data table portlet to display search results in another portal page or even on the same page.  Now your portlets are highly reusable.

A visual representation could look something like this:

In this case My Folders is one portlet and Folder Contents is another.  The same Folder Contents portlet could be used to show search results.  This (I believe) is a powerful concept that can be used in a variety of creative and intuitive ways to provide a new breed of reusable portlets that are - in IoC terms - unaware of what they will be used for.