Content Server
Content Management and Delivery with divine's Content Server
by Chris Brown
02-May-2002
In the beginning
To understand why a product is the way it is, it often helps to understand its origins. So I'll say a few words about the early days of Content Server as well as its original parent, FutureTense.
My first introduction to Content Server was in late 1998 when Version 2 was just being released as (at that time) purely a content management development platform -- meaning there was no content contributor interface. It was based on the Kiva application server (later bought by Netscape and turned into Netscape Application Server and even later, iPlanet) well before application servers had matured into a segmented market space. Written in Java from the start but realized as Kiva "AppLogics" (Kiva's version of servlets before and Java app server standards were in place) the product was ahead of its time architecturally to the point where selling the product also involved introducing people to the idea of application servers and convincing them of their merits!
The main targets of the FutureTense sales machine were traditional publishers like newspapers and magazines. The Washington Post and the New York Times were two of the earliest customers. In 1999 Content Center was born as the result of a joint development between FutureTense and The Washington Post to provide a truly useful yet customizable content-entry interface.
Since then the product has found customers in the retail, insurance, dot.com, and healthcare markets, as well as made further inroads into the financial services and publishing sectors. It has also been through two "mergers:" OpenMarket in late 1999 and Chicago-based divine in late 2001.
The rest of this article will deal with the Content Server platform as it stands in early 2002 where the majority of users are using version 3.6x. Version 4 was released in mid-March of this year, but is not in general use yet, although I will try to point out areas where there are significant differences between versions 3.6 & 4 that warrant further investigation.
Architecture
The architecture of the Content Server platform has matured over the last few versions along with Java standards more generally, but is not significantly different than it was 4 years ago. The product is architected to reside within the three-tier application server infrastructure of database, application server/web server and browser-based client, and is supported on BEA's WebLogic, IBM's Websphere, and Netscape/Sun Alliance's iPlanet.
It is essential here to realize the difference between this sort of architecture and other vendor's products (such as Vignette, Interwoven, etc.) that "sit alongside" an application server. In the latter case you merely have a level of integration (perhaps URL- or API-based) that allows the passing or fetching of content between the content management system and other systems sitting within the application server. This scenario is typical when the delivery of the content is being done by another J2EE application (usually homegrown but sometimes licensed, as with personalization applications from vendors like ATG).
In the case of Content Server the architecture is very different. Content Server is delivered as a bundled management/delivery application, split into three parts. The first part is a set of servlets that comprise the base functionality of templating, dynamic delivery, debugging, and caching content. The second is a relational schema necessary for the content management system. The final application, Content Center, makes up the third component. This entire application sits within the application server architecture and indeed cannot be installed without the application server and database being configured correctly ahead of time.
The benefits to this architecture are the features you would expect of any appserver-based system: load balancing, failover, database connectivity and connection pooling, and clustering of multiple JVMs within and across servers. In addition, you are also then utilizing an application based on J2EE standards that can easily be integrated with other J2EE applications at either a URL level or through Content Server's Java API.
With this in mind you will need to do some homework on the available application servers. They are all supportive of the J2EE standards but vary greatly in their approach to some of the features mentioned above. The primary area of difference that really needs to be understood is how applications are managed within a multi-machine cluster. The philosophies vary substantially and greatly affect the approach to security, session management, failover, and load balancing. But the important thing is that if your firm has already identified a J2EE application server infrastructure, chances are it will work just fine with Content Server.
The other area of concern here would ultimately be cost. When you consider database licensing, application server cost, and the cost to purchase Content Server, you are talking about a significant financial investment. Of course, many firms already have licenses for the database and application server, which then brings down the incremental cost. But in any case, this architecture places Content Server squarely in the enterprise-level class along with products from Vignette, Documentum, BroadVision etc., and might preclude it from users looking for departmental or intranet-only solutions.
Content Management
Notions of what content management really means have changed significantly over the last few years. The original idea was based on the separation of the content and its presentation to facilitate a template-driven approach to web site delivery. However, the real idea of managing content has now really taken hold, giving rise to the need for sophisticated applications used by non-technical users who are responsible for content creation. Content Server provides many -- but not all -- of the features a company could want, and in this respect is on a par with most other content management vendors who are continually responding to market needs. Let's take a closer look at Content Server in the context of content definition and entry, content lifecycle, and content publishing.
Content Definition & Entry
The Content Server platform comes with a predefined set of sample "asset types," examples of which are "article," "image," "page," and a few others. This directly relates to a predefined database table structure to support these types. This default structure reveals the publishing origins of the product, where newspapers and other media could use these sample structures with little modification.
However, in reality most organizations will need to create their own asset types to more closely match the kind of content structures they are managing, as well as their own in-house terminology. Content Server provides two ways in which this can be done, depending on the complexity of the content being managed and the required functionality.
The first and simplest option here is to create a simple asset -- like, for example, ""-- that equates to a single database table. This is a relatively simple process where an XML "ADF" (asset descriptor file) is created that describes the physical, user interface, search characteristics of these asset types. This ADF will then be read by the system to create the corresponding table and default contributor interface pages. This is appropriate when the content structure is relatively simple, and it is commonly employed by divine's publishing-oriented customers.
The second option is to create something called "flex assets." This asset structure was conceived by divine as a database abstraction layer enabling business people (not database administrators -- DBAs) to make alterations to data structures on the fly. It was originally developed to compete in the retail product catalog market, but has since been applied in many non-retail sites. The basic idea is to be able to create content families that are further refined (or subtyped) in an object-oriented model. This provides tremendous flexibility when defining content structures and enables attribute-level inheritance, as well as many ways of viewing that content from differing perspectives. This is certainly more complex to set up, but enables content to be managed in a more flexible way and appeals to business people who are now in charge of not only the content but also how it is structured in the system.
Sound complicated? Let's look at an example. If you were working in a retail organization that managed different sorts of products you would have several pieces of information that might be common to all, such as: SKU, name, description, and price. However, if -- in addition to selling clothing -- you are vending bedding and furniture as well, then there will be unique characteristics for each of these product types. And sub-categories may also have unique characteristics; e.g. shirts and tables would not have a "thread count," but bed sheets do. With flex assets you would be able to set up an asset family of "Products" and then derivative asset types within that main family of clothing, bedding, and furniture that would inherit the common characteristics of the product family as well as have unique characteristics of their own.
These flex assets are implementing common, object-oriented principles, but the real benefit is that they can be controlled by the content creators and do not require specialist DBA help to create or modify. When the content creator decides to create a product they will then be prompted to choose what type of product they want to create (clothing, furniture or bedding), which will then present them with appropriate forms for its creation that include the common and unique characteristics of the product type.
As with many other areas of the divine product, there is tremendous potential and flexibility with this kind of asset structure, but, like other OO-driven tools, the user interface design is inadequate and non-intuitive. However, after training and some practice it becomes clearer, and if you are a user that works on such content structures every day, in my experience it becomes straightforward after a while. Expect to be baffled the first time you see it, but remember this kind of flexible asset structure is not available from any other commercial content management vendor to my knowledge.
Some limitations do arise with these custom assets, whether you choose flex or conventional assets, which may or may not be an issue. The first of these is that the auto-generated contributor interface may not match exactly how content editors would like to see it. In this event, system customizations can be made, but this requires code level modifications that could be time consuming.
The other limitation is that by default there is no WYSIWYG HTML editor for text fields. Divine has provided a work-around for this in the shape of a relationship with Ektron (www.ektron.com) and an easy integration with their browser based editor "eWebEditPro," which works very well in Windows clients. In Version 4 an option to do content contribution entirely in MS Word is available thanks to a client-side API that communicates with the server and is "aware" of the asset's content structure (see image below). Other customizations are also possible that allow "in-line" editing of content directly from a page preview, but this again, requires some (relatively easy) code-based customizations.
On the whole, however, Content Server's content contribution facilities remain somewhat less mature than some of its competitors, notably Interwoven, Percussion, and Stellent. Nonetheless, it seems to be an area of significant development in Version 4.
Content Lifecycle
After content is added to the system, Content Server provides the option to define a workflow lifecycle that can be designed to follow in-house procedures.
I wouldn't compare this kind of content workflow with the workflow that is provided in specific business-process or document management products. The workflow in Content Server is designed to facilitate a relatively swift progression of content to the live site while maintaining security and providing an audit trail. This is very different from workflow that you might find in a sophisticated document management system. It means that Content Server does not support some advanced workflow features -- such as divergent branching, creation and merging of versions etc. But in my experience this is better suited to most organizations, whose objective is to get content to the site quickly -- in minutes or perhaps hours at most. As content is continually edited, revisions are also managed with check in/check out, record level locking, and rollback capabilities.
The content lifecycle allows you to define "workflow states," transitions between those states, and everyone's functional capabilities within any particular state -- giving very finite control over what a given user can do with content and when. It is also nicely integrated with any SMTP email server so that emails can be triggered based on the transition of content through the workflow. As with other products in its class, you can define multiple workflows that can be used based on the asset type being managed or indeed the portion of the site that's being worked on. However, my advice has always been to try to standardize on one workflow throughout the organization to reduce the complexity and confusion that can be caused with multiple workflow models. Of course, this is not always possible.
Content Deployment
At the end of the lifecycle content needs to be deployed to the site. Content Server provides the ability to publish content both statically and/or dynamically. By "static" generation I mean the publishing of a page or image which is then stored as a file in a directory (as with traditionally-managed web sites), as opposed to "dynamically," where pages or images are generated when they are needed, based on a user request on the live site at runtime. Notably, in Content Server either approach can be taken without change to the content or template.
When publishing statically you can easily control how files are named and the kind of folder structure that is used. However, one area of missing functionality is any kind of file deployment technology. Typically you would not actually serve these files from the file structure where Content Server puts them, but rather, within one or many web server folders. Currently Content Server customers need to utilize other file deployment technologies or write scripts that employ ftp or rsync utilities for file deployment. This sort of functionality is provided by other competing vendors, such as Interwoven natively or Documentum since its acquisition of Boxcar.
When publishing dynamically this means the transfer of content and associated metadata from a staging area to the production server. This is done using an underlying Content Server feature called "mirroring." It uses HTTP to communicate with the target system and generates a stream that is loaded through the web server or through a designated port directly on the application server. This is a transaction-safe function and can be repeated if content needs to be published to multiple destinations.
This capability provides for complex deployment architectures for dynamic sites. For example, the Financial Times (www.ft.com) has content managers in New York and London and employs separate servers in each location to support content entry. FT also has separate sets of clustered servers in the US and UK for the dynamic delivery of the site. When an editor in either location publishes their content, it needs to be dynamically deployed to the server infrastructure in both the US and UK. This is achieved by creating a custom publishing action in Content Server that mirrors the content to both places every time an editor needs to publish content. There are some complex customizations necessary behind the scenes for this to happen, but after successful integration, the process became seamless to the editors themselves.
In summary here, I would say the issue of static delivery has been handled better by other products like Interwoven and Documentum, but dynamic delivery is less complex and more elegant in Content Server than the solutions from Vignette or Broadvision that lack this mirroring capability.
Furthermore, if you chose to go forward with a dynamic site, having both management and dynamic delivery provided by the same vendor enables a tight integration and elegant solution. Conversely, with solutions where you are managing content with one product and then delivering it with another product (as with Interwoven and Percussion), the issue of deploying dynamic content becomes much more complex.
Development Technology
Before discussing how content is dynamically delivered with Content Server a brief explanation of the technologies that can be utilized to build your applications and templates is appropriate.
Historically, FutureTense chose to create an XML-based tag library that would make template development possible for people who just had HTML knowledge. This was fine at the time as their target market was primarily newspapers where the IT department typically had little or no experience with JSP, Java or any true programming experience for that matter. However, this was not a traditional use of XML as we accept it today and was just a definition of a basic scripting language that used tag-based directives. These directives were interpreted by the Content Server preprocessor and the associated Java functionality invoked.
The following screen shows what this actually looks like (click image to enlarge):
Template editing interface in Content Server 3.6
Happily, today there are other alternatives that have resulted from taking advantage of underlying application server capabilities. It is now possible to create templates using JSP and/or Java tag libraries ("taglibs") that provide the same (and more) functionality as the XML directives did, while giving you the full functionality of the JSP and Java languages as well. It is also possible to create your own JSP or Java taglibs to encapsulate functionality that may be specific to an organization and its integration needs. This is another example of extensive functionality that's made possible when the CMS application resides within an application server infrastructure.
Other than these specific languages, any technology can be used in your templates that can be recognized by the web server or target browser. For example, if you want to utilize PHP or Perl, there is no reason not to add this code. Content Server will simply ignore it and pass it through untouched to the web server as it does with Javascript and HTML.
The very comprehensive set of standardized languages that can be used makes for a rich development environment. Having said this, Content Server is lacking in its integration with standard IDEs. Content Server has its own very basic IDE called "Content Server Explorer" (see image, above). It is very good in giving you access to all the templating components, but its lack of proper syntax highlighting, thorough syntax validation, and flexible debugging make it an unfriendly environment to those familiar with Visual Interdev, Visual Caf, and the like.
Content Delivery
The last piece of this puzzle is the content delivery mechanism for dynamic sites. Content Server deals with this by first interpreting a dynamic URL that will look something like this:
http://server/servlet/cs/ContentServer?pagename=mysite/homepage&c=Page&cid=989898
This equates to telling Content Server the template that's needed ("pagename"), type of asset type being rendered ("c") and the instance of the asset type to render ("cid"). This may also be followed by other name-value pairs as needed.
So the first thing is that the ContentServer servlet is executed and passed the query string. The template is then retrieved from the database and executed. This triggers retrieval of the asset itself, and then the XML, JSP, and/or custom Java will execute to create the page. The page is then passed back to the application server and then out to the web server, and ultimately the user.
This sounds like a lot of overhead; however, the scenario above does not take into account any caching options, which are quite considerable and varied in Content Server. Caching can be done on a page or pagelet basis (a pagelet being any discrete element of a page). Each page or pagelet can be given its own caching criteria, i.e. the set of values that makes it unique. So for example, if you are caching a pagelet that displays the weather then you would probably have page criteria based on the page and page id (standard) but then also a variable zip code.
This can be taken further in the case of personalized content that may also be based on a visitor's access level, user grouping, or even user id (or combination thereof). Content Server automatically takes care of the assembly of pre-cached content based on its own self-maintained cross reference that it uses when accepting any page request. In this way any given page can be made up of cached and non-cached content and could even also include static content as well.
Expiry of the cache is handled either automatically through defining an expiry time, or can also be forced programmatically by templates themselves, depending on how they are coded. It is also possible (and indeed desirable in a lot of cases) to have long default expiry timeframes (circumvented only by the content publish process), but this requires a little system customization to achieve.
An additional level of caching can also be achieved by using a Content Server add-on called Satellite Server. Though not frequently used, the concept is powerful. Satellite Server enables you to push the burden of cache management and page assembly out to additional low cost machines. Typically this is done by adding small Microsoft NT/W2K- or Solaris-based servers that distribute the cache across multiple machines. These machines can even be configured to operate in multiple geographic locations giving an "Akamai-like" cache distribution while maintaining all the functionality mentioned above.
Summary & A Look Ahead
While Content Server offers a great level of content management functionality, it also requires a significant amount of resources to implement and thus is only appropriate for those investing hundreds of thousands of US dollars in a solution. However, it is offered on an open, flexible J2EE platform that should bring a good deal of comfort to those that shy away from more proprietary solutions.
I will be interested to work with the 4.0 version of the product that has recently become available. It offers such things as:
- Content contribution from within Word,
- Enhanced development & debugging tools,
- Improved workflow,
- A significantly overhauled user interface
- The notion of attribute inheritance across content in the system.
- An improved dynamic content deployment model for the automatic deployment and tracking of changed content
Version 4 promises to shore up some of the holes in previous versions while building in a lot of new functionality existing users have requested. I'll let you know how well it works.