KMWorld, the leading information provider serving the knowlege, document, and content management systems market, is featuring their “Top 100 Companies That Matter in Knowledge Management” list in its March 2010 issue. This year, Rivet Logic was selected again, for the second consecutive year, to be part of this prestigious list.

“The firms on this list are true solution providers that are dedicated to understanding what their customers need and delivering elegant technology for the requirements of the knowledge economy.”

We’re excited and honored that the industry is recognizing our efforts in driving successful open source software adoption. Over the past year, as we’ve continued to grow as an organization, we’ve also seen a positive response from organizations as the interest and awareness of open source software continues to increase in the arena of content management and collaboration.

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

Alfresco is running a 20-city Lunch & Learn series to review the new Enterprise 3.2 release, along with implementation best practices and solution demos.

Rivet Logic will be hosting the Washington DC, Orlando, and Boston Lunch & Learns over the next couple of weeks.

Click here to learn more and to register. We hope to see you there!

Join us in Waltham MA (Greater Boston area) and learn best practices for approaching and implementing projects with Alfresco ECM suite

• Determining your business use case
• Architectural best practices
• Development best practices
• Operational best practices

Our presentation was co-authored by Russ Danner of Rivet Logic, Jeff Potts of Optaros and Peter Monks of Alfresco

Where?
Rivet Logic Developer Forge, Boston
1050 Winter St
Waltham , MA
617.834.2781

When: 6:30 PM

Pizza, coffee and soda will be provided.

RSVP here to attend

At Rivet Logic we do quite a bit of work with the JBoss Seam framework, specifically with our Content Management System integration we call Crafter rivet.

Seam can be used with the Spring bean factory framework, a popular “IoC” or Inversion of Control / Dependency injection framework. Spring enables developers to create instances of java objects known as beans and then to wire them to other java objects. Most people working in J2EE today are familiar with this so I won’t spend any time going in to further detail here. Seam also supports the ability to use java annotations to declare a class as a bean and to specify how it should be wired through what they call out-jection and injection. Check out the Seam website for more details on how the Seam bi-jection mechanics work.

One question that has come up for me many times on consulting engagements is: “which approach to use, Spring or Seam bi-jection?” My experience shows me that the answer is not one or the other. Both approaches have significant benefits and can be used together to create a stronger approach than either one can provide on its own.

Here are some very simple guidelines

When to use Spring beans:

Infrastructure components and services are great candidates for Spring beans

• Such services are generally singletons within the system. Spring has excellent support for managing and wiring these objects
• Such service classes are often packaged in separate more commonly used libraries. Hard coding a bean name and wiring within the class definition or strongly coupling to Seam is less desireable.
• You want a very simple way to override the implementation at deployment time. Consider a scenario where you want to override a DAO. By managing the bean in Spring it is extremely easy to override the bean definition to use an alternate class and configuration in a given environment simply by placing an additional xml file in the classpath

When to use Seam annotations:

Domain specific components are good candidates for bi-jection.

• They are often fine grained application specific components.
• Explicitly stating how the component will be wired in the the class file has little impact on its re-usability because its scope is limited to the application at hand.
• Such components really benefit from one of Seams strongest features in its bean framework: Conversation Scoping. This is the ability to define a life-cycle which is shorter than a session. By limiting the lifetime of a object to its true life-cycle it’s possible to free memory up for other needs within the system. On large, high troughput applications the benefits here cannot be overstated.

By using a combined approach you get the reusability and flexibility of Spring framework with the performance orientation of conversation scoping and ease of development associated with Seam annotations.

Yesterday about 100 people crowded the halls of the Kellogg Conference Center in Washington DC as another round of Alfresco community summits got underway.

Bill Robinson (Alfresco, VP Sales) reported that 1% of the total Alfresco community / ecosystem base has been attending these meetings. The customer to vendor mix seemed to be about 50 / 50. As a member of Rivet Logic I now help to tip the scales on the vendor side. As a customer of Alfresco in my past life in publishing I can tell you that these events are really important for customers. The opportunity to network with other customers is unparalleled. If you can’t make it out to Atlanta or LA for the upcoming events, mark your calendar for next year. You can’t afford to miss these.

John Newton, Alfresco co-founder and CTO gave the keynote address and laid out the strategic and technical vision for the upcoming versions of Alfresco. As usual he did not disappoint. Alfresco will continue to attempt to disrupt the current ECM market with evolving open source business model and technical strategy and innovation. Of particular note:

