Alfresco 3 Web Content Management: Enterprise Web Content Management made easy and affordable

Finding and holding on to qualified employees can be a challenge. All the more a reason to make the most of each individual's skill set. A web content management solution that empowers content providers to post directly to a live site increases their productivity. By the same token, IT personnel who are not ensnared in the posting process are free to apply their skills and knowledge to more challenging tasks. Providing state-of-the-art tools helps promote positive attitudes while improving productivity, which can go a long way in retaining skilled personnel.

Does it take hours or even days to post new content on your websites? That's often far too long to leave outdated or incorrect information on a site. After all, the beauty of the Internet is providing target audiences with 24x7 access to all of the latest and greatest information. When a site becomes stale, users become disenchanted and are less likely to return. Recapturing a user's interest is far more difficult than maintaining it with fresh, personalized content.

When new information doesn't get posted quickly, what does it cost your organization? In case of a publicly-traded company, incorrect financial postings can have serious consequences. Providing only accurate, timely product information can prevent misunderstandings that lead to customer dissatisfaction. Giving distributors and suppliers incorrect, out-of-date, or partial information can have a negative effect on your bottom line. The right web content management solution, one that is easy to use and maintain, will help ensure that your organization provides site visitors with reliable content.

A website that cannot be scaled to meet a business' emerging needs is just as serious a problem as an inability to hire more people, move to a larger facility, or acquire additional suppliers. Revenue can be lost and the future of the organization diminished. Why take such chances, especially when websites are becoming central to doing business?

Hiring an experienced webmaster allows an organization to use that individual's skills beyond day-to-day site maintenance. A knowledgeable individual can help review site architecture, assess future site requirements, and implement upgrades. These are valuable activities for growing organizations that want to remain competitive in today's rapidly changing economic environment. However, when the webmaster must operate as a "web page processor", the time and skills of this valuable resource cannot be fully utilized.

The right web content management solution can allow your organization to:

Web projects are the production-side representation of a site. This is what manages the content consumed by the site. Here the access rules and roles for content producers are defined. Every Alfresco server can have multiple web projects. Within a web project the user can:

These actions can be controlled and managed through the use of workflows.

Alfresco provides a sandboxed development model. Content producers make use of the sandboxes to make changes to a site in isolation from one another. The default configuration is as follows:

Virtualization and In-context Preview is core to the sandboxing concept. Virtualization means that each user has a complete view of all current, approved, checked in content along with those unique modifications made within the context of their sandbox. Alfresco provides a complete virtual view of the website as it would look if all changes in a sandbox were committed to the live site even when previewing any non-modified or modified asset in a sandbox. This is In-context Preview.

Each user in the context of their sandbox can do rigorous and thorough quality checks for all changes they are posting to the website.

Transparent layers are the means to implement sandboxes in Alfresco. This layer is a central construct in the Advanced Versioning Manager (AVM) repository, very similar to the UnionFS Linux filesystem, and is used to define "composite" stores that can "read through" content from other stores. It can be defined at the store, directory, or file level.

From Alfresco 3.1 onwards, transparent layers can be configured by a Content Manager in the Staging Sandbox of a web project. This is useful for:

Web forms are used in Alfresco WCM to capture content from the user, and store as XML. An XML schema needs to be created by form developers for capturing content. It is then rendered automatically as a user-friendly web-based form for content contributors.

Alfresco uses the open source project Chiba, an XForms implementation used to transform the XML schema into an internal representation of a form (XForms), and then present UI controls for elements and attributes described in the schema. This helps to render the form entry UI to the end users.

Web forms are created and administered in the Web Forms space within the Data Dictionary. As they are located in Alfresco Spaces, they are accessible by the default CIFS, FTP, and WebDav interfaces. They can also be configured with rendering engine templates for generating renditions of the collected content.

The web form-managed XML can be transformed with rendition templates and the corresponding content into rendered output. Server-side templating languages, such as FreeMarker, XSLT, and XSLT-FO are provided by Alfresco. After a content item (XML file) is created via a web form, each rendition template configured for that content type is executed, producing an output file per template (shown in the following diagram). Typical formats for renditions of web content include HTML, JSP, PDF, XML, and so on:

