. This paper provides a formal foundation for distributed workflow executions. The state chart formalism is adapted to the needs of a workflow model in order to establish a basis for both correctness rea- soning and run--time support for complex and large--scale workflow applications. To allow for the distributed execution of a workflow across different workflow servers, which is required for scalability and organizational decentralization, a method for the partitioning of workflow specifications is developed. It is proven that the partitioning preserves the original state chart's behavior. 1 Introduction Workflow management is a rapidly growing research and development area of very high practical relevance [GHS95, Mo96, VB96, WfMC95, Sh96]. Typical examples of (semi--automated) workflows are the processing of a credit request in a bank, the edito- rial handling and refereeing process for papers in an electronic journal, or the medical treatment of patients in a hospital. Informa...

If the number of users within a workflow management system (WFMS) increases, a central workflow server (WF-- server) and a single local area network (LAN) may become overloaded. The approach presented in this paper describes an execution environment which is able to manage a growing number of users by adding new servers and subnets. The basic idea is to decompose processes into parts which are controlled by different WF--servers. That is, during the execution of a workflow instance its execution (step) control may migrate from one WF--server to another. By selecting the appropriate physical servers (for hosting the WF--servers) in the appropriate LANs, communication costs and individual WF--server workload can be reduced significantly. 1. Introduction Since a couple of years there has been a growing interest in using WFMS for implementing process--oriented application systems. As the benefit of such application systems increases with the number of applications being served, the number...

We describe two models for federating process-centered environments (PCEs): homogeneous federation among distinct instances of the same environment framework enacting the same or different process models, and heterogeneous federation among diverse process enactment systems. We identify the requirements and consider possible architectures for each model, although we concentrate primarily on the homogeneous case. The bulk of the paper presents our choice of architecture, and corresponding infrastructure, for homogeneous federation among Marvel environment instances as realized in the Oz system. We briefly consider how a single Marvel environment, or an Oz federation of Marvel environments, might be integrated into a heterogeneous federation based on ProcessWall's facilities for interoperating PCEs. Keywords: Collaborative work, Distributed system, Enterprise-wide environment, Geographical distribution, Internet, Process interoperability, Software process, Workflow management c fl1997...

Enterprise-spanning workflows require workflow management systems that can be tailored to specific application needs, as well as enhanced support for interoperability between different workflow management systems. In virtual enterprises, the interoperability problem is not limited to workflow execution, but also entails facili- ties like worklist management and history management to be interoperable. We present a light-weight system architecture, consist- ing of a small system kernel on top of which extensions like history management and worklist management are implemented as workflows themselves. The functionality of the kernel such as distributed workflow execution and interoperability interfaces is available for all extensions. We show the feasibility of our approach by presenting the imple- mentation of history management in our workflow specifica- tion language, based on state and activity charts, on top of our light-weight kernel, coined Mentor-lite. 1 Introduction Toda...

Workflow management systems support the efficient, largely au- tomated execution of business processes. However, using a workflow management system typically requires implementing the application's control flow exclusively by the workflow management system. This approach is powerful if the control flow is specified and implemented from scratch, but it has severe drawbacks if a workflow management system is to be integrated within environments with existing solutions for implementing control flow. Usual- ly, the existing solutions are too complex to be substituted by the workflow management system at once. Hence, the workflow management system must support an incremental integration, i.e. the reuse of existing implementations of control flow as well as their in- cremental substitution. Extending the workflow management system's functionality ac- cording to future application needs, e.g. by worklist and history management, must also be possible. In particular, at the beginning of...

We describe two models for federating process-centered environments, homogeneous federation where the interoperability is among distinct process models enacted by different copies of the same system and heterogeneous federation with interoperability among distinct process enactment systems. We identify the requirements and possible architectures for each model. The bulk of the paper presents the specific architecture and infrastructure for homogeneous federation we realized in the Oz system. We briefly consider how Oz might be integrated into a heterogeneous federation to serve as one of its interoperating PCEs. Keywords: Collaborative work, Distributed system, Enterprise-wide process, Geographical distribution, Internet, Software process, Workflow management c fl1996, Israel Z. Ben-Shaul and Gail E. Kaiser This paper is based on work sponsored in part by Advanced Research Project Agency under ARPA Order B128 monitoredby Air Force Rome Lab F30602-94-C-0197, in part by National Science...

workflows according to the organizational responsibilities of the enterprise. For the distributed execution of the partitioned workflow specification, MENTOR relies mostly on standard middleware components and adds own components only where the standard components fall short of functionality or scalability. In particular, the run--time environment is based on a TP monitor and a CORBA implementation. 2 Workflow Specification In virtually all commercially available WFMS the specification of a workflow is done via high--level graphical interfaces by drawing "bubbles and arcs". This specification must be mapped into an inter- nal representation in order to execute it. In most systems, the under- lying internal representation uses an ad hoc model and thus lacks ca- pabilities for formal correctness reasoning and interoperabi

The Workflow Management System AltaVista Works has been extended to be able to process workflows in a distributed, partly even parallel manner. Build-time data are replicated over all participating workflow servers. The distribution of workflow execution is based on migration. Instead of the usual, static pre-partitioning, highly dynamic management of distribution is applied. 1 Introduction The need for more efficient offices led to the concept of Business Process Re-engineering and to the technology that we call Workflow Management System (WMS). Early WMSs concentrated on small groups of users in a centralized environment. With the growing acceptance of workflows, the technology is used more and more in large organizations, which generate a high load and which are inherently distributed. These two new aspects leads to the desire to turn existing WMSs into distributed ones (DWMS). 2 Workflow-Management Workflow-Management is the automatization of business processes (BP). The partic...

Traditional workflow systems are not suited for highly interactive online systems. We present a state machine based workflow system, named FlexFlow, which formally describes Internet applications using statecharts. The FlexFlow engine uses these descriptions to directly control the execution of web applications.