E-mail: {guth | lenz | oberweis}@wiwi.uni-frankfurt.de ..... Workflow and Business Process Automation in Information Systems, State-of-the-art and Future ...
Office, Teleworking and Communication Tools', Vienna, Budapest, September 1998
DISTRIBUTED WORKFLOW EXECUTION BASED ON FRAGMENTATION OF PETRI NETS Volker Guth, Kirsten Lenz, Andreas Oberweis J.W. Goethe-University of Frankfurt/Main Institute of Information Systems P.O.-Box 11 19 32 D-60054 Frankfurt/Main Tel / Fax: ++49 69 798 – 23733 / 25073 E-mail: {guth | lenz | oberweis}@wiwi.uni-frankfurt.de
Abstract The development towards distributed business processes and the increasing demand to support business processes by information systems induce the necessity of distributed workflow management systems. This paper presents an approach for the distributed execution of workflows, based on the fragmentation of high-level Petri nets. Petri nets combine the graphical representation of workflows and a formal foundation. A method for the fragmentation of Petri nets is presented, which fulfills formal requirements concerning the workflow behavior.
1
Introduction
The globalization of companies, flexibilization of organizational structures, cooperation between companies, mobile computing and the development towards distributed business processes require the application of distributed information system technologies. Distributed database management systems, workflow management systems, and groupware technology as for example e-mail, video conferencing, or application sharing enable the distributed execution of business processes and support telecooperation. Complex centralized workflows have to be partitioned due to -
the geographical distribution of organizational units as for example in satellite working centers,
-
the distribution of data,
-
the complexity of the workflow, and
-
performance enhancement by parallel execution.
In the best case the workflow fragments should be stored and executed at the site where the responsible organizational unit and the required data are located [3]. This task requires a distributed workflow management system on the execution level and on the design level methods for the fragmentation of centralized workflows. In this paper, we present an approach for the distribution of workflows based on the fragmentation of high-level Petri nets such as predicate/transition nets. Data fragmentation and replication concepts for relational databases are modified and extended to process fragmentation and replication. Predicate/transition nets [6] provide a natural extension for the relational data model concerning the dynamic behavior of the relations. They combine the graphical workflow representation and a formal foundation [1, 5, 9]. Hence, the Petri net model can be directly executed by a workflow management system. In the next section, we survey some basic concepts from the area of distributed database systems and predicate/transition nets. In Section 3 we discuss the fragmentation of workflows. The requirements concerning the fragmentation of predicate/transition nets are explained and fragmentation methods are proposed. In Section 4 we compare our approach to related work and conclude with a brief outlook on future work.
2
Existing concepts
2.1
Data Distribution
Distributed database systems allow the management of geographically distributed data, stored at different sites of a computer network. The database user can work with the database as if it were a centralized system: the distribution of relations or parts of relations called fragments is transparent to the user. Fragments are either disjoint subsets of the tuples i.e. different rows of the table (horizontal fragmentation) or selected attribute values for all tuples of a relation i.e. different columns of the table (vertical fragmentation). For a simple example see Figure 1. An iterated fragmentation is possible, whereby horizontal and vertical fragmentation can be mixed up. The relations have to be fragmented in a way such that the original relation can be reconstructed [13]. Redundancies by overlapping data have to be omitted unless they are essential for the composition of the fragments (like primary key attributes in vertical fragments). The allocation of the fragments depends for instance on the availability and the storage costs of the sites, the communication costs, and the data retrieval and update frequencies. To ensure quick and reliable data access, the fragments can be replicated to several sites.
r id 35 87 61
name Miller Adams Jones
salary 5.000 5.800 6.400
r id 35 87 61
horizontal rh1 id name 35 Miller 87 Adams
salary 5.000 5.800
name Miller Adams Jones
salary 5.000 5.800 6.400
vertical rh2 id 61
name salary Jones 6.400
rv1 id 35 61 87
name Miller Jones Adams
rv2 id 35 61 87
salary 5.000 6.400 5.800
Figure 1: Fragmentation of a relation
On the one hand, the distribution of a database requires additional facilities of the database management system like transaction processing based on the two-phase-commit protocol [7, 10]. On the other hand, each site can be administrated autonomously and perform local query processing, what enables a high degree of concurrency. A detailed introduction into the area of distributed databases can be found for example in [10, 13]. 2.2
Petri nets
For the modeling of business processes several more or less formal description languages have been proposed. In contrast to other languages, Petri nets [2, 11] combine the advantages of the graphical representation of processes with a formal definition. This allows on the one hand the analysis and validation [4] of business processes and on the other hand the visualization of processes. High-level Petri nets such as predicate/transition nets [6, 9] integrate behavior- and object-related aspects of workflows. A predicate/transition net (PrT-net) is a Petri net where the places (predicates) represent relation schemes. The marking of the net assigns to each place a relation according to the respective relation scheme. A transition represents a class of operations on the relations in the adjacent places. Transitions and predicates are connected by directed arcs. A transition is enabled for a given marking (that means it may occur) if –
certain tuples exist in the relations of the input predicates,
–
certain tuples do not yet exist in the relations of the output predicates,
–
and the (optional) logical expression of the transition is true.
When a transition occurs, the respective tuples are removed from its input places and inserted into its output places according to the arc inscriptions. Figure 2 shows an example for a PrT-net. If the
transition 'assigning order number' occurs, the current order number is assigned to an order entry and the complete order is inserted into the relation 'order'. The respective order entry is deleted, and the next available order number is written into the relation counter. order entry
client_no 34064 93474
order entry order
no 577
article bolt pole
quantity price 200 0,50 5 20,35
assigning order number N'=N+1
order
order
stock (article, available quantity)
packing full quantity
Q > SQ ∧ SQ' = 0 ∧ M = Q - SQ
packing available quantity
missing articles (order no, client no, article, missing quantity)
package (order no, client no, article, delivered quantity, price)
send
delivered package (order no, client no, article, delivered quantity, price) Figure 3: PrT-net 'order execution'
3.1
Process patterns
Within business process models recurring process patterns can be recognized. The sequence of two activities, e.g., is a simple process pattern. The first activity can be executed independently of the next activity. Conversely, the results of the first activity are essential for the execution of the next activity. A Petri net for a sequential process can be seen in Figure 4 (a). Two activities are alternatives (Figure 4 (b)) if they compete for the same resources, i.e. the respective transitions have at least one common input or output place. Figure 4 (c) shows two concurrent activities which can be executed independently. Finally, two activities can depend on one another (Figure 4 (d)) which corresponds to cyclic processes. (a) sequence (b) alternative
(c) concurrency
(d) repetition
Figure 4: Process patterns
The different process patterns consisting of only two activities can be easily extended to processes with more than two activities. The recognition of such patterns represents a basis for a suitable fragmentation of workflows. 3.2
Requirements
Workflows should not be arbitrarily fragmented. In the first place, the fragmentation of the corresponding Petri net has to satisfy some formal conditions which can be derived from the requirements on the fragmentation of databases [10]. The fragmentation has to be complete, minimal, and disjoint. For a complete fragmentation, each place, transition, and arc of the original net is part of (at least) one of the fragments. The fragmentation is called minimal if no fragment contains a place, transition, or arc that is not part of the original net. A complete and minimal fragmentation is necessary to ensure the lossless reconstruction of the original net. On the workflow level the reconstruction property ensures that the process is not changed by fragmentation: neither predicates nor transitions have been added and the flow has not been changed. A disjoint fragmentation is a decomposition into fragments without overlapping parts – unless overlapping parts are needed for the reconstruction of the original net. Figure 5 shows an example of a fragmentation, which is not disjoint.
The overlapping fragments 1 and 2 in Figure 5 contain the same part of the process: the gray places and transitions. Yet, it is not clear how fragment 1 and fragment 2 communicate and at which point the decision is made whether the transition T3 occurs in fragment 1 or in fragment 2. To avoid this ambiguity, we only allow to model replication of processes by copying whole fragments. The subnet containing P2, T3, and P3 has to be a fragment of its own in order to be replicated.
T2 P1
T1
P2
P3
original net
T4
P4
T3
T2
fragment 1 P1
T1
P2
P3 T3
fragment 2 P2
T3
P3
T4
P4
Figure 5: Non disjoint fragmentation
Supplementary requirements with respect to the fragmentation of workflows concern the performance of the workflow execution. Reasons for fragmentation are for example -
the reduction of cost and time of the communication with the database by adapting the fragmentation to the distribution of data,
-
adapting the fragmentation to the organizational structure and resources like human resources, external applications etc., or
-
the hardware restriction of capacity and performance tuning by distributing the workflow.
On the other hand, distributed workflow execution implies cost for the communication between the fragments. Therefore, the cost saving by workflow distribution has to be considered in relation to the additional communication cost. A decomposition into many fragments can even turn out to be disadvantageous. 3.3
Fragmentation of PrT-nets
In this section, we describe the fragmentation of PrT-nets. Due to space limitations we omit the formal definitions and concentrate on an informal description of the fragmentation.
3.3.1 Methods of fragmentation We decompose PrT-nets by splitting the predicates. Predicates are split by duplicating them and assigning the copies to the respective fragments. In the following, we call these copies interface predicates. The marking of the predicate in the original net can be assigned to the corresponding interface predicates in two ways: Replication: The relation (marking) is replicated to those nodes where workflow fragments that contain the corresponding interface predicates are stored. Because the occurrence of an adjacent transition represents an operation on only one copy of the replicated relation the update of the other copies has to be synchronized. Although replica control is mainly a task of the database management system, the workflow management system has to handle concurrency of transitions concerning different copies of one relation. Due to data replication, the enabling of a transition can be tested locally, i.e. without communication with other fragments. Fragmentation: The relation can be fragmented horizontally. At one instance each tuple of the original marking is part of the marking of exactly one interface predicate. A tuple can be sent from one fragment to another (for example data resulting from one process can initiate another process). In this case, the rule for the enabling of transitions which are adjacent to an interface relation has to be modified: We do not test if a tuple is part of the whole relation of the predicate, but only if the local fragment contains this tuple. Therefore, tuple migration only presumes communication between the fragments based on a simple data transmission protocol. In Figure 6 the net is fragmented twice. The relation corresponding to the predicate P2 is also fragmented, but transition T4 cannot occur unless at least one tuple is sent from fragment 1 to fragment 3. The decision whether relations of interface predicates are replicated or fragmented depends on the workflow itself: fragmentation is more adequate if tasks are being delegated, whereas replication is suitable whenever tasks can be chosen from a 'to-do-list'. 3.3.2 Horizontal, vertical and diagonal fragmentation In the first place, we explain the notion of dependency between two fragments. Suppose a PrT-net being decomposed into fragments F1,...,Fn. Then we say fragment Fj depends on fragment Fi if both fragments contain a predicate s for which the following holds: s is an output predicate of at least one transition of fragment Fi and an input predicate of at least one transition of fragment Fj. That means,
we can observe a data flow from fragment Fi to fragment Fj in the original net. Using this definition we are able to distinguish between the following fragmentation methods. fragment 1
r
P2
A a1 a2
P2
T3
T1 P1
T2
P1
original net
T2
P3 B b1 b2
fragment 2 T1
T3
P3 r
P2 r
A a1 a2 a3
B b1 b2 b3
A a3
B b3
P3
T4 SEND
fragment 3 r
A
B
P2
T4
P3
Figure 6: Migration of tuples
Vertical fragmentation: A net is decomposed into two vertical fragments if one fragment depends on the other one, but a dependency does not exists in the other direction. We say the vertical fragmentation is orthogonal if the intersection of the fragments contains exactly one predicate. Examples for a vertical and an orthogonal fragmentation are shown in Figure 7. A vertical (orthogonal) fragmentation into three or more fragments can be reached by iterated decomposition of the fragments. The vertical fragmentation can be applied especially for sequential workflows.
(a) vertical fragmentation
(b) orthogonal fragmentation
Figure 7: Vertical fragmentation
Horizontal fragmentation: A Petri net is decomposed into two horizontal fragments, if no fragment depends on the other fragment. Alternative or concurrent processes can be fragmented horizontally like in Figure 8 (a) and (b). For concurrent processes the fragments have no interface predicates in common. Iterative application of horizontal fragmentation is also allowed.
(a) alternative process
(b) concurrent process
(c) repetition
Figure 8: Methods of fragmentation
Diagonal fragmentation: If two fragments depend on one another we call the net diagonally fragmented. A simple example is shown in Figure 8 (c) for a repetitive process. The three fragmentation methods can also be mixed up. 3.3.3 Example revisited In this section, we consider the example of Section 2.3 and first decompose the net into three vertical fragments. Afterwards, fragment 1 is decomposed into the horizontal fragments 1a and 1b (see Figure 9). The execution of the workflow fragment 1a is due to the workflow management system. The workflow fragment 1b must be executed at the finance department. Fragment 2 describes the inventory management, and finally fragment 3 concerns the mailing department. fragment 1b fragment 1a
fragment 2
fragment 3
Figure 9: Fragmentation of 'order execution'
3.4
Architectures
For the execution of centralized workflows, a single workflow engine serves as an interpreter for the PrT-net model of the workflow. If the workflows are distributed, the workflow management system can be implemented due to different architectures. First, the distributed workflow can be
executed by a central workflow engine that is installed at one of the sites (client/server architecture). Second, several workflow engines can be used instead of a single central workflow engine (distributed architecture). The workflow fragments are either executed by the local workflow engines at the corresponding sites with one of the sites being the workflow coordinator or by locally autonomous workflow engines without a central coordinator. The allocation of the workflow fragments can be fixed or variable. In the first case, the fragments are stored at the sites where they are executed. In the latter case, fragments can be sent to the execution site on demand. Whether a workflow engine is installed at a specific site or sent to the site on demand (together with the workflow fragment) depends for example on the size of the workflow engine in relation to the size of the workflow fragments, the average number of workflow fragments to be executed at the site, the maintenance and update cost of the workflow engine, and the flexibility of the workflow fragment allocation. The sending of the workflow engine (which is, e.g., implemented as a JAVA applet) to the execution sites allows for example to add spontaneously new execution sites to the system. Moreover, the workflow management system automatically works with the most recent version of the workflow engine. Though, if the migration of the workflow engine causes too much network traffic, the performance can be improved by installing the workflow engine locally.
4
Related work
4.1
State and activity charts
The workflow management system MENTOR [8] uses state and activity charts as modeling language for workflows. Activity charts specify the data flow between activities whereas state charts describe the control flow. A method for the fragmentation of workflows is based on the partitioning of activity charts and state charts. The correctness of the partitioning can be verified due to the formal foundation of the modeling language and the fragmentation method. 4.2
Communicative and cooperative nets
For communicative nets [12], the object-oriented paradigm is applied to PrT-nets. Yet, the main purpose of this approach is not the decomposition of large PrT-nets. In communicative nets, fragments correspond to objects of different object types which interact by sending messages and encapsulate their behavior. The interface between the objects are arcs: one object contains a transition which sends tuples to a so-called accept-place of another object. The enabling condition is
restricted to the object. Yet, it is not clear how to treat 'message sending transitions' with more than one output predicate. Cooperative nets differ from communicative nets only by the interaction mode, a client-server protocol.
5
Outlook
In this paper, we have presented concepts for the fragmentation of Petri net-based workflows. PrTnets can be fragmented horizontally, vertically and diagonally, and the fragmentation fulfills the necessary requirements like completeness, minimality and disjointness. Due to space limitations we had to omit several aspects. For example, protocols for the synchronization of replicated relations have to be adapted to the synchronization of replicated workflow fragments. Further, criteria for the allocation of workflow fragments depending on the allocation of data and resources must be found. Another relevant issue concerns the optimization of the fragmentation. For this purpose, the notions of size and complexity of a workflow and its Petri net model have to be examined in detail. Finally, recovery mechanisms must be found to support a failure-tolerant workflow execution. References [1] VAN DER AALST, W.M.P., Petri-net-based Workflow Management, in: Shedt, A. (ed.), Proc. NFS Workshop on Workflow and Business Process Automation in Information Systems, State-of-the-art and Future Directions, Athens (GA), 1996. [2] BRAUER, W., REISIG, W., ROZENBERG, G. (eds.), Advances in Petri Nets, Part I, Lecture Notes in Computer Science Vol. 254, 1986. [3] DEARLE, A., Towards Ubiquitous Environments for Mobile Users, in: IEEE Internet Computing, Vol. 2 (1), January/February 1998, p. 22-32. [4] DESEL, J., OBERWEIS, A., ZIMMER, T., ZIMMERMANN, G., Validation of Information System Models: Petri Nets and Test Case Generation, in: Proc. of the 1997 IEEE International Conference on Systems, Man, and Cybernetics, Orlando, Florida, USA, October 1997, pp. 3401-3406. [5] ELLIS, C.A., NUTT, G.J., Modeling and Enactment of Workflow Systems, in: Marsan, M.A. (ed.), Proc. 14th Int. Conf. on Application and Theory of Petri Nets, Chicago, Springer, Berlin/Heidelberg, 1993, pp 1-16. [6] GENRICH, H.J., Predicate/Transition Nets, in [2], pp. 207-247. [7] GRAY, J., REUTER, A., Transaction Processing: Concepts and Techniques, Morgan Kaufmann Publishers, 1993. [8] MUTH, P., WODTKE, D., WEISSENFELS, J., KOTZ DITTRICH, A., WEIKUM, G., From Centralized Workflow Specification to Distributed Workflow Execution, to appear in: Journal of Intelligent Information Systems (JIIS), Kluwer Academic Publishers, Vol. 10 (2), March 1998. [9] OBERWEIS, A., An Integrated Approach for the Specification of Processes and Related Complex Structured Objects in Business Applications, in: Decision Support Systems, 17, 1996, pp. 31-53. [10] ÖSZU, M.T., VALDURIEZ, P., Principles of Distributed Database Systems, Prentice-Hall, 1991. [11] REISIG, W., Petri Nets: an Introduction, EATCS monographs 4, Springer-Verlag, 1985. [12] SIBERTIN-BLANC, C., Cooperative Nets, in: Proc. 15th International Conference on Application and Theory of Petri Nets, Zaragoza, Spain, 1994, pp. 471-490. [13] SILBERSCHATZ, A., KORTH, H.F., SUNDARSHAN, S., Database System Concepts, McGraw-Hill, 1997.
