Genie Internet - a division of BT Cellnet, based in West London.
Developed from December 2000 to June 2001.
To design and implement a content management system to allow Genie joint venture partners (JVs) to dynamically modify content and effect design changes.
StoryServer V/5 was already being used in conjunction with Phone.com's messaging software for HTML and WML content managed using Vignettes UI client tools. It was deemed undesirable, inflexible and too expensive for JV's to have access to V/5 client tools.
Therefore the primary concern of the design was to allow multi-language, multi-brand, multi-target (HTML,WML etc.) deployment from the same set of servers, with a web interface for content management.
Genie had already developed a URL rewriting mechanism (using Apache mod_rewrite) which extended the incoming URL to include information about the requesting device and brower language settings, so that each page could be cached separately by StoryServer; I extended this to also include branding information. e.g.
www.genie.co.uk/sports => /genie/en-us/html/sport www.frbrand.fr/jeu => /frbrand/fr-fr/html/jeu wap.frbrand.fr/jeu => /frbrand/fr-fr/wml/jeu
Part of the content management requirement was to allow JVs to create their own site map; adding arbitrary paths to their site. A goal was to keep this all human-readable, allowing users to remember the path to their favorite section, and for editors to navigate easily to the part of the site they wished to edit.
To this end, the database kept track of all paths within the system (together with their brand, locale and content-type), and their associated content. A request URL could then be mapped directly to the all the content associated with the URL's path. As with other projects, a single V/5 template responded to all requests, although there was one copy of this template per brand to prevent V/5 flushing all pages of all brands when paths were added or removed to just one brand.
Each path could have a layout (see Wiley) and multiple pieces of content assigned to it; content was assignable to areas of the page, which were defined by the layout. Multiple pieces of content assigned to an area were concatenated within the assigned area in a definable order.
The content itself could be anything; indeed everything on the system was a piece of content, and lived within a unified database table. HTML, XML (Content and XSL stylesheets), and media files included. Each piece of content had associated with it its brand, language, content-type and a unique object identifier (OID), allowing partitioned access to the data from the multiple brands, devices and languages. The OID was actually a free-form piece of text, allowing flexibility and human-readability, e.g. the OID might be a the name of an image or the reference id of piece of feed data (integer primary keys existed too for speed of database operations).
Each piece of XML content could have an XSL style-sheet associated with it at the point where it was associated with a page. When a page association was made with a piece of XML data, or that data updated, the XML was processed with XSLT and the output cached within the database. This cached markup was then used at page assembly time. Hence, no XSL processing had to be performed as part of the page-demand process.
The XSL processing itself utilized the Java SAX and XSL transformation APIs, and could be performed either within the Oracle database using Java Stored Procedures (optimizing DB to Java I/O and throughput), or externally (off-loading the processing from the database), using the same code-base. The latter is usually appropriate for feeds, the former for editorial input, since it allows instant previewing. The Java and XML facilities of V/5 itself were not used for back-end processing.
Content which was not markup (e.g. media files) could be demanded by using a special path (e.g. in the src attribute) specifying the OID of the content; the content was then cached on that path using the normal StoryServer mechanism. Using a similar system, it was also possible for XSL Style-sheets to reference other documents within the database, e.g. to pull in additional XSL style-sheets.
To enable JVs to source their own data, a simple mechanism for incorporating feeds into the CMS was designed. The system allowed the programming of a timed poll for new data from given URLs, the result of which would be compared with the database for changes, pushed through the processing stages as necessary, and taken live onto the site at a specified location and OID. This was practical for daily to hourly feeds in HTML or XML; offline processing of more complex feeds (e.g. ICE) was supported through the Java API.
With the exception of feeds, all changes had to pass through a work-flow before becoming live; non-live items were pre-viewable by connecting to a specially configured preview server which performed no page caching, ensuring that the view was always up-to-date with incoming changes. This liveness of data was determined by keeping two copies of the data within the database; the live copy would only be updated on completion of the work-flow. V/5's own concept of liveness and versioning were not flexible or script-able enough to implement this solution.
Work-flow for was implemented using a simple database table; V/5s work-flow facilities were again found wanting; they are not atomic, indeed they are often delayed by many seconds, depending on system load, and thus make it impossible to reliably ascertain the current state of the system. Only Vignette's Users, Roles and Groups CMS facilities were used. The familiar Edit, Check, Publish workflow was provided as standard, although more stages could be added as a per-brand parameter.
Much attention was paid to cache design in this project; caching occurs both at the pre-processing stage (in the case of XSL processing) and at the page level. SSI Components were not necessary for the system to function, but could be used within the page design if it demanded it. Cache management was fully automatic; when content changed the change would ripple through the system updating both database cached pre-processed documents and flushing pages as necessary.
The main features of the final system were:
The system underwent extensive testing by Genie and Accenture and began to be deployed in October 2001, starting with Genie NL (www.genie.nl).