One of my favorite new features of Alfresco 3.2 is the concept of subsystems. Alfresco defines a subsystem as:

A configurable module responsible for a sub-part of Alfresco functionality. Typically, a subsystem wraps an optional functional area such as IMAP binding, or one with several alternative implementations, such as authentication.

In essence it’s like having mini child servers, each with its own Spring application context which makes configurability a lot more intuitive.

My first encounter with Alfresco’s subsystems was due to an AWPr jira issue that someone raised saying that STAr doesn’t work with Alfresco 3.2 because they “changed” the way authentication components are chained. To be honest my first reaction was “Oh no! More re-factoring!”. But then when I looked into how the Authentication Subsystem works it was clear that this new direction is better and allows for easier extensibility.

Remember how painful it was to chaining multiple LDAPs? Now it’s as simple as adding the following to your global properties file:

authentication.chain=ldap1:ldap,ldap2:ldap

then you create the following file/folder structure:

$TOMCAT_HOME/shared/classes/alfresco/extension/subsystems/
Authentication/ldap/ldap1/ldap-authentication.properties

and

$TOMCAT_HOME/shared/classes/alfresco/extension/subsystems/
Authentication/ldap/ldap2/ldap-authentication.properties

So what about custom authentication components like STAr? Piece of cake. All that needs to be done is create the following file/folder structure:

$TOMCAT_HOME/shared/classes/alfresco/extension/subsystems/
Authentication/star/star-authentication-context.xml

star-authentication-context.xml would basically contain the definition of the authentication component and authentication service with very minor differences from what it looked like in Alfresco 3.1. I documented the exact syntax on STAr’s wiki page.

The final step would be to modify alfresco-global.properties to add STAr to the authentication chain like so:

authentication.chain=alfrescoNtlm1:alfrescoNtlm,star1:star

It seems though that Alfresco 3.2r2 has a bug where it doesn’t pick up authentication subsystem entries from the extension folder on the shared classpath. So I had to release a new version of STAr (1.2.0) where the -context.xml file is in the STAr AMP and ultimately ends up inside alfresco.war. When Alfresco fixes this bug then STAr 1.1.0 will be sufficient.

To learn more about Alfresco’s subsystems and how to configure authentication components visit the following links:

http://wiki.alfresco.com/wiki/Alfresco_Subsystems
http://wiki.alfresco.com/wiki/Alfresco_Authentication_Subsystems

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

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.

Recently I needed one of my JSF portlets running in JBoss Portal to know some information about itself.  The information I needed was:

• Window name
• Page name
• Portal name

Surprisingly it was not easy to figure out how to do this. Not because it’s not feasible, it’s just that the information was simply not there for the common developer to find (forums, Google, etc.).  So I thought it would be worthwhile to share my findings.

This is what you need to do:

// Get render request object that contains needed info
JBossRenderRequest req =
    (JBossRenderRequest) FacesContext.getCurrentInstance()
        .getExternalContext().getRequest();

// Extract window name for this portlet
String windowName = req.getPortalNode().getName();

// Extract page name for this window
String pageName = req.getPortalNode().getParent().getName();

// Extract portal name
String portalName = null;
PortalNode portalNode = req.getPortalNode();
PortalNode rootNode = req.getPortalNode().getRoot();
while (true) {
    portalNode = portalNode.getParent();
    if (!rootNode.equals(portalNode)) {
        portalName = portalNode.getName();
    } else {
        break;
    }
}

Since Alfresco was first released in 2005, I have led a number of projects that required some sort of custom user interface on top of the Alfresco repository.  In a few cases, we customized Alfresco’s standard web client.  For others, we built custom interfaces that were stand-alone web applications or were exposed via portlets within a portal framework like Liferay or JBoss Portal.

In most cases, we needed a user interface that was not embedded within the repository, but rather was hosted remotely as a standalone web application.  To do this, the main choices for the web application to communicate remotely with Alfresco are the following mechanisms:

• Alfresco Surf and Web Scripts
  
• Alfresco web services
• Rivet Logic’s Remote Alfresco API rivet (aka RAAr)

