YAWL -- must see TV for Workflow practitioners
YAWL - Yet Another Workflow Language
I suppose the name would be funny, if the idea for the name wasn't so ingrained in Unix culture, with such landmark tools as YACC (Yet Another Compiler-Compiler - a BNF language tool available in some of the earliest releases of Unix from Bell Labs). Aside from the cute name, though, there's a real conceptual basis for this particular open-source product.
YAWL grew out of the research described on the Workflow Patterns homepage (https://www.workflowpatterns.com). This remarkable research and development effort, performed by Prof. Wil van der Aalst, Assoc. Prof. Arthur ter Hofstede, Lachlan Alred, Lindsay Bradford, and Dr. Marlon Dumas is an exceptional leap forward in the growth and maturation of workflow as a basis for collaborative applications in practical uses.
While I haven't actually implemented any of the YAWL engine code in the workflow engine I am creating, I freely admit to having read some of the research literature that Dr. van der Aalst has placed into the public domain. (I have not even downloaded the code, although I hear that Yawl now has a SourceForge site where the code is available. I don't want there to be any finger-pointing about "who owns what code" if my project is ever posted to the public domain.)
Splits and Joins
Some of the most compelling work went into creating a structure for understanding how process flows from task to task, and the kind of rules that can be embedded into the junctions between a task and the link that flows out of it. This was a new concept to me when I first heard it, and I suspect that it may be new to others as well. I will try to distill it here, but if I get it wrong, please tell me so I can correct my thinking.
A "split" is a condition on the exit for a task, where more than one link can emerge from the task. In other words, if there's two roads out of the state you are in, you have a split. There are three kinds of splits: AND-split, OR-split, and XOR-split.
A "join" is a condition for the entrance to a task, where more than one link merges in to the same task. In other words, of two different flows can come together in a single place, you have a join. Once again, three types: AND-join, OR-join, and XOR-join.
The logical operators are similarly named for a reason. The operations of the workflow engine are driven by the type of split and the type of join that the system encounters along the way.
XOR Split and XOR Join
An XOR split will activate one outgoing link from the task. Only one. Therefore, it doesn't create a situation of concurrency. An XOR join will activate the task each time an incoming link is activated. Therefore, if two concurrent processes are winding their way through the workflow, and they both come to the same task, the task will be triggered twice.
OR Split and OR Join
An OR split will activate one or more links from the task. As many as the conditions will allow. Therefore, an OR split can easily create a situation where concurrent operations begin to come into play. An OR join is useful for making sure that the task is only fired once, regardless of how many of the inbound links eventually fire. Essentially, the first one fires the task, and the rest are discarded without firing anything.
AND Split and AND Join
An AND split will activate all outgoing links from the task. Think of this as a constrained OR split... you are definitely creating a concurrent situation. An AND join will wait until ALL inbound links are activated before firing the task. In other words, if three links come together in an AND join, the task will not fire unless the processes that feed all three links are completed. This encapsulates a fairly powerful concept that is sometimes lost on workflow system developers.
There are other operators as well: Composition, Multiple Instance, Cancellation, etc. I don't have time, or room, to go into them here.
I encourage any student of collaborative workflow to read the material on the workflow patterns site and to look into YAWL.