Distributed and Parallel Databases, 4, 229-247 (1996)
`© 1996 Kluwer Academic Publishers, Boston. Manufactured in The Netherlands.
`
`Exotica/FMDC: A Workflow Management System for Mobile and Disconnected Clients
`
`G. ALONSO
`
`R. G I)NTHC)R
`
`M. KAMATH
`
`alonso@inf.ethz.ch
`
`rgunthor @ heidelbg.ibm.com
`
`kamath@cs.umass.edu
`
`D. AGRAWAL, A. EL ABBADI
`
`{agrawal,amr}@cs.ucsb.edu
`
`C. MOHAN
`
`mohan @ almaden.ibm.corn
`
`IBM Almaden Research Center, 650 Harry Road, San Jose, CA 95120, USA Received May 1, 1995; Accepted February 12, 1996 Recommended
`
`by: Daniel Barbara, Ravi Jain, Narayanan Krishnakumar
`
`Workflow Management Systems (WFMSs) automate the execution of business processes in envi-
`ronments encompassing large numbers of users distributed over a wide geographic area and using heterogeneous
`resources. Current implementations allow the definition and controlled execution of complex and long lived
`business processes as the basis for an enterprise-wide collaborative system but, in most cases, the autonomy of
`the users is greatly restricted due to architectural and design considerations. In particular, existing systems are
`built around a centralized server. As a result, users need to maintain an uninterrupted connection with the server
`to perform the different tasks assigned to them. This is a severe restriction, especially when considering the
`emergence of mobile computing, and the increase in use of laptops and small computers which are connected
`to the network only occasionally and which will, undoubtedly, be the tool of choice for many users. This paper
`addresses the problem of supporting disconnected workflow clients in large workflow management systems while
`still preserving the correctness of the overall execution and allowing coordinated interactions between the different
`users regardless of their location.
`
`Workflow, Disconnected Operation, Mobile Computing
`
`1. Introduction Workflow Management Systems,
`
`WFMSs, are seen as a key tool to improve the efficiency of
`an organization by automating the execution of its business processes. A WFMS supports
`the modeling, coordinated execution and monitoring of the activities that take place within
`an organization. It is up to the user to define such activities and organize them in the most
`efficient way using the tools provided by business process re-engineering [13], but once the
`activities and processes of interest have been defined, the workflow management system is
`
`Apple Inc. Exhibit 1012
`
`Department of Computer Science, ETH-Ziirich, ETH-Zentrum, CH-8092 Ziirich, Switzerland
`IBM European Networking Center, Postfach 10 30 68, 69020 Heidelberg, Germany
`Department of Computer Science, University of Massachusetts, Amherst, MA 01003, USA
`Department of Computer Science, University of California, Santa Barbara, CA 93106, USA
`Abstract.
`Keywords:
`

`
`230
`
`ALONSO ET AL.
`
`used to represent the business processes and to assign the staff and role hierarchies in the
`organization within which those business processes will be executed. During the execution
`of the business process, the workflow management system acts as a coordinator: the WFMS
`delivers the various tasks to each user, collects results, determines the next steps, controls
`the activities of each user, and detects when the process has successfully terminated. The
`patterns of collaboration among the users are predefined as dependencies between individual
`steps within a business process, with each step being assigned to potentially different users.
`Thus, the synergy between all the steps is provided by the designer of the business process.
`Note that full automation is not possible, since human intervention is necessary to solve
`many crucial steps and to determine what to do in case of errors and unpredictable events.
`However, the use of a workflow management system simplifies to a great extent the task of
`coordinating large numbers of users working in heterogeneous and distributed environments.
`Many existing WFMSs are built based on a client-server architecture due to the simplicity
`of the design and the synchronization problems posed by other architectures [4, 3]. Such
`an approach has many advantages and it is useful in many organizations where the server
`is installed in some central computer and users access the system through terminals, PCs
`or workstations, installed in their offices. Most clerical work, form processing, accounting
`activities, and stock management, to name a few applications, is done this way. However,
`there are many other applications where this may not be the best approach.
`Recently, disconnected operation
`has been identified as one of the main ways in which
`computers will be used in the future [ 17]. Taking advantage of the arrival of more reliable
`and powerful portable and home desktop computers, users within an organization can work
`independently of the main computer facilities: applications and data are loaded in the
`laptops or desktops by briefly connecting with a server, the connection is broken, and users
`work locally on those applications and data. After the work has been completed, which
`may be in a few hours or few days, users reconnect with the server and transfer the results
`of their work. Disconnected operation offers many obvious advantages but, in many ways,
`disconnected computing and workflow management systems have contradictory goals. A
`workflow management system is a tool for cooperation and collaborative work in which
`users work within a preestablished framework that guarantees progress towards a certain
`goal, the business process, of which the users may not be aware. This requires constant
`monitoring and checking of the users' activities. On the other hand, disconnected computing
`is geared towards supporting users who work in isolation from other users. There is not
`much room for collaboration in disconnected mode.
`This paper addresses the problem of supporting disconnected clients in a large workflow
`management system. The goal is to give enough autonomy to the clients to allow them to
`perform work without having to be connected to the rest of the system and still maintain
`the overall correctness and consistency of the processes being executed. To bridge the gap
`between disconnection and coordination, we propose a compromise between both worlds.
`Users must "commit" themselves to perform certain tasks before disconnecting from the
`system. The workflow management system takes advantage of such commitment to assign
`tasks to users, allowing them to work on their own while ensuring overall correctness and
`constant progress towards the goal of the business process. The ideas described in this paper
`is one of the first studies on the impact of portable computers on collaborative workflow
`
`28
`
`Apple Inc. Exhibit 1012
`
`

`
`EXOTICA/FMDC
`
`231
`
`systems [2, 5], and the first to provide a feasible solution where the implementation aspects
`are discussed within the constraints of a real system. For this purpose, we use FlowMark
`[18, 19], a workflow product from IBM that uses a client-server architecture, where the
`ideas described here have been implemented.
`The rest of the paper is organized as follows. Section 2 presents the basic ideas behind
`workflow systems pointing out the architectural and conceptual problems to support dis-
`connected operation. Section 3 describes the functioning of the system when clients are
`connected to the system at all times. Section 4 discusses possible solutions for supporting
`disconnected clients in terms of three different phases. Section 5 addresses the problem of
`locating clients in the system when they are mobile and can connect to different servers.
`Section 6 discusses some of the issues raised in previous sections and the implemented
`prototype. Section 7 summarizes related work and Section 8 concludes the paper.
`
`This section introduces the basic concepts of workflow management according to the def-
`initions provided by the Workflow Management Coalition, WfMC,
`in its Reference Model
`[14, 22]. The WfMC is an international organization leading the efforts to standardize
`workflow management products. Implementation details are discussed based on FlowMark
`[18, 19], IBM's workflow product.
`
`as "a procedure where documents, informa-
`The reference model defines a business process
`tion or tasks are passed between participants according to defined sets of rules to achieve,
`or contribute to, an overall business goal" [14]. An example of a business process is shown
`in Figure 1. Some of the steps within a process may also be complex processes themselves.
`For instance, in Figure 1, Case study
`and Finalize credit are
`shown as nested processes.
`From this definition, it is easy to see the contradictory goals of automating the execution of
`business processes and providing support for disconnected operation. The key idea in any
`workflow system is to pass "documents, information or tasks" around the participants (as
`[29], electronic mail
`[12, 23], or transactional activities [11, 27, 30], for instance),
`while disconnected operation is geared towards user's autonomy.
`A business process can be expressed as a schematic representation of the procedural
`knowledge related to certain activities. This is generally called a workflow.
`Hence, a
`WFMS, is "a system that completely defines, manages and
`executes workflows through the execution of software whose order of execution is driven
`by a computer representation of the workflow logic" [14]. Once again, note that a WFMS
`automates the execution of workflows, which are representations of business processes and,
`hence, "automation" acquires different meanings depending on the type of processes. For
`business processes in general, this automation involves performing several tasks: schedul-
`ing activities, mapping activities to users currently in the system, tracking the progress of
`activities, assigning resources to activities, and so forth. In existing systems these tasks are
`
`29
`
`Apple Inc. Exhibit 1012
`
`2. Workflow Systems
`2.1. Business Processes and Workflow Management Systems
`forms
`workflow management system,
`

`
`2 3 2
`
`ALONSO ET AL.
`
`CREDIT REQUEST PROCESS
`
`N275=N Figure
`
`1. A Loan Request as an Example of a Business Process
`
`all performed by the server, hence, to accommodate disconnected clients, some modifica-
`tions to the overall system design will be necessary to guarantee progress without clients
`having to access the server at each step.
`
`as a coordinated set of activities
`The Workflow Management Coalition defines a process
`connected in order to achieve a common goal [22]. The automated components of such
`a process forms a workflow process.
`For simplicity, in what follows we will use the term
`process to refer to a workflow process, i.e., we will assume a process can be automated in its
`entirety. A process
`consists of activities
`and relevant data.
`Activities are the different steps
`of the process and associated with each of them is an invoked application,
`the application to
`
`set of users responsible for the execution of the activity. The invoked application execute, and a role, the
`can be a computer program or a human activity. The relevant data
`is defined
`as the data being transferred among activities. The flow of control within a process, i.e.,
`what to execute next, is determined by transition conditions,
`usually boolean expressions
`based on relevant data. Users are represented in terms of roles,
`and activities are generally
`associated to roles instead of individual users. This allows the system to determine~who
`is currently available and assign the activity to that user instead of having to wait until an
`individual user logs on. The invoked applications can be almost anything as long as there is
`a way to communicate their result to the WFMS. In the case of applications being programs,
`API, calls are used to access and return data.
`
`30
`
`Apple Inc. Exhibit 1012
`
`2.2. Workflow Model
`Application Program Interface,
`

`
`EXOTICA/FMDC
`
`233
`
`Worklists can be seen
`One of the most relevant aspects of a WFMS is the use of worklists.
`as the interface of the WFMS to the end user. A worklist is a list of workitems associated
`with a particular user, and each user has one. Each workitem is an activity that belongs
`to a process being executed and that has been assigned to this user, and possibly also to
`others with the same role, for its completion. Hence, the same activity may appear in several
`worklists at the same time. In this case, when an activity is selected in one worklist, it will be
`deleted from all other worklists. The mapping between roles, users, activities and worklists
`is automatically performed by the system. All this functionality must be maintained during
`disconnected operation.
`
`WFMSs have various possible architectures [3], but for the purposes of this paper they all
`have similar characteristics. In general, the functionality of a workflow system is distributed
`among three different components: runtime control, runtime interactions
`and buildtime
`[14]. Runtime control has two aspects to it: persistent storage
`and process navigation.
`Persistent storage allows the system to recover from failures without losing data and also
`provides the means to maintain an audit trail of the execution of processes. The navigational
`logic controls the execution of processes. Thus, we consider two components within runtime
`control, the storage server
`and the navigation server.These are
`referred to as the Workflow
`control data and the Workflow Engine in the reference model. Similarly, runtime interactions
`are of two types, with the users and with invoked applications. The former is the interface
`with the end users and consist mainly of the worklist assigned to a given user. The latter
`is the interface to the applications being executed as part of a workflow. We consider
`them as separate components, the User Interface
`and the Application Interface.
`These
`appear in the reference model as Worklist
`and Invoked Applications.
`We will not discuss the
`details of buildtime operations since they are somewhat orthogonal to the actual execution
`of processes.
`
`The reference model does not provide any guidance in terms of implementation and lacks a
`detailed description of the interactions between the different components. For this purpose
`we use FlowMark, an IBM product which closely follows the reference model. Except for
`some minor implementation differences, the ideas described in the rest of the paper should
`apply to any WFMS that follows the functional specifications of the Workflow Coalition
`reference model.
`Business processes are modeled in FlowMark as acyclic directed graphs in which nodes
`represent steps of execution and edges represent the flow of control and data [18, 19].
`
`are: processes, activities, control connectors, data connectors, The main components of FlowMark's workflow model
`and conditions.
`A process is a description of the sequence of
`steps involved in accomplishing a given goal and it is represented as a graph. Activities are
`the nodes in the process graph and represent the steps to be completed. Control connectors
`
`31
`
`Apple Inc. Exhibit 1012
`
`2.3. Workflow System Architectures
`2.4. FlowMark's Model and Architecture
`

`
`234
`
`ALONSO ET AL.
`
`o s s - ObjectStore Server
`~
`FMS - FlowMark Server
`tL..Tr.2.1~
`RTC- Runtime Client
`d
`r
`;
`PEC - Program Execution Client ~ ~ i
`.
`
`APP - Application Program
`~iiii:iiii!i::~i
`
`I"--I
`
`__
`~
`
`IL.7..2.1
`~-"~
`.
`~l,
`~,,
`!
`~
`~
`
`RTcL~J===~-i!iiiii~i:i::~
`
`....
`
`are used to specify the order of execution between activities and are represented as directed
`edges in the process graph. Data connectors specify the flow of information from one
`activity to another in the form of mappings between the data containers of the activities
`and are also expressed as directed edges in the process graph. Each activity has one input data container
`and one output data container.
`Finally, conditions specify when certain
`events will happen. There are three types of conditions: transition conditions
`associated
`with control connectors determine whether the connector evaluates to true or false; start conditions,
`which specify when an activity will be started; and exit conditions,
`used to
`specify when an activity is considered to have terminated.
`
`In terms of its architecture, FlowMark runs across different platforms (AIX, OS/2, Win-
`dows) and supports distribution of most of its components. However, in its current version,
`persistent data resides in a single database server, ObjectStore. This has facilitated the
`design of the overall system, but introduces a single point of failure in the architecture [ 1 ].
`As far as we know, existing systems such as Wang's OPEN/Workflow,
`AT&T's ProcesslT,
`are also
`Fujitsu's Regatta,
`XSoft's InConcert,
`or Action Technologies' Action Workflow
`based on a centralized repository and, hence, suffer from the same problem. Besides the
`database server, FlowMark is organized into three other components: FlowMark Server, Runtime Client
`and Buildtime Client
`as shown in Figure 2. These correspond to the three
`functionalities mentioned in the reference model: Buildtime Client for buildtime functions,
`Runtime Client for runtime interactions, and FlowMark Server for runtime control.
`
`32
`
`Apple Inc. Exhibit 1012
`
`N
`Figure 2. Runtime Components of FlowMark
`

`
`235
`
`OSS 2 - FMS RTC PEC APP
`
`7
`
`1, Start Activity 2. DB update 3, Commit Transaction 4. Start Program 5. Start Application 6. Activity Running 7. API call 8. Data Request 9. DB query 10. Query results 11. Requested Data 12. API call return 13. Application terminates 14. Program Terminated 15. DB update 16. Commit and Next Activities 17. Activity Terminated OSS= ObjectStore Server FMS= FlowMark Server RTC= Runtime Client PEC= Program Execution Client APP= Application Figure 3. Message Exchange Between FlowMark Components During the Execution of an Activity
`
`10
`
`J
`
`and there can be many instances
`In FlowMark, a running process is called aprocess instance,
`of the same process running concurrently. An activity can be executed automatically (pro-
`grams) or manually by a human role. We focus only on manual activities since only they
`are interesting in the disconnected context. When an activity of a process instance becomes
`ready for execution, FlowMark first performs role and staff resolution to determine all the
`users who are eligible to execute the activity. It then updates the worklists of all these users
`by including the activity as a new workitem. For all of those users who are logged onto
`FlowMark, an activity ready
`message is sent to their corresponding runtime clients.
`The complete exchange of messages that occurs among the different components when
`an activity is executed, shown in Figure 3, is as follows: once the activity ready
`message
`arrives at a runtime client, the activity is displayed in the user's worklist. When the user
`selects the activity from the worklist, the runtime client sends a start activity
`message to the
`server. Upon receiving such a message, the workflow server initiates a transaction on the
`database to retrieve the necessary information to execute the application that corresponds to
`the activity. This includes the node where it has to be executed, the access path, permissions
`required, user-id, program name, and so forth. With this information, the server determines
`the program execution client that will execute the application and sends to it a start program
`message. The server also sends an activity running
`message to the runtime client that will
`result in the status of the activity being changed in the worklist. Finally, the server notifies
`all other users who were eligible to execute the activity that the activity is already executing,
`
`33
`
`Apple Inc. Exhibit 1012
`
`EXOTICA/FMDC
`3. Normal Operation with Continuous Connection to the Server
`

`
`236
`
`ALONSO ET AL.
`
`which results in a change in the worklists of these users to indicate that they can no longer
`select the activity.
`message, the program execution client starts the applica-
`Upon receiving a start program
`tion. The application may request information from its input container through API calls.
`These are received by the program execution client and, if the information is locally avail-
`able, the program execution client
`relays it to the application. If the information is not
`locally available, the program execution client requests it from the server and then relays
`it to the application. An application may not make use of the API calls, so this round of
`messages is optional. The program execution client captures the termination of the applica-
`tion and sends a program terminated
`message to the server with any values the application
`returned. At the server, this message triggers the execution of a transaction that will store
`the values returned by the application in the appropriate output data container, and check
`the exit condition of the activity. If the activity terminates successfully, then the same
`transaction determines the next activities ready for execution and the same sequence of
`messages starts all over again. The server also sends an activity terminated
`message to the
`original runtime client indicating that the activity completed its execution. Upon receiving
`this message, the activity is deleted from the worklist. Note that the entire sequence of
`messages is based on the fact that all components are always connected to the server and,
`therefore, to the database, which simplifies synchronization and the design of the clients.
`
`Support for disconnected operation can be provided in two ways, one is to have the clients
`working in a "batch" mode, where a set of activities is assigned to them and all the relevant
`information is downloaded to the clients prior to their disconnection. The other is to allow
`the clients to perform navigation themselves by transferring entire parts of a process to the
`clients. It turns out that the latter option adds significant overhead to the design since it
`requires to duplicate at the clients much of the functionality of the server. Thus, we have
`chosen the "batch" mode as the most viable option.
`
`For simplicity, we rule out from our model disconnections due to failures. In what follows,
`we will assume that disconnection is a voluntary step taken by the user and that this is
`declared to the system beforehand. This is not a very restrictive assumption since such an
`intention can be easily triggered by the user when declaring that some work is to be loaded
`in the client, a common procedure with portable computers. Such a procedure is known as
`disconnection in the mobile computing literature.
`During disconnected operation we will assume that both the runtime client and the program
`execution client are local, while other components are remote. Runtime clients in FlowMark
`play a passive role. They are mere interfaces for the user to specify actions such as start activity.
`As such, the role of a runtime client does not change in disconnected mode except
`for the fact that instead of sending the commands to the centralized database, in disconnected
`
`34
`
`Apple Inc. Exhibit 1012
`
`4. Supporting Disconnected Clients
`4.1. Process Execution During Disconnection
`a planned
`