Web scripts provide RESTful access to content held within your Alfresco Enterprise Content Repository. You can therefore place controls on your enterprise content to manage it, and provide uniform access for a wide variety of client applications and services, such as browser, portal, search engine, or any custom application.

Web scripts allow you to:

Alfresco WCM uses JBoss jBPM for all workflows. There are three aspects of workflows in Alfresco:

In Alfresco there are three delivery models: static, dynamic, and a hybrid of both static and dynamic. In a static delivery model, all requests to the web server return a static file of XHTML, XML, JSON, and so on to the web client without any additional processing (no CGIs, no SSI, and so on).

In a dynamic delivery model, all requests to the web server return objects of type XHTML, XML, JSON, and so on that are processed by some application server to render the resulting document.

Static delivery model

In such a model, pages are rendered as part of the content production process. The resulting HTML and associated assets (images, CSS, JS, and so on) are then published to the filesystem, typically a document root of a web server. This provides high levels of scalability on simplified production architectures (web server farms). This model, however, has limited personalization and there is a set number of rendering technologies (FreeMarker, XSLT, and XSLT-FO).

A File System Receiver (FSR) will need to be installed and configured to receive published static content from the Alfresco server. The FSR consists of a small server that receives updates from an Alfresco repository and publishes them to a flat filesystem, which is then typically served up by a web or application server. The following diagram illustrates this process:

Dynamic delivery model

A pure dynamic model publishes content to an Alfresco Runtime, thereby making the content available for dynamic queries with basically any web technology (PHP, Python, J2EE, AJAX, Flash, Cold Fusion, and so on). This provides ultimate flexibility in what and how content is displayed on a page. This provides the highest levels of personalization, but will require significantly more resources on the delivery servers for similar levels of traffic. For all but the smallest websites, significant effort is required in architecting, developing, and testing to ensure website or application stability. This is particularly the case during unexpected high-volume situations (for example, a Government website during a national disaster). The following diagram illustrates the dynamic delivery model:

An Alfresco System Receiver (ASR) will need to be installed on a server to facilitate the dynamic delivery model. The ASR is just another instance of the Alfresco server. The ASR allows a web project being authored in one Alfresco server instance to be deployed to another separate instance of Alfresco.

The best of both worlds

A hybrid approach is the preferred approach regardless of the WCMS and the underlying technologies. Determination of what is static and what is dynamic is highly dependent on the type of website and web applications.

Users also have the option of a hybrid delivery approach. This approach can be executed as follows:

• The web architecture model should be designed to support the dynamic model. This includes the ability to deploy content to both filesystems and Alfresco runtimes for flexibility.

• Leverage the static model wherever possible. If content must be personalized to a single user or a very small set of users with few "page" impressions, it most likely needs to be dynamic. Otherwise, it can be static.

• Choose a page composition model appropriate to the overall site and each page on the site:

  • Outside-in: Each page is static HTML with static components already embedded, but dynamic components or applications such as AJAX and Flash can be included.

  • Inside-out: Each page is dynamic and includes all page components dynamically regardless of whether those components are static or dynamic.

The Alfresco Web Editor (AWE) is a Spring Surf-based web application that utilizes the Forms Service to provide in-context editing capabilities to Alfresco repository content (non-AVM). Alfresco 3.3 also introduces the Web Editor Framework (WEF), which is a client-side JavaScript framework that is a dependency of the AWE.

With the initial release, the AWE will support JavaServer Pages (JSP)-based websites by providing a tag library. Additional languages will be supported in future releases with FreeMarker and PHP being on top of the list. The tags have been designed for easy implementation so that a developer can enable the AWE with minimal effort, and without effecting the CSS layout and design of the site.

The simplest and quickest way to deploy AWE is to use the prebuilt WAR (awe.war) file and deploy it in the same application server instance of your web application. Being a Spring Surf-based application, AWE does not have to be deployed in the same application server instance as the Alfresco repository. However, this section presumes that it is.