Elements_Architecture_and_Technology.pdf

Alfresco Elements
Architecture and Technology

2 Alfresco Elements
Contents
Architecture and Technology...................................................................................................3

Architecture and Technology 3
Introduction
In this Alfresco Element the architecture and technology of the Alfresco Enterprise Content
Management system is explored.
The decisions which can and should be made regarding how to architect your installation are
examined. The start-up process is reviewed, with particular reference to the order in which the
components of the system initiate. The choice of operating system, database, application server
and hardware configurations, which can be used for an Alfresco installation are examined.
Architecture
Enterprise Content Management covers a broad range of applications. The Alfresco architecture
is designed to support the requirements of these applications, resulting in a coherent solution
where content and management processes are not forced into silos.
Alfresco recognizes that each discipline has unique but overlapping characteristics. The design of
each Alfresco capability is not done in isolation but with consideration to the overall solution.
Complexity of Enterprise Content Management systems is often a barrier to entry. Many
deployments do not reach their full potential due to restrictions enforced on developers, IT and
users of the system.
Alfresco is driven to deliver a system which is simple to develop against, customize, deploy and
to use.

4 Alfresco Elements
The shared document drive is the most commonly used application for Enterprise Content
Management systems. Alfresco can present itself as a shared drive and this is the simplest and
easiest user interface which users can access. It is one of many different interfaces which the
Alfresco architecture has been engineered to deliver.
Layered architecture
The Alfresco architecture can be thought of in three layers. The storage layer is where the actual
data and content is stored. This is managed by the repository layer. Because the two layers
are separate they can be run on independent hardware to increase performance and to provide
resilience.
The repository layer provides a multitude of protocols and APIs through which client applications
can connect. When you install Alfresco various client applications are provided by default. Some
organizations will develop their own bespoke applications or integrate existing applications with
Alfresco to provide document and content services.
As for the storage and repository layers the client layer can also be deployed to a distinct physical
environment.

Scalable
Since the Alfresco architecture is abstracted by layers, flexibility of system deployment is
introduced. This is the mechanism through which scaling and clustering can be implemented,
thereby affording support for vast volumes of content and large numbers of system users.
Embedded services
Enterprise Content Management often refers to services embedded within an end-user
application. The Alfresco Enterprise Content Management system is written in one hundred
percent Java. This is a trusted runtime for many enterprises wishing to deploy applications in their
data centers. Each Alfresco capability is implemented as a black-box Java service that is tested
independently and tuned appropriately.
As you have seen there are a range of application servers which can be used for Alfresco and
you will be familiar with how your particular application server is implemented and structured. If
you purchase any Alfresco Element (where there is lab work) you will see we have chosen to use
the Tomcat application server within the supplied virtual machine.

6 Alfresco Elements
Technology agnostic
Enterprise Content Management often forms part of a larger solution. The Alfresco architecture
is engineered so it can be deployed to a range of operating systems, databases, application
servers, browsers and authentication systems. Alfresco does not dictate this choice, but certifies
the system for use within a large number of tested technology stacks and 3rd party integrations.
Supported technologies
Below is a list of Alfresco supported technologies. Use the following link to see specific version
information.
http://www.alfresco.com/services/subscription/supported-platforms/
Database
• MySQL
• Microsoft SQL Server
• Oracle
• Postgres SQL
• IBM DB2
Application server
• Tomcat
• JBoss
• Oracle WebLogic Server
• Websphere
Java development kit
• JDK
• IBM Java SDK
• OpenJDK
Web browser
• Mozilla Firefox
• Microsoft Internet Explorer
• Safari
• Chrome for Ubuntu

Authentication system
• Active directory LDAP
• NTLM
• OpenLDAP
• Oracle Directory Server
• Kerberos
• JASS
3rd Party integrations
• IMAP - Microsoft Outlook
• SharePoint - Microsoft Office
• Liferay
• Kofax
3rd Party components
• ImageMagick
• SWFTools
• OpenOffice
• VMWare ESXi
• FileZilla FTP
• Finder
Repository layer
The repository layer is often referred to as the content server. It stores content of all types and
provides a set of re-usable content management services such as content storage, query,
versioning and transformation which may be used by one or more applications.
Control services enable workflow, records management and changes sets. Collaboration services
provide functionality such as wikis, blogs, discussion forums and social media functionality.

