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 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

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.

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:

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.

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.