Hyland Connect

resplin · ‎06-05-2015

The official documentation is at: http://docs.alfresco.com

Introduction

This page is intended to be a brief summary of all the components involved in the process of setting up the Web Content Management (WCM) deployment facility of Alfresco. 'Components,' in this context, are defined as 'items which must be configured using Spring configuration'. The difference between an authoring server and a deployment server is introduced. Associations between server and component are declared. Configuration details for components are deferred to other pages.

This page describes the WCM facility in Alfresco community edition 3.2r2, and attempts to distill the concepts presented on WCM Deployment Features. If you are using a different version, the advice here may or may not apply.

WCM nuts and bolts

At the coarsest level, the model of WCM implemented by Alfresco may be represented by two major functions: 'authoring' and 'serving'. The authoring function, in general, may be performed by web application developers or by those responsible for content of a website. The serving function is also quite general, and may be performed by Alfresco itself (as either a DM or AVM repository), a Java servlet container such as Tomcat, Jetty or Jboss, a more general purpose webserver, such as Apache httpd or Microsoft IIS, or even a plain file server.

One unique attribute of Alfresco's WCM model is the openness: content does not need to conform to a specific framework in order to be managed by Alfresco. It also does not need to be formatted in a specific manner: Alfresco can handle a Java web app, a PHP application, raw HTML, or a directory full of PDFs. Alfresco WCM facilitates the collection and repeatable deployment of a set of files by a team of individuals authorized to manage that file set. It also facilitates the reconstruction of a website as it existed at a given point in time.

The model allows only for the transfer and management of files. Many modern applications for the presentation of information on the web store the actual information in a database. While Alfresco could manage the files containing the code for a MediaWiki site, a Joomla! site, or a Drupal site, for instance, backing up the web project would not safeguard the content of such sites, which resides in a database. Likewise, a database backup alone does not preserve configuration files, customizations, or any 'attachments' necessary for the website to be complete.

The task of deploying exactly the same files (representing the same web app with the same plugins, extensions, modules, and attachments) to multiple servers could be managed using Alfresco. Key benefits to using Alfresco to synchronize the files are:

Alfresco transmits only changed files, not everything.
Alfresco keeps track of what 'snapshots' were deployed to which servers.
Alfresco can compress the files which need to be transfered on the fly.
Alfresco can encrypt the files for transfer.
System admins can define very specific targets for deployment and control who has permission to deploy to those targets, without granting shell access to the server machine or creating an account on the server.

Highlights of the WCM Deployment facility may be found here. Note there is mention of a 'Preview' feature where Alfresco attempts to display the website snapshot prior to deployment. The preview facility makes certain assumptions about the nature of the files being managed (e.g., they constitute a java web application), and is thus only applicable when that assumption is accurate. For anything but raw HTML and java web apps, the appropriate workflow is to deploy to a test server, then point your browser at the test server.

The remainder of this page describes the components (relevant to deployment) which reside on an authoring server and those which reside on a 'deployment receiver' (e.g., anything which can receive content from an authoring server.) In addition, those shared components which define the connection protocol, compression, and encryption are described.

Authoring Server Components

The authoring server always runs within an Alfresco server which has WCM functionality enabled. This section focuses only on components and configuration having to do with communication with a deployment receiver.

Configuration of the authoring server is a two-stage process. Spring configuration is performed by the administrator to define the set of permissible options. Later, individual web projects are configured by the project owner (or those who have been given permission) thru the web interface, using the set of options defined by the administrator.

Spring configurable components

In the following table, 'o.a.r.d' represents the abbreviation of the package 'org.alfresco.repo.deploy'.

Component	Class
Deployment Service	`o.a.r.d.DeploymentServiceImpl`
RMI transport adapter	`o.a.r.d.DeploymentReceiverTransportAdapterRMI`
HTTP transport adapter	`o.a.r.d.DeploymentReceiverTransportAdapterSpringHTTP`
Hessian transport adapter	`o.a.r.d.DeploymentReceiverTransportAdapterHessian`

Configuration through the UI

Each web project has zero or more deployment receivers configured and made available for use. Each deployment receiver is configured using the following form:

Add Deployment Receiver.GIF

Detailed information about the meaning of each of these fields is given here. Briefly, this form lets you specify:

whether the server is a 'live' or 'test' server
what transport to use when connecting to it
the hostname and the port on which the deployment server is listening
the credentials to use during deployment
information about what files in the repository are not to be deployed
the name of the target on the deployment server.

The above form immediately demonstrates that each host/port/transport combination may control more than one target, which must be selected by specifying the target name. All four items must be specified in order to uniquely specify a destination. Note that all four items must be specified for every web project in which they are to be used. A web project cannot re-use a previously defined deployment receiver in a different web project.

Shared Transport Related Components

