Rusinkiewicz M., Sheth A., "Specification and Execution of Transaction Workflows", in Modern Database Systems: the Object Model, Interoperability, and beyond, Kim W. (ed.), Addison-Wesley, 1994.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....edge, with the intuitive meaning that, as soon as the former ends, the latter is ready for execution. In all other cases, connections among WTs are performed by two special purpose routing tasks: forks, for initiating concurrent executions, and joins, for synchronizing after concurrent execution [2, 19, 22]. Each fork is preceded by one WT, called its predecessor, and followed by many WTs, called successors. Forks are classified as: ffl Total: after the predecessor ends, all successors are ready for execution. ffl Non deterministic: the fork is associated with a value k; after the predecessor ....

Rusinkiewicz M., Sheth A., "Specification and Execution of Transaction Workflows", in Modern Database Systems: the Object Model, Interoperability, and beyond, Kim W. (ed.), Addison-Wesley, 1994.

.... and of the (dynamic) sequence of events signaling the completion of WTs and of generic events produced within the execution environment (including exceptions) For the specification of WF behavior, we have presented in [8] a conceptual WF model, inspired by a rich literature on WF specification [1, 13, 15, 18, 21, 24, 25]. The model includes a large collection of constructs for specifying WT interactions, enables the specification of accesses to external databases, and supports preconditions and exceptions. All these concepts are formalized in a Workflow Description Language (WFDL) which is presented in [8] ....

....indicates which WTs should be executed, in which order, which agent may be in charge of them, and which operations should be performed on external databases. Intertask dependencies are specified using a restricted number of constructs: sequence, alternatives, parallelism such as fork and join [2, 11, 24]. The behavior of each WT is formally described by listing its preconditions, its actions, and its exceptional conditions during its execution. The peculiar feature of the proposed WF model is to enable, within WTs conditions, actions, and exceptions, the manipulation of databases by means of ....

Rusinkiewicz M., Sheth A., "Specification and Execution of Transaction Workflows ", in Modern Database Systems: the Object Model, Interoperability, and beyond, Kim W. (ed.), Addison-Wesley, 1994.

....are the starting point of a wider research project aiming at the integrated management of different WFs (workflow interoperability) and at the implementation of a WFMS on the basis of an active DBMS. The purpose of the paper is to propose an innovative approach to WF modeling. In the literature [2, 7, 8, 10, 11, 14, 16, 17] the proposed models lack expressive power concerning the possibility of specifying WT interactions and the mapping from the WF specification to WF execution, in particular concerning exception handling. The model we propose in this paper is the basis for overcoming this semantic gap 2 . The ....

....during the WF executions and the mechanisms which are used for their activation and termination, both in normal and in exceptional situations. WT coordination is supported in a restricted number of alternative ways, thereby providing classical constructs for parallelism, such as fork and join [3, 7, 16]. In addition, the behavior of WTs is formally described by listing their preconditions, their actions, and their exceptional conditions during their execution. The peculiar feature of the proposed WFDL is to enable, within WTs conditions, actions, and exception sections, the manipulation of ....

Rusinkiewicz M., Sheth A., Specification and Execution of Transaction Workflows, in Modern Database Systems: the Object Model, Interoperability, and beyond, Kim W. (ed.), Addison-Wesley, 1994.

....edge, with the intuitive meaning that, as soon as the former ends, the latter is ready for execution. In all other cases, connections among tasks are performed by two special purpose routing tasks: forks, for initiating concurrent executions, and joins, for synchronizing after concurrent execution [2, 11]. The schema specification may include cycles, where the same task can be executed several times within the same WF instance. Each fork is preceded by one task, called its predecessor, and followed by many tasks, called successors. Forks are classified as: Conditional: each successor is ....

Rusinkiewicz M., Sheth A., Specification and Execution of Transaction Workflows, in Modern Database Systems: the Object Model, Interoperability, and beyond, Kim W. (ed.), Addison-Wesley, 1994.

.... contributions and WF specification languages [EN93, GHS95] Several tools for process modeling, generally based on Petri Nets, are focused on the ability of animating WFs, thereby understanding their dynamic behavior [BFG93] In the literature [ASSR93, DHL90, EN93, FKB95, GHS95, H93, RS94, SR93] the proposed models present a limited expressive power concerning the possibility of specifying WT interactions and the mapping from the WF specification to WF execution, in particular concerning exception handling. Recently, a growing interest has concentrated on connecting WF systems to ....

....routines. WIDE 37 The ObjectFlow model is very well suited to implement administrative workflows, but the lack of a flexible exception handling mechanism and of explicit access to external databases could limit its effectiveness for production workflows. In the model developed at Bellcore [RS94] the focus is on transactional workflows. The most peculiar feature of this model is that possible task states may differ from task to task. This is because tasks can have different characteristics according to their transactional behaviour. Tasks may also have different isolation properties: the ....

Rusinkiewicz, M., Sheth, A., Specification and Execution of Transaction Workflows, in Modern Database Systems: the Object Model, Interoperability, and beyond, Kim W. (ed.), Addison-Wesley, 1994.

....a higher level model based on transaction primitives is described in [2] These two models can be used to express and to implement respectively some of the control flow characteristics of agents. On the basis of extended transaction models, many researchers have defined control flow specifications [23, 10] along the lines of Section 3. Computations as recoverable objects are discussed in [25] Finally, transaction management in mobile computing environments is addressed in [6, 20, 30] The agent based approach is in compliance with these models. 7 Conclusions We are currently witnessing the ....

M. Rusinkiewicz and A. Sheth. Specification and Execution of Transaction Workflows. In W. Kim, editor, Modern Database Systems: The Object Model and Beyond, pages 592--620. Addison Wesley, 1995.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC