The topic of Liferay and Alfresco integration continues to be popular among portal developers and what we’ve seen is that in the last year both products have matured in important ways to enable better integration. This evolution also opens the door for more possibilities. And as we all know, with more options there is more confusion. From my readings on the Liferay and Alfresco forums I observe that there are two main issues that puzzle people when they’re thinking about integrating Liferay and Alfresco:
What are the different possible ways for me to integrate the two products?
Which approach should I use?

To help answer these questions I thought it might be useful to list what the current options for integration are as well as a brief description of the architectural implications of each.

Note that the type of integration I’m referring to here is between Liferay Portal and Alfresco’s Document Management (DM) repository, and not the Web Content Management (WCM) repository.

Option #1: Using the Web script Container
With this approach you would basically deploy Alfresco’s Web script container into Liferay as a portlet application. Your Web scripts would be deployed along with the container and will be fully executed within the Liferay Portal context. What’s new here is that authentication between the Web scripts running in the container and the Alfresco repository will be taken care of automatically. This is nice since it alleviates the need to deploy the entire Alfresco WAR file into the portal as was the case with Alfresco versions prior to 3.2.

That said you should keep in mind that (for now) to accomplish this you would need to deploy the Alfresco Share WAR file in its entirety into the Liferay portal. It should be mentioned though that according to Luis Sala’s blog post about the subject this is expected to change with the reduction of the needed WAR file’s footprint. Also, the portlet still needs some work to make it configurable from the Liferay Portal UI using portlet preferences — but I gather that this will be implemented eventually as well.

Option #2: Alfresco Web script Portlet rivet
Another option is Rivet Logic’s Alfresco Web script Portlet rivet (AWPr). This portlet is pretty much an Alfresco Web script proxy. With the help of a custom Alfresco authentication component known as STAr (Secure Token Authentication rivet), an AWPr portlet instance will use a series of Java HTTP Client calls to RESTfully and securely retrieve the rendered contents of a single Web script, proxy the contents so that all URLs are valid portal URLs (e.g. action URLs, serve resource URLs for downloads, etc.), and render the updated content in the portlet’s render phase.

AWPr has a very small footprint and thus can safely be used heavily on one Liferay portal page; meaning that a single portal page can have multiple instances of AWPr each configured to proxy a different Web script without much performance impact on the Liferay instance. Keep in mind that it is a proxy so the content is being transferred from Alfresco to Liferay and then from Liferay to the client browser, which might have some cost implications if bandwidth is not cheap and the Web script generated markup is large.

Options #3: Custom Portlet Development
For those of us who need to build their own custom portlets and need to have access to the Alfresco DM repository APIs from within their portlet code in order to perform certain ECMS functionality, there are a number of options.

CMIS
Recently, Alfresco, IBM, Microsoft, Documentum and others announced the submission of a new content management standard proposal called “CMIS” or “Content Management Interoperability Service” and on May 1st, 2010, the OASIS standards body approved CMIS v1.0 as an official OASIS Specification.

Alfresco has released a full implementation of CMIS v1.0, which includes support for both RESTful AtomPub and Web Services bindings. This basically allows Liferay portlet developers to use either one of those interfaces to communicate directly with the Alfresco repository (and any other content management system that supports the CMIS specification). More details on Alfresco’s CMIS support may be found at: http://wiki.alfresco.com/wiki/CMIS

RAAr
Another recently available option is presented by Rivet Logic’s Remote Alfresco API rivet (also referred to as RAAr). This API is a Java API that uses REST calls to communicate with a remote Alfresco repository. The advantage of this approach is that it provides all the pros of Alfresco’s Web services API but does not carry the burden of the SOAP stack — thus making it an attractive option for Java portlet developers.

RAAr is open source and is currently maintained by Rivet Logic Corporation. It provides most (if not all) of the Alfresco Foundation Service methods and can basically be used to do anything that the Alfresco web client can do.

More information about RAAr can be found at: http://wiki.rivetlogic.com/display/RAAr

Custom API
Even though it doesn’t really make much sense to do this I’m including this option just to be thorough. The idea here is that if you want to develop against Alfresoc’s REST API but want to abstract it using your own API you can do so. The problem with this approach is that depending on the problem you’re trying to solve you’ll eventually end up writing a CMIS API if you want to be platform independent (mostly) or RAAr if you want to access Alfresco’s service layer APIs remotely. So unless you have a legitimate reason to go down this road it’s most probably going to be better for you in the long run to stick with CMIS or RAAr.

