At Rivet Logic Corporation I’ve been tasked many times to expose Alfresco features through a JSR-168/286 portlet hosted in JBoss Portal or Liferay Portal. Easy right? Not really, and here’s why:

Today Alfresco provides us with a couple of ways to do this:

1. Write a portlet and use Alfresco’s Web services API to expose the Enterprise Content Management (ECMS) features
2. Use Alfresco’s out-of-the-box Web script portlet to expose an Alfresco Web script

The first approach works but in many cases requires that you develop custom Alfresco actions since the Web services API does not cover the full feature set of AFS (Alfresco Foundation Services).

The second approach provides us with more AFS coverage but has one restriction that is not easy to work with. It requires that all of Alfresco be deployed inside the portal as a portlet application. So if you needed to deploy JBoss Portal running an Alfresco Web script portlet that exposes the MySpaces Web script, the deployment would look like this:

The problem with this approach is that it introduces scalability constraints. Namely, if you need to scale the portal you are forced to scale Alfresco with it and vice versa.

For the Web services approach we have an alternative thanks to our Remote Alfresco API rivet (RAAr). With RAAr we are able to make use of Web frameworks like JBoss Seam backed by rich UI component libraries like RichFaces to develop JSR 168/286 portlets that expose most if not all of the AFS features using a Java-based API that uses RESTful communication to provide a secure and scalable interface to Alfresco. One example of a document library portlet that we created using this approach is shown below:

On the other hand, if you need to go with the Web script approach you’re pretty much out of luck unless you’re willing to go with the deployment architecture shown above. The fact that there was no single solution for this problem was all the motivation I needed to create AWPr (Alfresco Web Script Portlet rivet). With this portlet we will be able to have a better deployment architecture that could be represented by the following diagram:

Here the portal and the ECMS are in two separate tiers and can be managed or maintained as such. This not only allows for better flexibility when scaling becomes necessary, it also allows the portal to expose Web scripts that are hosted in different geographic locations.

To make this possible I leveraged a custom authentication component that we wrote called STAr (Secure Token Authentication rivet) that could be plugged into an Alfresco authentication chain. With this in place the portlet can carry the user credentials from the portal to Alfresco, authenticate the user in Alfresco and retrieve a ticket that can be used during all subsequent interactions between the end-user, the portlet and ultimately the Alfresco Web script itself.

We recently released the first public version of AWPr under the GNU Affero General Public License.

The release includes two example Web scripts that, when installed and configured correctly in your portal (e.g. Liferay Portal), will look like this:

If you would like to know more about AWPr you can visit its wiki pages at the following location: http://wiki.rivetlogic.org/display/AWPr/Home

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

As a trusted advisor to many major enterprises who are using or considering open source portals and enterprise/web content management, we see first hand how real the trend is toward open source and away from proprietary software. However, many of our clients are unwilling to discuss publicly their growing adoption of open source (for the most part, they don’t want their competitors to know).

So it’s always great to see public recognition of leading enterprise open source platforms, especially when it comes from the likes of Gartner.

As Liferay’s CEO Bryan Cheung points out, Gartner has recognized Liferay in two of its Magic Quadrants, Horizontal Portals and Social Software.

Well deserved.