Workflow definitions and workflow instances are similar concepts. Workflow definition is the design-time concept of an workflow, which is represented as a class. A workflow instance is a run-time concept, which is an object of the workflow definition class.
A class tagged with “Workflow” annotation is recognized as a workflow definition, which contains all transitions related to this workflow. The “Workflow” annotation contains the following attributes:
Honestly I don’t like XML when developing metadata driven applications, as that would separate the code of a piece of logic into two different files. While this defect can be bridged with the use of design tools, just as what .NET WF and jBPM does, both of them provide visualized workflow definition tool. While my framework will keep it simple, without introducing any graphical tools to assist designing the workflow. Therefore, I choose using annotation instead of XML as the metadata language when designing workflows.
In a state workflow definition, one of the core concept is activity. e.g. in commercialized workflows, we have code activity, “if…else…” activity, while loop activity, invoke web service activity, etc. Some activities hold the business logic, while some others are only used for linking other activities to form a whole procedure, just like the “if…else…” activity. In Hyperion, all these activities are simplified into one type, which is the “code activity”, as I believe everything that can be achieved by predefined activities can also be written in code. So why we still need workflow definition? That’s because we still need to handle state transitions.
We may have the concept of workflow in many kinds of projects, and of different scales. There are many well known workflow projects, including Microsoft .NET WF, JBPM by JBOSS, etc. Both of these workflow engines support state workflow, but when working on another project, I noticed that none of these can fit into my requirement, as what I needed was a multi-state workflow engine.
Why do I call it multi-state? At a particular time, one workflow instance should only have one state. However the instance may have multiple aspects, and for each aspect, it can have a separate state. For example, a workflow instance represents a task that need to be done by multiple roles in parallel. One role may see this task at state A, while at the same time, another role may see this task at state B. So in fact, at a particular time, a workflow instance has a State Set associated with it.