This pretty much covers the options available for integrating Liferay with Alfresco’s DM repository. To know which options suites you best, you should weigh the features and drawbacks of each until you find a good fit, and with enough projects, making the right choice will start to become more obvious.

We recently released a new case study, Team Beachbody: A Large-Scale Social Community Platform Built on the Open Source Liferay Portal, which highlights how Rivet Logic utilized Liferay Portal to build a revenue-generating social network for Product Partners and the business benefits derived from the solution.

Product Partners, LLC, an exercise and nutrition market leader, launched the Team Beachbody program as a membership-based online support community that offers a wide array of fitness programs. In order to generate revenue growth, Product Partners decided to harness the existing community around its products and combine it with the power of social networking to turn the site into a revenue generating resource. By offering active community members a percentage of sales of Beachbody products that they refer to new members, it encourages increased community participation.

Liferay Portal was selected as the development platform for its flexibility and scalability to cater to evolving business requirements and future growth, as well as its low total cost of ownership. Rivet Logic was chosen as the system integrator to implement the solution, and in particular, the WOWY SuperGym application, a featured element of the overall Team Beachbody experience. The WOWY SuperGym application has resulted in stronger customer loyalty and recurring revenue opportunities through a set of social collaboration features that encourage use and membership retention.

Click here to download the full case study.

This year, BIZcon Europe 2010, hosted by Ricston, will be held in Malta on March 4th and 5th. BIZcon is all about informing business leaders about significant trends and developments in business, and interestingly, the theme this year will be “Understanding and Leveraging Open Source”.

While many business executives are familiar with the term open source, not many have a clear understanding of how open source can be used and integrated into their organization’s environment, and more importantly, the value that can be gained compared to traditional proprietary solutions. As open source continues to gain traction, it’s important to keep business executives informed so that open source can be effectively incorporated into their strategy and leveraged to deliver bottom line results.

The agenda includes presentations from various business executives and leaders in open source, including Liferay CEO Bryan Cheung.

Alfresco just selected Rivet Logic as the winner of their Americas Partner of the Quarter Award.

Alfresco Partner of the Quarter, Q2 2009 - Rivet Logic

We’re truly honored to be recognized again by Alfresco for our accomplishments. Over the past year, we’ve continued to see strong demand for our Alfresco consulting services as more and more organizations are becoming more liberal towards the idea of open source. Last quarter, we kicked off several new Alfresco projects in a variety of sectors - including higher ed, media/publishing, technology and non-profit.

We look forward to continuing our work with major enterprises, and contributing back to the Alfresco community.

Last week was Red Hat Summit and JBoss World. We participated as a sponsor of JBoss World and also gave a few presentations during the breakout sessions. Below are some highlights from our trip:

JBoss World at the downtown Chicago Hilton:

 

Our booth at the partner pavilion:

 

Museum of Science & Industry party:

 

Closing ceremony:

 

Although we didn’t walk away with the overall JBoss Innovator of the Year Award, we still have our category award for Optimized Systems to display in our trophy case….

Until next year!!

This year, Rivet Logic will be hosting Liferay’s first ever East Coast User Conference, taking place on 5/21, at our training facilities in Reston, VA. It would be an opportunity to meet some of the faces behind Liferay in person while discussing the product’s future as well as best practices.

The agenda includes keynote speakers and both technical and business tracks to cover a variety of topics. Technical tracks include “Liferay Solutions, SaaS Style” and “Social Networking with Liferay, ICEfaces, and Vizster”, while business tracks include “Enterprise Collaboration: Overcoming Issues with Big Implementations” and “Fostering Open Source Adoption Within Reluctant Enterprises”.

We are pleased to host this event and look forward to further involvement with future Liferay events.

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

We just published a new case study on one of our projects in the public education sector. The Council of Chief State School Officers (CCSSO) does great work for advancing public education goals at the US Federal and State levels, and open source portals and content management from Liferay and Alfresco help them collaborate, find, and share critical information in support of many of their projects.

Learn more from our new Case Study: CCSSO Increases Project Efficiency Through Open Source Content Management and Collaboration.