As described on this page, there are two sample 'transformer' objects which manipulate the communications channel between the authoring server and the deployment server. One transformer object compresses (or decompresses) the stream, and the other encrypts (or decrypts) it. These transformers must be configured on both the authoring server and on the deployment server. If a different operator is required, the interface to implement is given on that page as well.

In the following table, 'o.a.d.t' represents an abbreviation for the package 'org.alfresco.deployment.transformers'.

Component	Class
Compression	`o.a.d.t.CompressionTransformer`
Encryption	`o.a.d.t.SampleEncryptionTransformer`

Deployment Receiver Components

Version Note: The DM deployment receiver is not present in 3.2r2 Community, but is present in 3.2R Enterprise. The DM target will be available in 3.3 Community.

A 'deployment receiver' could be a 'stand-alone deployment receiver', or it could be a full-blown instance of Alfresco. The stand-alone deployment receiver is only capable of storing the deployed files in the filesystem, whereas a full instance of Alfresco is also capable of storing the files in a Document Management (DM) or advanced versioning management (AVM) space. The stand-alone receiver has a simple, configurable, single-user username/password authentication mechanism, which is unnecessary for deployment engines running within Alfresco itself.

By default, the stand-alone receiver has a single configured File System Deployment Target named 'default'. An alfresco instance has three default targets: 'filesystem' for the File System Deployment Target, 'avm' for an AVM Deployment Target, and 'alfresco' for a DM Deployment Target. These default configurations all support unencrypted, uncompressed Java RMI as the transport mechanism. Simple configuration modifications may be accomplished by setting the correct properties in alfresco-global.properties, but more complex changes must be handled with spring configuration.

In the following table, 'o.a.d' represents an abbreviation for the package org.alfresco.deployment.

Component	Class
Deployment Receiver Engine	`o.a.d.impl.server.DeploymentReceiverEngineImpl`
File System Receiver Service	`o.a.d.impl.fsr.FileSystemReceiverServiceImpl`
AVM Deployment Target	`o.a.d.impl.asr.AVMDeploymentTarget`
DM Deployment Target	`o.a.d.impl.dmr.DMDeploymentTarget`
Simple Root Locator	`o.a.d.impl.dmr.RootLocatorImpl`
Simple Store name mapper	`o.a.d.impl.dmr.StoreNameMapperImpl`
File System Deployment Target	`o.a.d.impl.fsr.FileSystemDeploymentTarget`
Deployment Target Registration Bean	`o.a.d.impl.server.DeploymentTargetRegistrationBean`
Command Queue	`o.a.d.impl.server.DeploymentCommandQueueImpl`
Command Queue Housekeeper	`o.a.d.impl.server.DeploymentCommandQueueHousekeeper`
Timeout Housekeeper	`o.a.d.impl.server.DeploymentTimeoutHousekeeper`
Simple Reader Management	`o.a.d.impl.server.ReaderManagementSimpleImpl`
Pooled Reader Management	`o.a.d.impl.server.ReaderManagementPool`
Nonblocking Reader Management	`o.a.d.impl.server.NonblockingReaderManagement`
Simple Authenticator	`o.a.d.impl.server.DeploymentReceiverAuthenticatorSimple`
Full Alfresco Authentication	`o.a.repo.deploy.DeploymentReceiverAuthenticatorAuthenticationService`

Two types of deployment receiver

Most of the components in the above table are common to all three deployment receivers. All receivers use the same deployment receiver engine, for instance. All of them can use the same authenticators, target registration beans, housekeepers, and command queues. However, the AVM receiver and the DM receiver are part of the Web Delivery Runtime (WDR) system and the filesystem receiver is not. The WDR receivers can safely assume that they will always run within an Alfresco instance, and the filesystem receiver cannot. The filesystem receiver has an extra layer, labeled above as the File System Receiver Service which stores values for some parameters, such as the location of temporary and log directories, as well as a flag indicating whether it is an error to overwrite files not managed by the deployer. The File System Receiver Service is essentially the extra overhead which allows the filesystem receiver to work outside of an Alfresco instance.

Aside from this major structural difference, certain components apply only to certain types of receivers. For instance, a store name mapper contains the logic required to map the path to an AVM object (on the authoring server) to a corresponding path in a DM repository. These components play a supporting role which is specific to a particular deployment target type.

Where to go from here

Alfresco allows a great deal of flexibility in deployment. Much flexibility is available out of the box, with simple configuration. More flexibility is available by implementing the missing piece you require. This section attempts to be an index to resources on the wiki which illustrate the configuration and customization of the WCM deployment function.

Configuration examples

Coding examples

Many interfaces are mentioned on WCM Deployment Engine as the various components are described. Example implementations are also mentioned. Locate these implementations within SVN to view examples.

References

Community Edition
3.2
3.2r2
AVM