250 likes | 361 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
E N D
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, yoursolution will continue to be supported until Alfresco 5 isreleased. • 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.
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.