Each one of these approaches has its pros and cons and the choice is highly influenced by the client’s needs.

Alfresco’s Surf platform provides a powerful framework that enables developers to leverage most if not all of the repository’s features using a RESTful approach using their Web Script runtime engine. It also allows for the web tier to be remote to the Alfresco repository.  Surf is a very good option for projects that have a Javascript-centric web tier, using frameworks such as ExtJS.  We have successfully built and deployed several Web Script-based UIs for customers, including one of the very first public sites to leverage Web Scripts found at http://highschool.ccsso.org.  In its most recent v3.0 release, Alfresco provides a UI platform for aggregating Surf dashlets to create fully functional web clients.  This platform is known as Alfresco Share.

However, we also have customers who want a Java-based UI solution too.  Alfresco’s original web client UI is a JSF/Spring based application that is customizable in many ways and is the only available alternative in this case (short of building your own web client).  It is built using a large number of custom JSF components that are very nice as long as your target UI is expected to behave similarly to Alfresco’s web client.  If you were asked to change the way one or more of these components work things start to get a little hairy especially when you realize how much work is required to make it do exactly what was needed.  There was an apparent need for developing a Java-based UI platform that shared some of the Share features.

So we set out to fill this void: To create an open source, Java-based UI platform for Alfresco.

We turned to JSF for the view framework, as it is the predominant standard in the Java community.  One of the challenges of JSF component development has always been ease of customization, or the lack of it.  Even though the JSF spec allows for extending UI components, it is still not trivial to make your components very flexible.  And what typically happens in those situations is that smart people decide to put in a lot of work into getting rid of the problem.  That’s where the JSF component suites come in. There are a lot of them out there.  Some open source, some not. Naturally I’m only interested in the open source ones.

When working with JSF components suites like JBoss RichFaces you gain a lot of leverage when you incorporate a framework that makes dealing with the JSF lifecycle both intuitive and easy.  If you guessed that I was talking about JBoss Seam, you’re right.

Projects that are more Java-centric and make use of web frameworks such as JSF would find that a remote Java API that provides access to the Alfresco Foundation Services (AFS) is necessary.  In this case, our own Remote Alfresco API rivet is ideal.  It is both scalable and fits within the JEE tiered approach quite nicely.

For these reasons, the technology stack we used for building our Java-based Alfresco web client is comprised of JBoss Seam, RichFaces/Facelets, and RAAr.

So here was the perfect opportunity to bring all this technology together and provide the Alfresco community with an example of a new way for developing Web 2.0 rich web clients for the Alfresco repository.  We decided that the web client had to be rich (AJAX is key here and RichFaces among other JSF component suites makes it possible), remote from the Alfresco repository, and modular so that it could be reused in other projects in the future.  And while we were at it, it needed to be easy for new developers to contribute to.

We gave the web client a name that explains what it really is; Seam Client for Alfresco rivet — SCAr.  (As an aside, because we incorporate RichFaces we also considered calling it ScarFaces :^)

From a high level, SCAr makes use of RAAr to utilize a complete suite of services that fully expose Alfresco ECM’s core services at the back-end, and a number of out of the box JBoss RichFaces AJAX enabled UI components at the front-end tied together using JBoss Seam to provide a single page multi-user interface to Alfresco ECM’s document management system.  The following diagram shows a high-level overview of SCAr.  The power of this architecture is in its inherent simplicity without sacrificing flexibility.

The internal architecture of SCAr is broken down into a number of RichFaces components each exposing one or more of Alfresco’s document management features.  Each RichFaces component is backed by a Seam action class (POJO), where each Seam listener has access to a RAAr abstraction layer providing it with an easy to use domain specific API into Alfresco ECM. By making use of Seam observers each user action triggers one or more events at the back-end allowing one UI component to manipulate the state of the other components on the screen as needed.

The following is a screenshot of what SCAr looks like to a typical end user:

This development framework makes enabling new features and customizing the behavior of existing ones straightforward.

A demo site running SCAr can be accessed at http://scar.rivetlogic.com.

If you want to know more about SCAr you can visit its wiki pages here: http://wiki.rivetlogic.org/display/SCAr/