!Introduction
Responsibilities are the foundations of jBpm. On the one hand this document describes the research we have been doing to serve as the foundations for the jBpm theory. On the other hand, the responsibilities can be seen as a higher level description of the jBpm requirements.
Responsibilities identifies the different sub-topics of workflow systems (aka perspectives of process definitions). For each responsibility the alternatives and implications are sketched. These sub-topics in the workflow domain or responsibilities have not been identified yet. As a consequence, workflow systems are presented as a monolythic block, while most WFMSs show clear overlaps and similarities. That makes comparing workflow systems and standards the hardest task.
This is mainly an approach for structuring the analysis of the workflow domain. But it turns out that this approach provides a very solid basis for implementing a workflow system. Every responsibility is implemented as a separate module. The state responsibility module can be implemented without it having any dependencies on other modules. The other modules have a dependency on the state module. If implemented properly, these modules can form the basis for an implementation of any workflow specification.
Motivation
The most direct benefits of workflow management systems is the common language between the business analyst and the technical developer. Without the use of a WFMS, the business analyst has to express requirements in diagrams and text documents. Then, the technical developer has to translate these requirements into a technical design. This is a costly and risky operation. So the main benefit of using a WFMS should be improved communication between business analyst and technical developer. The business analysts should be able to express the bulk of the requirements as a process definition. If the technical developer is able to implement the software on the basis of that same process definition, no more translation is required to a technical design. The technical developer only needs to fill in the technical details surrounding the business logic.
Goal
As can be derived from the context, the final goal is the development of workflow software. In every scenario where a WFMS is applicable, a different mix of the different responsibilities is required. Designing a reusable WFMS is therefore a real challenge. Typically WFMS's or specifications in that field are designed around a fixed mix of these responsibilities. This is a new analysis that identifies the topics of workflow as the responsibilities of workflow management systems. The core ideas behind the creation of these responsibilities is twofold :
Understanding
We want to split the topic of workflow into smaller manageable pieces. This is good for understanding each individual responsibility and their interdependencies. The responsibilities provide a good framework for communicating about a WFMS. It makes comparing WFMSs much easier. Above all, architects are able to see the subset of features they need and which parts of the WFMS are necessary. In my experience WFMSs are often used with a lot of overkill.
Pluggable architecture
The responsibilities will composed to form a basic layout for the architecture of new workflow management system. The users of a WFMS should be able to select any number of responsibilities that fit their needs and use only those without dependencies on unwanted features. On the other hand, it should be possible to plug in new responsibilities. Since the list below is not complete (e.g. predictive scheduling) new responsibilities should be pluggable into the main architecture framework.
State
Disadvantages of existing alternatives
The state responsibility is a central aspect in every workflow management system. State machines is a typical example of an aspect which is harder to program in a programming language then it is to specify in a declarative way. So its the ideal candidate for extracting state management information from the programming language and specify it in a declarative way. For specifying a state definition, the following alternatives have been considered :
uml state diagrams (= finite state machines)
uml activity diagrams
Each of these alternatives has disadvantages which make it unsuitable for specifying state management in workflow management systems :
Petri nets is a good language for specifying state but its too low level. The fact that its good can be concluded from the vast amount of academic research that has been done on this topic. An indication that petri nets are too low level could be concluded from the fact that Wil van der Aalst has assembled a set of 20 workflow patterns from the petri net constructs. The workflow patterns are described on the desired level.
Finite state machines have too limited concurrency features.
Activity diagrams are designed for business process modelling. They are great for doing business analysis with non-technical people. But its not a good basis for implementing a workflow engine. The trouble is the concept of 'activity'. First, its confusing because an activity is either a state or an action. Second, the action-activities create an overlap with plain programming constructs. See also Why the term 'activity' should be banned...
A new proposal
The proposal below takes the best of three worlds. In short, this is how you can think of the proposed model : Finite state machines are taken as the basis. Then the concurrency features of activity diagrams are added. And at runtime, the execution semantics of petri nets are used.
Definition
This proposal takes a as a basis a directed graph. Nodes are connected with directed transitions.
Execution
At runtime, a pointer needs to be maintained that references the current state of one path of execution. As long as no concurrency is involved the process instance could reference the current state directly. But when a path of execution splits in multiple concurrent paths of execution, each of the paths needs a pointer to the current state. That pointer corresponds to the concept of a token in petri nets. So lets just borrow that name. For easy referencing, tokens can maintain with a parent-child relation. A token becomes the parent token of all the child tokens that it forks. As a concluding remark we can say that the state of a process instance corresponds to a tree of tokens.
Logging
A WFMS is responsible for maintaining a set of state logs. Every state change has to be logged. Logs can be used for showing audit trails and performing undo operations. Most important data of a state log is
token on which the state transition took place
previous state
time
next state
Links
Comments