Proceedings of the 2009 13th International Conference on Computer Supported Cooperative Work in Design
Collaborative Execution Mechanisms for the TCPN-Enhanced Process-View Approach Based Inter-Enterprises Workflow Ping Jiang, Liang Gao, Peigen Li, Haobo Qiu The State Key Laboratory of Digital Manufacturing Equipment and Technology, Huazhong University of Science & Technology, P.R. China
[email protected] Abstract Inter-enterprises workflow is by no means rare recently, which is more complex and dynamic than the intra-enterprise workflow. The Timed Colored Petri Nets (TCPN)-enhanced process-view approach implemented in our previous work provides an effective way to facilitate inter-enterprises workflow management. In this paper, the collaborative execution mechanisms have been developed for the TCPNenhanced process-view approach based interenterprises workflow. The state dependencies mechanism is proposed to facilitate the collaborative execution between TCPN workflow models and process-view workflow models in participating enterprises. The Synchronization Points (SPs) mechanism is proposed to coordinate the execution between process-view workflow models of participating enterprises and the integrated process-view workflow models of the enterprise alliance. Keywords: Inter-Enterprises Workflow, Process-View, TCPN.
1. Introduction Nowadays, the cooperative relationships between enterprises are moving from tightly coupled ones to loosely coupled ones, to better adapt to the dynamic market environment. Inter-enterprises workflow is by no means rare (such as the collaborative product design workflow in a multi-enterprise environment), which is more complex and dynamic than the intra-enterprise workflow. Workflow Management Systems (WMSs), which can automate business processes through coordinating and controlling the flow of work and information between functional departments, have been successfully applied for intra-enterprise workflow [1]. For inter-enterprises workflow, however, it is still a challenging research issue due to the dynamic and distributed nature of the problem. Motivated by the view concept of database, processview has been proposed to facilitate B2B workflow interoperability. According to different cooperative
requirements of business, the private workflow models of an enterprise can be mapped to process-views to encapsulate sensitive business details and expose necessary business to partner enterprises for better cooperation management. The process-views act as workflow interoperability interfaces to realize interenterprises business collaboration while keeping autonomy of participating enterprises. The processview approach provides a multi-granularity abstraction mechanism for workflow designer to flexibly conceal information of private workflow models. At the other hand, the existing workflow models are reusable in the process-view approach, which avoids expensive computing and cost on remodeling. The process-view approach provides a promising way to implement effective management of inter-enterprises workflow. However, the process-view is just a conceptual approach, and it will exert maximal effect if combined with powerful workflow modeling methods. Our previous work [2, 3] developed a Timed Colored Petri Nets (TCPN) enhanced process-view approach to implement the inter-enterprises workflow management for collaborative product development. In this paper, the collaborative execution mechanisms for the TCPNenhanced process-view approach based interenterprises workflow have been proposed to improve the previous approach. The rest of this paper is organized as follows. Section 2 introduces the related work. Section 3 presents the inter-enterprises workflow design based on the TCPN-enhanced process-view approach. Section 4 describes the collaborative execution mechanisms for the TCPN-enhanced process-view approach based inter-enterprises workflow. Section 5 gives the conclusion and future work.
2. Related work The process-view approach has attracted considerable research interests recently. Liu et al. focused on deriving an order-preserving process view from a given structured process definition, and applied the process-view approach to B2B workflow interoperability [4, 5]. Chiu et al. adopted the workflow view approach to drive cross-organizational workflows
978-1-4244-3535-7/09/$25.00 ©2009 IEEE
480
interoperability in the Web services environment [6, 7]. Karsten et al. proposed a workflow view approach to facilitate cross-organizational workflows interoperability, and focused on the communication between the entities of view-based workflow models [8]. Chebbi et al. presented a view-based approach for inter-organizational workflow cooperation [9]. The CrossWork project constructed the required process view in two steps, firstly, constructed the noncustomized process view from an internal structured process model, and then the customized process view is constructed by hiding and omitting activities from the non-customized process view [10, 11]. In the processview approach for inter-enterprises workflow management, there exist many inter-enterprises workflow models, including the private workflow models of participating enterprises, and the processview workflow models provided by participating enterprises to as the workflow interoperability interfaces for inter-enterprises collaboration. The implementation of the collaborative execution among all these inter-enterprises workflow models is vital to the success of inter-enterprises collaboration. Some corresponding rules were proposed, such as virtual states [5] and states dependencies [8]. However, the work discussed above has not addressed the problem completely. In this paper, the collaborative execution mechanisms for the TCPN-enhanced process-view approach based inter-enterprises workflow have been proposed at the base of previous work [3, 5, 8].
3. Inter-enterprises workflow design based on TCPN-enhanced process-view approach 3.1. TCPN-enhanced process-view approach The principle of process-view is the abstraction of workflow models. Figure 1 describes the process-view workflow models derived from a Petri nets workflow model, where the abstract places (AP) replace the denoted sub-models that are surrounded by dashed rectangles to hide business details, and logic transitions (LT) are added to the process-view workflow models to preserve the integrity of workflow models. Figure 1. (c) is a Petri nets workflow model, and Figure 1. (a) and (b) are both Petri nets based process-view workflow models with different information abstraction granularity. The formal definition of TCPN based process-view (called PV) was given in our previous work [3], where places were divided into base places and abstract places, while transitions were divided into base transitions and logic transitions. The abstract places (such as AP1 and AP2 in Figure 1) are used to replace the sub-models to conceal some sensitive business details. The logic transitions (such as LT1 and LT2 in Figure 1) are just used as logic control to ensure the
integrity of workflow models, i.e., the derived PV workflow models are TCPN workflow model. More information on PV and the TCPN-enhanced processview approach can be referred to [3].
Figure 1. The process-view workflow models derived from a Petri nets workflow model The TCPN-enhanced process-view approach merges the powerful modeling and simulation abilities of TCPN and the merits of process-view discussed in Section 1, which provides an effective way to facilitate inter-enterprises workflow management.
3.2. A design framework for inter-enterprises workflow How to effectively design inter-enterprises workflow to support the loose couple cooperative relationship among enterprises is one of the major challenges in the research and applications of inter-enterprises collaboration. Figure 2 describes a design framework for inter-enterprises workflow based on the TCPNenhanced process-view approach. There are two temporary Enterprise Alliances (EAs): EA1 and EA2. EA1 consists of enterprises A, B and C, and EA2 contains enterprises A, D and E. Each participating enterprise in EA maps its internal TCPN workflow models to PV workflow models according to business collaboration requirements respectively, and then the integrated PV workflow model of EA can be obtained by integrating these PV workflow models. As to enterprise A, which is a member of EA1 as well as a member of EA2, its internal TCPN workflow model can be mapped to the corresponding PV workflow model (such as PV workflow model to EA1 or PV workflow model to EA2) when designing different inter-enterprises workflow. With the proposed framework, participating enterprises can design all the inter-enterprises workflow models (including TCPN workflow models, PV workflow models and the integrated PV workflow model) flexibly and quickly through reusing their internal existing TCPN workflow models to adapt to the
481
Figure 2. A design framework for inter-enterprises workflow dynamic market environment. The PV workflow models of participating enterprises and the integrated PV workflow model of EA are the workflow interoperability interfaces to implement business collaboration among enterprises, which are visible to all participating enterprises.
4. Collaborative execution mechanisms for inter-enterprises workflow In the TCPN-enhanced process-view approach, the execution of TCPN workflow models is implemented by the actual execution of tangible tasks in participating enterprises; however, the execution of PV workflow models and the integrated PV workflow models does not refer to the execution of tangible tasks, which are just used to coordinate the execution of the underlying
TCPN workflow models among participating enterprises. In order to implement the collaborative execution of all these three kinds of inter-enterprises workflow models, the collaborative execution mechanisms have been proposed, and described in Figure 3. The state dependencies mechanism has been developed to realize the collaborative execution between TCPN workflow models and PV workflow models in participating enterprises, considering the relationships between TCPN workflow models and PV workflow models are tightly coupled ones. The Synchronization Points (SPs) mechanism has been proposed to coordinate the execution between PV workflow models of participating enterprises and integrated PV workflow models of the EA, considering the PV workflow models and integrated PV workflow models are loosely coupled relationships.
Figure 3. Collaborative execution mechanisms for inter-enterprises workflow
482
Figure 4. States and transformation of workflow task instances
4.1. The state dependencies mechanism Figure 4 describes states and the corresponding states transformation of workflow task instances in Petri nets representation [8], where places represent the states and transitions represent the events to implement states transformation. The state notStarted can be changed to states running, aborted and terminated directly, but it can not be changed to states completed and suspended directly. Supposing there exit a TCPN workflow instance TS and its corresponding PV workflow instance PS, ts is a task instance in TS, and ps is a task instance in PS, the state of ts is s and the state of ps is s1 . The function cs ( s`)ts represents that the state of the task instance ts in TS is changed from s to s` , and denoted in s → s` . The state dependencies mechanism between task instances in TS and task instances in PS is as follow. (1) The state dependencies mechanism from task instance ts in TS to task instance ps in PS. When ps requires cs ( s`)ts , ts will perform the following steps: Step 1: Is the state change of the ts from s → s` valid? If true ( s can be changed to s` directly), continue to step 2. If false, return false. Step 2: Are all needed resources for the operation of the event to implement s → s` available? If true, continue to step 3. If false, return false. Step 3: Perform s → s` . The state of the task instance ts is s` now. Return true. (2) The state dependencies mechanism from task instance ps in PS to task instance ts in TS. (i) When ps is a task instance of a base transition, ts and ps are the same task instances. When ts requires cs ( s1 `) ps , ps will perform the following steps: Step 1: Is the state change of the ps from s1 → s1 ` valid? If true, continue to step 2. If false, return false.
Step 2: Are all needed resources for the operation of the event to implement s1 → s1 ` available? If true, continue to step 3. If false, return false. Step 3: Perform s1 → s1 ` . The state of the task instance ps is s1 ` now. Return true. (ii) When ps is a task instance of an abstract place, ts is one of the tasks instances in task instance ps. When ts requires cs ( s1 `) ps , ps will perform the following steps: Step 1: Is the state change of the ps from s1 → s1 ` valid? If true, continue to step 2. If false, return false. Step 2: According to the relationships between the state of ps and the states of corresponding tasks instances set {ts} of ps described in Table 1, judge s1 → s1 ` is also valid? If true, continue to step 3. If false, return false. Step 3: Perform s1 → s1 ` . The state of the task instance ps is s1 ` now. Return true. Table 1. Sate relationships between ps and its corresponding tasks instances set {ts} Task instance ps of an abstract place notStarted
running
suspended
completed aborted terminated
483
Tasks instances set {ts} of ps States of all tasks instances in {ts} are notStarted States of some tasks instances in {ts} are running, while the states of the rest tasks instances are not aborted or terminated States of some tasks instances in {ts} are suspended, while the states of the rest tasks instances are not running, aborted or terminated States of all tasks instances in {ts} are completed States of some tasks instances in {ts} are aborted States of some tasks instances in {ts} are terminated
Figure 5. The SPs mechanism
4.2. The SPs mechanism
5. Conclusion SPs are some base transitions in the integrated PV workflow models, which can facilitate the exchange of workflows status information and the coordination of the workflows progress among the PV workflow models of participating enterprises at workflow execution stage. The SPs are defined by workflow designer of the EA, and the SPs of the same integrated PV workflow models can be different in different interenterprises collaboration. Fig. 5 describes the SPs mechanism. The base transitions Scheduling and Assembling2 are SPs in the integrated PV workflow model. When the integrated PV workflow instance executes to SPs, the SPs will trigger the global workflow engine of EA (step 1) to inquire the status information of corresponding PV workflow instances of local workflow engines in participating enterprises (steps 2 and 3). If there exists some delayed or abnormal information, the responsible local workflow engines will be triggered (step 4) to synchronize the execution of corresponding TCPN workflow instances in participating enterprises (step 5). When the integrated PV workflow instance executes to other nodes except SPs, each participating enterprises can freely execute their private TCPN workflow instances, and preserve the state dependencies between TCPN workflow instances and PV workflow instances.
In this paper, the collaborative execution mechanisms have been proposed for the TCPNenhanced process-view approach based interenterprises workflow, including the state dependencies mechanism and synchronization points mechanism. With the proposed mechanisms, the collaborative execution among the TCPN workflow models and PV workflow models of participating enterprises, and the integrated PV workflow models of the enterprise alliance can be effectively implemented. In the future, the proposed collaborative execution mechanisms will be applied to the TCPN-enhanced process-view approach based prototype system WFPNPV [3] to implement more effective inter-enterprises workflow management.
Acknowledgement This research has been supported by the National Basic Research Program (973 Program) of China under grant No. 2004CB719405, the Hi-Tech Research and Development Program of China under grant No. 2007AA04Z120, the Natural Science Foundation of China under grant No. 50705032.
484
References [1]
E. Stohr, J. Zhao, “Workflow Automation: Overview and Research Issues”, Information Systems Frontiers, 2001, 3 (3), 281-296. [2] X. Shao, P. Jiang, H. Qiu, L. Gao, “Workflow Modeling for Virtual Enterprise: a Petri Net based Process-View Approach”, in: Proceeding of the 10th International Conference on CSCW in Design (CSCWD 2006), pp.1213-1218. [3] P. Jiang, X. Shao, H. Qiu, P. Li, “Interoperability of Cross-Organizational Workflows based on ProcessView for Collaborative Product Development”, Concurrent Engineering: Research and Applications, 2008, 16 (1), 73-87. [4] D. Liu, M. Shen, “Workflow Modeling for Virtual Processes: an Order-Preserving Process-View Approach”, Information Systems, 2003, 28, 505-532. [5] D. Liu, M. Shen, “Business-to-Business Workflow Interoperation based on Process-Views”, Decision Support Systems, 2004, 38, 399-419. [6] D. Chiu, S. Cheung, S. Till, K. et al., “Workflow View Driven Cross-Organizational Interoperability in a Web Service Environment”, Information Technology and Management, 2004, 5, 221-250. [7] Z. Shan, D. Chiu, Q. Li, “Systematic Interaction Management in a Workflow View based B2B Process Engine”, Proceedings of the 38th Hawaii International Conference on System Sciences, 2005. [8] A. Karsten, E. Maria, “Facilitating Cross-Organizational Workflows with a Workflow View Approach”, Data & Knowledge Engineering, 2004, 51, 109-147. [9] Chebbi, S. Dustdar, S. Tata, “The View-based Approach to Dynamic Inter-Organizational Workflow Cooperation”, Data & Knowledge Engineering, 2006, 56, 139-173. [10] R. Eshuis, P. Grefen, “Constructing Customized Process Views”, Data & Knowledge Engineering, 2008, 64, 419438. [11] P. Grefen, N. Mehandjiev, et al., “Dynamic Business Network Process Management in Instant Virtual Enterprises”, Computers in Industry, 2008.
485