`
`EXOTICA/FMDC
`
`237
`
`OSS FMS RTC @ ec' 10
`
`PEC APP PRIOR TO DISCONNECTION ............ 6 .... DISCONNECTED MODE RECONNECTION 1.- RTC send "lock activity" message to server. 2.- RTC sends "lock activity" message to PEC. 3.- Server begins transaction to update database. 4.- Transaction commits. Activit~ is now "running" 5.- Server sends "start program message to PEC. 6.- Message is logged in the PEC . 7.- RTC sends "start locked activity" to PEC. 8.- PEC starts application . 9.- Application terminates returning results. 10.- IlTC is notified that the activity has finished. 11.- PEC logs results of the application. 12.- RTC reconnects to server, 13.- Server checks the worklist for the RTC. 14.- Server sends worklist to RTC. 15.- PEC reconnects to server. 16.- Server acknowledges reconneetion. 17.- PEC sends "program terminated" message to server. 18.- Server updates database . Figure 4. Message Exchange Between the Different ElowMark Components During Disconnected Operation
`
`17
`
`2!---
`
`mode it will send them to the program execution client. Similarly, the termination of an
`activity will not be reported by the database but by the program execution client. Thus, for all
`practical purposes, the runtime client does not change, except for some added functionality
`that will be discussed later. The program execution client, during disconnected operation,
`will act according to the messages received from the runtime client as opposed to reacting
`to the messages sent from the server. Since it cannot connect to the database to provide
`additional information requested by the application through API calls, it must also provide
`its own persistent storage for the information that may be requested by the application.
`Similarly, it must also persistently store the results of the application's execution until they
`can be sent to the server.
`
`To accomplish all these changes, we distinguish three phases in the disconnected operation
`process. The first is a synchronization
`phase in which, prior to disconnection, a user declares
`the intention to reserve an activity. If it is an activity that can be executed by several users,
`then the other users are notified that they are no longer eligible to execute the activity. This
`phase also involves transferring all the information pertaining to the activity from the server
`to the program execution client. The second phase is the disconnected operation per se,
`in
`which the user works on the reserved activities without any control from the server. The
`third phase is the reconnection
`to the server, in which the worklist of the user is updated,
`and the results of the executions of the activities are reported back to the server for storage
`in the database. The actual sequence of messages exchanged during these three phases is
`summarized in Figure 4.
`
`35
`
`Apple Inc. Exhibit 1012
`
`

