Web Content Management - Content Delivery Types

  • 6,912 views
Uploaded on

discussion about pro's and con's of the different types of content delivery in the web content management market today

discussion about pro's and con's of the different types of content delivery in the web content management market today

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
6,912
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
92
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Differentiating between Web Content Management delivery mechanisms Architectures for WCMS content delivery can be broadly classified into two types: • Decoupled / Loosely coupled delivery • Tightly coupled delivery In a decoupled or loosely coupled architecture, the WCMS and delivery applications are generally separate applications, with different repositories, but there can be an association between the two that creates a dependency. For fully decoupled delivery mechanisms the WCMS is primarily used as an editing, authoring, approval tool before content is published to a live environment which has no WCMS software installed (often referred to as ‘static’ or ‘baked’ content delivery). For loosely coupled content delivery, content managed by the WCMS is published to another repository from where it is picked up by the delivery application and rendered to the visitor. The content delivery application is generally not aware of the WCMS, but is configured to accept content from it. In a tightly coupled architecture, both the creation of the content and the delivery of the same content is done by the same WCMS application on the same server or there is much tighter dependency. In a scaled or separated architecture, the content delivery application is in most cases a replication of the WCMS application used to edit the content - simply installed again on another server to allow the architecture to scale. Loosely coupled delivery This is preferred by organizations who want to use best of breed applications for different aspects of managing the content lifecycle. In this, there can be a very thin layer of integration between the two environments. The environments are either decoupled, or at best very loosely coupled. If the environments are completely decoupled, the content management system's responsibility ends after it publishes content. This can be to a file system (as static html, asp, aspx, php, XML etc) or to a database for a more dynamic personalised approach to content delivery. The presentation layer is then written in the delivery application that picks this published content and presents it to users. Interwoven TeamSite is a good example of loosely coupled content delivery. Content is created and managed by TeamSite and converted to html (or XML files). This content is then deployed using OpenDeploy to an application server's file system and the associated metadata is published to a database using Database or home grown scripts. A J2EE presentation layer written on an application server (ATG, BEA or similar) queries this database and includes appropriate files to display to the users. There are different possibilities of achieving this, depending on the choice of delivery environment but the idea is similar. Similarly, Open Texts Web Solution (pka RedDot) offers loosely coupled content delivery akin to the Interwoven model – the main difference that it provides its own presentation layer application as well as being able to use BEA or similar. In addition Open Text WCMS offers a totally de-coupled content delivery model for websites not requiring e.g. personalisation or any form of management of the content post publication. Pros 1. There is division of labour. Each system does what it is best at and hence best of breed products can be used. 2. Existing investments are protected. So if an organization has invested in an application server, they can reuse the same infrastructure. 3. In general, requirements of a WCMS and Delivery application, in terms of infrastructure resources, performance and availability are very different. Hence this model becomes quite useful as each component can be optimised to its task. 4. Different best of breed applications can be used for doing multi channel delivery such as delivering content to PDA devices.
  • 2. 5. If a customer does not need e.g. personalisation and simply wants a tool to manage content but not delivery, they do not need to purchase ‘redundant’ licenses from the WCMS vendor as they would with tightly coupled solutions. Cons 1. The two environments are generally disparate. This usually means a different file system or different repositories for content management and content delivery. 2. Features like in-context editing where users can make changes from within the context of end user application may not be there as they are only available in the live environment and not whilst editing. 3. If changes are done on delivery environment, it is generally not possible to bring them back into the CMS. Changes have to be made to the application that is responsible for editing and published to the content delivery mechanism. 4. Different skills sets for development and maintenance, potentially different vendors to manage each component (though Open Text offers a total solution) Tightly coupled delivery In this, usually, the same application does an end to end management of content lifecycle – from content creation to content delivery. There could be separate instance for management and delivery but essentially the applications are same. Even if there are different products being used for content management and delivery, the integration is much tighter as they are essentially the same product. Fatwire and Vignette are good examples of this approach. In Fatwire, for instance, content is created and managed within Content Server. The content is published (either dynamically or statically) to another environment that also runs Fatwire Content Server. Templates are then written within Fatwire to deliver personalized content. Pros 1. It is easier to manage because the same product is used for end to end. So, in terms of resources, support and integration issues, it is less painful. 2. The delivery and management systems are better synchronized. So changes in one can be easily propagated to the other. 3. Replication, backup and recovery are generally easier. Cons 1. Dynamic delivery of content is never as fast as static decoupled delivery – even with sophisticated caching – thus potentially degrading the visitor experience unless hardware is scaled to offset the performance drag (see point 9 for license implications) 2. Some of the features in best of breed applications might not be present in this approach. 3. Many entry level WCMS solutions offer one software application for both editing processes and content delivery processes – effectively installing a single point of failure (if the editing server goes down so does the live environment). 4. If the same instance is used for content editing, publishing and delivery – the editing process may impact on the visitor experience as the server slows and vice versa. 5. Many solutions that offer tightly coupled delivery provide for different WCMS software instances to scale but share the same database – making the database a single point of failure.
  • 3. 6. Even if the customer only wants an application to manage the creation of content, they have to purchase and install the WCMS software at all points rather than only where needed. 7. Multi Channel delivery becomes also controlled by the WCMS resulting in a compromise for best application to deliver e.g. Blackberry or other PDA output. 8. The product itself might not be good at doing all things and hence some compromises might be required. 9. Licensing cost could be prohibitive if the product needs to be there on both management and delivery environments – especially as many tightly coupled solutions not only license per software install but per CPU and in some cases the amount of memory installed – even more so if the live environments are hosted across multiple clustered servers for failover or performance considerations. References: This article is based on a submission made by Apoorv Durga in 2006. The original can be viewed at http://it.toolbox.com/blogs/pcm/my-cms-does-delivery-too-10191 and Apoorv’s own blog can be viewed at http://it.toolbox.com/people/apoorvdurga/. The article has been updated and reproduced with kind permission. Copyright notice: This document and the version available on the website and its associated content are copyright of "contentmanager.eu.com" © "contentmanager.eu.com" 2008. All rights reserved. Any redistribution or reproduction of part or all of the contents in any form is prohibited other than the following: • you may print or download to a local hard disk extracts for your personal and non-commercial use only • you may copy the content to individual third parties for their personal use, but only if you acknowledge the website as the source of the material You may not, except with our express written permission, distribute or commercially exploit the content. Nor may you transmit it or store it in any other website or other form of electronic retrieval system.