Rivet Logic Blogs

Web CMS on The Alfresco Core Repository (Part 1 of 2)

I was on a call today with a long time Alfresco WCM customer who would like to upgrade from 3.x to 4.x. They have been using the Alfresco WCM solution provided by Alfresco in 2006 for many years. As many of you know Alfresco’s original WCM solution is based on a technology called the AVM – Alternative Versioning Model. The AVM is a separate repository and associated user interface that was constructed to handle a number of WCM related use cases. Alfresco has since enhanced their offering in their “Document Management” repository, which now handles WCM use cases. As a result, Alfresco has now announced that the AVM will no longer be offered to new customers. In discussing the upgrade with our clients on the call today. “It’s time to move to the ‘DM’” was the most responsible message to provide. Existing customers won’t lose support over night, but eventually the AVM will hit its end of life. You want to migrate at your earliest convenience rather than procrastinating and allowing pressure to build.

It’s also important at this point to abandon the use of the term “DM repository”. DM was used to differentiate from the AVM. At this point there is only one repository. The “core repository” is much more descriptive of the architecture going forward. As Jeff points out in his blog and as I will elaborate here, there are differences in the the AVM and the core repository in terms of features. That said, features and use cases should not be confused. The core repository is every bit as capable of providing a platform for Web content management use cases as the AVM.

At Rivet Logic we have made a significant investment in a Web content and experience management application for Alfresco that we call Crafter Rivet. Crafter Rivet is a 100% open source, full featured environment that powers 100s of websites and has over 40 man years of development effort invested in it. Initially Crafter Rivet’s authoring and management capability was based on the AVM. When Alfresco made the decision to direct the full force of its innovation on the core repository we knew it was time to convert. Crafter Rivet 2.0 is now based on the core repository, Solr search and Activiti workflow for Alfresco 4 CE and EE. Making the switch from the AVM to the core repository required a deep examination of our use cases and the features we would have on hand within the core repository.

I thought it would be helpful to share some of that thinking. Today we’ll look at the differences in these repositories and tomorrow, in a second post we’ll discuss the actual Web CMS use cases that need to be addressed and how we addressed them in Crafter Rivet. Let’s explore!

Unique Features of the AVM

The first thing I want to do is address the question of what the AVM can do that the core repository cannot. Because we’re comparing repository to repository we’re going to discuss features and not use cases. Note that for simplicity, on occasion we’ll collapse the features of the AVM repository, supporting UI and supporting integration into the single term AVM. It’s also fair to note that what we’ll discuss here are the aspects of the AVM which exposed through the associated user interface and thus applicable to customer engagements. There are features/capabilities of the AVM repository that were not fully exposed by the UI.

Sandboxing (more accurately, layering)

Sandboxing is the ability for a user to work on any asset or group of assets within the site without interfering with another user’s work. For example, a user could modify and even break a template or CSS file and no one would know until and unless the user promoted that broken asset out of their work area. For non-technical readers, a sandbox is best described as your own copy of the website. For the technical readers, you can think of a sandbox as a long running transaction — in source control terminology, a sandbox is like a checked out branch of the site.

Sandboxing is a high order feature born out a lower level feature called “layering.” The AVM is constructed of lightweight stores. Stores can be layered one on top of the other. The store on the top appears as though it contains the assets within the store layered below it. If a user places an changed in the top store it appears to over-write the asset at the same path below it. If we have a base store we’ll call “the stage area” and then a store for each user; say Bob and Alice, and both Bob and Alice’s stores are layered on top of the staging area you can see how we create the concept of sandbox. Alice can see everything in the staging area, but nothing in Bob’s store. Alice’s work is in a “sandbox.” If Alice pushes her change from her store to the staging area, Bob sees it immediately as if it were in his store.

Multi-Asset Versioning

In the AVM, versions are taken at the store level not per asset. When you place a change in the store, a lightweight version is created for all assets at that moment. Because of this, it is possible to know the state of every object at a point in time relative to a given object. For Web CMS applications, we deal with compound assets all the time. Consider a webpage. A webpage is not typically a single file asset, it’s a document that points to other documents: components, images, css, javascript, etc. When you version a page, you generally intend that entire collection of assets to be versioned along with the page.

