Skip to content
This repository was archived by the owner on Mar 12, 2025. It is now read-only.

Commit 2aa89ea

Browse files
sebastianbergmannsebastianbergmann
committed
- Move to trunk.
0 parents  commit 2aa89ea

File tree

114 files changed

+8605
-0
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

114 files changed

+8605
-0
lines changed

‎CREDITS

+4
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
CREDITS
2+
=======
3+
4+
...

‎ChangeLog

Whitespace-only changes.

‎DEPS

Whitespace-only changes.

‎DESCRIPTION

Whitespace-only changes.

‎TODO

+3
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
TODO
2+
====
3+

‎composer.json

+44
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,44 @@
1+
{
2+
"authors": [
3+
{
4+
"name": "Sergey Alexeev"
5+
},
6+
{
7+
"name": "Sebastian Bergmann"
8+
},
9+
{
10+
"name": "Jan Borsodi"
11+
},
12+
{
13+
"name": "Raymond Bosman"
14+
},
15+
{
16+
"name": "Frederik Holljen"
17+
},
18+
{
19+
"name": "Kore Nordmann"
20+
},
21+
{
22+
"name": "Derick Rethans"
23+
},
24+
{
25+
"name": "Vadym Savchuk"
26+
},
27+
{
28+
"name": "Tobias Schlitt"
29+
},
30+
{
31+
"name": "Alexandru Stanoi"
32+
}
33+
],
34+
"autoload": {
35+
"classmap": [
36+
"src"
37+
]
38+
},
39+
"description": "The purpose of the Workflow component is to provide the core functionality of an activity-based workflow system including the definition and execution of workflow specifications.",
40+
"homepage": "https://github.com/zetacomponents",
41+
"license": "apache2",
42+
"name": "zetacomponents/workflow",
43+
"type": "library"
44+
}

‎design/design.txt

