Dynamic Work ow Management on the Web - Semantic Scholar

Dynamic Work ow Management on the Web Gottfried Vossen, Mathias Weske, Gregor Wittkowski Lehrstuhl fur Informatik, Universitat Munster Grevener Strae 91, D-48159 Munster, Germany fvossen,weske,[email protected] November 1996

Abstract

Work ow management has gained increasing attention recently, since it allows to combine a data-oriented view on applications, which is the traditional one for an information system, with a process-oriented one in which activities and their occurrence over time are modeled and supported properly. While work ow management has mostly been considered in business applications so far, the focus of the WASA project is on scienti c applications such as geoprocessing or molecular biology. In particular, WASA aims at exible and platformindependent work ow support, both w.r.t. speci cation and execution of work ows. To achieve these goals, the prototype reported upon in this paper is based on Java and Internet technologies, and exploits existing infrastructure as far as possible. Speci cally, the work ow engine, which is implemented in Java, accesses a work ow database via a JDBC interface; agents access the system via Java applets interpreted by Web browsers or stand-alone Java applications. The paper outlines the design decisions, describes sample applications, and reports on the current state of the project.

1 Introduction Work ow management aims at modeling and controlling the execution of processes in both business applications [10, 6, 12] and scienti c applications [9, 15, 20]. It has gained increasing attention recently, since it allows to combine a data-oriented view on applications, which is the traditional one for an information system, with a process-oriented one in which activities and their occurrence over time are modeled and supported properly [19]. While a number of work ow management systems for business applications are commercially available already, systems for scienti c applications are still in their infancy. One goal of the WASA project is to remedy this situation. Speci cally, WASA tries to take the particular requirements of these applications, such as high modeling and speci cation exibility as well as platform independence [1, 13], into account. In this paper, we report on a WASA prototype that has recently been completed, and that is suited for performing work ow management on the Web. The prototype is based on the WASA (Work ow-based Architecture to support Scienti c Applications) architecture introduced in [20], and essentially captures the WASA work ow 1

engine, which is the core component. This component aims at enhancing the exibility of existing work ow management systems while providing a high degree of platform independence [21]. The term \ exibility" refers to the ability of users (or system administrators) to change a work ow description while the work ow executes (also known as dynamic modi cation [5]). Furthermore, the prototype supports exible work ow modeling by allowing to reuse pre-existing component work ow models in multiple other work ow models. While the usage of the WASA architecture is proving successful in scienti c applications [1, 13], this paper reports on the use of the WASA work ow engine for business work ows involving exible speci cation and dynamic modi cation. As one of our examples, we choose an \order processing" work ow. The paper is organized as follows: In Section 2 we present the key ideas underlying exible work ow management, discuss our goals and provide a running example. The system design and implementation are discussed in Sections 3 and 4, resp. Concluding remarks in Section 5 complete the paper.

2 Preliminaries 2.1 Modeling Work ows Work ow management combines in uences from a variety of disciplines, including cooperative information systems, computer-supported cooperative work, groupware systems, or active databases [19]. Its major application area has so far been in the business eld [12]; as the modeling of business processes has become a strategic goal in many enterprises, a further step is to optimize or to re-engineer them, with the goal of automation in mind. Various tools are now commercially available which support such business process re-engineering; a prominent example is ARIS [17]. Once the modeling and speci cation of business processes has been completed, they can be veri ed, optimized, and nally brought onto a work ow management system. Besides in the traditional eld of work ow management, i.e., business applications, new domains emerge, among which scienti c ones play a major role [20, 1]. In general, work ows can be characterized as the automated control and management of processes in businesses and other organizations. The structure of these processes and the structure of the organization performing them are speci ed in work ow models [8, 10, 12]. In general, work ows consist of a set of related activities which are executed by processing entities [16]. The building blocks of process models are activities. Activities are units of work as perceived by the modeler. Each activity includes a description of what it codes for, the data used and generated by the activity, formalized as typed input and output parameters, resp. Activities can be speci ed in a variety of ways, including textual descriptions (e.g., in email or a le), forms, messages, or computer programs. Processing entities which can perform tasks may be humans or software systems, e.g., mailers, application programs, or database management systems. Work ow management systems (WFMS) are used to control the execution of work ows 2

