In this article by Jeffrey T. Potts and Snehal K Shah, authors of Alfresco Developer Guide, Second Edition, we will discuss the Alfresco architecture.

(For more resources related to this topic, see here.)

Alfresco architecture

Many of Alfresco’s competitors, particularly in the closed-source space, have sprawling footprints composed of multiple, sometimes competing, technologies that have been acquired and integrated over time. Some have undergone massive infrastructure overhauls over the years, resulting in bizarre vestigial tails of sorts. Luckily, Alfresco doesn’t suffer from these traits. On the contrary, Alfresco’s architecture is advantageous for the following reasons:

• It is relatively straightforward
• It is built with state of the art frameworks and open source components
• It supports several important content management and related standards

Let’s look at each of these characteristics, starting with a high-level look at the Alfresco architecture.

High-level architecture

The following diagram shows Alfresco’s high-level architecture:

The important takeaways at this point are as follows:

• There are many ways to get content into or out of a repository, whether it’s via the protocols on the left-hand side of the diagram or the APIs on the right-hand side.
• Alfresco runs as a web application within a servlet container. In the current release, the web client runs in the same process as the content repository itself.
• Customizations and extensions run as part of the Alfresco web application. An extension mechanism separates customizations from the core product to keep the path clear for future upgrades.
• Metadata resides in a relational database, while content files and Solr/Lucene indexes reside on the filesystem. The diagram shows the content residing on the same physical filesystem as Alfresco but other types of file storage could be used as well.
• The WCM Virtualization Server is an instance of Tomcat with Alfresco configurations and JAR files. The Virtualization Server is used to serve live previews of the website[SC2]  as it is being worked on. It can run on the same physical machine as Alfresco, or it can be split to show a separate node as well.

Add-ons

Add-ons are pieces of functionality not found in the core Alfresco distribution. If you are working with a binary distribution, this means that you’ll have additional files to download and install on top of the base Alfresco installation.

Add-ons are provided by Alfresco, third-party software vendors, and members of the Alfresco community, such as partners and customers. Alfresco makes several add-on modules available for the taking, such as Records Management and Facebook integration. Kofax, a software vendor, provides add-on software that integrates Alfresco with Kofax imaging solutions. Members of the Alfresco community create and share add-on modules via the Alfresco Forge, a website that Alfresco has set up for this purpose. However, a majority of what is available on it are language packs that are used to localize the Alfresco web client.

Open source components

One of the reasons Alfresco has been able to create a viable offering so quickly is because they didn’t start it from scratch. Alfresco’s engineers assembled the product from many finer-grained open source components. Instead of reinventing the wheel, they used proven components. This saved them time, of course, but it also resulted in a more robust, standards-based product. It also eases the transition for people who are new to the platform. If a developer already knows JavaServer Faces or Spring, for example, many of the customization concepts are going to be familiar to them.

The following table lists some of the major open source components used to build Alfresco:

Developers looking to contribute significant product enhancements to Alfresco or those making major, deep customizations to the product may require experience with a particular component, depending on exactly what they are trying to do. Everyone else will be able to customize and extend Alfresco using basic Java and web application development skills.

Major standards and protocols[SC6] that are supported

Software vendors love buzzwords. As new acronyms climb the hype cycle, vendors scramble to figure out how they can at least appear to support the standard or protocol so that prospective clients can check that box on the[SC7]  RFP (don’t even get me started on RFPs). Commercial open source vendors are still software vendors and are thus no less guilty of this practice. But because open source software is developed in the open by a community of developers, its compliance to standards tends to be more genuine. It makes more sense for an open source project to implement a standard than go off in some new direction because it saves time, promotes interoperability with other open source projects, and stays true to what open source is all about—freedom and choice.

Here, then, are the significant standards and protocols that Alfresco supports:

Summary

In this article, we took a look at how Alfresco could be assembled with open source components, run as a web application within an application server, and exposed the repository through many different protocols and APIs. Alfresco can also be customized. We explored how some types of customization are very basic (more configuration than customization) and can be performed by end users through the web client. Others are more advanced and require coding. Advanced customizations is the subject of this book.

Resources for Article:

Further resources on this subject:

• Core Ephesoft Features [article]
• Introducing Liferay for Your Intranet [article]
• Alfresco Web Scrpits [article]