WCM Overview

[resplin]

Obsolete Pages{{Obsolete}}

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

{{AVMWarning}}
AVM2.2

Table of Contents

• 1 When to use WCM in addition to DM?


• 2 What is the AVM?


• 3 What are AVM Layers?


• 4 What are Alfresco Web Projects?


• 5 What is an Alfresco Web Project Sandbox?


• 6 What is Virtualization?


• 7 What are Alfresco Web Project Workflow and Workflow Sandboxes?


• 8 What is Alfresco Deployment?

When to use WCM in addition to DM?

WCM is generally more appropriate to build and deploy web sites.

Using DM only, you get:

• A Content-Type model (with metadata properties, inheritance etc.),
  
• Rule triggers (on update / addition / deletion),
  
• Behaviours,
  
• Aspects,
  
• Workflows,
  
• Associations,
  
• Actions,
  
• Access control,
  
• Simple document versioning (no folder versioning)
  

Using the WCM in addition to DM, you get:

• Content modelling is done using XML/XSDs of the content nodes themselves,
  
• Workflows,
  
• Aspects (through XML meta-data extraction),
  
• An Advanced versioning model (branching, merging, folder versioning, etc),
  
• Sandboxed editorial environments,
  
• Access control (not quite as granular as the ADM... I think),
  
• Preview services,
  
• Link Validation,
  
• Advanced remote Deployment features,
  
• Web-forms (XSD/template separation of content from presentation)
  

WCM may be made to reuse content from DM.

What is the AVM?

The Alfresco repository currently supports two store implementations, ADM and AVM.  Alfresco AVM is an advanced store implementation designed to support the version control requirements of managing large websites and web applications.  The AVM consists of a forest of content stores that can be used to manage the development and staging of web content and associated source code.  Each AVM store is loosely modeled on Subversion, providing source code control for websites.  Each AVM store supports an extended versioning model, including:

•   File-level version control
  
•   File-level branching
  
•   Directory-level version control
  
•   Directory-level branching
  
•   Store-level version control (snapshots)
  
•   Store-level branching
  

In addition to these extended versioning operations, the AVM also supports the following capabilities:

•   File version comparison
  

•   Between two file versions on the same branch within a single store
  
•   Between two file versions on different branches within the same store
  
•   Between two file versions between any two stores
  

•   Directory version comparison
  

•   Between two directory versions on the same branch within a single store
  
•   Between two directory versions on different branches within the same store
  
•   Between two directory versions between any two store
  

•   Store version comparison
  

•   Between two versions of any single store
  
•   Between any two stores
  

AVM's support for file, directory, and store comparison provides the basis for synchronization operations, for example, to synchronize any two branched versions of a source tree within an AVM store or maintained in separate AVM stores.

For more information see Versioned Directories.

What are AVM Layers?

Layers are a special AVM construct that enable transparent sharing of resources across different AVM stores. AVM supports both file and directory layers.

A layered file created within an AVM store can point to a file in any other AVM store (so long as that second AVM store is resident on the same Alfresco repository server instance). If the source file is updated, all stores with a layered file targeting that source are instantly and transparently updated. In this manner, layered files provide automatic resource updates across both branches and stores without requiring any explicit synchronization operations, operating much like a symlink in a UNIX system. Unlike a symlink, however, layered files enable local modification in the target store without losing the underlying reference to the source asset. If, for example, both the source file and that layered file are modified, that layered file is considered to have a unique instance of the file and the change to the underlying source file is masked out by the modification directly made to the layered file. At any point, any local modification to the layered file can be uncovered to expose the current state of the source asset. If a layered file is updated in an AVM store, that change is, therefore, not reflected back into the source asset, and thus no other store that has a layered file pointing to that same asset is affected by any other stores decision to create a unique instance of that asset.

The AVM likewise supports a concept of layered directories. Layered directories allow for entire hierarchies of content to be transparently shared across AVM stores. Any content added, deleted, or modified with the source directory targeted by a layer are transparently and immediately visible to all other AVM stores. These content updates include changes to both files and directories. Like layered files, layered directories support local modification, where any local modification 'masks out' any corresponding update to the underlying source directory (which remains unmodified, and therefore leaves all other AVM stores with a layered directory pointing to that same source unmodified as well). In this manner, a user in one store can add, delete, or modify any resource to a layered directory, which would be considered unique to that store instance. Any adds, deletes, or modifications to the underlying source store, as long as it is not in conflict with any changes made in the layered directory, are transparently and immediately reflected. This, for examples, lets each store share a common source tree of assets and stay constantly in sync upon any changes while support a private set of modifications unique to each store.

For more information see Transparent Layers.

What are Alfresco Web Projects?

Alfresco Web Projects are a collection of AVM stores implemented to support a development and staging model for changes to website content and source code assets. Separate AVM stores are used to represent different development states of the websites.  AVM layered directories are used within each store to support a different development state of the website. This use of layered directories enables support of a virtual view of all resources associated with the website by targeting a common source tree.  Changes made within a layered directory within any AVM store dedicated for some development activity ultimately synchronize back with the source directory, allowing finalized sets of changes to be transparently shared with all other AVM stores. This set of updates to the common source directory can be tracked by versioning the source directory upon each update, which in the case of an Alfresco Web Project, involves versioning the entire source AVM store (the root directory) via snapshoting.

An Alfresco Web Project is created via Alfresco's Web Project wizard. This wizard automates the creation of a source store of web assets and a default set of stores dedicated to website development that implement a layered directory to share resources with a common parent. The source store is labeled as Staging Sandbox and each store dedicated to development is labeled a User Sandbox. The number of store dedicated to development corresponds to the number of users invited to the Web Project, with each user given by default their own store for maintaining a virtual view of all web resources to allow private, in-context modification of the websites. Changes made to any User Sandbox are synchronized with the source Staging Sandbox using a Web Project's Submit action. This Submit action both synchronizes the source Staging Sandbox and automates the versioning of the Staging Sandbox upon any update (creation of a new version of the Staging Sandbox via snapshoting). This Submit action also automates the kick-off of any workflow associated with asset updates, if workflow is configured for the set of changes made within a User Sandbox. By updating the source Staging Sandbox, any committed set of changes made in any User Sandbox become immediately available to every other User Sandbox via their layered directory (unless they have a locally modified version of that same updated resource or resources). By versioning the source Staging Sandbox via snapshots, a complete history of any and all updates are maintained, providing both a rich audit trail as well as an ability to rollback any set of changes by reverting to an earlier store version (which in turn updates all User Sandboxes layered atop the source Staging Sandbox). This combination of Staging Sandboxes, User Sandboxes, layered directories, submit actions, optional workflow, and snapshots allows a Web Project to implement a default production model of virtual development and staging servers, allowing end-users the ability to work in a virtual view of an entire website or web application and easily synchronize and share finalized, working sets of changes with others in a simple, easy manner.

For more information see Collaborative Content Production.

What is an Alfresco Web Project Sandbox?

An Alfresco Web Project Sandbox is a synonym for an AVM store. The term sandbox is used within the context of the Alfresco Web Client to denote an AVM store that has a development context rooted atop an Alfresco Staging Sandbox via a layered directory.  This term is used within the Web Client as this configuration of AVM store via a Web Project supports a sandboxed development model, that is, each user can make changes to a website completely independently of other users, test and preview them via Alfresco's integration Virtualization Server, and then commit them to a shared common Staging Sandbox to update all other users working on the website. Server-side, however, each sandbox denoted in the GUI represents a unique AVM store, and server-side each AVM store is a unique, first-class citizen whose relationship with other stores is completely arbitrary based on the layered directory relationship created via an Alfresco Web Project.

What is Virtualization?

