Cascade Server: Competent and predictable

24 09 2009

I’ve spent the past year or so up to my armpits in Hannon Hill’s Cascade Server. My overall impression is that it’s a competent and (mostly) predictable product. But as content management systems go that’s pretty high praise.

I’ve used the SOAP interface to migrate about 8,000 pieces of content (articles, images, etc.) from Vignette V6 and V7 into Cascade Server. There are a few real “gotchas” that made life difficult. For example, link tracking isn’t activated automatically when creating or editing content through the web services interface, at least in Cascade 5.x. Documentation in 5.x is a bit skimpy. There’s no way to output “structured data” as plain text — HTML yes, XML yes, PDF yes, RTF yes … but not plain text.

But for the most part, Cascade Server works as advertised. It doesn’t claim to solve all your problems, but it is quite good at managing and publishing static Web pages. I look forward to the 6.x upgrade, which introduces a “site” metaphor that will help to bring cross-site links under control.

There is one feature of Cascade Server that deserves special mention — the versioning system. As configured by default, each edit to a page creates a new version. It’s trivial to view / audit / compare / roll back / revert between versions. Most importantly, initiating a workflow will create a new version and bind that version to the workflow instance. Editors, approvers, and publishers will work on that version and that version alone. I think it’s even possible to have multiple versions of an article in multiple workflow instances — for example, one version in publishing workflow and another version being bounced around in editing workflow for a later update. To some people this might sound like a bug — but large organizations have silly needs.

Obviously this versioning capability comes at a cost. Cascade Server is very database-intensive, and can be very CPU-intensive depending on the complexity of your XSL stylesheets. (Yes, Xalan has never been accused of excessive speed, nor efficiency.) Its scalability depends in large part on the scalability of your MySQL installation. Hannon Hill recommends circular replication, something which sounds great in theory but scares the living crap out of me in practice. I’d recommend keeping either a very good DBA or a gold-plated support contract to back up large installations.





OpenCms: For us, by us

7 08 2008

It’s the FUBU content management system.

And by that I mean it was designed for techies, by techies. And for “normal” people, too. This is one system that is user-friendly both on the front end and on the back end. What’s the last time you saw ANY J2EE webapp that comes with an optional command-line interface for disaster recovery?

Let’s look the ways in which OpenCms excels in a crowded and highly competitive niche:

  • Content types are defined using XML schemas
  • Structured content is stored as XML, and rendered using JSP templates and custom taglibs.
  • Most system resources are managed through the “Virtual File System” (VFS), which is a database-backed repository similar in concept to Microsoft’s long-promised WinFS.
  • Powerful module packaging system allows effortless export and import of extensions
  • Multiple databases are supported through the use of properties files (!!!) that contain translations of various queries into different SQL dialects
  • Clusterable and scalable without arcane remote interfaces and protocols
  • Automatic versioning of content, with rollback and diff functions
  • Site navigation is an integral part of the system and not an afterthought
  • Fast, responsive, customizable management interface (“Workplace”)
  • Friendly URLs. Nothing but friendly URLs.

Imagine this: You can create a complex content type as a special .xsd file, which can specify not only the structure of the content but the options for the auto-generated content input form. You then can create one or more templates to display that content using plain old JSP, scriptlets, and taglibs. The content you create is stored in a database-backed repository that looks like a plain old file system (down to our old friend index.html), but with the ability to tag items with nearly unlimited free-form metadata.

Make a boo-boo? Roll back to a previous version with a few mouse clicks. Want to put something live? Flip a bit in the database with a few mouse clicks — no worries about the management and delivery stages getting out of sync, failed publish jobs, checking the status of multiple endpoints, etc. Need to create a new page template? Just use your favorite JSP editor and upload it through the workplace, then change a bit of page metadata. Need to embed a custom application or extension? JSP is your friend.

Is it perfect? Nothing is perfect, no matter what your local friendly Vignette account rep may say. Lack of an OOTB workflow engine is the most glaring omission, though the project management tools go a long way toward making up for it. Oh yeah, and I accidentally blew away the master log4j.properties file while trying to deploy my own custom module code through the workplace, but that was easy enough to fix :)

But if you can live with the few deficiencies, you’ll find much to like about OpenCms, either as a content contributor or as a developer. What’s not to like about familiar technology in a robust, simple platform?