Month: July 2010

Rivet Logic Participates in New Alfresco Community Committer Program

Posted by on July 15, 2010

Alfresco recently launched the Alfresco Community Committer Program (ACCP), which is designed to promote and encourage open source contributions to the Alfresco platform through a structured process.

Software contributions accepted into ACCP will include any and all software extensions, language packs, plug-ins, and integrations, which enhance Alfresco’s core capabilities, meet a specified set of standards and attain voting approval by the ACCP Committee.

While there has always been developer contributions to the Alfresco platform, the ACCP now presents a better way to organize the contributions that will ultimately benefit all Alfresco Community and Enterprise users.

To show our continued commitment towards open source and Alfresco, Mike Vertal and Russ Danner from Rivet Logic are both on the ACCP founding committee. We’re excited to see this new program start and how the extensions contributed by the community can further enhance the Alfresco platform and benefit the overall community.

For more information on the ACCP, please visit: http://wiki.alfresco.com/wiki/Accp

Liferay & Alfresco DM Integration Options

Posted by on July 08, 2010

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 Will Abson’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.

Rivet Logic Partners with Lucid Imagination

Posted by on July 06, 2010

Last week, Rivet Logic officially announced its newly formed partnership with Lucid Imagination, the commercial company dedicated to Apache Lucene/Solr open source technology. This is an exciting partnership for us since we’ve already been working with Lucene/Solr technologies for quite a while and have implemented it in various Alfresco and Liferay projects.

It’s exciting to see how much the Lucene/Solr community has grown over the years and the adoption of its technologies into major enterprises worldwide. Lucene/Solr is now being used to power major sites like whitehouse.gov, LinkedIn, Netflix, and Monster.

This partnership reflects our commitment to partner with leading vendors in the open source community to design and implement enterprise-grade open source solutions, provide responsive consulting support, and advance the use of open source software through innovation and community leadership.