WfMSs (workflow management systems) are software systems that support coordination and cooperation among members of an organization when they are performing complex business processes [108]; these processes are modeled as workflow processes that are automated by the WfMS. The workflow model (also referred to as the workflow process definition) is the computerized representation of the business process that defines its starting conditions, stopping conditions, activities, and control and data flows among the involved activities. An activity is a logic step within a workflow that includes information about the starting and stopping conditions, the users who are allowed to participate (the participants), the tools and/or data needed to complete the activity, and the constraints on how the activity should be completed. The activities in a process are usually organized into a directed graph that defines the order of their execution, where nodes and edges in the graph represent activities and control flow, respectively. A workflow process instance represents the state of execution of a workflow process definition by the WfMS, and is usually controlled by the workflow
engine.
A workflow process definition is usually presented in a workflow definition (or
description) language that is used to express the causal or temporal dependencies
among activities in the workflow process. There are several workflow definition languages, including XML (Extensible Markup Language) Process Definition Language (XPDL) [109], Business Process Execution Language (BPEL) [110], and“Yet Another Workflow Language” (YAWL) [111]. A workflow designer traditionally develops a workflow process definition using a graphical workflow editor, which provides an interface for defining and modifying workflows by arranging and
connecting activities. It is possible to view and edit the workflow process definition, which the workflow editor stores in a workflow definition language. For example, the Enhydra JaWE is a graphical workflow editor that implements XPDL specification V2.1 using the Business Process Model and Notation (BPMN) graphical notation [112, 113]; while the BPEL Designer project, a graphical editor, adds comprehensive support to Eclipse for the definition, authoring, editing, deploying, testing, and debugging of BPEL 2.0 [114]. Generally speaking, these graphical workflow editors consider a workflow as a directed graph that illustrates the execution sequence of the activities.
Activities and flow-control constructs15 are represented by the nodes, and transitions are represented by the edges in a directed graph.
Cloud collaboration is an emerging way of sharing and co-authoring documents
through the use of cloud computing, whereby documents or objects are uploaded to central cloud servers, where they can be accessed by others (e.g., Google Docs and Google Calendar [115, 116]). Cloud collaboration technologies allow users to upload and edit documents or objects within the cloud. Businesses are now increasingly switching to the use of cloud collaboration. New advances in cloud computing and collaboration are being prompted by the increasing need for firms to operate in an increasingly globalized world. Collaboration in this context refers to the ability of workers in a company to work together simultaneously on a particular task. With cloud collaboration users do not have to be in the same room or even the same country to effectively work together toward a common goal. In today’s globalized society, having the capability to work together effectively is important to the productivity of an organization, and cloud collaboration tools are ideal for fostering this. In the past, most collaborations involving the production and editing of documents would have to be15 Common flow-control constructs of workflow process include “IF”, “SEQUENCE”, “WHILE”,
“REPEAT UNTIL”, “AND-join”, “OR-join”, “AND-split”, and “OR-split” [117].
completed face to face. However, collaboration has become more complex, now involving working with people all over the world in real time on a variety of different types of documents or objects, and using different devices.
This chapter addresses the issue for defining the workflow process by cloud collaboration, which we show is not possible using a traditional workflow definition language. We propose a new workflow process definition language and framework targeting a collaborative definition of the workflow process. One of the main features of cloud collaboration is that multiple people work together simultaneously on a particular task. Consider the situation that multiple users from one or more organizations are working on defining a workflow process. Referring to Figure 5-1, the traditional way for n users (u0, u1, u2, …,un–1) to define a workflow process collaboratively is for the users to specify their requirements [RQ(u0), RQ(u1), …, RQ(un–1)] about the execution of a workflow process, which contain the proposed activities and the causal or temporal relationships between them in a workflow process.
A workflow administrator then analyzes these requirements and employs a graphic workflow editor to make a workflow definition that will be saved in a specific workflow definition language. Finally, a workflow engine can read the workflow definition to control the execution of this workflow process. Sometimes the requirements [RQ(u0), RQ(u1), …, RQ(un–1)] may conflict with each other. For example, RQ(ui) contains the requirement that activity E can be started only when both activities A and B are finished and RQ(uj) contains the requirement that activity E should be started immediately when either activity C or D is finished. The workflow administrator should report all the conflicts to users after performing the system analysis in order for users to revise their requirements so as to remove these conflicts.
If multiple users revise an existing workflow definition, the workflow administrator
should read the revised requirements and then modify the workflow definition in a graphical workflow editor. Users are generally not allowed to edit an existing definition directly, and especially not edit it concurrently.
Workflow
Figure 5-1. Traditional way to define a workflow process by multiple users In the follows, we use a scenario to demonstrate that the traditional working model is inappropriate if we want to define a workflow process by cloud collaboration.
Assume that there are four persons, Alice, Peter, John, and Bruce, who are chairmen from four communities in different universities. They are going to jointly organize a party for members in their communities. They want to define a workflow process which prepares this party so that they can use a WfMS to coordinate their works.
Because their universities are located in different cities, they try to reduce the cost by defining a workflow process without meeting in the same location. They decide to
Table 5-1. The activities of the workflow
Activities Description
Start Workflow starts End Workflow ends
A1 Estimate the number of participants A2 Book a place and decide the party time
A3 Reserve facilities and food A4 Make Promotional materials A5 Book a rain shelter
A6 Make and deliver propaganda posters A7 Build a home page
A8 Participants make registration A9 Book accessibility equipment A10 Reserve food for vegetarians
Second, Alice, Peter, John, and Bruce need to define the causal or temporal relationships between these activities. To avoid the concurrent revision problem, they decide to use the form tool in Google Docs to collect their workflow requirements [118]. It is a tool to collect information quickly from multiple persons. Each person submits his own forms and the system will collect all the submitted forms and produce a report which is a table. The involved people can read the table which is composed of submitted forms before they submit their own forms. Assume that their submission of forms generates Table 5-2. Note that the submission time of a form and ID of the submitter are also shown in the table. Actually, Alice and Bruce submitted two forms.
Table 5-2. The Workflow Requirements of Alice, Peter, John, and Bruce Timestamp User User Requirements
T1 Alice
A1 should be started after workflow starts.
A1 should be finished before starting A2.
A2 should be finished before starting A4.
A4 should be finished before starting A6 and A8.
T2 Peter
A2 should be started after workflow starts.
A2 should be finished before starting A3.
A3 should be finished before starting A4.
T3 John A8 should be finished before starting A9 A9 should be finished before workflow ends.
T4 Bruce
If the probability of precipitation is bigger than 60%
on the party date, A5 should be started after A2 finished.
A4 should be finished before starting A7 and A8.
T5 Alice A8 should be finished before starting A10.
A10 should be finished before workflow ends.
T6 Bruce A6 and A7 should be finished before workflow ends.
Finally, Alice, Peter, John, and Bruce need to hire a person to analyze the requirements shown in Table 5-2. That person plays a role of the workflow administrator. In the working model shown in Figure 5-1, all editing of the workflow definition should be performed by the workflow administrator. The workflow requirement in a natural language usually has to be analyzed by a human because no tool is available to automatically translate the numerous requirements into a workflow process definition. In this situation, whenever any user updates his or her workflow requirement or supplies a new requirement, the workflow definition cannot be amended automatically. The working model therefore does not fit the working model of cloud collaboration.
One of the solutions that addresses the inadequacy of the workflow model shown in Figure 5-1 is to give each user the privileges necessary to revise the workflow definition in a graphical workflow editor. Without loss of generality, we assume that multiple users are allowed to edit a directed graph simultaneously, because a workflow definition is usually modeled as a directed graph [109, 110, 111]. Consider a simple workflow definition of a workflow process that consists of three activities as shown in Figure 5-2A. In this example, user ui is going to add an activity D after activity A, as shown in Figure 5-2B, and user uj is going to remove activity B, as shown in Figure 5-2C. It is obvious that the final workflow process should be the one shown in Figure 5-2D. Users ui and uj can revise the workflow definition shown in Figure 5-2A concurrently. User ui would employ a graphical workflow editor to perform the following operations: OPi,1—remove edge (A, B), OPi,2—add node D, OPi,3—add edge (A, D), and OPi,4—add edge (D, B); while user uj issues the following operations:
OPj,1—remove edge (A, B), OPj,2—remove edge (B, C), OPj,3—remove node B, and
OPj,4—add edge (A, C). Since the two users are working concurrently, they read the same definition and their operations will interleave. It seems impossible to find a suitable interleaving that would allow their operations to execute properly. For example, if we execute operations in the order (OPj,1, OPj,2, OPj,3, OPj,4, OPi,1, OPi,2, OPi,3, OPi,4), operations OPi,1 and OPi,4 cannot be executed because activity B does not exist after the execution of operations OPj,1, OPj,2, OPj,3, and OPj,4. This kind of
concurrent editing error occurs when multiple users are trying to alter specific data
items simultaneously [119]. It can be prevented by the restriction of allowing only a single user to edit the workflow definition at a time, which can be implemented by a lock mechanism [120]. However, employing a lock mechanism to prevent concurrent editing has two drawbacks: (1) it may result in inefficiency, since a user might lock a workflow definition for editing for too long, resulting in a bottleneck; and (2) there is no mechanism to prevent a user from modifying the requirements of other users.B
Figure 5-2. A sample workflow definition
Workflow
Figure 5-3. Cloud collaboration of the workflow definition
This chapter proposes a working model for cloud collaboration in workflow definition. Referring to Figure 5-3, consider n users (u0, u1, u2, …, un–1) who are
wanting to define a workflow process collaboratively. These users specify their requirements for workflow executions [RQ(u0), RQ(u1), …, RQ(un–1)], and a translator, which could be a computer program, reads these requirements and translates them into a workflow definition that defines an appropriate workflow process. A human is not needed to analyze the workflow requirements, and each user contributes to part of the workflow definition. Whenever a user ui revises his/her own requirement, RQ(ui), the translator updates the workflow definition accordingly. It is possible that multiple users will submit their requirements concurrently, in which case the translator can still generate the revised workflow definition as long as there is no conflict within RQ(u0), RQ(u1), …, and RQ(un–1). In cases where there is a conflict, the translator informs the involved users immediately, who then need to revise their requirements and submit them accordingly. This process is repeated until an agreed workflow definition is finally obtained from multiple users.
We propose a workflow definition language to support collaborative workflow definition in the cloud. Consider n users (u0, u1, u2, …, un–1), where each user ui (0i<n) specifies his/her workflow requirement RQ(ui) distributively. RQ(ui) (0i<n) is part of the definition of a workflow process. A translator can read all the requirements [RQ(u0), RQ(u1), …, RQ(un–1)] to construct a complete workflow process definition. The translator can also determine if there is any conflict between these workflow requirements. Users are allowed to revise their workflow requirement concurrently, but they are not able to modify the requirements of other users. A human does not need to analyze the workflow requirements.
This chapter is organized as follows. Section 5-1 proposes a novel definition language that supports workflow definition by cloud collaboration. Section 5-2 discusses how to deal with the situation when there is conflict among the requirements
of different users. Section 5-3 summarizes the capability for distributed definition and concurrent revision provided by the proposed definition language. Section 5-4 presents an API to support the implementation of the translator shown in Figure 5-3 based on the proposed definition language. Section 5-5 surveys previous work.
5-1.A definition language for collaboration workflow definition
This section presents a workflow definition language that fits the working model of cloud collaboration, which is called the CLWfDL (Cloud Collaboration Workflow Definition Language). As we have mentioned, each user ui (0i<n) specifies his/her workflow requirement RQ(ui) distributively. In the CLWfDL, RQ(ui) consists of a set of rules, where each rule is either (x ⊱{, f(z)} y) or (x ⊰{, f(z)} y), defined as follows:
“x” and “y” are activities in the defined workflow process, which are called theantecedent and consequent activities of , respectively.
“μ” specifies the relationship between “x” and “y”. f(z) is a Boolean predicate,
where “z” represents the set of parameters for evaluating the predicate. f(z) can be absent, in which case the rule is either (x ⊱ y) or (x ⊰ y).
“⊱” and “⊰” are used to specify the type of “μ”, being join and split, respectively.We now describe the abstract meaning of the two different types of rules. First, we consider using the CLWfDL to define the AND-join relationship between multiple activities. Referring to Figure 5-4, the rule (x ⊱AND-join y) means that activity x is one of the activities that enables the AND-join transition to make activity y start (Figure 5-4A), while (x ⊱OR-join y) means that activity x is one of the activities that enables the OR-join transition to make activity y start (Figure 5-4B). Similarly, (x ⊰OR-split y) indicates an OR-split construct (Figure 5-4C). These three types of rules can be associated with a Boolean predicate, as shown in Figure 5-4D, E, and F.
(A) OR-split can comprise rules from different users. For example, consider the situation where the requirements of Alice, John, and Bruce are RQ(Alice) = {…, A10 ⊱AND-join
End, …}, RQ(John) = { …, A9 ⊱AND-join End,…}, and RQ(Bruce) = { …, A6 ⊱AND-join
End, A7 ⊱AND-join End,…}, respectively. This requires the workflow definition to contain the AND-join flow-control construct involving activities A6, A7, A9, A10, and End, as shown in Figure 5-5. This construct means that activities A6, A7, A9, and A10 have finished if and only if End has started. Also, we can employ the AND-join
To show the defining power of CLWfDL rules, we first demonstrate how to use them to define all the flow-control constructs defined in BPEL that contain
<sequence>, <if>, <while>, <repeatUntil>, <flow>, <pick>, sequential <forEach>, and parallel <forEach>. In [121], Appendix A shows illustrative directed graphs and the corresponding CLWfDL rules that implement these constructs. Appendix B discusses how to use CLWfDL rules to define other advanced flow-control constructs.
We now discuss how to make a translator for CLWfDL rules as shown in Figure 5-3. Our idea is to design an algorithm that can translate a set of CLWfDL rules into a directed graph in which nodes are activities and flow-control constructs and edges are transitions. The workflow definitions for existing workflow description languages can then be generated according to the directed graph so that we can employ an existing workflow engine to provide the workflow enactment service (see Figure 5-1 and 5-2).
Consider n users (u0, u1, u2, …,un–1), where each user ui (0i<n) specifies his/her workflow requirement RQ(ui). The workflow enactment service should satisfy RQ(u0), RQ(u1), …, and RQ(un–1). Assume that RQ(ui) consists of a set of CLWfDL rules. A system is needed that controls the execution of the workflow process according to rules in RQ(u0) ⋃ RQ(u1) ⋃ … ⋃ RQ(un–1). We employ the following notations to explain our idea:
Γ is the set of all rules from all users in the workflow definition; that is, Γ = RQ(u0)⋃ RQ(u1) ⋃… ⋃ RQ(un–1).
Φa,μ(Γ) denotes a set of join rules in Γ that have the ⊱ type of “μ” and an identical consequent activity “a”. Thus, we have Φa,μ(Γ) = { | = (x ⊱ a) or = (x ⊱,f(z) a), Γ }.
Ψa,μ(Γ) denotes a set of split rules in Γ that have the ⊰ type of “μ” and an identical antecedent activity “a”. Therefore, we have Ψa,μ(Γ) = { | =
(a ⊰ y) or = (a
⊰,f(z) y), Γ }.
The set of antecedent activities of a set of rules
ℝ, denoted AAS(ℝ), consists of the union of the antecedent activities of rules in ℝ. If the rule has a Boolean predicate, the activity is associated with this predicate. Thus, we have AAS(ℝ) = { x | (x ⊱ a) ℝ } ⋃ { xf(z) | (x ⊱,f(z) a) ℝ } ⋃ { x | (x ⊰ a) ℝ } ⋃ { xf(z) | (x⊰,f(z) a) ℝ }.
The set of consequent activities of a set of rules ℝ, denoted CAS(ℝ), consists of
the union of the consequent activities of rules in ℝ. If the rule has a Boolean predicate, the activity is associated with this predicate. Thus, we have CAS(ℝ) = { y | (a ⊱ y) ℝ } ⋃ { yf(z) | (a ⊱,f(z) y) ℝ } ⋃ { y | (a ⊰ y) ℝ } ⋃ { yf(z) | (a⊰,f(z) y) ℝ }.
For example, if we have Γ1 = { Start ⊱AND-join A1, A1 ⊱AND-join A2, A2 ⊱AND-join A4, A4 ⊰AND-split A6, A4 ⊰AND-split A8, A8 ⊰AND-split A10, A10 ⊱AND-join End, Start ⊱AND-join A2, A2 ⊰AND-split A3, A3 ⊱AND-join A4, A8 ⊰AND-split A9, A9 ⊱AND-join End, A2 ⊰AND-split,f(z) A5, A4 ⊰AND-split A7, A6 ⊱AND-join End, A7 ⊱AND-join End }, then we have (1) ΦA4,AND-join(Γ1)
= { A2 ⊱AND-join A4, A3 ⊱AND-join A4 }, (2) ΨStart,AND-join(Γ1) = { Start ⊱AND-join A1, Start
⊱AND-join A2 }, (3) AAS(Γ1) = { Start, A1, A2, A2f(z), A3, A4, A6, A7, A8, A9, A10 }, (4) AAS(ΦA4,AND-join(Γ1)) = { A2, A3 }, (5) CAS(Γ1) = { A1, A2, A3, A4, A5f(z), A6, A7, A8, A9, A10, End }, and (6) CAS(ΦA4,AND-join(Γ1)) = { A4 }.
Given Γ = RQ(u0) ⋃ RQ(u1) ⋃ … ⋃ RQ(un–1), the workflow enactment service should fit the following requirements according to rules in Γ. An activity derived from AAS() or CAS() might or might not be associated with a Boolean predicate. We define an activity that is not associated with a Boolean function as being finished if its execution is finished, while an activity that is associated with a Boolean predicate (e.g., Bf(z)) is finished when its execution is finished and the associated Boolean predicate is True. Similarly, an activity that is associated with a Boolean predicate f(z) can be
started only if f(z) is True. We define that a set
ℝ of rules is satisfied, denoted Satisfy(ℝ), if the predicates P1 and P2 are True. Assume that is the set of all
activities that are referred in ℝ, then P1: A in and in ℝ, the execution of A and activities in AAS(Φ
A,(ℝ)) should be controlled according to . P2: A in and in
ℝ, the execution of A and activities in CAS(ΨA,(ℝ)) should be controlled according to .For example, if
is an AND-join construct, then all activities in
AAS(ΦA,AND-join(ℝ)) are finished if and only if A has started; if is an OR-join
construct, then one of the activities in AAS(ΦA,OR-join(ℝ)) is finished if and only if A has started; and if is an OR-split construct, then A is finished if and only if one of the activities in CAS(ΨA,OR-split(ℝ)) has started. Note that we assume that there is no conflict between rules—in section 5-2 we discuss how to deal with such conflicts.Predicates P1 and P2 define the causal or temporal relationship between activities from a set of rules. The fulfillment of Satisfy(Γ) obeys the causal or temporal relationship between activities defined by all the users. Algorithm 5-1 shows how to generate a directed graph from a set of CLWfDL rules, Γ. Actually, steps (4) and (5) ensure that the generated directed graph satisfy predicates P1 and P2, respectively. The generated directed graph G represents a workflow definition that fulfills Satisfy(Γ).
Algorithm 5-1: Generate a directed graph from a set of CLWfDL rules.
Input: A set of CLWfDL rules, Γ.
Output: A directed graph, G.
GenerateDG(Γ)
(1) Construct a directed graph G = (V, E) with no node (V = 16) or edge (E = ).
(2) Let be the set of all activities involved in Γ.
(3) For each activity in , create an activity node that is named by the ID of the activity, and add this node to V.
(4) FOR EACH activity in and in Γ // To satisfy predicate P1
IF Φ,(Γ) ≠ THEN
16 “” is the empty set.
Add a node named "_" to V.
Add edge (_, ) to E.
FOR EACH activity in AAS(Φ,(Γ))
IF is associated with a Boolean predicate f(z)
IF there is not a node "IF_fz" in V
Add an IF-ELSE node named "IF_fz" to V.s
Add edge (, IF_fz) to E.
Add edge (IF_fz, _) to E.
ELSE IF is not associated with a Boolean predicate f(z)
Add edge (, _) to E.
IF is associated with a Boolean predicate f(z)
IF there is not a node "IF_fz" in V
Add an IF-ELSE node named "IF_fz" to V.
Add an IF-ELSE node named "IF_fz" to V.