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.)
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:
Let's look at each of these characteristics, starting with a high-level look at the Alfresco architecture.
The following diagram shows Alfresco's high-level architecture:
The important takeaways at this point are as follows:
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.
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:
Open source components |
What the open source component does in Alfresco |
Apache Lucene (http://lucene.apache.org/) |
Full text and metadata search. |
Apache Solr (http://lucene.apache.org/solr/) |
Alfresco allow the usage of the Solr index instead of Lucene. |
Hibernate (http://www.hibernate.org/) iBatis (http://ibatis.apache.org/) |
Database persistence. Both are supported by Alfresco. |
Apache MyFaces (http://myfaces.apache.org/) |
JavaServer Faces components in the web client . |
FreeMarker (http://freemarker.org/) |
Web script framework views, custom views in the web client, Web client dashlets, and e-mail templates. |
Mozilla Rhino JavaScript Engine (http://www.mozilla.org/rhino/) |
Web script framework controllers, server-side JavaScript, and actions |
OpenSymphony Quartz (http://www.opensymphony.com/quartz/) |
Scheduling of asynchronous processes. |
Spring ACEGI (http://www.acegisecurity.org/) |
Security (authorization), roles, and permissions. |
Apache Axis (http://ws.apache.org/axis/) |
Web services. |
OpenOffice.org (http://www.openoffice.org/) |
Conversion of office documents to the PDF format. |
Apache FOP (http://xmlgraphics.apache.org/fop/) |
Transformation of XSL:FO to the PDF format. |
Apache POI (http://poi.apache.org/) |
Metadata extraction from Microsoft Office files. |
JBoss jBPM (http://www.jboss.com/products/jbpm) |
Advanced workflow. |
Activiti (http://activiti.org/) |
Advanced workflow. |
ImageMagick (http://www.imagemagick.org) |
Image file manipulation. |
Chiba (http://chiba.sourceforge.net/) |
Web form generation that's based on XForms. |
Spring Surf (http://www.springsurf.org/) |
This is used by Alfresco Share. |
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.
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:
Standard/porotocol |
Comment |
FTP |
Content can be contributed to the repository via FTP. Secure FTP is not yet supported. |
WebDAV
|
WebDAV is an HTTP-based protocol that's commonly supported by content management vendors and is one way to make the repository look like a filesystem. |
CIFS |
CIFS lets the repository be mounted as a shared drive by other machines. As opposed to WebDAV, systems (and people) can't tell the difference between an Alfresco repository mounted as a shared drive through CIFS and a traditional file server. |
The JCR API (JSR-170) |
JCR is a Java API that works with content repositories, such as Alfresco. Alfresco is a JCR-compliant repository. There are two levels of JCR compliance. Alfresco is level-1-compliant and almost level-2-compliant. |
The Portlet API (JSR-168) |
The Web Script Framework lets you define a RESTful API for the repository. Web Scripts can return XML, HTML, JSON, and JSR-168 portlets. In the current release, this requires the portal and Alfresco to run in the same JVM, but this restriction may go away in the near future. |
SOAP |
The Alfresco Web Services API uses SOAP-based web services. |
OpenSearch (http://www.opensearch.org) |
Alfresco repositories can be configured in the form of an OpenSearch data source, which allows Alfresco to participate in federated search queries. OpenSearch queries can be executed from the Web Client as well. This means that if your organization has several repositories that are OpenSearch-compliant (including non-Alfresco repositories), they can be searched from within the web client. |
XForms and XML Schema |
Web forms are defined using XML Schema. Not all XForms widgets are supported. |
XSLT and XSL:FO |
Web form data can be transformed using XSL 1.0. |
LDAP |
Alfresco can authenticate against an LDAP directory or a Microsoft Active Directory server. |
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.
Further resources on this subject: