DevCon Presentation WCM to WCS Final - Alfresco Devcon

bammobInternet and Web Development

Dec 4, 2013 (4 years and 7 months ago)


WCM to WCS Migration

Times are a changin’

Today’s Web is not the Web of 2005.

Web sites are built differently

Web Content is “authored” differently

Web sites are assembled by a team made up of
diverse skills

There are many Web Content Use cases
where the AVM provides no advantage
over the Core Repository.

The Core Repository has gotten the lions
share of attention over the past few years.

Many of the compelling features of the
AVM have been added to the Core

As of Alfresco 4.0 the AVM is being


Records Management

Web Content


Open Source Platform

A Fundamental Shift

Alfresco is an Enterprise Content Management

Web Content is
enterprise content

Web Content Services provides a means for
making content available on the web in a scalable

Do I have to change?

Option 1: Continue with the Status Quo

If you are running Alfresco 3.x and using the AVM,

solution will continue to be supported until Alfresco 5


Option 2: Upgrade to Alfresco Enterprise 4, and continue using

If you are an existing Alfresco Enterprise AVM customer, you may upgrade to
Alfresco Enterprise 4 and you will continue to be supported with AVM until Alfresco
6 is released.

Option 3: Upgrade to Alfresco Enterprise 4 and switch to the core
repository with one of our Web Content Services approaches

You can only delay change for so long. Plan now to
minimize the downside and take full advantage of the

What are Web Content Services?

Supporting a diverse set of web content use cases

Alfresco’s Web Content Services are a set of
open content services
that deliver web
ready content
to today’s content
rich web
applications, portals and social media sites

Alfresco Web Content Services are built on the three following

A Core Alfresco Repository (Authoring Tier)
that handles process, workflow,
record keeping, auditing, transformations and the content creation

A CMIS Compatible web tier repository, suited to dynamically deliver content to any
web tier framework (e.g. Drupal, Liferay, CrafterRivet or your own custom App.

File System Transfer Receiver that delivers static assets.

These three components are connected via Transfer Services.

Differences Between our WCS and
WCM implementations

The AVM provides three features that have no equivalent in the
Core Repository


Multi Asset Versioning

Snapshots and Roll Back.

The Core Repository has a number of features that are not
available in the AVM

Support for Rules

More sophisticated Access Control

CMIS Support

More complete functionality in a number of area including search,
workflow, APIs, modeling, metadata extraction and content

Impact of the WCM and WCS

The WCS web tier has all of the functionality that is
available in the WCM web tier.

The additional and expanded features in the DM based
authoring tier should provide improvements for content

The features that are not available in the Core Repository
are useful for a small and shrinking set of use cases.

Characteristics of Sites that the AVM
was designed for.

Sites that were versioned and released for deployment as a
complete unit.

Sites where page changes included a large number of
assets whose changes needed to be grouped together.

Sites that deploy code (theming or operational) and content

Sites that have these characteristics will need to be reviewed
soon to determine the path forward.

Characteristics of Emerging Use Cases

Content items have fewer interdependencies.

Content on the same site may come from different sources.

Content may be targeted to multiple sources.

Content may appear on the web as a small part of a larger

These characteristics to not require the deprecated WCM

So is there Life After the AVM?

Yes….. But….

Projects with a heavy dependency on the AVM will need to be
engineered, re
architected and will undergo process

Projects that naturally lend themselves to Web Content
Services will still need a fair amount of renovation.

There will be benefits but they do not come for free

Some examples of Issues to contend

The content modeling is different.

The user interface uses a different framework

Deployment tools are different

The Problem with the old Web Forms

Web Forms defined the UI and the Content model together.

The constraint validation is done at the UI layer and not at
the Repo layer.

This makes it difficult to validate ingested content

Similar to the way many lighter weight CMSs approach
creating types

easy for quick definition of a content type
and it’s capture form.

Low entry threshold, inflexible to go beyond what this is
initially designed for.

Conversion Example Content Model

<?xml version=

<xs:schema xmlns:xs=

"" elementFormDefault="qualified">

<xs:element name=



<xs:element name=
"title" type="xs:normalizedString" />

<xs:element name=
"teaser" type="xs:normalizedString" />

<xs:element name=
"publish_date" type="xs:date" minOccurs="0" />

<xs:element name=
"is_feature" type="xs:boolean”
"0" />

<xs:element name=
"body" type="xs:string" />

<xs:element name=
"related_links" minOccurs="0" maxOccurs="10">



<xs:element name=
"link_text" type="xs:normalizedString"

<xs:element name=
"link" type="xs:anyURI" />








XSD to Content Model

DM can model anything that the XSD can model

Cardinality can be handled with required and multiple and perhaps a
constraint where needed.

content relationships can be handled with nodeRefs
(versioned) or Relationships (not versioned).

Complex Metadata Types can be an issue.

Bundle the value in a serialized version of the composite property

Have a set of parallel multi
valued properties.

Use child objects

Altering the Data Dictionary to support proper composite properties
is quite ambitious

Unified Modeling Scheme for all content

Rather than XSD which was not designed to content modeling, we
have a modeling language that is tailored to the Repository.

Web Form XSD to Forms SDK

Like the Web Form XSD, the Share based Forms will pick
reasonable default UI components for a piece of content

Both have OOTB Widgets

Both allow for custom widgets

Web Forms uses Dojo

Forms SDK uses YUI

Developers can also use widgets in UIs build on other

The Repository enforces data integrity with constraints and what not

Developers can write Helper webscripts to populate pickers and
select lists

Changes in Deployment

The deployment tools are similar.

But….. there are some differences

If you have extended any of the deployment tools you will
need to revisit some of the code.

This is a non Trivial Migration

Risk vs Reward

There is a definite cost to conversion

There are benefits in performance, clarity of development process,

High Level Generic Conversion Process

Assessment and Vision

Brainstorming/White Boarding/Protoyping/POC/Enablement

Develop Credible Plan


Partner Products

Lot’s of opportunities to solve problems based upon use cases

Some partners already have solutions based upon their experience

Opportunity for Alfresco/Partner collaboration here.


Walking Through the process

Assessment and Vision

Analysis of the current use case.

Does the current process work?

Are there improvements that can be made

Are there features that are left out that will hinder adoption

Is this important enough to renovate?

Can this be absorbed into another process?

Should this be completely re

Build a Technical Inventory of

things that need conversion



ui widgets



deployment schemes

Usability Analysis

Distinct Roles/User profiles

Key "cannot live without" features

Processes that could be streamlined

Brainstorming and White Boarding

Familiarizing the Project on the conversion process (as it
relates to Alfresco)

Have a whiteboading/brainstorming session

Discuss competing strategies

Talk about potentially expensive tasks

Bucket features into (Must, Should, Can, Won’t)

Talk about Actors

engineering Opptys.

Prototyping and Enablement

Identify a representative set of items that could be done
quickly and represent go/no go items

Identify items that will allow the development team to gain
some insights in to the process.

Develop Credible Plan

Review the lessons learned in the prototyping session.

Understand the areas of technical risk.

Talk to the stake holders.

Discuss any changes that the business users might incur

Identify the resources that will be needed

Consider getting help from a partner or consulting.


Armed with a well thought out plan, you will be prepared to

Plans notwithstanding, you will most likely be in uncharted

Don’t be surprised if there are bumps in the road.


Moving to Web Content Services will become necessary at
some point

In general there is much to gain from the process

It is a non trivial process

Be prepared to commit resources to it.