On Transactional Work ows

The basic transaction model has evolved over time to incorporate more complex transactions struc tures and to take the advantage of semantics of higher level operations that cannot be seen at the level of page reads and writes Well known examples of such extended transaction models include nested and multi level transactions A number of relaxed transaction models have been de ned in the last several years that permit a controlled relaxation of the transaction isolation and atomicity to better match the requirements of various database applications Correctness criteria other than global serializability have also been proposed Several examples of extended relaxed transaction models are reported in Recently transaction concepts have begun to be applied to support applications or activities that involve multiple tasks of possibly di erent types including but not limited to transactions and ex ecuted over di erent types of entities including but not limited to DBMSs The designer of such applications may specify inter task dependencies to de ne task coordination requirements and some times additional requirements for isolation and failure atomicity of the application We will refer to such applications as multi system transactional work ows While such work ows can be developed using ad hoc methods it is desirable that they maintain at least some of the safeguards of transactions related to the correctness of computations and data integrity Below we discuss brie y the speci cation and execution issues in this evolving eld with emphasis on the role of database transaction concepts The idea of a work ow can be traced to Job Control Languages JCL of batch operating systems that allowed the user to specify a job as a collection of steps Each step was an invocation of a program and the steps were executed as a sequence Some steps could be executed conditionally This simple idea was subsequently expanded in many products and research prototypes by allowing structuring of the activity and providing control for concurrency and commitment The extensions allow the designer of a multitask activity to specify the data and control ow among tasks and to selectively choose transactional characteristics of the activity based on its semantics The work in this area has been in uenced by the concept of long running activities Work ows discussed in this paper may be long running or not Other related terms used in the database literature are task ow multitransaction activities multi system applications application mul tiactivities and networked applications Some related issues are also addressed in various relaxed transaction models A fundamental problem with many extended and relaxed transaction models is that they provide a prede ned set of properties that may or may be not required by the semantics of a particular activity Another problem with adopting these models for designing and implementing work ows is that the systems involved in the processing of a work ow may not provide support for facilities implied by an extended relaxed transaction model Furthermore the extended and relaxed transaction models are mainly geared towards processing entities that are DBMSs that provide transaction management features often assumed to be of a particular restrictive type with the focus on preserving data consistency and not on coordinating independent tasks on di erent entities including legacy systems