by controlling and coordinating the work of the processing entities to ensure ecient work ow executions [5, 18, 4]. Commercially available WFMS frequently use database management systems as embedded tools, which uniformly contain all data necessary for work ow execution. These environments allow users to create, execute and monitor the execution of work ows.

2.2 Motivation and Goals The work ow management systems which have reached the marketplace in recent years are mostly tailored towards business processes with a xed structure [14], which means that the business process or work ow under consideration is de ned completely before it is executed. After work ow modeling is complete, work ows are instantiated and executed. Changes to the structure of work ows are either not permitted during work ow executions, or require a re-compilation with subsequent re-execution. From a technical point of view, running work ows correspond to running programs, and (like executing programs) work ows cannot be changed after they have started. While the need for ad-hoc work ow support and dynamic modi cation (changing work ow models while work ows run) has been discussed in the literature in terms of speci cation issues [5], running systems supporting ad-hoc work ows and/or dynamic modi cation, however, are not yet available. Moreover, work ows typically are executed in distributed and heterogeneous environments. From a technical point of view this implies the need for platform independent software systems. Work ows today are often executed within a single organization, based an a client/server architecture and using a local computer network. With the trend to international and global markets, inter-organization work ows performed in distributed heterogeneous environments will become increasingly important. To support the enhanced functionality of work ow management systems, the traditional \built-time/run-time" approach to work ow management may no longer appear feasible. For this reason, the prototype we are developing is based on an interpretation approach. In particular, work ow models are stored in a database and are interpreted at runtime. We have based the design of our prototype on this decision to allow for dynamic change without interrupting the execution of work ows with a compilation run | as needed in previous approaches to incorporate the change. We aim at building a work ow management system that supports a high degree of exibility in specifying and executing work ows, while providing platform independence. While these properties are important for work ow management in scienti c applications [9, 20], modern requirements in business computing also indicate the need for these properties. In particular, specifying error conditions may not be feasible in business applications, and dynamic change of work ow models is an important functionality of a work ow management system to cope with exception handling [5]. More speci cally, a business work ow can easily contain more exception or error cases than valid cases or non-error cases, and it may happen that these error cases are only detected over time, but not completely foreseen in advance. It is then necessary to incorporate the error cases, or to modify the work ow model appropriately. Doing this on 3

the y appears more attractive than doing it through re-compilation whenever it occurs. In terms of exibility in modeling and executing work ows, our approach relates to several approaches that have been reported in the literature. A paper by Ellis et al [5] shows that the need for dynamic change is present in oce work ows, in order to circumvent or augment standard procedures. After a change happens, the work \resumes its progression in a new environment as described by the new procedure" [5]. The authors show how the change modi es a work ow by replacing a given sub-work ow by another completely speci ed subwork ow. As also stressed by Craven and Mahling [3], work environments nowadays are becoming increasingly dynamic, which requires new types of support for cooperative work. Business work ows may have to be changed on the y in order to take this dynamics into consideration (e.g., due to business process re-engineering).

2.3 Sample Scenarios By dynamic modi cation we mean to change a work ow model while a corresponding work ow is running. For instance, dynamic changes may alter the control or data ow of subsequent activities of the work ow to react to exceptions or to changes in the environment. We now discuss sample scenarios which require dynamic modi cation. In particular, the second scenario presents a sample work ow which recursively comprises a (self-modifying) modeling activity. In such a situation, the traditional separation of built-time and run-time in work ow management systems no longer makes sense, since now work ow modeling is considered to be a part of a work ow execution.

Scenario 1 Consider an organization in which many long-running work ows exist (weeks

or months). With long-running work ows the probability of the need for dynamic change increases. When work ows are to be changed in these organizations, the only way to do this without aborting active work ow instances is by dynamic modi cation: Delaying the modi cations to the time when all work ow instances have terminated may not be a feasible solution. The same holds for aborting the active work ow instances, make the change to the work ow model and restart the work ows based on the newly de ned work ow model. In addition, restarting work ows may be impossible because starting conditions of the work ow may already be lost. The second alternative (to continue active instances without the changes) may be not feasible, too. There are some examples which show that changes of work ow models have to concern every instance: 