• Alfresco will license the Webscript engine and Surf framework under an ASF (Apache Software Foundation) license. The repository and other core technology will remain under the GPL. Alfresco will retain ownership and continue to maintain these libraries.
• Alfresco will continue with ongoing activities in partnership with SpringSource (now a division of VMware) to integrate the Webscript engine and Surf in to Spring MVC.
• Some components of the platform, which are intended specifically for enterprise deployments, will only be available in the Enterprise edition of Alfresco.
• CMIS, an emerging content management standard continues along its approval process within the OASIS standards body, albeit at a slower pace mostly due to red tape. CMIS is to content repositories as SQL is to the database. In the late 80’s and early 90’s the adoption of SQL standards helped the relational database market gain widespread traction. SQL enabled third party vendors and development platforms more easily and cost effectively develop value. John Newton, a veteran of the SQL revolution, strongly believes that CMIS will have a similar effect in the content management space. CMIS will be a core component of the Alfresco architecture and strategy.
• Alfresco will be evolving its architecture to better support an ability to run in a cloud environment. Alfresco’s architecture has always contained key elements of cloud-ready software including its stateless service tier. Future enhancements will include functionality like repository sharding.
• The DM and WCM repositories will be consolidated. The AVM technology under the WCM repository will be retired in favor of a DM / CMIS based store which supports a similar feature set including snapshots, sandboxes, and a simplified layering scheme. This activity will lead to a, much needed single object model and a single set of core services for library functions, permissions, auditing and so on.
• Alfresco will focus on CMIS and WCM for 4.x.
  • Alfresco WCM focus will deepen its developer focus going forward with Spring and Eclipse integration.
  • Alfresco Runtime servers, currently based on AVM stores will be replaced with scalable CMIS runtimes.
  • Alfresco Share will continue to take on administrative functionality and should completely replace the Alfresco Explorer client by 4.x

I was able to get to the Records Management best practices break out session, which I found very informative. Strong RM capabilities and DOD 5015.2 certification have been a long time coming. Alfresco RM is implemented within Alfresco Share as a “Site type.” Users may be invited in to the RM space to become record managers and consumers. During the presentation we learned about current trends in RM and were treated to a demonstration of the RM application and the process of moving content through its lifecycle as a record from declaration to deposition.

Our CEO, Mike Vertal, outlined a large-scale records management solution that Rivet Logic has been working on with SAIC based on Alfresco, Liferay, and SAIC’s Teratext email archiving platform.

I gave a talk entitled Alfresco Best Practices, which I co-authored with Jeff Potts of Optaros and Peter Monks of Alfresco. The three of us are very excited to have had an opportunity to consolidate all of the practices, pointers and gotchas we’ve learned over the years. The presentation is aimed a variety of levels from Alfresco noobs to Alfresco experts and attempts to cover the lifecycle of a project from conception to deployment and operational aspects. It’s a lot of material to cover in 90 minutes. We invited listeners to tweet about their favorite best practices, practices they thought they could implement immediately and any areas we might have missed. The most active, productive tweeter in each section was awarded a much-coveted Alfresco Community Member t-shirt. We’ll be giving this talk in Atlanta, LA and at a number of the international meet ups – so bring your notepad and twitter account! For those who can’t make it to the events please watch and contribute online at: #alfrescobestpractices. All the material – including more detailed source material will be made available on line after the meet ups. We invite you to enhance and embellish the material. Also for those of you who run local community groups… this presentation is a great score. Download it and present it at your next meeting!

Last year, Rivet Logic won the 2008 JBoss Innovator of the Year Award with our Kaplan implementation utilizing Alfresco and JBoss. Can we do it again this year?

JBoss notified us earlier this month of the terrific news that we had been selected as the category winner for the 2009 JBoss Innovation Awards for Optimized Systems for an Alfresco/JBoss implementation we performed for Harvard Business Publishing. But can we repeat what we did last year and take the overall Innovator of the Year Award again? The judge of that will be left up to the voters, so place your vote for Rivet Logic!!

The winner for the 2009 Innovator of the Year Award will be announced at this year’s JBoss World held in Chicago from September 1 - 4. We will be participating, so if you find yourself there, drop by and say hi!!

Today eXo Platform, a leading European open source company, announced the merger of its eXo Portal project with JBoss Portal to create an open source portal platform.

The goal of the new project is to forge a strong portal solution by bringing together the technical strengths of the two projects through the open source community.

According to eXo Platform CEO, Benjamin Mestrallet, “What has always been a challenge for any portal community or vendor is providing the right balance of robust infrastructure and engaging usability features. This collaborative project will strive to strike that balance and will work to create an enterprise-grade, open source alternative to expensive, bloated closed source portals.”

“The eXo portal has some impressive functionality in terms of ease of use, UI flexibility and straightforward management administration; JBoss.org’s current portal project has a robust engine, performance and security features, combined this collaboration project will help drive portal capabilities forward,” said Dr. Mark Little, Sr. Director of Engineering, Middleware at Red Hat.

What does this new portal product mean for other open source portal platforms like Liferay and Plone? Should they be worried? They may want to keep an eye out as eXo is contributing a new project to the JBoss community, eXo JCR, which is a “robust cluster-ready Java Content Repository that is standards based and a key component for the project”. Could this be seen a threat to other portal platforms which lacks the robust content management features that eXo JCR will bring?

It would be interesting to see how the new JBoss eXo portal platform fares with enterprises in their choice of portal and collaboration software.

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

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;
    }
}