`
`2 3 8
`
`ALONSO ET AL.
`
`9 FMS RTC PEC 1.- User locks an activity. Server is notified 2.- User locks an activity. PEC is notified. 3.- Server begins transaction to update the database. 4.- Transaction commits. Activity is now "running" 5.- Server notifies RTC of the new state of the activity. 6.- Server sends "start program" message to PEC * PEC logs the message 7.- PEC request input data container for application 8.- Server begins transaction to access data container 9.- Transaction commits returning the data container. 10.- Server sends data container to PEC * PEC stores the data container 11.- PEC notifies RTC that activity has been locked *RTC sets activity to locked in the worklist Figure 5. Messages Exchanged Prior to Disconnecting from the Server
`
`*~-~
`
`7
`
`The main purpose of the synchronization phase is to get all participants to "agree" with
`the disconnection of a given user. During this phase there are two important steps: locking
`and preloading
`the activities that will be available at the client while being disconnected.
`Locking is necessary due to the fact that the same activities may appear in several worklists
`simultaneously. Under normal circumstances, the centralized database serializes all changes
`to an activity and, hence, even if two users attempt to start the same activity concurrently,
`only one of them will be able to register in the database as the user to which the activity
`has been assigned. To prevent other users from working concurrently on the same activity,
`before a user can disconnect from the server, all activities they intend to work on must be
`by the user. When a user locks an activity, this implies an explicit commitment to
`work on that activity, regardless of whether the user works on the activities while connected
`to the server or disconnected from it. A locked activity is permanently assigned to a
`user until the user completes it or unlocks it. During disconnected operation only locked
`activities will appear in the worklist of the user. An activity in the worklist can enter the
`locked state only from the ready state: activities already running cannot be locked. The
`server only allows the locking and downloading of activities that can completely run on
`the mobile client, i.e., not those which need to access a program or database located on a
`remote machine.
`Locking only requires changes to the runtime and program execution clients. Upon
`receiving a request to lock an activity, the server treats the request as if it were a start activity
`message and behaves accordingly. At the program execution client, however, a
`is not to be executed immediately.
`Instead, all the information is stored
`persistently for later retrieval. At the runtime client, the worklist will change the status of
`the activity to reflect the fact that it has been locked.
`
`36
`
`Apple Inc. Exhibit 1012
`
`OSS
`8
`4.2. Synchronization Prior to Disconnection
`locked
`locked activity
`