+313
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,313 @@
1+
eZ publish Enterprise Component: Workflow, Design
2+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3+
:Author: Sebastian Bergmann
4+
:Revision: $Revision$
5+
:Date: $Date$
6+
7+
Workflow Model
8+
==============
9+
10+
Activities and Transitions
11+
--------------------------
12+
13+
The workflow model is activity-based [FG02]. The activities that are to be
14+
completed throughout the workflow and the transitions between them are mapped to
15+
the nodes and edges of a directed graph. This choice was made to faciliate the
16+
application of the Graph-Oriented Programming paradigm for the implementation.
17+
Using a directed graph as the foundation for the workflow model makes it
18+
possible to define the syntax of the workflow description language using the
19+
formalism of graph grammars [DQZ01].
20+
21+
Graph Traversal and Execution Strategy
22+
--------------------------------------
23+
24+
The execution of a workflow starts with the graph's only Start node. A graph may
25+
have one or more End nodes that explicitly terminate the workflow execution.
26+
27+
After a node has finished executing, it can activate one or more of its possible
28+
outgoing nodes. Activation adds a node to a set of nodes that are waiting for
29+
execution. During each execution step, a node from this set is executed. When
30+
the execution of a node has been completed, the node is removed from the set.
31+
32+
The workflow execution is implicitly terminated when no nodes are activated
33+
and no more nodes can be activated.
34+
35+
State and Workflow Variables
36+
----------------------------
37+
38+
The workflow model supports state through the concept of workflow variables.
39+
Such a variable can either be requested as user input (from an Input node) or be
40+
set and manipulated through the VariableSet, VariableAdd, VariableSub,
41+
VariableMul, VariableDiv, VariableIncrement, and VariableDecrement nodes.
42+
43+
While a VariableSet node may set the value of a workflow variable to any type
44+
that is supported by PHP, the other variable manipulation nodes only operate on
45+
numeric values.
46+
47+
Variables are bound to the scope of the thread in which they were defined. This
48+
allows parallel threads of execution to use variables of the same name without
49+
side effects.
50+
51+
When the execution of a workflow reaches an Input node (see above), the
52+
execution is suspended until such time when the user input has been provided and
53+
the execution can be resumed.
54+
55+
Control Flow
56+
------------
57+
58+
The control flow semantics of the workflow model draws upon the workflow
59+
patterns from [BK03]. The Sequence, Parallel Split, Synchronization, Exclusive
60+
Choice, Simple Merge, Multi-Choice, Synchronizing Merge, and Discriminator
61+
workflow patterns are all directly supported by the workflow model.
62+
63+
Exclusive Choice and Multi-Choice nodes have branching conditions attached to
64+
them that operate on workflow variables to make their control flow decisions.
65+
66+
The workflow model supports one workflow construct, loops, that is not based on
67+
a workflow pattern. Loops are represented by a pair of LoopStart and LoopEnd
68+
nodes that bracket the loop body. Both start and end node of a loop can have
69+
break conditions attached to them that operate on workflow variables. Inside the
70+
loop body, VariableAdd, VariableSub, VariableMul, VariableDiv,
71+
VariableIncrement, and VariableDecrement nodes can be used, for instance, to
72+
model for or while loops.
73+
74+
Action Nodes and Service Objects
75+
--------------------------------
76+
77+
So far we have only discussed nodes that control the flow and that can
78+
manipulate workflow variables. We are still missing a type of nodes that
79+
actually performs an activity. This is where the Action node comes into play.
80+
81+
When the execution of a workflow reaches an Action node, the business logic of
82+
the attached service object is executed. Service Objects live in the domain of
83+
the application into which the workflow engine is embedded. They have read and
84+
write access to the workflow variables to interact with the rest of the
85+
workflow.
86+
87+
Sub-Workflows
88+
-------------
89+
90+
The workflow model supports sub-workflows to break down a complex workflow into
91+
parts that are easier to conceive, understand, maintain, and which can be
92+
reused.
93+
94+
A sub-workflow is started when the respective Sub-Workflow node is reached
95+
during workflow execution. The execution of the parent workflow is suspended
96+
while the sub-workflow is executing. It is resumed once the execution of the
97+
sub-workflow has ended.
98+
99+
100+
Software Design
101+
===============
102+
103+
Architecture
104+
------------
105+
106+
The workflow engine been designed and implemented as three loosely coupled
107+
components. The Workflow component provides an object-oriented framework to
108+
define workflows and an execution engine to execute them.
109+
The WorkflowDatabaseTiein and WorkflowEventLogTiein components tie the Database
110+
and EventLog components into the main Workflow component for persistence
111+
and monitoring, respectively.
112+
113+
A workflow can be defined programmatically by creating and connecting objects
114+
that represent control flow constructs. The classes for these objects are
115+
provided by the Workflow Definition API. This API also provides the
116+
functionality to save workflow definitions (ie. object graphs) to and load
117+
workflow definitions from a data storage. Two data storage backends have been
118+
implemented, one for relational database systems and another for XML files.
119+
Through the Workflow Execution API the execution of a workflow definition can be
120+
started (and resumed). The figure below shows the conceptual architecture for
121+
the workflow engine.
122+
123+
+---------+ +---------+ +------------------------+
124+
| GUI | <=> | XML | | Mail, SOAP, ... |
125+
+---------+ +---------+ +------------------------+
126+
/\ /\
127+
|| ||
128+
\/ \/
129+
+-------------------------+ +------------------------+
130+
| Workflow Definition API | | Workflow Execution API |
131+
+-------------------------+ +------------------------+
132+
/\ /\
133+
|| ||
134+
|| \/
135+
|| +------------------------+
136+
|| | Workflow Core |
137+
|| +------------------------+
138+
|| /\
139+
|| ||
140+
\/ \/
141+
+-----------------------------------------------------+
142+
| Data Storage |
143+
+-----------------------------------------------------+
144+
145+
The idea that a workflow system should be comprised of loosely coupled
146+
components is discussed, for instance, in [DAM01,DG95,PM99]. Manolescu
147+
states that
148+
149+
"an object-oriented workflow architecture must provide abstractions
150+
that enable software developers to define and enact how the work flows through
151+
the system" [DAM01].
152+
153+
Like Manolescu's Micro-Workflow architecture, the Workflow components
154+
encapsulate workflow features in separate components following the
155+
Microkernel pattern which
156+
157+
"applies to software systems that must be able to adapt to changing
158+
system requirements. It separates a minimal functional core from extended
159+
functionality and customer-specific parts. The microkernel also serves as a
160+
socket for plugging in these extensions and coordinating their
161+
collaboration" [FB96].
162+
163+
The minimalistic core of the Workflow component is provides basic workflow
164+
functionality:
165+
166+
- The Workflow Definition API implements an activity-based workflow model and
167+
provides the abstractions required to build workflows.
168+
- The Workflow Execution API implements the functionality to execute workflows.
169+
170+
On top of these core components other components, for instance for persistence
171+
(suspending and resuming workflow execution), monitoring (status of running
172+
workflows), history (history of executed workflows), and worklist management
173+
(human-computer interface), can be implemented. Each of these components
174+
encapsulates a design decision and can be customized or replaced.
175+
176+
177+
Workflow Virtual Machine
178+
------------------------
179+
180+
Given the fact that standardization efforts, e.g. XPDL [WfMC05] proposed by the
181+
Workflow Management Coalition, have essentially failed to gain universal
182+
acceptance [WA04], the problem of developing a workflow system that supports
183+
changes in the workflow description language needs to be addressed.
184+
185+
Fernandes et. al. propose to
186+
187+
"split the workflow system into two layers: (1) a layer implementing a
188+
Workflow Virtual Machine, which is responsible for most of the workflow system
189+
activities; and (2) a layer where the different workflow description languages
190+
are handled, which is responsible for making the mapping between each workflow
191+
description language and the Workflow Virtual Machine" [SF04].
192+
193+
The Workflow component's Workflow Execution API implements such a workflow
194+
virtual machine and isolates the executing part of a workflow management system,
195+
the backend, from the parts that users interact with, the frontend. This
196+
isolation allows for the definition of a backend language to describe exactly
197+
the workflows that are supported by the executer and its underlying workflow
198+
model. This backend language is not the workflow description language users use
199+
to define their workflows. They use frontend languages that can be mapped to the
200+
system's backend language.
201+
202+
203+
Graph-Oriented Programming
204+
--------------------------
205+
206+
Graph-Oriented Programming [JBOSS] implements the graphical representation and
207+
the wait states of a process language in an object-oriented programming
208+
language. The former can be achieved by providing a framework of node classes.
209+
Objects of these classes represent the nodes in the process graph, relations
210+
between these objects represent the edges. Such an object graph can then be
211+
traversed for execution. These executions need to be persistable, for instance
212+
in a relational database, to support the wait states.
213+
214+
The aforementioned node classes implement the Command design pattern [GoF94] and
215+
encapsulate an action and its parameters.
216+
217+
The executing part of the workflow engine is implemented in an Execution class.
218+
An object of this class represents a workflow in execution. The execution object
219+
has a reference to the current node. When the execution of a workflow is
220+
started, a new execution object is created and the current node is set to the
221+
workflow's start node. The execute() method that is to be provided by the node
222+
classes is not only responsible for executing the node's action, but also for
223+
propagating the execution: a node can pass the execution that arrived in the
224+
node to one of its leaving transitions to the next node.
225+
226+
Like Fowler in [MF05], the authors of the JBoss jBPM manual [JBOSS] acknowledge
227+
the fact that current software development relies more and more on domain
228+
specific languages. They see Graph-Oriented Programming as a means to implement
229+
domain specific languages that describe how graphs can be defined and executed
230+
on top of an object-oriented programming language.
231+
232+
In this context, a process language (like a workflow description language) is
233+
nothing more than a set of Node classes. The semantics of each node are defined
234+
by the implementation of the execute() method in the respective node class. This
235+
language can be used as the backend language of a Workflow Virtual Machine. In
236+
this lanugage, the workflow is represented as a graph of command objects.
237+
238+
One of the advantages of using a domain specific language that Fowler gives in
239+
[MF05 regards the involvement of lay programmers: domain experts who are not
240+
professional programmers but program in domain specific languages as part of the
241+
development effort. In essence this means that a software system that provides a
242+
domain specific language can be customized and extended without knowledge of the
243+
underlying programming language that was used to implement it.
244+
245+
246+
Summary
247+
-------
248+
249+
The core of the workflow engine is a virtual machine that executes workflows
250+
represented through object graphs. These object graphs can be created
251+
programmatically through the software component's Workflow Definition API.
252+
Alternatively, a workflow definition can be loaded from an XML file. Object
253+
graph and XML file are two different representations of a workflow definition
254+
that uses the so-called backend language of the workflow engine's core.
255+
Arbitrary frontend languages such as the XML Process Definition Language (XPDL)
256+
[WfMC05], for instance, can be mapped to the workflow engine's backend language.
257+
258+
259+
Bibliography
260+
============
261+
262+
- [BK03] Bartosz Kiepuszewski.
263+
Expressiveness and Suitability of Languages for Control Flow Modelling in Workflows.
264+
PhD Thesis, Faculty of Information Technology, Queensland University of Technology, Australia, 2003.
265+
266+
- [DAM01 Dragos-Anton Manolescu.
267+
Micro-Workflow: A Workflow Architecture Supporting Compositional Object-Oriented Software Development.
268+
PhD Thesis, Department of Computer Science, University of Illinois at Urbana-Champaign, USA, 2001.
269+
270+
- [DG95] Dimitrios Georgakopoulos and Mark F. Hornick and Amit P. Sheth.
271+
An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure.
272+
In: Distributed and Parallel Databases, Volume 3, Number 2, Pages 119--153, 1995.
273+
274+
- [DQZ01] Da-Qian Zhang and Kang Zhang and Jiannong Cao.
275+
A Context-Sensitive Graph Grammar Formalism for the Specification of Visual Languages.
276+
In: The Computer Journal, Volume 33, Number 3, Pages 186--200, 2001.
277+
278+
- [FB96] Frank Buschmann and Regine Meunier and Hans Rohnert and Peter Sommerlad and Michael Stahl.
279+
Pattern-Oriented Software Architecture -- A System of Patterns.
280+
John Wiley \& Sons, 1996.
281+
282+
- [FG02] Florent Guillaume.
283+
Trying to unify Entity-based and Activity-based workflows.
284+
http://wiki.zope.org/zope3/TryingToUnifiyWorkflowConcepts
285+
286+
- [GoF94] Erich Gamma and Richard Helm and Ralph Johnson and John Vlissides.
287+
Design Patterns: Elements of Reusable Object-Oriented Software.
288+
Addison-Wesley, 1994.
289+
290+
- [JBOSS] The JBoss Project.
291+
JBoss jBPM: Workflow and BPM Made Practical.
292+
http://docs.jboss.com/jbpm/v3/userguide/graphorientedprogramming.html
293+
294+
- [MF05] Martin Fowler.
295+
Language Workbenches: The Killer-App for Domain Specific Languages?
296+
June, 2005.
297+
http://martinfowler.com/articles/languageWorkbench.html
298+
299+
- [PM99] Peter Muth and Jeanine Weisenfels and Michael Gillmann and Gerhard Weikum.
300+
Integrating Light-Weight Workflow Management Systems within Existing Business Environments.
301+
In: Proceedings of the 15th International Conference on Data Engineering, March 1999, Sydney, Australia.
302+
303+
- [SF04] Sérgio Fernandes and João Cachopo and António Rito-Silva.
304+
Supporting Evolution in Workflow Definition Languages.
305+
In: Proceedings of the 20th Conference on Current Trends in Theory and Practice of Computer Science (SOFSEM 2004), Springer-Verlag, 2004.
306+
307+
- [WA04] W. M. P. van der Aalst and L. Aldred and M. Dumas and A. H. M. ter Hofstede.
308+
Design and Implementation of the YAWL System.
309+
In: Proceedings of the 16th International Conference on Advanced Information Systems Engineering (CAiSE 2004), June 2004, Riga, Latvia.
310+
311+
- [WfMC05] Workflow Management Coalition.
312+
Workflow Process Definition Interface -- XML Process Definition Language (XPDL).
313+
Document Number WFMC-TC-1025, 2005.

0 commit comments

Comments
 (0)