Alfresco Documentation
Published on Alfresco Documentation (https://docs.alfresco.com)

Home > Alfresco One 5.0.5 > Alfresco One overview > Alfresco architecture

Alfresco architecture

At the core of the Alfresco system is a repository supported by a server that persists content, metadata, associations, and full text indexes. Programming interfaces support multiple languages and protocols upon which developers can create custom applications and solutions. Out-of-the-box applications provide standard solutions such as document management and records management.

As a Java application, the Alfresco system runs on virtually any system that can run Java Enterprise Edition. At the core is the Spring platform, providing the ability to modularize functionality, such as versioning, security, and rules. Alfresco uses scripting to simplify adding new functionality and developing new programming interfaces. This portion of the architecture is known as web scripts and can be used for both data and presentation services. The lightweight architecture is easy to download, install, and deploy.

There are many ways to deploy Alfresco, however most deployments follow a general pattern. Ultimately, Alfresco is used to implement ECM solutions, such as document management and records management. There can also be elements of collaboration and search across these solutions.

The solutions are typically split between clients and server, where clients offer users a user interface to the solution and the server provides content management services and storage. Solutions commonly offer multiple clients against a shared server, where each client is tailored for the environment in which it is used.

Clients

Alfresco offers a web-based client called Alfresco Share, built entirely with the Alfresco web script technology. Share provides content management capabilities with simple user interfaces, tools to search and browse the repository, content such as thumbnails and associated metadata, previews, and a set of collaboration tools such as wikis and discussions. Alfresco Share is organized as a set of sites that can be used as a meeting place for collaboration. Alfresco Share is a web-based application that can be run on a different server to the server that runs the Alfresco repository, thus providing opportunities to increase scale and performance.

Alfresco Share can be deployed to its own tier separate from the Alfresco content application server. Alfresco Share focuses on the collaboration aspects of content management and streamlining the user experience. Alfresco Share is implemented using Alfresco Surf and can be customized without JSF knowledge.

Clients also exist for portals (by using JSR-168 portlets), mobile platforms, Microsoft Office, and the desktop. In addition, using the folder drive of the operating system, users can share documents through a network drive. Using JLAN technology, Alfresco can look and act just like a folder drive. JLAN is the only Java server-side implementation of the CIFS protocol, letting users interact with Alfresco as they do any other normal file drive except the content is now stored and managed in the Alfresco content application server.

Server

The Alfresco content application server comprises a content repository and value-added services for building ECM solutions.

The Alfresco content application server provides the following categories of services built upon the content repository:
  • Content services (transformation, tagging, metadata extraction)
  • Control services (workflow, records management, change sets)
  • Collaboration services (social graph, activities, wiki)

Clients communicate with the Alfresco content application server and its services through numerous supported protocols. HTTP and SOAP offer programmatic access while CIFS, FTP, WebDAV, IMAP, and Microsoft SharePoint protocols offer application access. The Alfresco installer provides an out-of-the-box prepackaged deployment where the Alfresco content application server and Alfresco Share are deployed as distinct web applications inside Apache Tomcat.

  • Guiding design principles [1] The Alfresco architecture supports the requirements of Enterprise Content Management (ECM) applications, such as Document Management (DM), Web Content Management (WCM), Records Management (RM), Digital Asset Management (DAM), and Search.
  • Alfresco web tier and Surf [2] Alfresco provides ECM capabilities as data services, user interfaces, and user applications. The user interface capabilities are provided by applications and application components using Alfresco's web tier, Surf, originally developed as a faster way to develop content applications using scripting and REST architecture.
  • Alfresco content application server [3] At the heart of the Alfresco system is the content application server, which manages and maintains the content repository. The server's primary responsibility is to provide services for use in building ECM solutions. All the applications of the Alfresco ECM suite are built upon and executed by the content application server.
  • Alfresco content repository [4] The content repository is comparable to a database, except that it holds more than data. The binary streams of content are stored in the repository and the associated full-text indexes are maintained by SOLR indexes.
  • Alfresco content services [5] Services address the core use cases for content management applications including the logical organization of content, file management, version control, and security. Services also support the control of content through workflow and process management, and social and collaborative applications.
  • Alfresco programming models [6] A number of programming models are available for building an application using the Alfresco content application server.
  • APIs [7] To access and extend Alfresco out-of-the-box services, the Alfresco content application server exposes two flavors of API, each designed for a specific type of client.
  • Content modeling [8] Content modeling is a fundamental building block of the Alfresco content repository that provides a foundation for structuring and working with content.
  • Protocols [9] The Alfresco content application server supports many folder and document-based protocols to access and manage content held within the content repository using familiar client tools.
  • Modularity [10] The Alfresco system is modular. Every moving part is encapsulated as a service, where each service provides an external face in a formally defined interface and has one or more black-box implementations.
  • Alfresco web application framework [11] Alfresco Share and all new Alfresco web applications are built on Alfresco Surf. This web application framework provides the typical features of this kind of framework and supports web content management needs.
  • Deployment options [12] You can deploy Alfresco in many different forms and topologies. Because its infrastructure foundation protects Alfresco from the environment within which it executes, you can choose components such as operating system, database, application server, web browser, and authentication system. Alfresco is designed to scale down as well as up.
Parent topic: Alfresco One overview [13]

Guiding design principles

The Alfresco architecture supports the requirements of Enterprise Content Management (ECM) applications, such as Document Management (DM), Web Content Management (WCM), Records Management (RM), Digital Asset Management (DAM), and Search.

Support ECM requirements

Each of these disciplines has unique and overlapping characteristics so that the design of each Alfresco capability is not done in isolation but in the context of the whole system.

Simple, simple, simple

Alfresco aims to be as simple as possible to develop against, customize, deploy, and use. The simplest and probably most widely deployed ECM solution is the shared document drive: the Alfresco architecture is driven by the desire to be as simple as a shared drive.

Scaling to the enterprise

Every service and feature of Alfresco is designed up front to scale in terms of size of data set, processing power, and number of users.

Modular approach

Alfresco architecture takes a modular approach in which capabilities are bundled into modules whose implementation can be replaced if required, or not included at all. Aspect-Oriented Programming (AOP) techniques allow for fine-tuning and optimization of an ECM solution.

Incorporating best-of-breed libraries

Where possible, Alfresco incorporates best-of-breed third-party libraries. The open source nature of Alfresco lends itself to integrating with the wealth of available open source libraries. This is done whenever it is more profitable to integrate than build or whenever expertise is better provided in another project rather than in-house.

Environment independence

Alfresco ECM does not dictate the environment upon which it depends, allowing choice in the operating system, database, application server, browser, and authentication system to use when deploying Alfresco. ECM is less about the application and more about the services embedded within an application. You can choose how to package Alfresco — for example, as a web application, an embedded library, or portlet.

Solid core

The heart of Alfresco ECM is implemented in Java. This decision was driven by the wealth of available Java libraries, monitoring tools, and enterprise integrations. Java is also 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 tested independently and tuned appropriately.

Scriptable extensions

Extensions will always need to be created for custom solutions and there are many custom solutions versus the single Alfresco core. Therefore, Alfresco extension points are developed using JVM-based scripting languages, allowing a much wider pool of developers to build extensions versus those that can contribute to the Alfresco core. Extensions are packaged entities, allowing for the growth of a library of third-party reusable extensions.

Standards-based approach

The Alfresco architecture always complies with standards where applicable and advantageous. Primary concerns are to reduce lock-in, improve integration possibilities, and hook into the ecosystems built around the chosen standards.

Architecture of participation

The Alfresco architecture promotes a system designed for community contribution. In particular, the architecture principles of a solid core, modularity, standards compliance, simplicity of development, and scriptable extensions encourage contribution of plug-ins and custom ECM solutions. Participation complements the open source approach to the development of Alfresco and fosters growth of the Alfresco community. As the community grows, the quality of self service improves, as well as the quality of feedback to Alfresco. This, in turn, enhances Alfresco and creates the ultimate feedback loop.
Parent topic: Alfresco architecture [14]

Alfresco web tier and Surf

Alfresco provides ECM capabilities as data services, user interfaces, and user applications. The user interface capabilities are provided by applications and application components using Alfresco's web tier, Surf, originally developed as a faster way to develop content applications using scripting and REST architecture.

Development of web scripts allows for the creation of a REST-based API. Web scripts can be executed without compilation, and provide a quick and easy way to extend and enhance Alfresco's standard services.

The web script infrastructure accommodates Java beans as easily as JavaScript. Web scripts add little overhead but provide a great deal of flexibility and development productivity. Web scripts in the web tier let you quickly build user interface components with Surf or simple HTML and deploy them as Alfresco Share components, portlets, or other web platforms such as Google Gadgets.

Parent topic: Alfresco architecture [14]

Alfresco content application server

At the heart of the Alfresco system is the content application server, which manages and maintains the content repository. The server's primary responsibility is to provide services for use in building ECM solutions. All the applications of the Alfresco ECM suite are built upon and executed by the content application server.

The Alfresco content application server exposes a set of remote public interfaces for allowing a client to communicate with it. The remote public interfaces are the only part of the server visible to the client. There are two types:

  • Remote APIs - for interacting with services of the server programmatically
  • Protocol bindings - for mapping services for use by a protocol-compliant client

Internally, the server comprises several layers. The foundation includes infrastructure concerns, such as configuration, authentication, permissions, and transactions that cut across all capabilities. Infrastructure also shields the server from being tied to any specific environmental implementation, such as transaction managers or caching mechanisms.

The content repository is built on this infrastructure, which itself is the building block for content, control, and collaboration services. Each capability of the content repository and content services is individually bundled as a module with its own in-process interface and implementation. Modules are bound together by the infrastructure through their interfaces.

You can deploy extensions to the content application server to extend or override its capabilities. Their implementation might use the in-process interfaces offered by the content repository and content services.

Parent topic: Alfresco architecture [14]

Alfresco content repository

The content repository is comparable to a database, except that it holds more than data. The binary streams of content are stored in the repository and the associated full-text indexes are maintained by SOLR indexes.

The actual binary streams of the content are stored in files managed in the repository, although these files are for internal use only and do not reflect what you might see through the shared drive interfaces. The repository also holds the associations among content items, classifications, and the folder/file structure. The folder/file structure is maintained in the database and is not reflected in the internal file storage structure.

The Alfresco content repository implements services including:

  • Definition of content structure (modeling)
  • Creation, modification, and deletion of content, associated metadata, and relationships
  • Query of content
  • Access control on content (permissions)
  • Versioning of content
  • Content renditions
  • Locking
  • Events
  • Audits
  • Import/Export
  • Multilingual
  • Rules/Actions
The Alfresco content repository implements and exposes these services through an Alfresco API, CMIS protocol bindings, and the JSR-170 Java API. The storage engine of the repository stores and retrieves content, metadata, and relationships, and operates on the following constructs:
  • Nodes - provide metadata and structure to content. A node can support properties, such as author, and relate to other nodes such as folder hierarchy and annotations. Parent to child relationships are treated specially.
  • Content - the content to record, such as a Microsoft Word document or an XML fragment.

Content models are registered with the content repository to constrain the structure of nodes and the relationships between them, and to constrain property values.

The storage engine also exposes query capabilities provided by a custom query engine built on Apache Lucene that supports the following search constructs:
  • Metadata filtering
  • Path matching
  • Full text search
  • Any combination of these search constructs

The query engine and storage engines are hooked into the transaction and permission support of the infrastructure, offering consistent views and permission access. Several query languages are exposed, including native Lucene, XPath, Alfresco FTS (Full Text Search), and CMIS Query Language (with embedded Alfresco FTS).

By default, Alfresco stores nodes in an RDBMS while content is stored in the file system. Using a database provides transaction support, scaling, and administration capabilities. Alfresco uses a database abstraction layer for interacting with the database, which isolates the storage engine from variations in SQL dialect. This eases the database porting effort, allowing the certification of Alfresco against all the prominent RDBMS implementations. The file system stores content to allow for very large content, random access, streaming, and options for different storage devices. Updates to content are always translated to append operations in the file system, allowing for transaction consistency between database and file system.

You can bundle and deploy the Alfresco content repository independently or as part of a greater bundle, such as the Alfresco content application server.

Parent topic: Alfresco architecture [14]

Alfresco content services

Services address the core use cases for content management applications including the logical organization of content, file management, version control, and security. Services also support the control of content through workflow and process management, and social and collaborative applications.
Alfresco exposes services at various levels including:
  • Java
  • Scripting
  • REST
  • Web services
  • Client interfaces, such as Alfresco Share

Some services are considered internal; others are public. For example, the Java level services are internal. The majority of these are accessible through other public interfaces including the public APIs, client applications, and CMIS.

Alfresco services are divided into two main categories; content application services and content repository services.

  • Content repository services [15] Content repository services are the fundamental services for working with content in Alfresco. Content repository services are written in Java.
  • Content application services [16] Content application services extend the repository services, providing extended capabilities for rich content and collaborative applications.
Parent topic: Alfresco architecture [14]
Parent topic: Alfresco Services [17]

Alfresco programming models

A number of programming models are available for building an application using the Alfresco content application server.
  • The simplest model for non-programmers is to use out-of-the-box components of the Alfresco Share application and the Rules and Actions model, a set of conditions and actions to take on content based on those conditions. You can define rules and actions using a wizard and perform actions such as converting content, moving content, or executing a simple JavaScript snippet.
  • Web scripts let you perform more sophisticated processing without complex programming. The Alfresco Content Management Interoperability Services (CMIS) implementation was built using web scripts. By using JavaScript to build these data services, it is easy to create new services in Alfresco. To build new user interfaces or extensions to Alfresco Share, you can also use web scripts by using a web templating language like FreeMarker. Most of Alfresco Share was built using web scripts.
  • To use Java to build applications or extend Alfresco Share, you can use the many tools associated with Java that were used to build the Alfresco system. Surf, the web runtime framework, lets you extend Alfresco Share and build web applications. Because Alfresco Share was built using Surf, you can build your own extensions as a combination of Java programming and web scripts, or with Java alone. You can also use Java to access or even replace whole pieces of Alfresco, content application server, or Alfresco Share by using the Spring platform. You can use the source code as an example for rewriting pieces and using Spring beans and configuration to extend or replace functionality in Alfresco.
  • To write applications that use Alfresco but are portable to other ECM systems, you can use Content Management Interoperability Services (CMIS), the OASIS standard for accessing content repositories.
Parent topic: Alfresco architecture [14]

APIs

To access and extend Alfresco out-of-the-box services, the Alfresco content application server exposes two flavors of API, each designed for a specific type of client.

The two main categories of API are embedded and remote APIs.

  • Embedded APIs [18] The Embedded API is used for developing extensions to the Alfresco content application server. Extensions deployed into the server often depend on existing services provided by the server. Therefore, developers of extensions use the Embedded API to gain access to those services.
  • Remote APIs [19] The Remote API is primarily used to build ECM solutions against the Alfresco content application server.
Parent topic: Alfresco architecture [14]

Embedded APIs

The Embedded API is used for developing extensions to the Alfresco content application server. Extensions deployed into the server often depend on existing services provided by the server. Therefore, developers of extensions use the Embedded API to gain access to those services.

The Embedded API comes in several forms, where each form is structured for a particular need or kind of extension:
  • Alfresco Public Java API [20] - a set of public Java interfaces exposed by services built into the Alfresco content application server
  • JavaScript API - an object-oriented view of the Java Foundation API specifically tailored for use in JavaScript. There is a JavaScript API for the repository tier [21] and a JavaScript API for the Share tier [22].
  • FreeMarker API [23] - an object-oriented view of the Java Foundation API specifically tailored for use in FreeMarker templates
  • Content Definition - an API for creating and editing content models
  • Workflow Definition - an API for defining business processes

The JavaScript and Template APIs are the key building blocks for web scripts to develop the RESTful APIs.

Web scripts are a popular extension for the Alfresco content application server. They allow you to define your own Remote API for clients to interact with the Alfresco content application server. A web script implementation can use any of the Embedded APIs, such as the Public Java API, JavaScript, and FreeMarker, for its implementation. Developing your own Remote API is very useful for the following scenarios:
  • Exposing new extension services deployed into the Alfresco content application server to remote clients
  • Providing alternate batching or transaction demarcation of existing services
  • Creating a facade for integration with a third-party tool, such as a Forms engine

There is another use case for the Embedded API. An application or client can also directly embed the Alfresco content application server to inherit its suite of content services.

The infrastructure of the server means it can be deployed into a number of environments, not just as a web application. Essentially, the Alfresco content application server is treated as a library, where any of its services, including the content repository, can be chosen independently or mixed to provide a custom solution. The server can scale down as well as up.

Parent topic: APIs [7]

Remote APIs

The Remote API is primarily used to build ECM solutions against the Alfresco content application server.

There are three main remote APIs:

  1. Alfresco One API
  2. Repository REST API
  3. CMIS API

The Alfresco One API was introduced with Alfresco 4.x, and was present in the public cloud version of Alfresco. It provides the main remote API, and is the recommended API for developing remote client applications to work across cloud, on-premise and hybrid deployments of Alfresco. It comprises two sub-APIs, the Alfresco One REST API for gaining access to Alfresco-specific functionality such as Sites, and a standard CMIS API for repository manipulation and management. Alfresco SDKs such as the Mobile SDK for Android and the Mobile SDK for iOS both use the services of the Alfresco One API.

The Repository REST API provides a RESTful interface to the repository for client applications. If you have an HTTP client you can communicate with Alfresco. It is also easy to use with AJAX-oriented web clients. Alfresco Share remotely communicates with the Alfresco content application server exclusively through the Repository REST API. The Repository REST API is implemented via web scripts.

CMIS provides a standardized set of common services for working with content repositories. CMIS is not language-specific, it does not dictate how a content repository works, and it does not seek to incorporate every feature of every content repository. Alfresco provides an implementation of CMIS Web service and RESTful bindings, as well as a CMIS client API for use in Alfresco Surf and other environments.

Parent topic: APIs [7]
Related information
About CMIS [24]

Content modeling

Content modeling is a fundamental building block of the Alfresco content repository that provides a foundation for structuring and working with content.

Content modeling specifies how nodes stored in the content repository are constrained, imposing a formal structure on nodes that an ECM application can understand and enforce. Nodes can represent anything stored in the repository, such as folders, documents, XML fragments, renditions, collaboration sites, and people. Each node has a unique ID and is a container for any number of named properties, where property values can be of any data type, single or multi-valued.

Nodes are related to each other through relationships. A parent/child relationship represents a hierarchy of nodes where child nodes cannot outlive their parent. You can also create arbitrary relationships between nodes and define different types of nodes and relationships.

A content model defines how a node in the content repository is constrained. Each model defines one or more types, where a type enumerates the properties and relationships that a node of that type can support. Often, concepts that cross multiple types of node must be modeled, which the Alfresco content repository supports through aspects. Although a node can only be of a single type, you can apply any number of aspects to a node. An aspect can encapsulate both data and process, providing a flexible tool for modeling content.

Content modeling puts the following constraints on the data structure:

  • A node must be of a given kind.
  • A node must carry an enumerated set of properties.
  • A property must be of a given data type.
  • A value must be within a defined set of values.
  • A node must be related to other nodes in a particular way.

These constraints allow the definition (or modeling) of entities within the ECM domain. For example, many ECM applications are built around the notion of folders and documents. It is content modeling that adds meaning to the node data structure.

The Alfresco content repository provides services for reading, querying, and maintaining nodes. Events are fired on changes, allowing for processes to be triggered. In particular, the content repository provides the following capabilities based on events:

  • Policies: event handlers registered for specific kinds of node events for either all nodes or nodes of a specific type
  • Rules: declarative definition of processes based on addition, update, or removal of nodes (for example, the equivalent of email rules)

Models also define kinds of relationships, property data types, and value constraints. A special data type called content allows a property to hold arbitrary length binary data. Alfresco comes prepackaged with several content models. You can define new models for specific ECM use cases from scratch or by inheriting definitions from existing models.

  • Content metadata model [25] Content modeling is about metadata; data describing data. Content modeling in Alfresco refers to a four-layer metadata model.
  • Deploying a content model [26] A content model is defined in its entirety as a single XML document that must comply with the content metamodel XSD schema provided by the Alfresco content repository. Each model contains a set of related and coherent definitions and is deployed as a unit.
  • Content metamodel [27] Defining a content model is expressed in terms of the content metamodel.
  • Out-of-the-box models [28] The content repository comprises several content models out of the box for specifying the core content types of an ECM system. They are expressed in terms of the content metamodel and provide a set of samples on which to base custom content models.
  • Localizing models in Alfresco Share [29] Every type, aspect, property, association, constraint, and data type defined in a model has a title and description. Both of these values are provided in the model XML file but only one language is supported, which is the language of the values specified in the XML file.
  • Alfresco content models and CMIS [30] CMIS defines a data model, which encapsulates the core concepts found in most content repositories. Alfresco provides an implementation of the CMIS bindings and maps the Alfresco content metamodel to the CMIS domain model. This allows content models defined in Alfresco to be exposed and manipulated by using CMIS.
  • Content Model Tutorials [31] You will learn how to create a custom content model and deploy it through a series of tutorials.
Parent topic: Alfresco architecture [14]
Parent topic: Developing [32]

Protocols

The Alfresco content application server supports many folder and document-based protocols to access and manage content held within the content repository using familiar client tools.

All the protocol bindings expose folders and documents held in the Alfresco content repository. This means a client tool accessing the repository using the protocol can navigate through folders, examine properties, and read content. Most protocols also permit updates, allowing a client tool to modify the folder structure, create and update documents, and write content. Some protocols also allow interaction with capabilities such as version histories, search, and tasks.

Internally, the protocol bindings interact with the content repository services, which encapsulate the behavior of working with folders and files. This ensures a consistent view and update approach across all client tools interacting with the Alfresco content application server.

An Alfresco subsystem for file servers allows configuration and lifecycle management for each of the protocols either through property files or JMX.

Supported protocols include:

CIFS (Common Internet File System)
CIFS allows the projection of Alfresco as a native shared file drive. Any client that can read and write to file drives can read and write to Alfresco, allowing the commonly used shared file drive to be replaced with an ECM system without users even knowing.
WebDAV (Web-based Distributed Authoring and Versioning)
WebDAV provides a set of extensions to HTTP for managing files collaboratively on web servers. It has strong support for authoring scenarios such as locking, metadata, and versioning. Many content production tools, such as the Microsoft Office suite, support WebDAV. Additionally, there are tools for mounting a WebDAV server as a network drive.
FTP (File Transfer Protocol)
FTP is a standard network protocol for exchanging and manipulating files over a network. This protocol is particularly useful for bulk loading folders and files into the Alfresco content repository.
IMAP (Internet Message Access Protocol)
IMAP is a prevalent standard for allowing email access on a remote mail server. Alfresco presents itself as a mail server, allowing clients such as Microsoft Outlook, AppleMail, and Thunderbird to connect to and interact with folders and files held within the Alfresco content repository. IMAP supports three modes of operation:
  1. Archive: allows email storage in the Alfresco content repository by using drag/drop and copy/paste from the IMAP client
  2. Virtual: folders and files held in the Alfresco content repository are exposed as emails within the IMAP client with the ability to view metadata and trigger actions using links embedded in the email body
  3. Mixed: a combination of both archive and virtual
Microsoft SharePoint Protocols
Alfresco Office Services support Microsoft SharePoint Protocols. This allows Alfresco to act as a SharePoint server, creating tight integration with the Microsoft Office suite. A user who is familiar with the Microsoft task pane can view and act upon documents held within the Alfresco content repository. Collaborative features of Microsoft SharePoint are mapped to Alfresco Share site capabilities.
Parent topic: Alfresco architecture [14]

Modularity

The Alfresco system is modular. Every moving part is encapsulated as a service, where each service provides an external face in a formally defined interface and has one or more black-box implementations.
The system is designed this way to allow for:
  • Pick and mix of services for building an ECM solution
  • Reimplementation of individual services
  • Multiple implementations of a service, where the appropriate implementation is chosen based on the context within which the solution is executed
  • A pattern for extending Alfresco (at design and runtime)
  • Easier testing of services

To support this approach, Alfresco used the Spring framework for its factory, Dependency Injection, and Aspect-Oriented Programming (AOP) capabilities. Services are bound together through their interfaces and configured using Spring’s declarative Dependency Injection.

A service interface is defined as a Java interface. For services that form the internal embedded API for extensions, cross-cutting concerns such as transaction demarcation, access control, auditing, logging, and multi-tenancy are plugged in through Spring AOP behind the service interface. This means that service implementations are not polluted with these concerns. It also means the cross-cutting concerns can be configured independently or even switched off across the server if, for example, performance is the top-most requirement and the feature is not necessary.

Multiple services are aggregated into an Alfresco subsystem where a subsystem represents a complete coherent capability of the Alfresco server, such as authentication, transformation, and protocols. As a unit, subsystems have their own lifecycle where they can be shut down and restarted while the Alfresco server is running. This is useful to disable aspects of the server, or reconfigure parts of it, such as how LDAP synchronization is mapped. Each subsystem supports its own administration interface that is accessible through property files or JMX.

Parent topic: Alfresco architecture [14]

Alfresco web application framework

Alfresco Share and all new Alfresco web applications are built on Alfresco Surf. This web application framework provides the typical features of this kind of framework and supports web content management needs.

At the heart of Alfresco Surf is a site assembly framework that bundles a full site construction object model and toolkit for building websites and applications.

Its features include:
  • A Site Dispatcher to create pages easily, link them to the overall navigation of a website, and build pages in a way that promotes reusability.
  • Templates for defining a page layout once and then reusing it across a large set of pages. You can develop pages using FreeMarker, JSP, HTML, or Java.
  • A UI Library containing reusable UI components comprising back-end application logic and front-end presentation code that can be bound into regions (or slots) within a page or template.
  • Pages that you can render in multiple formats, such as print, PDF, or mobile device.
  • AJAX support for integration with the Yahoo! User Interface (YUI) library.
  • Forms in a rich forms engine for rendering and collecting data.

Alfresco Surf embeds Spring web scripts, allowing developers to use the same techniques that were used when building Alfresco content application server RESTful APIs. Often, a Alfresco Surf website requires access to and management of content held within the application content server, such as to support user-generated content, dynamic site artifacts, personalized presentation, and tagging. To support this, Alfresco Surf provides the following integration services:
  • Remote: encapsulates any number of data sources with out-of-the-box support for the Alfresco content application server
  • Credentials: manages user authentication with out-of-the-box support for the Alfresco content application server
Alfresco Surf works with Alfresco web content management and provides virtualized content retrieval, preview, and test support for user sandboxes and web projects. Applications built with Alfresco Surf can be deployed from Alfresco web project spaces to production servers. To facilitate this, Alfresco Surf uses a lightweight XML-driven model to represent all site artifacts, such as pages, templates, themes, and chrome. This means that Alfresco services, such as change sets, preview, and deployment, can manage Alfresco Surf sites. In addition, an embedded API supports programmatic control of the same artifacts (see the following figure).

As Alfresco Surf sites are XML and file-based, they are easily managed in Alfresco WCM, as shown in the following figure:

It offers features such as:
  • Safe editing of all Alfresco Surf artifacts, including the ability to snapshot a site and roll it backward in time
  • Review and Approve workflow of Alfresco Surf site changes
  • Preview of site changes
  • Deployment of site changes to test or production servers

With the CMIS client API, Alfresco Surf provides an open stack for implementing web-based, content-enabled applications.

Alfresco 5.0 includes the new UI framework built on Alfresco Surf, Aikau [33]. Aikau provides a modern, higher-level approach to developing custom UI applications, and features a simplified method for creating pages and widgets. New pages with standard widgets can be created through JSON code, and then extended as required using JavaScript.

Parent topic: Alfresco architecture [14]
Related concepts
Working with the Surf framework [34]

Deployment options

You can deploy Alfresco in many different forms and topologies. Because its infrastructure foundation protects Alfresco from the environment within which it executes, you can choose components such as operating system, database, application server, web browser, and authentication system. Alfresco is designed to scale down as well as up.

Embedded Alfresco

An embedded Alfresco is contained directly within a host where the host communicates with Alfresco through its embedded API, meaning the host and Alfresco reside in the same process. Typical hosts include content-rich client applications that require content-oriented storage, retrieval, and services, but can also include hosts such as test harnesses and samples. A client can choose to embed the Alfresco web application framework or content application server, or both, treating Alfresco as a third-party library. In any case, the client can pick and mix the services of Alfresco to embed, allowing very small-footprint versions of Alfresco. The host is responsible for the startup and shutdown of Alfresco.

Alfresco content application server

An Alfresco content application server is a stand-alone server capable of servicing requests over remote protocols. A single server can support any number of different applications and clients where new applications can be arbitrarily added. Clients communicate with Alfresco through its Remote API and protocol bindings, although you can configure a server to omit or prohibit specific access points. This type of deployment takes advantage of an application server where Alfresco is bundled as a web application. Application server features, such as transaction management and resource pooling, are injected into the Alfresco infrastructure foundation, allowing Alfresco to take advantage of them.

For example, you can embed the Alfresco content application server inside Apache Tomcat for the lightest-weight deployment, as well as inside Java Enterprise Edition compliant application servers from JBoss, Oracle, or IBM to take advantage of advanced capabilities such as distributed transactions.

Clustered Alfresco

To support large-scale systems, you can cluster Alfresco. This lets you set up multiple Alfresco servers to work with each other, allowing client requests to be fulfilled across a number of processors. You can cluster both the Alfresco web application framework and content application server, allowing each tier to scale out independently. Each node of a clustered Alfresco content application server shares the same content repository store, although the store itself can be replicated across the nodes, if required. Caches and search indexes are also distributed, meaning that a clustered content application server looks and acts like a single content application server.

Typically, a load balancer is placed in front of the clustered Alfresco content application server to distribute requests across the nodes. This setup also supports Cloud deployments. Alfresco provides images and tools for easily deploying a clustered Alfresco content application server across multiple Amazon EC2 virtual nodes.

Backup server

This is a special case of the clustered deployment where, in case of failure, an application can switch to a backup version of the deployed stack. Depending upon configuration, the backup version might be available immediately on failure (known as hot backup) or shortly after failure, following some configuration changes (known as warm backup). One of the nodes in the cluster is designated the master, which supports the live application, while the other node is designated the slave, which keeps itself replicated with the master. The slave remains read-only until the point of switchover.

Multi-tenancy

Multi-tenancy allows a single Alfresco content application server (clustered or not) to support multiple tenants, where a tenant such as a customer, company, or organization believes they are the only user of the server as they connect to a logical partition. Physically, all tenants share the same infrastructure, such as deployed nodes in a cluster and content, repository storage. However, data maintained by one tenant cannot be read or manipulated by another tenant. A deployment of this type eases administration and reduces the cost associated with maintaining many different applications and user bases, in particular when upgrading core services or performing backups, as this only needs to be done once for all tenants.

Alfresco provides administration tools for managing tenants, including the creation of tenants at runtime. In conjunction with clustering, multi-tenancy provides an ideal deployment option for the Cloud.

Parent topic: Alfresco architecture [14]

Source URL: https://docs.alfresco.com/5.0/concepts/alfresco-arch-about.html

Links:
[1] https://docs.alfresco.com/../concepts/alfresco-principles.html
[2] https://docs.alfresco.com/../concepts/surf-about.html
[3] https://docs.alfresco.com/../concepts/content-server-about.html
[4] https://docs.alfresco.com/../concepts/content-repo-about.html
[5] https://docs.alfresco.com/../concepts/serv-about.html
[6] https://docs.alfresco.com/../concepts/models-about.html
[7] https://docs.alfresco.com/../concepts/api-about.html
[8] https://docs.alfresco.com/../concepts/content-modeling-about.html
[9] https://docs.alfresco.com/../concepts/protocols-about.html
[10] https://docs.alfresco.com/../concepts/spring-fw-modularity.html
[11] https://docs.alfresco.com/../concepts/web-app-framework.html
[12] https://docs.alfresco.com/../concepts/deploy-options.html
[13] https://docs.alfresco.com/../concepts/system-about.html
[14] https://docs.alfresco.com/../concepts/alfresco-arch-about.html
[15] https://docs.alfresco.com/../concepts/serv-repo-about.html
[16] https://docs.alfresco.com/../concepts/serv-application-about.html
[17] https://docs.alfresco.com/../concepts/serv-using-about.html
[18] https://docs.alfresco.com/../concepts/arch-api-embedded.html
[19] https://docs.alfresco.com/../concepts/arch-api-remote.html
[20] https://docs.alfresco.com/java-public-api-list.html
[21] https://docs.alfresco.com/API-JS-intro.html
[22] https://docs.alfresco.com/../references/APISurfPlatform-intro.html
[23] https://docs.alfresco.com/../references/API-FreeMarker-intro.html
[24] https://docs.alfresco.com/../pra/1/topics/cmis-welcome.html
[25] https://docs.alfresco.com/../concepts/metadata-model.html
[26] https://docs.alfresco.com/../concepts/content-model-deploy.html
[27] https://docs.alfresco.com/../concepts/metadata-model-define.html
[28] https://docs.alfresco.com/../concepts/content-model-preconfigured.html
[29] https://docs.alfresco.com/../concepts/content-model-localization-share.html
[30] https://docs.alfresco.com/../concepts/content-model-cmis.html
[31] https://docs.alfresco.com/../concepts/dev-extensions-content-models-tutorials-intro.html
[32] https://docs.alfresco.com/../concepts/dev-for-developers.html
[33] https://docs.alfresco.com/aikau-intro.html
[34] https://docs.alfresco.com/surf-fwork-intro.html