The core repository manages each individual asset’s version history independently. If page X points to component Y there is no innate support within the version system to know what version of Y was in use at any given point of X’s history.

Snapshots / Comparison and Rollback

In the AVM you can label a version and compare one version to another. It is easy to see what files have changed. Because of this it is possible to create “diffs” from one version to another. Once you have a diff you can roll back entire check-ins very easily.

Content Forms (Now supported in core)

The AVM user interface used to support a forms capability that was not available for the core repository. The forms engine made it simple to create content capture interfaces through mere configuration. Today the core repository has a forms capability that is more powerful than what was provided for in the AVM user interface.

Content Deployment (Now supported in core)

An AVM project could be configured with remote content receivers. There was out-of-the-box support for repository to file system deployment (FSR) and repository to repository deployment (ASR). Today the core repository provides two deployment mechanisms; Transfer Service and Channel Publishing framework, which combined now exceed the capabilities of the AVM content deployment framework.

Unique Features of the Core Repository

Now lets look at what the core repository has going for it that the AVM repository and supporting UI never got around to implementing. Again we’ll look at features rather than use cases.

Rules Support

The core repository allows you to attach rules to a folder that execute based on lifecycle events and configurable conditions. This is extremely powerful and its a feature that was sorely absent in AVM.

Stronger Modeling Support

Both repositories allow us to create types and (more commonly) aspects which contain metadata. However the core repository allows for associations at the modeling layer. In the AVM, associations were kept only as paths within files. This turns out to be fine for content delivery but bad for managing the content due to move and rename operations because of the unbounded number of updates you may have to perform. Associations in files also makes it difficult for supporting user experience features in your content management platform. Users expect a platform to understand it’s assets and how they relate to one another in a way that can be quickly accessed through query. The core repository can do this innately through it’s use of associations. The AVM cannot.

Strong Transformation and Metadata Extraction

The transformation and metadata extraction frameworks integrated with the core repository greatly exceed the capabilities of the those integrated with the AVM. The AVM is only integrated with an XML metadata extraction and transformation. The core repository on the other hand has integrated support for all kinds of metadata extraction and transformation including Microsoft Office documents, images, PDF and many many more.

Powerful, Fine-grained Permissions

The core repository gives us the flexibility to create and manage user access to content in a way that best fits an individual engagement through the use of ACLs (Access Control Lists.) While the AVM was based on a similar scheme under the hood, these were never exposed through the UI and thus it were not practical to deploy on engagements. Out-of-the-box AVM exposed a few roles that could be applied broadly to the entire site in each sandbox.

API support

The core repository has much better remote API support. The core repository supports CMIS, webscripts, and RAAr. AVM only supports a remote API based on RMI.

Workflow Engine

The core repository has 3 workflow engines integrated with it: Simple, JBPM, and Activiti. Activiti is based on standards and has parity with JBPM, but incorporates a far better management console. The AVM provides workflows based on JBPM integration only.

Search

Full text search support is based on indexing. You index a store. In the AVM universe every web project was made up of many (layered) stores. It was not practical to index every store. Although you can configure individual stores for indexing, if every author in the system wants to be able to search their sandbox, you will hit obvious limitations to the approach. The core repository content has only one store which is constantly tracked by a search index which means that search is very current with work in progress. Alfresco 4 has introduced Solr as one of its search subsystems. Solr provides capabilities that greatly exceed Lucene, the indexing engine used by the AVM.

Integrations

The core repository has many integrations that allow users to interact with content on their own terms, be it email, WEBDAV, FTP, shared drive, Sharepoint and so on. With exception to the filesystem projections, these are simply not made available in the AVM.

Native support in the UI and APIs for taxonomies, folksonomies and collaboration features

The core repository has repository service and UI support for

Hierarchical taxonomies

Tags

Comments

Content lists

Making Sense of the Differences

By this time you should have a pretty good idea of how the repositories compare from a feature perspective. Two observations are obvious:

The core repository has a had the benefit of deep continuous innovation.

The AVM has certain features intended for WCM use cases that will need to be addressed in a solution that leverages the core repository.

Join us tomorrow for a blog post that will demonstrate the use cases that these features were intended to cover and how we addressed all the Web CMS use cases with Crafter Rivet using and capturing the full power and innovation of Alfresco 4 and the core repository.