8 Alfresco Elements
Contents objects
Content files are constructed in two parts. The first component is metadata (often described
as data about data). This contains information such as the creation date, modification date,
keywords, annotations and a host of additional describing detail. The content itself is stored in the
secondary component and this is the representation the user sees within an editing or viewing
application.
Alfresco utilizes this file structure when managing content.
The metadata is extracted and stored in the database, thereby delivering a range of functionality
which can be undertaken against this data.
The content is stored within the file system. Placing it within the file system (rather than in the
database as some system do) delivers maximum performance when accessing, retrieving and
working with the content. In order to support user searching and queries Alfresco indexes the
content within a full text indexing system.
High level architecture
There are many ways to deploy Alfresco, using some or all of the solution components. Each
component typically splits functionality across a client and server, where clients offer users and

interface to the solution and the server provides content management services and storage. It
is common for a solution to offer multiple clients against a shared server, where each client is
tailored for the environment in which it is to be used.
The Alfresco architectural components are discussed here:
Clients
The primary web based client is Alfresco Share. It provides collaboration for content and
streamlines the user experience by introducing features such as web previews, tagging,
metadata representation and editing, social publishing, blogs, wikis, discussions and many other
collaborative functions.
It is implemented in Spring Surf and fully customizable. Alfresco Share can also be deployed to
its own tier separate from the Alfresco content server.
Alfresco Explorer also exists as a web based client. This is no longer in development but still
ships with Alfresco. It is important to be aware of its historical value. It was implemented in
JavaServer Faces, but had to be deployed to the content server rather than deployed to its own
tier.
There are a range of other clients and integrations; for example Microsoft Outlook via IMAP,
Microsoft Office via the SharePoint protocol, Liferay and Kofax.
The client often overlooked is the shared drive, available to the operating system. This is probably
one of the most common home-grown Enterprise Content Management solution where users
share documents through a network drive. Using this technology, Alfresco can look and act just
like a network drive. This is the only Java server-side implementation of the CIFS protocol. By
using CIFS, users interact with Alfresco just as they do any other normal network drive, except
the content is now stored and managed in the Alfresco content server. WebDav and FTP are also
supported.
Content server
The Alfresco content server is primarily responsible for content definition and storage, retrieval of
content, versioning, and permissions. The content server provides a highly reliable, scalable, and
efficient implementation.
The Alfresco content server provides the following categories of services: content services,
for example, transformation, tagging and metadata extraction; control services, for example,
workflow, deployment and records management and collaboration services, for example, blogs,
activities, wiki and social publishing.
Physical storage
Content storage, by default, is a combination of relational database for metadata and file system
for content. In order to support fast text search in documents and other types of query Solr is
used as the full text search engine.
Using a database immediately brings benefits that have been developed over many years such
as transaction support, scaling, and administration capabilities.
Alfresco uses a database independent layer for interacting with the database, which brings
additional cache control and SQL dialect support and allows Alfresco to be certified against all the
prominent database implementations.
Content is stored in the file system to allow for very large content, random access, streaming,
and options for different storage devices. Updates to content are always translated to append

10 Alfresco Elements
operations in the file system. This allows for transaction consistency between database and file
system.
Alfresco server startup
Alfresco can be installed as a service for Windows, a daemon for Linux or manually for either
platform.
The modular nature of the Alfresco architecture means that the startup procedure will be different
for each deployment. Certain components are core and this description is designed to give you a
flavor for when these components are initiated and what part they play in an installation.
Early in the startup procedure checks are made to see if the database to be used with Alfresco is
running, if not it is launched.
When the web application server initiates (in our case Tomcat) the file web.xml (~tomcat/
webapps/alfresco/WEB-INF/) is loaded. This in turn loads Spring configuration and property files
which launch the Alfresco server.
The Alfresco Element 'Repository configuration' examines these files and the configuration in
greater detail.
Configuration and property files
In sequence the web application server reads the following files, which configure and launch the
server:
• web.xml (~tomcat/webapps/alfresco/WEB-INF/)
• web-application-context.xml (~tomcat/webapps/alfresco/WEB-INF/)
• application-context.xml (~tomcat/webapps/alfresco/WEB-INF/classes/alfresco/)
• application-context-core.xml (~tomcat/webapps/alfresco/WEB-INF/classes/alfresco/)
Actions:
• Read Spring configuration files.
• Read property files (these enable changeable item configuration and system
configuration).
• Check database for property values.
Initialize subsystems
The first subsystems from the content repository are initiated. Multiple subsystems launch
asynchronously as dictated by the specific configuration. One of the first subsystems to launch is
'sysAdmin'.
Database schema updates
Check for and apply any database schema changes within the Alfresco installation.
OpenOffice
OpenOffice provides rendering and transformation services to Alfresco. A connection is
attempted and if not successful re-attempted later in the startup process.

