Pro-Spective

Digg This!

Page 2 of 2   « previous page

Once the site and its content has been analyzed, and it's been determined that caching is a realistic option, then the type or types of caching to be implemented need to be finalized. This includes determining:

• The server's default cache type
• The server's default caching and expiration settings
• What custom caching and expiration methods to use

WebCM provides different caching options as well as pre-rendering feature. For the purpose of this article:

• Pre-rendering refers to a function in WebCM to collate design and content components and then store them on a physical disk as complete HTML files.
• Caching refers to the ability to store content (after it's been rendered from various components) in either memory and/or on the hard disk. The cache is stored when a browser requests a page. Both WebCM and DynaCache (part of WebSphere Application Server) offer both memory/disk caching and expiration management.

WEBCM PRE-RENDERING
The pre-rendering engine renders an entire site (based on the site framework selected) and can't be broken down into partial pre-rendering. It's done by enabling the <Cacher class=....> module in connect.cfg. The resulting HTML files can be stored on another device and used by other Web servers.

Pre-rendering doesn't have expiration management and a pre-rendered site is replaced when the pre-rendering engine is triggered. It's suitable for a small to medium-size Web site that contains static information without personalization.

WEBCM CACHING
WebCM caching will also do the pre-rendering function. It also offers a caching functionality in terms of memory/disk caching, basic/component/custom caching, and cache expiration options. These functions are set up through the cache configuration in connect.cfg. It must use WebCM as a Web server since the caching file system isn't in true HTML format.

Caching options (basic or custom) can be used in conjunction with memory/hard disk caching to improve performance. However, WebCM memory/hard disk caching can only be used when WebCM is used as the Web server.

There are two caching options:

• Basic caching: This is a default setting for WebCM and is almost the same as pre-rendering in the sense that the entire site is rendered. The main difference lies in the mechanics of how the physical files are created. Basic caching (via the Cacher module) renders a page at a time. It also provides basic cache expiration options. Basic caching offers a more flexible solution for a larger Web site for more current content because of the expiration management. However, it can't provide caching for dynamic, personalized, or secured content.
• Advanced caching: Advanced caching that provides options to selectively cache content by session, users, etc. provides the same output as the basic caching option. In addition, 'connect' tags can be used to selectively cache (or un-cache) components in a Web page. This option is useful for a Web site that has largely static content with some dynamic components.

Note: Connect tags can only be processed when the default caching mode is enabled and the WebCM Web server processes the tag.

WEBSPHERE DYNACACHE
DynaCache can be configured to work with the WebCM servlet to provide a cached page when it's first requested. There's a configuration file cachespec.xml file to be added to the [was_root]\installedApps\wcm.ear\ilwwcm.war\WEB-INF. In this file, parameters have to be specified on site structure, expiration, etc. Pages from DynaCache can be stored on a Web server, but the WAS plug-in has to be configured to work with this setup.

It's also possible to configure DynaCache to cache content at the Web server. This requires that Edge Side Includes (ESI) components (or SunOne's equivalent driver) be installed on the Web server.

Deployment Strategy
During deployment, the design components will be promoted (or transferred) from the development environment to the Quality Assurance (QA), User Acceptance Testing (UAT), and Production environments.

All design components (or code), such as WebCM content templates, WebCM presentational templates, JSPs, and Portal themes are produced in the development environment. Due to the differences in capabilities, a number of code deployments will be used for code promotion.

Figure 3 provides an overview of how the codes (regardless of their location) can be deployed.

For WebCM, syndication can be the vehicle for code deployment. However, the syndication can also be used to promote content as well as design components (codes). However, detailed deployment planning and operational procedures must be set up to ensure content integrity and security.

An alternative is to create a custom export/import function for the design components to provide code deployment instead. However, this option uses unpublished features of the API to access the components for both the export and import processes.

Another possible option is the integration with WebSphere Process Choreographer. It also uses part of the unpublished API to create custom workflow actions. The custom workflow action will have a configurable URL to provide content ID, the workflow stage of the content, etc. to a JSP. It's the JSP that will interface with the Process Choreographer using the published API.

Conclusion
With a promising future for WebCM including an integrated development environment (IDE), repository syndication, and task-based workflows together with IBM's commitment to delivering world-class portal, workplace, and content management solutions, many organizations are making the transition from Vignette to WebCM. By doing so you not only gain a content solution but you gain a completely robust and scalable architecture.

Page 2 of 2   « previous page