Vignette V/5
An Omnibus Solution for High-Volume Sites
by Adam Fields
14-Aug-2001
Formerly known as "StoryServer," Vignette V/5 Content Management Server is an all-in-one content management and publishing system. StoryServer originally rose to prevalence as a high-volume Tcl-based templating system grown out of technology developed at CNET.
Calling V/5 a strict content management or publishing system is deceptive. V/5 can serve those functions, and excels at high-volume delivery of content that changes moderately frequently, but it's also thoroughly expandable to a variety of other uses.
Basic Architecture
V/5's basic architecture consists of:
- one central content management server (CMS);
- two or more content delivery servers (CDSs), one CDS for content management access and another for public access;
- one or more webservers associated with each CDS -- Apache, IIS, and Netscape Enterprise Server are supported;
- at least one enterprise-class database servers -- Oracle, Microsoft SQL Server, Sybase, or DB2 (more about this below).
Under this application model, the Content Management Application (CMA) comprises the templates that run on the development CDS, behind one or more firewalls, while the Content Delivery Application (CDA) includes only those on the live CDS accessible to the outside world.
With only this basic architecture, you would end up doing code development on your live server (a dangerous practice for a high-availability service), so for a production system, you'll need at least two CMSs, each with two CDSs. However, the system can be customized to individual application needs. Pricing varies according to the specifics of your environment.
The database server stores data about the Vignette objects as well as your template code. Asset management in V/5 revolves around the basic objects of templates (code), records (database rows), and files (binaries stored on the filesystem). Each of these assets can have associated workflow to track status and ultimately determine whether or not the asset is available on the public site.
The practice of storing templates in the system database is one of the most controversial aspects of V/5 (and StoryServer before it), since it prevents using third-party utilities to access the data for commonly performed maintenance tasks such as searching and source control. Indeed, I've found this fairly annoying, although less so with each release as Vignette has slowly added support tools to the client. These include global templates search and dependency maps of links between templates.
The new CMS Explorer Plug-in should address most of the remaining gripes about storing templates in the database, since it allows mounting and browsing the CMS as a filesystem. This also means that your developers can use the development environments they already employ, such as emacs, Dreamweaver, or MS VisualInterdev.
On the plus side, storing templates in the database lays a useful abstraction between the template hierarchy in the CMS and the directory structure of the generated pages, making it trivial and safe to add site structure manipulation to the list of features in your custom CMA. That is, one template can respond to multiple URLs, adjustable in the CMA, and serve pages differently depending on which URL was referenced.
What do you get out of the box?
V/5 CMS comes with a client-side Java application for controlling access to the server as well as basic content and code management. However, one of the first things you'll want to do is limit the use of that tool to code developers, while building web-based interfaces for your content managers (in the CMA), using the Vignette API.
These tools will probably supercede the built-in workflow for everything except code and file asset management, and it's best to undertake a Vignette project with the expectation that making an initial investment in building a customized CMA will pay off in the long run with happier users employing tools better tailored to the way they work. Moreover, you can tweak those tools along the way as users inevitably discover features they'd like, and more importantly, features they don't like. In practice, we usually start with a core CMA toolkit assembled from previous experience, and adjust it to a client's particular needs.
V/5 offers a number of services, each of which tends to perform admirably if your requirements are exactly contained within the scope of what that service does out of the box. The list of these services is broad but not deep: XML Processing, Syndication, Workflow, Personalization, Caching, and Authentication among others.
To illustrate the nature of these services, I'll use Workflow as an example. The CMS workflow lets you to define a series of steps that a piece of data must pass through before becoming live, or visible, on the CDA. V/5 offers the ability to step forwards or backwards through workflow, but if you want anything more complicated than strict linear task-based redirection, you'll have to build it yourself. The good news is that you can, since V/5 has full application server functionality. With StoryServer 5, you were limited to coding these extensions in Tcl (or calling out to a shared object or DLL), but V/5 has brought the ability to code templates and the logic around them in Microsoft Active Server Pages (ASP) and Java Server Pages (JSP), and, by extension, COM+ and J2EE.
The transition from Tcl has proceeded in small steps, but the ASP and JSP APIs now include full access to the CMS controls, and lack only features already natively present in ASP or JSP, such as database access.
Dynamic Execution, Caching, and Personalization
V/5 can operate in multiple modes, configurable on a template-by-template basis. A template can be dynamically executed on demand for each user - typically called a "fried" operation - to generate a unique page of html, binary data, or other content.
The standard alternative to frying pages is "baking", where each page is generated beforehand from a dynamic template, but the user doesn't ever see any server-side dynamic content. V/5 doesn't directly support baking (although it can be combined with an off-the-shelf spider to harvest and deploy end-product html), but instead has a caching mechanism whereby a snapshot of a fried page is saved and served instead of regenerating the page from scratch on the next hit. You might call this "roasting".
Using the V/5 Personalization features, you can insert small bits of user-specific data into previously cached pages at page delivery time, giving the illusion of dynamic execution with minimal overhead. Cached and non-cached elements can be combined on the same page through the use of V/5 Components, which are Server-Side Includes (SSIs). These SSIs are managed by the system as any other template, and can be used to mix Tcl, ASP, and JSP content.
Developing an efficient caching and personalization strategy tailored to the specifics of site content and traffic is often one of the most difficult parts of a good Vignette installation, but also one of the strongest advantages of the platform. With a good caching strategy, a well-architected infrastructure, and sufficient hardware, V/5 is capable of serving extremely high volumes of users, well into millions of hits a day.
Add-on products
As of V/5, Vignette has formalized other offerings, hints of which were present in earlier versions or as standalone products. These add-on products can supplement your base V/5 installation and eliminate the need for you to build certain functionality yourself. These include modules to extend the personalization process to full end-to-end content targeting, aggregate and distribute your content to disparate systems, and manage remote installations.
As always, you'll need to determine whether it's worth it to buy these solutions and accept their built-in features and constraints, or build a totally customized solution. Of course, many customers simply don't have the business structure to take advantage of many of the major features. If you're a small web publisher, you may not have the sales infrastructure to take advantage of, say, syndicating your content with ICE, but you'll certainly be able to use the high-volume publishing reliability of the system. On the other hand, these add-on features will work well for you if you can take advantage of them.
Conclusions
V/5 has many of the strengths that Tcl itself does - it's easy to learn, flexible, very good for rapid prototyping, and simple to read and maintain the codebase. With the addition of increasingly better ASP and JSP support in V/5 and future versions, some of the weaknesses exhibited in earlier versions have been addressed - notably disappointing dynamic performance and lack of object-oriented code modularity. Vignette's support for industry standards gets stronger with each release, from early adoption of XML to thorough J2EE compliance.
While I'm unhappy with certain things about the V/5 platform, I do like developing applications for it. I've performed numerous Vignette installations, from publishing systems to online coursework to product catalogs to portals. The simple conclusion is that V/5 works. It has at least some built-in support for almost all web management needs as well as a strong track record of delivering usable applications. For me, that makes all the difference in choosing an omnibus solution.