Rendering includes generating full screen previews of content. Transformation includes functions
such as converting a file from one format to another, for example converting a Microsoft Word file
to an Adobe PDF.
Alfresco module packages
Alfresco module packages (AMPs) are functional additions or patches, which can be applied to
Alfresco in the startup procedure.
A single AMP file bundles XML, images, CSS and code which collectively extends the
functionality or data provided by the Alfresco repository.
Server running
The final steps of the server startup procedure is to
• Deploy the share.war file which implements Alfresco Share. (~tomcat/webapps/)
• Register Web Scripts. (Web Scripts are services which responds to HTTP methods such
as GET, POST, PUT and DELETE to perform functions within Alfresco. A number are
supplied and they can easily be created without knowledge of Java.)
This is the basic ordering to the Alfresco server startup. Be mindful that certain components rely
on each other, some components are started asynchronously, while others, for example patches,
may be applied in several cycles.
For greater details see the 'Repository configuration' Alfresco Element.
Demo: Alfresco server startup
Having explored the startup process by component, let’s look in greater detail.
In this example Alfresco has been installed manually. The alfresco.sh command is used to initiate
the server. This checks if the database to be used with Alfresco is running. In this instance it’s
not, and Postgres is launched. The Tomcat web application server is next started. The alfresco.sh
script ends as tomcat is now launching.
The alfresco.log file records the actions and errors of the Alfresco server and we could examine
this, however I tail the tomcat log file catalina.out since this shows the same detail with some
additional information I wish to highlight.
The tomcat server reads the web.xml file and then a number of other Spring configuration and
property files which define and control the Alfresco startup. The first of the sub systems is started,
in this instance the ‘sysAdmin’ subsystem. Many others will be launched at various points in the
process.
The system checks if any database schema changes are required for the Alfresco database. A
connection to the rendering and transformation service, OpenOffice, is attempted. The service is
not presently available. Next checks for any AMP files or patches to be applied are made. These
would be written to the alfresco.war file (which contains the application), prior to that file being
expanded and deployed.
Illustrating the asynchronous nature of the startup process a number of other subsytems are
initiated. These include, file systems, email, Google Docs, and others Apache Solr is next started.
A second attempt to connect to the OpenOffice server succeeds now that service is running.
Alfresco Share is deployed and expanded from the share.war file.
Web Scripts are registered and deployed. Web Scripts are an enabling and extensible
technology, core functionality of Alfresco is written in Web Scripts. The Alfresco server is now
fully launched and available.

Architectual decisions
When you are planning out your Alfresco installation there are some key architecture decisions
which you will make, these relate principally to where you place different components of the
system. The location of components can have a dramatic effect on the performance and reliability
of the system, so it is important to get this right.
There are decisions about which you have no choice over and there are some general rules
which you can use to ensure that you get a good and solid architecture.
Architecture deployment
Whilst for development purposes you may often run all the components of Alfresco on a single
system, for production it is best practice to deploy your database and the content server on
different machines. This gives you greater flexibility when configuring the hardware and tuning the
system's independently.
This configuration should be treated as the minimum configuration for production. Obviously your
real configuration will vary depending on the application for which you are using Alfresco. For
example if you are using Alfresco for Image Management and therefore doing scanning you will
need other servers to host the scanning software.
The flexibility in the Alfresco architecture affords the possibility of moving the front end
application server to one or more servers; allowing for improved performance, load balancing and
redundancy.
There are some hardware and software considerations you should take into account when
building your production Alfresco infrastructure. Firstly with respect to hardware you should
use server class machines with SCSI Raid disk arrays. The performance of reading and writing
content is almost solely dependent on the speed of your network and the speed of your disk
infrastructure, the overhead of the Alfresco content server itself for reading and writing content
is very low. So SCSI should be considered the entry level configuration, you should seriously
consider using a SAN infrastructure for enterprise scale performance.
In some cases it may be tempting to make the file system remote and mount onto the content
server machine across a LAN or WAN, this is not advised and will cause performance problems.
The file system should always be attached to the content server through a high-speed connection
such as fibre channel.
As you have seen the operating system must be 64bit since the size of a Java Virtual Machine
is restricted to 2GB on a 32bit operating system. This will not support the requirements of a
production Alfresco deployment.
Apache Solrt
Alfresco version 4 introduced a change in architecture for indexing and user search; Apache Solr
is now the default full text indexing technology. Lucene was used prior to this and can be enabled
in favour of Solr if required.
Solr embeds and leverages Lucene, however Solr provides a functionally abstracted layer and
can be installed on a dedicated server.
Solr delivers a number of advantages over Lucene including scalability, improved performance,
enhanced language support and fine control over what gets indexed.
A principle issue for Lucene is transactional dependence; the indexes are updated as content is
loaded or edited. This delivers fully accurate and synchronised indexes, but means the content

