Cascade Server: Competent and predictable

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.

Workflow: “A bunch of spoiled brats”

I’m not a drooling rabid fan of JBoss’ jBPM workflow engine, but I do agree with many of the sentiments expressed by jBPM lead developer Tom Baeyens in “The State of Workflow,” on jboss.com.

If database systems are like a respected, wise man telling a clear story, then workflow must be a bunch of spoiled brats shouting their own truth at each other. …

[W]orkflow management systems are at the very initial phase of the technology hype curve. … One of the observations that form the basis of this statement is the overwhelming number of concepts used. None of the numerous specs and tools in this area is similar.

Baeyens explains in detail why the concept of “activities” should be discarded in favor of “states” and “actions.” Baeyens then:

Many vendors of workflow management systems will let you believe that with their graphical process designer it only takes a business analyst to create process definitions. This vision originates from the fact that programming is hard. …

I’d disagree with the assertion that “programming is hard.” Certainly it’s not easy, but it’s not as hard as developing and codifying the actual business procedures … finding that delicate balance between oversimplification and analyzing everything to death.

While not having to write code is a good thing, most vendors go overboard on this and don’t foresee a mechanism to integrate code into a process definition … Developing process definitions requires input from -and collaboration between- a business analyst and software developer. A good graphical process designer should support this collaboration.

Here I’d have to agree 2000 percent. A GUI workflow builder seems simple and “intuitive” at first glance. Just keep in mind that the actual workflow engine has no such sense of human intuition. It helps to be able to explain the fine details of complex processes in a language that the workflow engine speaks.

Workflow options in OpenCms (Updated)

Currently there are three ways to handle workflow in OpenCms:

1. Don’t: just use the role-based permissions system to handle things. Regular users create or edit content, but lack publishing rights. Projects can be created to encapsulate changes or additions. Reviewers check the contents of projects and publish when ready.

2. BearingPoint Workflow2 module. Simple, but rudimentary. A workflow is defined as a sequence of OpenCms projects. Content is moved back and forth between projects and is published manually from the last project when approved. At least it doesn’t mess with the core classes, as does the …

3. Langhua.cn jBPM module. Amounts to an unmaintainable fork of OpenCms 7.0.3, with numerous changes made to core classes. Kinda-sorta worked with 7.0.4, but I seemed to run into problems with 7.0.5. This is unfortunate because in many ways it’s a very good module.

The core developers have hinted at some sort of workflow in the upcoming 8.0 release (due some time in 2010). Until then we can make do with what we have, or choose the next option:

4. Roll your own workflow module. It’s tempting. I mean, what could possibly go wrong?