Transcript DevCon Presentation WCM to WCS Final

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
<xs:element
<xs:element
<xs:element
<xs:element
name="title" type="xs:normalizedString" />
name="teaser" type="xs:normalizedString" />
name="publish_date" type="xs:date" minOccurs="0" />
name="is_feature" type="xs:boolean” minOccurs="0" />
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.
Walking Through the process
HIGH LEVEL GENERIC CONVERSION
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.