I’ve been meaning to discuss a topic that’s always been near and dear to my heart for quite some time, but as is wont to happen, things sometimes get in the way. What I’m referring to is the topic of “Alfresco and Portals”.
There is a natural “synergy” between a CMS such as Alfresco and a JSR-168 portal such as those offered by Liferay and JBoss. Alfresco’s repository makes it easy for content contributors to author and store content while a portal offers a powerful framework for displaying said content for consumption by end-users.
Should I use a portal?
To begin with, I must state that it is my opinion that a majority of projects where a portal is being considered don’t actually require a full portal solution. Portals offer many powerful features including drag-and-drop page assembly, a fine-grained security model and user administration but they also introduce a great deal of overhead.
Many portal frameworks are rather hefty web applications weighing in at more than 40MB (compressed) and the very features that makes them appealing often have a detrimental effect on performance and memory footprints. Additionally that there are use cases where the security and personalization requirements of a given project simply don’t have a 1-to-1 mapping with the capabilities of a portal.
My first bit of advice is therefore thus:
Before considering a portal, make sure you understand the requirements and consider building your website/application with more basic frameworks be they Struts, Wicket, Rails, PHP, .NET, Alfresco Surf or any of the countless frameworks available. I think you’ll find that it’s sometimes easier to build from scratch than to try to re-mold a die that’s already been cast.
Now, let’s get on with the discussion…
A Short History of Alfresco and Portals
Since the early days, Alfresco has been deployable in its entirety as a JSR-168 compliant portlet to portals. The problem with this approach is that Alfresco makes for a very large portlet. As of version 3.0, the Alfresco WAR file takes up about 30MB and running it as a portlet meant that the entire UI would exist within the (very tight) screen “real estate” that’s usually afforded to a portlet. This UI limitation was somewhat addressed when we developed a wrapper for Web Scripts thereby permitting certain Alfresco Web Scripts, such as the Document Library, to be exposed as “standalone” portlets. In my eyes, this technique did not address one core issue:
The CMS Repository should be a separately installed component that’s independent of the presentation layer be that a portal or some other website or application. The memory and processor requirements alone justify this separation but more importantly, the repository should be viewed and treated as a “content-oriented database”.
A question naturally arises upon reading such a comment…
How do I integrate Alfresco and a portal?
Assuming that there’s agreement that, like a database, the content repository should be managed as a separate server/service, then the only real way to integrate Alfresco and the portal is by developing pure JSR-168 portlets that, in some cases, replicate functionality that already exists within Alfresco. This may sound like we’re re-inventing the wheel, but it is a necessary evil.
In order to meet the UI and system resource restrictions imposed by the portlet model, one must identify the most desirable features and develop one or more portlets that expose this functionality in a way that more “naturally” fits the portal/portlet model. Fortunately, Alfresco 3.0 introduces a collection of services and new development paradigms that simplify this process.
A few weeks ago, I wrote a wiki article outlining a few ways by which portlets can be developed. I invite you to take a look, but in short, what a developer needs to do is leverage Alfresco’s Remote API.
Alfresco’s Remote API
Alfresco’s new CMIS and Repository REST APIs are the cornerstone for developing a whole new breed of content-aware applications and portlets. These offer the ability to remotely invoke all types of content actions such as queries, content creation, tagging and much more. These services are easily called through simple HTTP calls which means that pure JSR-168/283 portlets can be easily developed to expose whatever functionality is required.
Alfresco Share is a prime example of an application that uses these very same remote services. Steve Reiner’s “FlexSpaces” is another example. In short, there’s absolutely no reason why portlets couldn’t be developed to do the same. I believe the main reason why it hasn’t happened yet is because many developers don’t know where to begin, which leads me to make an open call for portlets.
An Open Call for Portlets
At this time, Alfresco does not have the time and resources to develop portlets. This means that the community of developers, independent contractors and system integrators have a unique opportunity to develop a new suite of portlets or other components that work with Alfresco.
Portlet development has a rather low barrier to entry in that a simple portlet might only need to expose very discreet functionality thereby making them relatively quick to develop. Also, should the contributor wish to make the source code available, anyone in the Alfresco community could customize and extend these portlets.
I should note that the Alfresco Network will soon offer a directory where these components can be made freely available or sold as the developer desires.
There’s a green field here for developers to explore and I strongly urge you to take advantage of this opportunity.
Please let me know if you build something so we can feature it on Tech Talk Live.
Addendum - Added on Jan. 21, 2009
It’s occurred to me that I forgot to mention a few things:
First, I still hold to my opinions of JSR-168/283.
Second, for those who are not Java developers or are not interested in developing pure JSR-168 portlets, I should note that the Alfresco Web Script container is deployable as a fairly lightweight, standalone portlet. This means that one can develop portlets in JavaScript and Freemarker instead of compiled Java code.
January 21st, 2009 | Category: Uncategorized | Comments (1)
