Implementing content management at a high-volume Web site

---

This section reviews the customer requirements, tool selection process, and high-level design using Content Manager.

Requirements

The customer requirements for the content management solution included:

• The solution should allow definition of types of assets. Content consists of assets. An asset is a piece of content that is included in another asset or a page. Assets are combined to create fragments and pages.

• The solution should support creation of templates. Templates can be reused to create multiple pages.

• Information architecture, site structure, and actual site content should be managed in an integrated fashion within the same tool. The information architecture is the tree of categories in which asset production is managed.

• The solution must fit in the customer's existing Web-serving environment, which was complex, and be able to publish content based on the scheme defined by this environment.

Clearly, no existing prepackaged solution could meet these requirements. The customer had decided to build the solution instead of buying a packaged product and trying to retrofit it to match the requirements. The only decision left was whether to build it from scratch or use middleware that would speed up the development process. It was at this juncture that IBM entered the picture and presented Content Manager. Although the product was in its beta cycle, the customer realized the benefits of using Content Manager.

Design decisions

• Represent the run-time site structure with an author-time folder hierarchy. Manage the site structure as changes to the folder hierarchy.

• Use the folder hierarchy to create the site access URLs at run time.

• Represent and store pages and assets as XML data that are rendered through an XSL transformation on the client side.

• Use in-place editing for page and assets, using features provided by Microsoft Internet Explorer 6.0.

Content Manager

Content Manager is based on a hierarchical data model of items. Items can have subcomponents. Items can be related to each other through references or links. The structure and representation of items are defined by an item type, which determines the underlying storage of items of that type and the access methods to the items. Content Manager has application program interfaces (APIs) for C++ and Java, and this customer had chosen to implement this solution with the Java API. Items are exposed in the Java API as dynamic data objects (DDOs).

In IBM Content Manager, relationships between items can be represented through links or references. Links model a one-to-many relationship between items. They can be used to relate only root components of items and do not distinguish the versions of the items related. References, on the other hand, model a one-to-one relationship between a root or child component and another root component. References can also refer to a specific version of an item. The reference model lent itself naturally to represent the containment of assets within other assets, and by a simple extension could also be used to represent the relationship between assets and subfolders within a folder. Consequently, we decided to use the reference model to represent the containment of assets within other assets and the location of assets and subfolders within the folder hierarchy.

We decided to define application-specific Java classes to represent the data types that were identified for the application and to create for each type a special factory object to map between the Content Manager DDO and the corresponding Java object. This allowed maximum separation between the application objects and the Content Manager objects. Any change or extension on either side could be accomplished without affecting the design on the other side.

The identified data types include:

Folders: A folder is represented by an item that can have a collection of items. Each folder is associated with a folder type that constrains the type of items that can belong to that folder. Specialized folders that have additional functionality were also defined; examples of specialized folders are site folders and page folders.

Assets: An asset is a piece of content that is included in another asset or a page. Two types of assets were defined: simple and reusable. A simple asset can be used in only one place and is considered an integral part of its container. A reusable asset can be used in multiple locations and has an identity of its own. In either case an asset can represent static content, such as a paragraph of text or an image, or it can represent a dynamic object, such as an applet. Assets abide to asset types that define their structure, restrict the allowable content, and determine the rendering mechanism. The rendering mechanism was based on XSL transformation. Both assets and asset types were represented as Content Manager hierarchical items and their content was stored in Content Manager as XML fragments.

Pages: A page represents a piece of content that is identified by a URL. The URL of a page in the system is constructed based on the folder where the page is created. A page abides to a page template and consists of a hierarchy of simple and reusable assets. The page template specifies the format of the page and the rendering mechanism, and restricts the types of assets that can be used in the construction of the page. A page is rendered as a Web page based on the specification of the rendering mechanism of the page template that it abides to, in conjunction with the rendering mechanism of the types of the assets that it contains. Both pages and page templates were represented as hierarchical Content Manager items. The relationship of pages to assets was represented through Content Manager references.

We determined early on that the native user/group/access control model in Content Manager did not support all the requirements set by the customer. Consequently, we extended the native model by defining application level item types as follows:

Users: The customer requirements specified a number of attributes for users that were not readily available in the built-in Content Manager user model. The solution was as easy as defining an additional Content Manager item type to represent these additional attributes and to tie this item type to the built-in Content Manager user model. An additional requirement was the periodic synchronization of the user information with the customer's corporate employee directory. This was accomplished using a specialized program that updated the Content Manager user information based on the corporate employee directory.

Groups: The customer requirements specified a hierarchical user group structure, while the Content Manager built-in group model provided only a flat group model. Again, it was an easy task to define a custom Content Manager item type to represent this concept of group.

Permissions: The customer requirements specified the management of permissions independent of any access control list (ACL). While Content Manager implements the classic definition of ACLs and permissions, it did not natively support this unique definition of permissions and the associated access control mechanisms. Again, it was an easy task to define and implement a set of Content Manager item types that represented these new concepts and enforce the access control policies specified by the customer.

We also determined early on that the built-in workflow engine in Content Manager does not exactly satisfy certain customer specific requirements. It was an easy task to define a set of new item types to build an application specific workflow system.

The advantages of using Content Manager for this customer engagement were:

• A better fit between the underlying data model and its representation made it possible for the team to rapidly design and implement the Web content management system needed by the customer. For example, the hierarchical data model of items in Content Manager matches well with the folder and content hierarchy required by the customer.

• The flexibility of the Content Manager programming model made it possible to implement concepts that were not inherent in Content Manager. For example, custom item types and the Java API provided the flexibility to build a unique workflow system for both metadata and content management.

---