---

Introduction

Content Management Systems are a core component of the web delivery stack for many companies. Using a CMS, companies are able to exert greater control over the branding and presentation of their web properties. The CMS also helps to establish a repeatable and tunable process for creating, testing, approving and deploying content.

From an architectural point of view content management systems can roughly be categorized two ways:

• Static delivery of content (Baked)
• Dynamic delivery of content (Fried)

While this is an over-simplification for some of the more sophisticated systems, it holds true for the vast majority. Both architectural approaches have their benefits:

Baked

• Pages are pre-generated, thus are delivered to the user more quickly
• The decoupled architecture (CMS from presentation) means the CMS can be down, but the website is still functional
• System can live entirely behind a firewall and push content to the presentation component in the DMZ

Fried

• Because content is presented dynamically, the system can take advantage of personalization and localization more easily than statically presented content
• Content can be updated more quickly because the publish cycle can be shorter

There are significant benefits to both architectural approaches. In most cases, a thorough analysis of the overall requirements makes it clear which approach is best suited for the problem.

---

Hybrid Approach

There are cases where it makes sense to explore a hybrid approach to architecting the system. For example:

• Security requirements demand a decoupled system (baked), but the application requires extensive personalization (fried)
• Large amounts of the system can be statically delivered, but parts require localization and integration to a third party system

There are a number of ways to architect this system, but one of the most flexible is to build a lightweight application around the statically delivered content. The system is made up of the following components:

• Content management system
• Database
• Web/Application server
• Third party system

In this example, the CMS is configured with a set of input templates that allow non-technical users to enter content. The content is input separate of any presentation markup (HTML, CSS, etc.). The content administrator can also assign metadata describing the content that has been submitted. The content can then be advanced through a simple or complex workflow, until it is ready to be published.

At publish time, the content data is transformed to HTML by applying a set of output templates. The output templates map the raw content into a file (or DB table) that includes the presentation-layer markup. The resultant HTML can then be published to the file system, or written directly into a database table. Individual content assets such as image files can be moved directly to a web server. The CMS also publishes the corresponding metadata.

At this stage the entire site has been statically generated and copied into the database. So how do users gain access to the static content if it is stored in the database? A lightweight application is in place to deliver the static content, as well as add any personalization and content from the third-party system.

Considering this at a very high-level, the application intercepts requests for pages and maps the page requests to content items in the database. The metadata can be used to select the specific content requested, or used indirectly by a personalization component. The application could also use a templating system such as Velocity or Freemarker on the front-end to make things somewhat simpler. The key is that the application now has access to all of the pre-generated HTML content, as well as a full framework (Java or .Net) to assist with business logic. Note that since the content is already ‘baked’ there is no need to transform it again; when it is retrieved from the database, it can be written directly to the browser.

---

Case Study

NavigationArts has recently assisted with a development effort that is architected similarly to the system described in the previous section. The system documented in this case study used the following components:

• Apache web server
• Tomcat servlet container
• Rhythmyx CMS
• Hibernate and Oracle database
• Spring framework
• Spring MVC / Velocity template engine

The system required great flexibility in how the content would be presented. A user system and limited content personalization were required. Also, there were several major integration points, as well as Flex components. For this reason, it made sense architecturally to pre-generate the content and publish it to a database, then let the application handle the presentation and integration layers.

Content entered the system via a series of Rhythmyx input templates. The input templates also handled the metadata assignments and managed all of the navigation (internal linking). Allowing Rhythmyx to manage all internal links saved lots of effort on the application side. When one piece of content referenced another, the internal linkage mapped perfectly when the content was extracted from the database.

A very simple workflow system was established to handle content approvals. Also, Rhythmyx’s extensible workflow system allowed developers to insert plugins that assisted with some of the integration requirements. When content was published to the database and file system, the plugins sent references to the relevant content to the external system.

Once content is published to the database, it is immediately accessible to the application. The application used Spring MVC to manage the front-end interactions. When page requests come in, they are intercepted by Spring controllers and mapped to Velocity templates. The controllers extract the correct content items from the content database and make them available to the Velocity templates. The templates provide simple logic to allow the content items to be manipulated and presented. The Rhythmyx CMS also uses Velocity templates. This made it very simple for the developers to leverage the work done on the CMS output templates. It wasn’t quite a simple as copying them directly over, but it required very few modifications.

Using Spring to intercept the URLs also allowed the developers to implement a very simple URL structure. This is key because friendly URLs are very important for Search Engine Optimization.

---

Conclusion

Overall, the developers were very pleased with the hybrid architecture of the resultant system. A clean, simple design allowed the team to reap the benefits of both static and dynamically generated content systems. The case study described above used a Java based system. However, this could have just as easily been deployed using the .Net framework.

View all Insight articles
NavigationArts home