DevCon Presentation WCM to WCS Final - Alfresco Devcon

bammobInternet and Web Development

Dec 4, 2013 (3 years and 6 months ago)

114 views

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


As of Alfresco 4.0 the AVM is being
deprecated.




Document
Management



Records Management



Web Content
Services



Enterprise
Collaboration



Open Source Platform

A Fundamental Shift

Alfresco is an Enterprise Content Management
System….


Web Content is
enterprise content
.


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



Do I have to change?


Option 1: Continue with the Status Quo


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


solution will continue to be supported until Alfresco 5
is


released.


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


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

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
components


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


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


Sandboxes


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

Impact of the WCM and WCS
differences


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


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

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

These characteristics to not require the deprecated WCM
features.

So is there Life After the AVM?

Yes….. But….


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


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
with


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=
"1.0"?>

<xs:schema xmlns:xs=
"http://www.w3.org/2001/XMLSchema”
xmlns:trn=
"http://www.alfresco.org/training"

xmlns:alf="http://www.alfresco.org"
targetNamespace=
"http://www.alfresco.org/training" elementFormDefault="qualified">


<xs:element name=
"article">



<xs:complexType>




<xs:sequence>





<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”
minOccurs=
"0" />





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





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






<xs:complexType>







<xs:sequence>








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








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







</xs:sequence>






</xs:complexType>





</xs:element>




</xs:sequence>



</xs:complexType>


</xs:element>

</xs:schema>

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.


Inter
-
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
Frameworks.


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,
flexibility.


High Level Generic Conversion Process


Assessment and Vision


Brainstorming/White Boarding/Protoyping/POC/Enablement


Develop Credible Plan


Execute


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.

HIGH LEVEL GENERIC CONVERSION
PROCESS

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


Build a Technical Inventory of

things that need conversion


forms


models


ui widgets


transformations


workflows


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


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

Execute


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


Plans notwithstanding, you will most likely be in uncharted
waters.


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

Conclusions


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.