`
`EXOTICA/FMDC
`
`239
`
`To facilitate the identification of locked activities and minimize the changes at the server,
`when a user locks an activity, the runtime client sends a lock activity
`message to both the
`server and the program execution client. To avoid race conditions, the runtime client will
`have to send the message first to the program execution client, and once it receives an
`acknowledgement, send the same message to the server. In this way, the server sends the
`information in exactly the same way as if it were an activity to be executed under normal
`circumstances and yet the program execution client is able to differentiate between a locked
`activity and other types of activities.
`The program execution client keeps a list of locked activities. When a start program
`message arrives, it is matched against all entries in the worklist. If the application to be
`executed corresponds to a locked activity, instead of starting the application, the message
`is stored for later use. Note that this first message contains only the information necessary
`to start the execution of the program. If the program uses API calls to request information
`during disconnected operation, more information needs to be retrieved from the database.
`For this reason, the program execution client also requests from the server the input data
`container of the locked activity, to be stored with the information of the first message.
`Once all this is done, the program execution client notifies the runtime client, which then
`considers the activity to be successfully locked. The exchange of messages is shown in
`Figure 5.
`
`One of the goals of our design is to maintain the "look and feel" of the interface. From the
`user's point of view there should not be any difference between normal and disconnected
`operation, beyond the limitation that during disconnected operation the worklist contains
`only locked activities. Locked activities behave the same way as standard activities: the
`user can start the execution of a locked activity, or force its termination. However, this
`will result in a series of messages exchanged between the runtime client and the program
`execution client, instead of using the server as an intermediate step.
`When the user starts a locked activity, the runtime client sends a start locked activity
`message to the program execution client. Upon receiving this message, the program execu-
`tion client retrieves the data from its own repository and proceeds as usual when executing
`an application. Since the input data container of the activity is available at the program
`execution client when the execution starts, API calls to request data from the container can
`be satisfied from the program execution client itself.
`When the execution of an application terminates, the values it returns are captured by
`the program execution client. Under normal circumstances, the program execution client
`would send this data to the server immediately. During disconnected operation, however,
`this is not possible and, hence, it must store the results until it is reconnected to the server.
`The termination of the application is also notified to the runtime client which will remove
`the locked activity from the worklist. However, the runtime client still keeps the name
`of the activity in a list of locked activities that have