When an organization performs business process re-engineering, some activities of a work ow may be deleted during that process. If these activities are not deleted in active work ow instances, no agent may be assigned to execute these activities, and the instances would never be completed.



Another example is the adjustment of a work ow model to the change in the environment of the process, e.g., the installation of new tax laws. In this case it is very important 4

model new subworkflow

choose existing subworkflow

start subworkflow

Figure 1: Modeling Work ows during Work ow Execution. that all work ow instances re ect the changes. To solve such problems, dynamic modi cation is necessary. In Section 4 we explain how the prototype is designed to support the dynamic change operations required, and how these can be executed by the user.

Scenario 2 Now consider the situation depicted in Figure 1. Assume a work ow in which

an activity will be executed under the supervision of a particular person. The system oers a number of sub-work ows to implement the activity, which were de ned beforehand. The person may choose (Activity \model new sub-work ow" in Figure 1) one of the pre-de ned sub-work ows to implement the activity by accessing the work ow library. However, if none of them seems suitable to execute the work ow, he or she may decide to specify a new subwork ow to implement the activity (\model new sub-work ow"). In this case, modeling a sub-work ow is done while the work ow executes. Finally, the chosen (or newly de ned) work ow is started (\start sub-work ow"). The traditional \built-time/run-time" approach to work ow management is hence no longer the only option in this context.

3 Conceptual Design of the Prototype In this section we discuss the conceptual design of the prototype, its system architecture and functionality. The following design decisions have been taken, in order to achieve our main goals of exibility and platform independence: 

Exploitation of Java: The work ow system has a client/server architecture, where both the work ow server and the clients are written in Java [7]. Java byte code can be interpreted on a large variety of platforms (including the Sun Solaris and Windows95 platforms used by us). This allows to execute the code on a large variety of systems without recompiling it.



Database access via JDBC: Work ow models are currently stored in a relational database, and the work ow server accesses these models using a JDBC interface (Java DataBase

5

Connectivity [11]). Using this middleware component, dierent underlying relational database products can be used without changing the code (at the moment, we use the Oracle relational database system). 

Web Browser as Work ow Client: HTTP (Hyper Text Transfer Protocol) is today an industry standard for communication between Internet-connected computers. Web Browsers (like Netscape Navigator or HotJava) can be used as front-ends to the HTTP protocol; these are available for a large number of platforms. We use standard Web browsers interpreting Java applets or stand-alone Java applications as work ow clients.

3.1 System Architecture The design decisions discussed above have led to the system architecture shown in Figure 2. Essentially, this is a client/server architecture, where the server reads work ow models from the database, controls the execution of work ows, and performs other important services like role resolution. Internally, it is composed of the core component, the work ow engine, and the database server which accesses application data stored in the underlying database. Both components are connected to the database by a JDBC interface, and the database contains work ow-related data (like work ow models and role descriptions) as well as application speci c data (like addresses of suppliers or ordered goods). Users access the work ow system using work ow clients. The basic functionality of a work ow client is to inform users (agents in general) of activities to perform. We have implemented two types of work ow clients: (i) as stand-alone Java application (ii) as Java applets, interpreted by Web browsers. We now comment on the respective properties of these alternative implementations. 

Since the Java byte code of an applet can be transferred when the work ow client is started (by accessing the work ow client URL), the applet version of a client requires a Web browser on the client side only. Due to security restrictions, local data accesses are not allowed for Java applets.



Stand-alone Java applications do not have this restriction. In particular, work ow clients can access the local le system and may start arbitrary application programs to implement activities. However, they have to be installed on the client host before they can be used, which requires the Java byte code of the application and a Java interpreter.

In both cases, the communication between the work ow server and the work ow clients is based on the TCP/IP protocol.

3.2 System Functionality We now outline the functionality of our prototype and focus on dynamic modi cation, as occurring in the sample scenarios below. 6

Client File System Workflow Client applications

Java Client Application

Java Client Applet Workflow Applications

TCP/IP

Server

Workflow Server Database Server

Kernel

JDBC Driver

File System

Oracle DB

applications

workflow library application data

Figure 2: System Architecture.

7

goods not in stock order from customer arrives

order goods from supplier

goods arrive

goods in stock

delivery to customer

booking

Figure 3: Work ow Model of Scenario 1.

3.2.1 Modeling and Dynamic Modi cation of Work ows As discussed above, a key functionality of our system is the possibility of re-using speci ed work ow models in other work ow models. When work ows are quite similar, re-using their models obviously enhances the eciency of modeling. There are two ways of re-use. First, work ow models can be re-used in other work ow models without changing them. For instance a work ow \billing" may occur in dierent work ows of a company. The \billing" work ow can then be used in all these dierent work ows without specifying it again for each particular case. In addition, work ow modeling may start from scratch or it may be based on pre-speci ed work ow model. In this case, a work ow model is edited to re ect the changes needed for the particular work ow. In this case, a new version of the work ow model will be created, which can be used in dierent work ows. It is also possible to dynamically change role information like assignments of roles to activities. In general, atomic work ows are implemented by applications. By changing the application program eld of an atomic work ow speci cation, the user may dynamically change the assignment of work ow activities to application programs. This functionality is implemented in the prototype. The dynamic change operations as discussed in the following examples are supported by the prototype in the way described next.

Scenario 1 We now make Scenario 1 discussed in the previous section more concrete: Con-

sider a work ow to process an order by a customer for speci c trading goods, as illustrated in Figure 3. The work ow starts with the arrival of the order and ends with the entry of the payment into the company's les, done after the delivery of the commodity to the customer. If not enough items are present then the company has to order additional items from the respective manufacturers. Because of potential long delivery times by the manufacturers such a work ow could take weeks or even months. Now suppose the installation of a new tax law that changes the payment entry handled by the sub-work ow \payment arrival". The modi cation is done by executing some SQL statements on the speci cation database. Every instance that not yet reached \payment arrival" will automatically pay regard to the changes because the speci cation of sub-work ows are loaded just before executing those sub-work ows. 8

Scenario 2 In Scenario 2 from the previous section, the dynamic modi cation is done within

a single work ow. Consider again the top-level work ow shown in Figure 1 This work ow has an activity \start sub-work ow", which has to be de ned during the execution of the toplevel work ow. Notice that \start sub-work ow" can be implemented by an arbitrary subwork ow model. We now look at activity \choose existing work ow" and de ne its structure. First, a number of pre-de ned work ow models are displayed, from which the user can choose one to implement \start sub-work ow". The activity then sends an SQL statement to the speci cation database which attaches the chosen sub-work ow to \start sub-work ow". If an adequate work ow model is not available in the work ow library, the sub-work ow \model new sub-work ow" is executed. This activity requests the user to de ne a new work ow model by using the work ow speci cation mechanism. In the simplest case, it shows an SQL prompt from which statements to de ne the new work ow model can be executed. After de ning the new sub-work ow, the system registers it as the re nement of activity \start sub-work ow", and this activity can be executed.

3.2.2 Executing Work ows When the work ow server is started, it reads all work ow models from the database and displays those which can be started immediately. In general, a work ow model can be started if it does not have any incoming control connectors. By selecting the work ow model, a new work ow instance is created. At any point in time, the system may control multiple instances of a given work ow model. Hence, the system supports concurrent execution of multiple work ows. The prototype also supports a construct known as bundle, introduced in the FlowMark system [8]. A bundle in a work ow model consists of an activity which may even be re ned by a complex work ow model. When the work ow is speci ed, the modeler does not know how many instances of the bundle activity will be needed when the work ow executes. In contrast, the system decides on the number of instances of a bundle activity to start while the work ow executes. Consider a work ow with activities A and B , which are executed sequentially. A is an atomic activity implemented by an application, and B is a bundle activity. One way of deciding on the number of instances of B to create is to examine the outcome of activity A which may be de ned as the bundle parameter. Assume the outcome of A is m then the system starts m instances of activity B . The activities of the bundle are executed concurrently, and the complex bundle activity terminates only if all activities of the bundle have terminated. To allow for dynamic modi cation, the work ow model is successively retrieved from the database while the work ow executes. In particular, the work ow server reads models of sub-work ows only when the sub-work ow is about to start. This allows to change the re nements of activities to sub-work ows when the top-level work ow executes, permitting dynamic modi cation. The work ow server creates a log le which includes information on the creation and termination dates of the work ow and its activities and role resolution information. This 9

historical information on work ow executions can be used to analyze and optimize work ows.

4 Implementation Based on the system architecture displayed in Figure 2 the main components of the WASA prototype are implemented as follows (details of the implementation are described in [21]). From a technical point of view, work ow data is stored in an Oracle relational database system; the work ow server is implemented in Java, an object-oriented programming language which is based on the interpretation approach. The work ow server may be used on any platform for which a Java interpreter exists. On the server side, platform independence is supported by using a JDBC driver, which is a uni ed interface to relational database systems. The work ow program contains JDBC calls which are translated to Oracle-speci c queries. Hence, the work ow data may also be stored in a dierent relational database system. Linking the speci c JDBC driver to the work ow server program is the only change required to adapt the program. Notice that the Java code of the work ow server does not need to be changed. (Currently, JDBC drivers are available for a wide range of commercial relational database tools.)

4.1 The Work ow Engine The work ow engine is the core part of the prototype (called \kernel" in Figure 2). When the system is started, the work ow engine reads work ow models from the work ow library. Since work ow models without any incoming control connectors can be started in an adhoc fashion, work ow models with this property are displayed. The key functionality of the work ow engine is to control the execution of executing work ows using information on the structure of the work ow and on the agents ready to perform activities. In general, for each activity a role is de ned, and when the activity is about to be started, the work ow engine determines the agents ready to perform it. This functionality is called role resolution. The engine is multi-threaded so that at any point in time multiple work ow instances, which may belong to dierent work ow models, may be executing. Starting work ows is done as follows. 

Starting a complex work ow: Complex work ows contain a number of sub-work ows which are related to each other by control connectors and/or data connectors. The work ow engine determines the sub-work ows to be executed, the agents to do so (role resolution), and supplies the input data needed to execute the complex work ow. When a sub-work ow of a complex work ow terminates, the work ow engine determines the next sub-work ow to be executed. Notice that sub-work ow models are retrieved from the database only if (and when) the sub-work ow is about to start.



Starting an elementary work ow: Elementary work ows are described by roles and applications. When an elementary work ow has to be executed, the work ow server

10

puts items on the worklists of all agents ready to perform the requested activity. When one agent selects an item, the respective items in the worklists of the other agents are deleted. Then, the input data is supplied, the application is started, and the agent performs the activity. When a sub-work ow terminates the work ow engine evaluates the transition conditions of its outgoing control connectors and starts follow-up sub-work ows if they exist. Otherwise, the execution of the work ow terminates.

4.2 Work ow Clients Users interact with the work ow system using work ow clients. As was mentioned already, we have implemented two types of work ow clients: 

Java Applications: For this type, a Java interpreter has to be present on the client side. Since there are no restrictions on the accesses of Java applications, implementations of work ow clients may access local data and may start external applications.



Java Applets, interpreted by standard Web browsers: For this type, now the presence of a standard Web browser suces on the client side. The Java applet is down-loaded to the client Web browser and interpreted by it. Like the other type of client, it communicates with the work ow server using the TCP/IP protocol. However, security restrictions apply to Java applets, e.g., access to local data and starting external applications may not be performed by work ow clients implemented by Java applets.

Work ow clients carry out automatic and manual applications. Automatic applications are executed by the clients without any control by human agents, whereas manual ones are represented on a worklist. A human agent may choose an application from his or her worklist and in doing so she requests to perform the activity. Although in general more than one agent can be informed about an activity, only one of them is allowed to perform it. Therefore an application has to be withdrawn from every other agent's worklist as soon as one agent chooses the item. Using the synchronized construct of Java, the work ow engine synchronizes the requests and accepts only one agent because multiple agents could choose one task simultaneously. When sending a grant message to the client, the work ow engine also transfers the input parameters. Thereafter the client invokes the application and hands over the parameters. After nishing an application the client transfers the output parameters back to the engine, which afterwards terminates the elementary work ow and coordinates following activities.

4.3 Work ow Applications Generally speaking, work ow applications are realized by Java programs. These programs are able to carry out any external program on the client machine provided that the work ow client has been started as a Java application (not as an applet, as discussed above). The advantage 11

of using Java to implement a work ow application is that it can easily access the common database running on the server computer using the database server, discussed now.

4.4 Database Server The database server controls accesses of work ow applications to the database. Before accessing the database, work ow applications have to undergo a log-in procedure, implemented as follows. The database server supervises a pre-de ned Internet port and reacts to log-in requests of applications. A request consists of the name and the password of the agent performing the particular application. Then the database server veri es the identity of the agent, so that only registered users can access the database. When the identi cation is correct, the application can send queries to the database server, which then passes them directly to the database. When the query produces return values, these are are transferred to the application.

4.5 Discussion The prototypical implementation of the WASA work ow system discussed in this paper is able to achieve its main goals of exibility and platform independence. Some other important properties, not yet realized in the current system, are discussed next. 

Complex organizational structures existing in large enterprises are not yet taken into consideration. Our system supports a simple role concept. The database structure has to be expanded if a more powerful role concept is needed.



We generally assume that elementary work ows are implemented by Java programs. These programs either represent forms used by persons to read or write data, or they automatically perform operations. External applications can also be integrated, provided that the work ow client has been started as a Java application. Data can easily be transferred to the application by starting the application with parameters. However, it is more dicult to transfer return values from the application to the work ow client. This could be realized by certain les, generated by the application, which are read by the work ow client.



Speci cations of work ows supported by the actual version are not allowed to contain loops. When the work ow system is, for instance, installed in a scienti c environment, it would be helpful to support such loops [2].



One should also take into account that the dynamic modi cation of a work ow speci cation in the current version eects all active instances.



In addition to the dynamic modi cation of work ows, roles may also change during runtime. Therefore, the database relations representing the role concept have to be reconsidered in regular intervals. In the existing version all of the agents together with 12

there roles are loaded when starting the system. Because work ows may run a long time, agents and roles may change during work ow executions.

5 Conclusions In this paper we have reported on our prototypical implementation of the WASA work ow manager and its capability of supporting dierent dynamic change operations which are useful for a wide range of applications. The WASA architecture has been designed with a number of scienti c applications in mind, and is supposed to take care of their speci c work ow requirements. Our current prototype is a rst step in realizing our goals, and it obviously gives rise to a number of future enhancements. We will use the work ow manager in business work ow management and in scienti c work ow management projects, for instance in molecular biology [13] and geoprocessing [1], but also in laboratory information systems. As we have mentioned already, work ow management can be considered an important direction in the future development of information systems, since it contributes to making them \active" in the sense that data-oriented and process-oriented view are integrated. In business applications, the need for process orientation as a strategic goal is well-understood by now; what we try to contribute to is to convey this approach to non-business applications as well. The prototype we have reported upon in this paper is our rst concrete step in this direction. Among the things that will be done in the future are the following: The user interface needs to become more user-friendly; indeed, specifying work ow models in terms of SQL statements is not the most convenient way to do this. To this end, we are building a graphical interface which will ease the speci cation of work ows and their constituents. Moreover, we plan to replace Oracle by a database system which goes beyond a purely relational representation of data. Next, we plan to built a lter which translates FlowMark's FDL code to JDBC calls to the work ow library; hence, FlowMark work ow models can be directly imported into our system. For bringing the prototype to real-world applications, we are implementing a variety of work ows from the geoprocessing domain as well as from the area of laboratory information and management systems. These will provide a eld study of the applicability of the prototype. Underneath the work ow engine, we are exploring CORBA functionality for both support of the work ow engine and uniform access to external storage systems, including database managers and le systems.

References [1] C. Bauzer Medeiros, G. Vossen, M. Weske. GEO-WASA: Supporting Geoprocessing Applications using Work ow Management. In Proc. 7th Israeli Conference on Computer Systems and Software Engineering, Herzliya, Israel 1996, 129{139, IEEE Computer Society Press, Los Alamitos, CA. 13

[2] A. Brayner, M. Weske. Using FlowMarkTM in Molecular Biology (in German). EMISA Forum 2/1996, 14{21. [3] N. Craven, D. Mahling. A Task Basis for Projects and Work ows. In Proc. Conference on Organizational Computing Systems (COOCS), Milpitas, CA 1995, 237{248. [4] G. Dinko, V. Gruhn, A. Saalmann, and M. Zilonka. Business Process Modeling in the Work ow Management Environment LEU. In P. Loucopoulos (editor) 13th International Conference on the Entity-Relationship Approach: Business Modeling and ReEngineering, pages 46{63, Manchester, UK, December 1994. Lecture Notes in Computer Science. [5] C. Ellis, K. Keddara, G. Rozenberg. Dynamic Change Within Work ow Systems. In Proc. Conference on Organizational Computing Systems (COOCS), Milpitas, CA 1995, 10{22. [6] D. Georgakopoulos, M. Hornick, A. Sheth. An Overview of Work ow Mangement: From Process Modeling to Work ow Automation Infrastructure. Distributed and Parallel Databases, 3:119{153, 1995. [7] A. Van Ho, S. Shaio, O. Starbuck. Hooked on Java. Addison-Wesley, Reading, MA, 1996. [8] IBM. IBM FlowMark: Modeling Work ow, Version 2 Release 2. Publ. No SH-19-8241-01, 1996. [9] Y. Ioannidis (ed.). Special Issue on Scienti c Databases. Data Engineering Bulletin 16 (1) 1993 [10] S. Jablonski. Work ow Management Systems { Modeling and Architecture (in German). Thomson's Aktuelle Tutorien 9, International Thomson Publishing, Bonn, 1995. [11] JavaSoft: Drivers)

http://splash.javasoft.com/jdbc/jdbc.drivers.html.

(JDBC(tm)

[12] F. Leymann, W. Alterhuber. Managing Business Processes as an Information Resource. IBM Systems Journal 33, 1994, 326{347. [13] J. Meidanis, G. Vossen, M. Weske. Using Work ow Management in DNA Sequencing. In Proc. 1st IFCIS International Conference on Cooperative Information Systems (CoopIS), Brussel, Belgium 1996, 114{123, IEEE Computer Society Press, Los Alamitos, CA. [14] C. Mohan. State of the Art in Work ow Management System Research and Products. Tutorial notes, 5th International Conference on Extending Database Technology, Avignon, France 1996. 14

[15] B. Rieche, K. Dittrich. A Federated DBMS-based Integrated Environment for Molecular Biology. In Proc. 7th Int. Working Conf. on Scienti c and Statistical Database Management 1994. [16] M. Rusinkiewicz and A. Sheth. Speci cation and Execution of Transactional Work ows. In Kim Won (editor): Modern Database Systems The Object Model, Interoperability, and Beyond, chapter 29, pages 592{620. ACM Press, 1995. [17] A.-W. Scheer. ARIS Toolset: a Software Product is Born. Information Systems 19, 1994, 607{624. [18] K.D. Swenson and K. Irwin. Work ow Technology: Tradeos for Business Process Reengineering. In COOCS'95, pages 22{29, Milpitas, CA, 1995. [19] G. Vossen, J. Becker. (editors) Business Process Modeling and Work ow Management: Models, Methods, Tools (in German). International Thomson Publishing, Bonn, Germany, 1996. [20] M. Weske, G. Vossen, C.B. Medeiros. Scienti c Work ow Management: WASA Architecture and Applications. Fachbericht Angewandte Mathematik und Informatik 03/96-I, Universitat Munster, 1996. [21] G. Wittkowski. Design and Implementation of a Work ow System in Java (in German). Diploma Thesis, Universitat Munster, 1996.

15