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 (at least not yet!). On the contrary, Alfresco's architecture:
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. By the time you finish this book, you'll be intimately familiar with just about every box in the diagram:
The important takeaways at this point are as follows:
There are many ways to get content into or out of the repository, whether that's via the protocols on the left side of the diagram or the APIs on the right.
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.
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 DB while content files and Lucene index reside on the file system. The diagram shows the content residing on the same physical file system as Alfresco, but other types of file storage could be used as well.
The WCM Virtualization Server is an instance of Tomcat with Alfresco configuration and JAR files. The Virtualization Server is used to serve up live previews of the web site as the site is being worked on. It can run on the same physical machine as Alfresco or can be split out to a separate node.
The "Add-ons" are pieces of functionality not found in the core Alfresco distribution. If you are working with the binary distribution, it means 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 such as Records Management and Facebook integration. Software vendor Kofax provides add-on software that integrates Alfresco with the Kofax imaging solution. Members of the Alfresco community create and share add-on modules via the Alfresco Forge, a web site set up by Alfresco for that purpose. But the majority of what is available is language packs used to localize the Alfresco web client.
One of the reasons Alfresco has been able to create a viable offering so quickly is because it didn't start from scratch. The Alfresco engineers assembled the product from many finer-grained open source components. Why does this matter? First, instead of reinventing the wheel, they used proven components. This saved them time, but it also resulted in a more robust, more standard-based product. Second, it eases the transition for people new to the platform. If a developer already knows JavaServer Faces (JSF) or Spring, for example, many of the customization concepts are going to be familiar. (And besides, as a developer, wouldn't you rather invest your time and effort in learning standard development frameworks rather than proprietary "development kits"?)
The following table lists some of the major open source components used to build Alfresco:
|
Open Source Component |
Use in Alfresco |
|---|---|
|
Apache Lucene (http://lucene.apache.org/) |
Full-text and metadata search |
|
Hibernate (http://www.hibernate.org/) |
Database persistence |
|
Apache MyFaces (http://myfaces.apache.org/) |
JSF components in the web client |
|
FreeMarker (http://freemarker.org/) |
Web script framework views, custom views in the web client, web client dashlets, email templates |
|
Mozilla Rhino JavaScript Engine (http://www.mozilla.org/rhino/) |
Web script framework controllers, Server-side JavaScript, 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 into PDF |
|
Apache FOP (http://xmlgraphics.apache.org/fop/) |
Transformation of XSL:FO into PDF |
|
Apache POI (http://poi.apache.org/) |
Metadata extraction from Microsoft Office files |
|
JBoss jBPM (http://www.jboss.com/products/jbpm) |
Advanced workflow |
|
ImageMagick (http://www.imagemagick.org) |
Image file manipulation |
|
Chiba (http://chiba.sourceforge.net/) |
Web form generation based on XForms |
Does this mean you have to be an expert in all open source components used to build Alfresco to successfully implement and customize the product? Not at all! 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 buzz words. 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 the prospective clients can check that box on the Request for proposal (RFP) (don't even get me started on RFPs). Commercial open source vendors are still software vendors and thus are 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 to go off in some new direction because it saves time. It promotes interoperability with other open source projects, and stays true to what open source is all about: freedom and choice.
Here, are the significant standards and protocols Alfresco supports:
|
Standard/Protocol |
Comment |
|---|---|
|
FTP |
Content can be contributed to the repository via FTP. Secure FTP is not yet supported. |
|
WebDAV |
WebDAV is an HTTP-based protocol commonly supported by content management vendors. It is one way to make the repository look like a file system. |
|
CIFS |
CIFS allows the repository to 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. |
|
JCR API (JSR-170) |
JCR is a Java API for working 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 is near to Level 2 compliant. |
|
Portlet API (JSR-168) |
The Web Script Framework lets you define a RESTful API to the repository. Web Scripts can return XML, HTML, JSON, and JSR-168 portlets. In the current release, this requires the portal and Alfresco to be running 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 as 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 if your organization has several repositories that are OpenSearch-compliant (including non-Alfresco repositories), they can be searched from within the web client. |
|
XForms, XML Schema |
Web forms are defined using XML Schema. Not all XForms widgets are supported. |
|
XSLT, XSL:FO |
Web form data can be transformed using XSL 1.0. |
|
Alfresco can authenticate against an LDAP directory or a Microsoft Active Directory server. |