As mentioned in the introduction to the last chapter, there are two basic paradigms for workflow: state-based and procedural. The wftk is comfortable with either.

Most of the commercial workflow systems on the market, and the commercial procedural definition languages, are procedural workflow; most of the open-source workflow systems I've seen seem to be state-based. I'm sure this crass overgeneralization is wrong, because I haven't actually done a survey any more recently than about 2002, and that one was pretty lame -- but this is why discussion of established procdef standards is in this chapter, and not the last.

A purely procedural workflow definition can be seen as encoding the detail progression of the system from the "start" state to the "complete" state, so the wftk generalizes that notion to allow the definition of a procedure to take the system between any two states. When a potential task is completed, triggering the transition, then assuming that a procedure is attached to the transition, that procedure is initiated.

A procedure (which gives its name to the procdef for historical reasons, as I hadn't considered state-based workflow in my initial approach to the wftk) is made up of the following:

• Actions
  The system can take direct action. In so doing, the system takes on the identity of either the owner of the process or the person who started the transition. If the permission levels for the action taken require an approval process, then the procedure blocks until that approval process completes. If the action is rejected, an exception state is entered. If the exception is handled by the procdef, then we're good -- otherwise, the exception invokes the default exception handler of the system. The "default default" exception handler is notification of the sysadmin.
• Sequences
  A sequence is just what you think it is: it specifies that its elements be executed in order. When one completes, the next starts. If one blocks, the sequence blocks.
• Parallels
  A parallel starts its elements "simultaneously". That is, if one blocks the rest don't. You can specify whether the parallel is complete if all of its elements complete, or if only one is sufficient. If only one, then the blocked elements which didn't complete are all canceled when the winner does.
• Decisions
  A decision is an "if-then-else" node which applies a simple expression or a rule set to decide which of its elements should be executed.
• Notifications
  A notification is an action (you've got me), but for the sake of convenience, notifications are given a special rank because they're so ubiquitous and also because the idea of a permission for a notification is a little silly. (Unless you're not testing for spam in your workflow -- but in that case, you want to address that at any earlier stage anyway.)
• Tasks
  Finally, a task in a procedural workflow is a "might" variety of potential task. When execution encounters it, it becomes a concrete and actual task, and the procedure blocks until it is complete.

As you can see, this provides a very powerful way of specifying what the system should do after a given state transition -- powerful enough that the transition from "start" to "finish" is often all you need to specify the workflow. Note that the checklist workflow we looked at back in Chapter 06 is essentially a parallel of tasks, which is how the wftk implements it.

The wftk defines a fairly basic language for representing this workflow, a language that looks a lot like its data language. However, there are a number of other languages in common use for the definition of workflow procedures. So a given procdef list can be defined as using an alternate procedural language, and the wftk will translate that language into its own internal representation. And yes, you can write your own language translator if you want to.

Here is an index to the information in this chapter: