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.
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.
The Alfresco content application server comprises a content repository and value-added services for building ECM solutions.
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.
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.
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:
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.
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:
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 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.
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.
The two main categories of API are embedded and remote APIs.
The JavaScript and Template APIs are the key building blocks for web scripts to develop the RESTful APIs.
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.
There are three main remote APIs:
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.
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:
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:
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.
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:
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.
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.
As Alfresco Surf sites are XML and file-based, they are easily managed in Alfresco WCM, as shown in the following figure:
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.
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.
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.
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