server is locked during the transaction. This is a particular problem if the indexes ever have to be
rebuilt from scratch, an operation that can take many hours with large content repositories.
The drawback and consideration when using Solr, is that it works asynchronously and is known
as “eventually consistent”. Content is indexed at small regular intervals and until the indexes are
up to date.
Subsystems
Let’s examine the content server and the architecture of the content repository.
The content repository is comprised of a number of subsystems. These are configurable modules
responsible for a sub-part of Alfresco functionality. Typically, a subsystem wraps an optional
functional area, such as IMAP bindings, or one with several alternative implementations, such as
authentication.
As a unit, subsystems have their own lifecycle and they may be shut down and restarted while
the Alfresco server is running. This is useful if you wish to disable an aspect of the server, or
reconfigure parts of it, for instance how LDAP synchronization is mapped.
Each subsystem supports its own administration interface that is accessible through the
administrator’s console of Alfresco Share, within property files, or directly through a management
console using Java Management Extensions (JMX).
Subsystems are implemented so that there may be multiple instances of the same type where
this makes sense. For example there may be more than one way of facilitating authentication.

Within the ‘Managing the Repository’ Alfresco Element you have the opportunity to configure and
manipulate subsystems.
Deployed file strucutre
This diagram below depicts an Alfresco installation. This is the file structure as created by the
installer.
In production systems it is unlikely you would use the installer to deploy Alfresco, components
are typically installed manually, for example directly to the web application server. Additionally
remember that individual components can be split out to their own tier or server and therefore this
is only a general representation.
alf_data
This is default location for storing Alfresco content and includes the data dictionary for all nodes,
full text indexes and the actual content.
Naturally this is one of the most important directories for your backup and recovery regime.
The Solr indexes are an obvious target for moving to a separate server, as can the content (when
used with an appropriate network infrastructure).
tomcat
This directory is the web application server, responsible for running and presenting the Alfresco
instance. In a production environment it is likely other applications will also be installed here.

This is the default location when Alfresco is installed using the supplied installer. You may well
place tomcat at a different location or you may be using a different web application server.
Within the tomcat directory the Alfresco application installation is split over two directories; shared
and webapps.
shared
This directory contains java classes and configuration files which are shared across the whole
installation, we refer to ~tomcat/shared/classes as extensionRoot. This is important because
many of the configuration files are noted as being relative to this point in the structure.
Configuration files are either .properties or .xml files. These define functionality and
characteristics for Alfresco when initiated and includes the important Alfresco global properties
file.
webapps
In this directory are the Alfresco web applications, they are structured in the conventional way for
your application server.
There will always be an alfresco directory containing the server and its components. Depending
on how your system is installed and the applications you have deployed you may see application
directories such as share, solr, mobile and others.
alfresco
The alfresco directory contains the deployed alfresco server. This is extracted and deployed from
the alfresco.war file (which is held in the webapps directory) when the server initiates.
The alfresco server manifests and presents the content server (i.e. the content services and
repository).
It is of course possible to deploy the server without the related share directory (which deploys
Alfresco Share) as the alfresco server can be accessed from many different user interfaces other
than a web browser.
share
The share directory contains the Alfresco Share application, the web user interface to the content
server.
This is extracted and deployed from the share.war file (which is held in the webapps directory)
when the server initiates.
It is possible to deploy the alfresco content server without share as any one of the other possible
user interfaces can be used to access the content server.

Elements_Architecture_and_Technology.pdf

More Related Content

What's hot (16)

Viewers also liked (20)

Similar to Elements_Architecture_and_Technology.pdf (20)

More from Jeff Smith (20)

Elements_Architecture_and_Technology.pdf