Virtualization is the ability to provide in-context preview of a website or web application in the context of an AVM store or sandbox. Whereas layered files and directories can virtualize a development context at an asset level with a store (whether browsed via Alfresco's API, Web Client, or CIFS interface), Alfresco's Virtualization Server virtualizes a source tree of assets from the perspective of a web server/application server. Alfresco's Virtualization Server is implemented as a dedicated servlet engine based on Apache's Tomcat that implements a custom set of valves and filters in order to efficiently render a full in-context view of an entire functioning website or web application for any given sandbox without requiring the set-up and configuration of numerous web server or application server instances. This virtualization logic implemented in the custom set of valves and filters used in Alfresco's dedicated servlet instance, Alfresco's Virtualization Server, also minimizes in-memory footprint of application resources (*.jars, for example) shared via layered directories. This enables massive parallel development by the end-user of different sets of updates to the website with full preview capabilities all from a single servlet instance without massive increase in server resources.

For more information see Virtualization FAQ Page.

What are Alfresco Web Project Workflow and Workflow Sandboxes?

Alfresco Web Project leverages jBPM to support routing of sets of changes (collections of added, deleted, or modified files and directories) through any set of automated or user-driven steps in a business process before final commit to the shared common Staging Sandbox. The unique set of changes made within the layered directory in a User Sandbox can be added to the list of resources associated with the initial start-up task of the workflow instance. 

To support proper in-context preview by reviewers of a submitted set of changes, Alfresco's default workflow implementation for Web Project automatically created a dedicated store for each set of items submitted for approval, a Workflow Sandbox. This Workflow Sandbox is implemented in a similar manner as a User Sandbox, created as a dedicated AVM store with a layered directory whose source target is the root directory of the Staging Sandbox. In this manner, all end-users in the content review chain are afforded an in-context preview of what the Staging Sandbox would look like if, and only if, that exact set of updates were approved and committed to the Staging repository. Once approved and committed to Staging, the Workflow Sandboxes are removed from the server as they are no longer need (they exist only as temporary stores to provide an in-context preview and editing environment for a unique set of modifications associated with a workflow task).

What is Alfresco Deployment?

Deployment is the concept of taking a specific version of the Staging Sandbox - snapshot - and replicating it in a transactional, auditable manner to one or multiple target end-points. These end-points can be either file systems or other Alfresco AVM stores, either on the same local server or any number of remote servers. Natively, any installed Alfresco server instance can support deployment to and from any other installed Alfresco server. For file systems, Alfresco provides a separate, light-weight, Spring-configured Java application to support the transactional, incremental replication of a set of resources to any remote file system on which Alfresco's File system Deployment Receiver is installed.

When deploying to either a local or remote Alfresco server, Alfresco's deployment services detect and synchronize a remote AVM repository associated with each given Staging Sandbox. This target repository for deployed Staging snapshots is called the live repository and is the repository version used to support delivery of content via a website or web application to content consumers.  Upon first deployment to an Alfresco end-point, if a corresponding live content repository does not exist, Alfresco's deployment service automatically creates the live content store and does a full synchronization. Upon either a full or incremental synchronization, the live content repository is snapshoted, allowing each Alfresco live content repository end-point to maintain its own version history of updates for auditable (and potential) rollback purposes. 

Alfresco's Deployment between Staging and Live repositories leverages the same underlying synchronization services used to synchronize User Sandboxes, Workflow Sandboxes, and Staging Sandboxes. In the case of deployment, synchronization is done over-the-wire using Alfresco WCM's remote API, AVMRemote, with special business logic for handling both live repository creation (should a live content repository not exist) along with live repository snapshoting (upon successful completion of deployment). Aside from the use of a remoting interface and wrapper logic for automating other tasks associated with deployment, Alfresco Deployment essentially is another manifestation of an underlying capability in the AVM's advanced versioning model, its ability to synchronization any two files, directories, and content repositories in a fast, efficient, transactional manner - whether on the same physical server machine or a remote server machine.

For more information see WCM Deployment Features.