Monday, March 31, 2008

Alfresco content management with Liferay

At work we've been pondering a better long-term solution to our content management. A year ago we gave some thought to Liferay and in fact deployed it for one of our sites. Recently we've reconsidered our approach due to some new additional requirements accompanied with a more thoughtful perspective on leveraging internal content management with future web projects. We spent last week looking at JSR-170 alternatives/companions to Liferay, which with all due respect, only provides the implementation in their Document Library. We wanted something all-encompassing, that is, a repository where we could manage both web, print and other electronic content. Alfresco seemed to be the best option for us. After all of us spending a week with it and having various meetings trying to define the roles of stakeholders and functionality requirements, this was my conclusive perspective with enumerated priorities:

  1. Versioning
    This is easily satisfied with Alfresco and I was specifically impressed with the various ways to update content. I'm particularly pleased with the multiple capabilities of creating/updating content given the built-in CIFS server, FTP server, Office plug-ins and web interface. This wide array of interfaces should enable our users to begin versioning content with a limited learning curve (especially in terms of the shared drive notion). The WebProject versioning feature is very worthwhile in that it provides us with the ability to view/rollback content at any given time for each release, very helpful for auditing and liability. Lastly, their implementation of sandboxing is especially beneficial in concurrent development as each user can submit their work to workflow after sufficient authoring and testing.

  2. Document Management
    Alfresco was written primarily to manage documents, and given the aforementioned information on versioning, I think it's very capable for our needs.

  3. Integration
    I'm very pleased and excited about the ease of creating REST endpoints using Alfresco's WebScript framework. We won't have to write any extra functionality (read: additional JARs) to work with existing APIs but can rely on implementing custom WebScripts for exposing what we want, how we want. This is particularly useful for rapid development for any of our potential integration points, this is specificall a boon for both integration with our Rails CRM and the custom Liferay content portlet Jeff Wilson is writing.

  4. Workflow
    I think creating workflows specific to our needs will require the most work. Granted, the WCM component ships with a very basic approval workflow, we'll still need to create custom workflows once we decide how to hone our processes (and choose our deployment strategies). Depending on our needs, we may only need to define the rules in XML and forgo additional code (I believe our definitions will need to precede the investigation of additional functionality).

  5. User Experience
    Again, referencing the Versioning info above, I think this is covered. It'd be very helpful for the users to see that state/phase of workflow that a given item is in, but that appears to be a current enhancement request (per Jared).

Additional Benefits
  • Search: all meta-data (including custom aspects) is indexed, with incredible ease users will be able to find content much faster than perusing through shared drives trying to remember the location of specific files.

  • Task dashboard: users are able to see what tasks they have awaiting their action (be it approval, updates, reviews, etc.)

  • SSO options are plentiful for integrating with our ActiveDirectory: LDAP, NTLM, Kerberos

  • Simplified replication: there's already a pre-configured XML doc for repository replication

  • Space Rules: Alfresco has a great rule-engine for manipulating content based on a set of Space rules. For example, specific meta-data (via custom aspects) can be applied to certain content as defined in the rules. Space rules have an inheritance model

  • Roles are configured per Space (and thus also subject to inheritance) enabling a very flexible detailed system of privileges. Roles can be applied to users or groups of users, per Space.

  • Content transformations: Alfresco integrates with OpenOffice to provide instant content transformations(text to PDF, PowerPoint to Flash) and can be extended to provide custom transformations.

  • Send content to Alfresco via email: The next release of Alfresco will include the ability to add content to Alfresco via email attachment. This could be a very efficient way for sales people to put quotes,proposals,contracts, etc straight into Alfresco without leaving their email client.

  • Space Templates: we can setup a space and template it to create future spaces based on that template, thereby ensuring default layouts and content are appropriately propagated.

  • Alfresco deployable run-time enables us to deploy the repository to our environments w/o the overhead and deployment of the web client (a clear separation of concerns strategy that also avoids potential content tampering).

  • Stability and product maturation: Alfresco is clearly a player in the marketplace with 400+ enterprise clients and 20k deployed instances.

  • Speed: Alfresco and RedHat created a JSR-170 benchmark with Optaros validating its results in a 10 million doc test exercising repository corruption avoidance and high-concurrency usage, 0.4s response time. Updated results.

  • Search: all meta-data (including custom aspects) is indexed, with incredible ease users will be able to find content much faster than perusing through shared drives trying to remember the location of specific files.

I clearly believe that the Alfresco solution, coupled with our Liferay content-rendering portlet, is the best approach we could pursue in managing long-term corporate content. It enables all of our departments and users to create and manage content, whether print or web-related, in a variety of very intuitive and thoughtful interfaces. Furthermore, it satisfies multiple IT goals in terms of application integration, data replication, content authorization and workflow/process definition. To that end, and knowing more functional valued enhancements will be soon released, I strongly recommend it.

Been a pleasure to muck with it, looking forward to future implementation (which I hope is approved).


ONeudeck said...


we have been working with Alfresco and Liferay for a couple of years now, so I find your post very interesting.

You very clearly pointed out the benefits of Alfresco. Let me add that Alfresco (as well as Liferay) is based on "best of breed" open source technologies like Spring, Hibernate, TinyMCE and many, many more. Besides the buzzword best-of-breed, you can be sure to take benefit of standardized and well-proven technologies.

You mentioned that you think most of the work will be needed for creating the workflows. Did you know that you can use the JBoss jBPM Process Designer for accelerating workflow design? Maybe you want to try it...

Greetings from Nuremberg ;-)

Oliver Neudeck
Ancud IT

RLM fan said...

The main problem is the limited integration between Liferay and Alfesco. You have to develop all the portlets yourself and you get two different administration environments. I did not find a good integration in the user list between the two systems, via LDAP or other. You have two different users list and need to maintain them synchronized at all times in their permissions, etc. Liferay groups, organizations, communities, etc can only map to Alfresco Groups, and semantically they are not exactly the same. Liferay should have the doc library, journal content and image gallery equivalents working against Alfresco or any other JCR 170 implementation, as well as the blog, wiki and all user content. Currently you have to reimplement all that, losing a large part of Liferay. Unfortunately I see Alfresco moving toward implementing their own portal rather than integrating better with JSR 168 portals...

RR said...

@rlm fan:

I agree that you lose a fair amount of included functionality from Liferay when you completely supplant the content drawing it all from Alfresco. That being said, we've decided to not use the document library or image gallery at all. The custom portlet that we're writing will allow browsing the Alfresco repository and intelligently render (based on mime-type) the selected content.

As for the user integration, we expect to have a limited approach. That is, the content repository will be role-less in terms of what is accessible from within Liferay. All page development will occur in a staged environment and we'll push the content and pages to production after the testing and approval. Thus rendered content, all being piped from Alfresco, will be subject to Liferay's rules. This way we can take advantage of the user and role management in Liferay,(none of which will be able to author in the production instance) and not have to worry about authoring roles and that type of specific integration with Alfresco.

Again, this is all specific to our setup and we expect it to work as we theorize. We almost have our custom portlet completed and we're beginning work on the rest of the environment and business rules for deploying content.

RLM fan said...

We wanted to use the CIFS feature of Alfresco so users can update or get docs easily via a network share, but this required that users in AF be kept in synch with LR. We implemented scripts and API calls from LR to AF to keep the lists in synch, putting calls at different events in LR.

If a user is removed/changed in LR, the same will happen in AF. If you are interested in exchanging code or other experiences, feel free to contact me at mrc [at], please!


RR said...

@rlm fan:
We expect to employ a similar approach, thanks for your useful information. I'll pass this on to my colleagues and see where it goes from there.