Protecting the consistency of workflow applications in collaborative development environments

Future Generation Computer Systems 28 (2012) 500–512

Contents lists available at SciVerse ScienceDirect

Future Generation Computer Systems

journal homepage: www.elsevier.com/locate/fgcs

Protecting the consistency of workflow applications in collaborativedevelopment environmentsGergely SiposMTA SZTAKI, Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems, H-1518, Budapest, P.O. Box 63, Hungary

a r t i c l e i n f o

Article history:Received 16 December 2010Received in revised form12 September 2011Accepted 17 September 2011Available online 1 October 2011

Keywords:WorkflowCollaborationReal-timeGroupwareLockingCSCW

a b s t r a c t

Collaborative development environments allow a group of users to view and edit a shared item fromgeographically dispersed sites. Consistency maintenance in the face of concurrent accesses to sharedentities is one of the core issues in the design of these systems. The paper introduces a lock based solutionand three different algorithms that enable controlled, concurrent access to workflows for multipleapplication developers. Collaborative development of workflow applications promises better outcomein shorter time. The described method ensures that collaborators cannot break the consistency criteria ofworkflows by adding cycles or invalid edges to the graphs. A formal analysis of the three graph lockingalgorithms is also provided, focusing on the number of users who are allowed to edit a single workflowsimultaneously. Based on the findings, a more powerful fourth graph locking algorithm is defined.

© 2011 Elsevier B.V. All rights reserved.

1. Introduction

During the ’90s, driven by the wider availability of desk-top computers and standardised software services, businessprocesses started to be defined and controlled by software appli-cations. At around the same time the term ‘‘workflow’’ emergedfor computer automated and enabled process control and man-agement. A workflow in this context is a directed graph that de-fines the integration of distributed applications and resources inorder to manage their execution on distributed infrastructures [1].Since then the popularity of workflows and workflow systems iscontinuously increasing and resulted in a large number of work-flow solutions for various different application domains [2–4].Distributedworkflows are enabled by integration technologies andinfrastructures such as Web Services, grids and clouds. Many ofthe workflow applications can be built by a single person. At thesame time involved workflows – with large number of compo-nents, complex dependences among components, or complex ex-ecution infrastructures – require collaborative work frommultiplepersons, members of a developer team.

In 2005 our research group coined the term ‘‘collaborativegrid workflow’’ to describe workflow applications defined andexecuted on distributed infrastructures by a group of usersthrough a collaborative groupware environment [5]. Since then theterm was generalised and collaborative workflows became usefulenablers of inter-disciplinary research [6], urban planning [7], genesequence analysis [8], engineering [9] and other scientific areas

E-mail address: [email protected].

0167-739X/$ – see front matter© 2011 Elsevier B.V. All rights reserved.doi:10.1016/j.future.2011.09.003

where intangible knowledge and tangible resources and servicesfrom multiple organisations and individuals must be integrated.

Recent related works studied the concurrent access to col-laborative workflows during the development phase [8,10], butdid not deal with inconsistency, a typical issue in collaborativeediting, with rich literature within the Computer Supported Col-laborative Work (CSCW) domain. Protecting the consistency ofcollaboratively editedworkflows is highly important, because con-sistency can ensure the correctness of the integrated componentswithin the graph and the correct execution of the workflow on thedistributed infrastructure.

Our first paper on this topic introduced lock based concurrencycontrol mechanism to enable the simultaneous editing of differentparts of a single workflow by multiple developers [5]. Ourlater works presented [11,12] an extension of this lock basedmechanism to protect the following three workflow consistencycriteria: (1) workflows must remain acyclic; (2) edges in theworkflowmust point to existing vertices; (3) atmost one incomingedge can be connected to an input channel of a vertex (maximumone edge can provide data for an input channel of a service/job).These recent papers introduced three graph locking algorithms.Each of these algorithms can guarantee graph consistency. It hasbeen proven about the algorithms that they allocate sub-graphsfrom a workflow to the concurrent developers in such a way, thatno modification performed on these sub-graphs can break theconsistency of the complete graph. Moreover, it has been alsoshown that the algorithms guarantee graph consistency withoutdropping any of the users’ changes, or forcing them to compensatetheir already committed modifications.

http://dx.doi.org/10.1016/j.future.2011.09.003

http://www.elsevier.com/locate/fgcs

http://www.elsevier.com/locate/fgcs

mailto:[email protected]

http://dx.doi.org/10.1016/j.future.2011.09.003

G. Sipos / Future Generation Computer Systems 28 (2012) 500–512 501

In the current paper, the three graph locking algorithms arerevisited, then a formal approach to evaluate their performanceis described. The evaluation uses ‘‘the number of users who areallowed to share and edit a single graph simultaneously’’ as a metricto compare locking algorithms. The higher this number, the better,because thismeans thatmoreworkflowdevelopers can collaboratewithout breaking the consistency rules. Based on the findings afourth, integrated algorithm is defined. The contribution of thepaper to the parallel computing field is a lock based solutionand associated algorithms to partition workflow graphs amongmultiple parties. The contribution to the CSCW domain is a novelmethod to evaluate and compare the performance of lockingprotocols used within collaborative environments.

In the next section, an overview of the related works isgiven. In Section 3, the concept of collaborative workflow editorsbuild on replicated, lock based architecture is described. Theproblems related to consistency maintenance of workflows insuch an architecture are discussed in Section 4. In Section 5,three algorithms are introduced. These algorithms – to be calledlock evaluator algorithms – can be integrated into any workflowdeveloper environment in order to protect the consistency ofshared graphs during editing. In Section 6, the collaborativeperformance of graph locking algorithms is studied from the users’perspective and a comparative analysis of the three algorithmsis given. The analysis reveals the shortcomings of the algorithmsand a fourth algorithm is defined to overcome these. This fourthalgorithm allows even more users to share a graph withoutjeopardising its consistency. In Section 7, additional propertiesof the presented solutions are discussed, such as deadlock andstarvation, and an overview of the P-GRADE Portal based prototypeimplementation of the concepts is given. Summary, conclusionsand future works are described in Section 8.

2. Related works

Real-time collaboration of people through shared, editableentities is an intensively researched topic within the CSCWdomain [13]. Most of the related efforts focused on enabling con-current editing of items that are either unstructured (such as adrawing) or have hierarchical structure (such as a document). Un-structured itemsdonot have consistency requirements (no one candefine when a freeform drawing is good or bad) and do not re-quire consistencymaintenance frameworks. Although consistencymaintenance of hierarchical structures is well understood [14,15],directed acyclic graphs cannot be mapped to hierarchical graphsand that is why they require different consistency maintenancesolutions.

The application of collaborative working practices to dis-tributed applications is a less researched field. Although there area few distributed computing environments that support the col-laboration of users, these systems are often tightly coupled withone particular application—so users do not have flexibility onwhatinformation or application they would like to share and edit to-gether (e.g. [16,17]). In other cases they do not support real-timecollaboration. For example, MyExperiment.org is a Web 2 stylecommunity site where workflow developers can publish, discoverand download workflows [18], but the site does not include anysupport for the concurrent editing of workflows. Because the My-Experiment portal does not know the structure of the sharedworkflows, possible inconsistencies in the structures cannot berecognised.

Some recent efforts in workflow research have focused on theknowledge sharing aspects of collaborative workflows in multi-organisational environments. While these works provide detailedanalysis on the users’ awareness and propose system architecturalcomponents, they rarely discuss concurrency control mechanisms

and implementations [6,7]. There are a few exceptions though.Lock based concurrency control frameworks are given in [5,19,20].Unfortunately, none of these solutions protect the consistencyof workflow graphs. If some of the concurrent editing scenariosresults inconsistent applications then these workflows cannot beexecuted. The HOBBES environment uses locks for concurrencycontrol in collaborative workflow development [19]. At thesame time HOBBES does not guarantee the consistency ofshared workflows, the owner of the graph must compensate thecollaborators’ work in case the team results an inconsistent orinefficient graph structure.

Version Control Systems (VCS) such as CVS, SVN, Git, Mercurialare the most widely used tools to facilitate the concurrentengineering of software. However these environments havelimitations when used for the collaborative development ofworkflows because [14] (i) workflows are typically stored in asingle file (workflow description file) meanwhile most of the VCSsupport collaboration on file sets, and (ii) those VCS that work atthe level of individual files can interpret text document and cannotresolve conflicts that happen at a higher abstraction level (in ourcase at the level of graph vertices or edges).

The challenges involved in themaintenance of consistency con-straints on collaboratively edited items are recognised and dis-cussed in various contexts, such as Visio diagrams [21], whiteboardgraphics [22] and drawings [23,24]. These works consider the con-sistency constraints as part of the shared, collaboratively editeditems. Some of these constraints are represented with acyclic, di-rected graphs, and the acyclic property must be maintained dur-ing the shared editing of these components [21]. This requirementis common with our area of interest. However, while in our casean edge of a workflow graph is defined by various, manually setparameters, edges in the requirement graphs are simply links be-tween two objects within a drawing. For such simple links the re-moval of problematic edges (edges that cause cycle) do not causea huge loss of work to the users, the edges can be easily redone. Inour case, the removal of edges from a workflow graph can causesignificant loss to the developers and should be avoided. This is aunique requirement for our framework; therefore, our research isfocused on solutions that can recognise dangerous situations dur-ing the shared development of graphs, and can protect the usersfrom investing any effort into the creation of edges that would beremoved from the graph at a later stage.

Collaborative editor environments are typically analysed usingreal or artificial user scenarios [25]. At the same time, these meth-ods are also criticised, mainly because the whole spectrum of pos-sible use cases cannot be covered in this way [26]. The systemevaluation part of this paper (Section 6 and onward) focuses on oneimportant aspect of usability: on the number of developers whoare allowed to share a graph through a collaborative environment.Because of the well defined focus, we can perform a purely theo-retical analysis withoutmissing any possible scenario. Baeza-Yatesand Pino analyse collaborative systems in a similar fashion [27].However, their work is focused on the quality of shared entities,not on the number of users. They describe the quality of the col-laboratively edited object as a function of group size.

3. Collaborative editing of workflow graphs

To establish the formal specification of our collaborativeworkflow editing study, let us give a formal definition for aworkflow first. The definition used in the paper is widely acceptedin the literature [2,3].

• Workflow: a directed graph that contains vertices (V ) and edges(E) : G = (V , E).

502 G. Sipos / Future Generation Computer Systems 28 (2012) 500–512

• A vertex (V = {A, B, C, . . .}) represents an activity, e.g. a job,activity or a service to run. A vertex transforms input datato output data. A vertex can be described with n parameters,such as location of the executable or URL of the service;input parameters; environment variables; input files; etc. Thenumber and the types of parameters depend on the particularworkflow implementation.

• An edge is a directed edge from one vertex to another vertex.It can represent data and/or control dependency between jobs,activities or services. A directed edge from an A vertex to a Bvertex is denoted as ab. An edge is describedwithm parametersthat specify e.g. data transfer protocol of the link, physicalroute for the transfer, etc. While the number and the type ofparameters are implementation details, at least two parametersare necessary to identify end points of the edge: one sourcevertex and one sink vertex.1

In a real-time, collaborative workflow development scenariomultiple users require simultaneous access to a single graph. Real-time, collaborative workflow development environments mustensure that the developers’ contributions are integrated into asingle, coherent graph without loss of data or producing an invalidfinal state. This is a typical requirement in any collaborativedevelopment environment (groupware environment) that sharesentities which have consistency criteria.

Workflow development is a labour intensive activity. Changesin a workflow are results of time consuming, and sometimeshardly reproducible human actions. This is especially true whenthe vertices and edges are described with many parameters, orwhen theworkflowdevelopment involves the development of newsoftware services that are integrated as vertices into the graph. If adeveloperA’s changesmade to aworkflow is lost, or droppeddue tothe concurrent changes of a B user, then this would result wasted,sometimes irreproducible effort for A. An important requirementfor real-time, collaborative, workflow developer environments isthat none of the users’ development sessions should be abortedbecause of the concurrent work [11,12]. The groupware systemin use must recognise when a collaborative workflow editingsession converges towards an inconsistent workflow and mustoffer the possibility for users to safely close the session before theinconsistent state is reached, before any data is lost or dropped.

Groupware environments use turn-taking, serialisation (oftenextended with operation transformation) or locking techniques todeal with issues related to concurrency-control [15]. [5,10] arguethat lock based concurrency control satisfies most of the needs oftypical workflow developers and collaborative groups. Exclusivelocking of vertices and edges ensure that concurrent changesperformed by the developers on theworkflow affect different partsof the graph, thus overwriting each other’s changes is impossible.If the locks are used with the granularity of graph components,i.e. vertices and edges are independently lockable units, and if usersare allowed to lock multiple edges and/or multiple vertices at atime, then workflow developers can flexibly define the focus oftheirworkwithout blocking each other too frequently.Meanwhile,a sub-graph (a set of edges and vertices) is locked for a certain user,no other person is able to modify these components but can lockother, currently unlocked components from the graph.

Real-time groupware environments typically use a replicatedarchitecture to provide high responsiveness for local user interac-tions [28]. In the replicated architecture, each of the collaborators’machines have a local copy of the shared entity. Such a copy can

1 In practice, edges are connected to input/output channels (also called ports) ofvertices. This is the case for example in P-GRADE Portal, Kepler, Taverna or Triana.Because the connections to channels can be describedwith additional parameters ofthe edges (one parameter to identify the vertex, and another parameter to identifythe channel within the vertex), the described model covers this aspect.

Fig. 1. Real-time groupware environment for the collaborative editing ofworkflows. The system uses replicated architecture and lock-based concurrencycontrol mechanism.

be managed directly by the local user and indirectly – with mes-sages sent via the network – by the other users. The remote users’modification messages are received through the network and areexecuted on the local copy.

If a replicated architecture uses locks to control access to differ-ent parts of the shared entity, then there must be a component tomanage the locks. This component – from now on called the lockmanager – can be filled with a single architectural element or canbe distributed and shared among multiple elements [29]. The re-sponsibility of the lockmanager is to accept lock requests from col-laborating parties, to evaluate the requests based on some lockingpolicies and to grant or deny the requested locks.

Because the focus of our research is to define lock policies forthe lock manager of real-time, collaborative workflow developerenvironments, we assume that the manager is a central, pre-defined machine in the network and the collaborating parties donot need any sophisticated discovery mechanism to identify it.This architecture is presented in Fig. 1. The ways in which lockingpolicies could be implemented in a distributed manager is outsidethe scope of the paper.

The lock manager consists of different parts: (1) a server thataccepts the locking and unlocking requests over the network,(2) a lock evaluator algorithm that implements the locking policiesand decides about lock requests and (3) a workflow storage wherethe permanent versions of the shared workflows are stored. Thefocus of the paper is on the lock evaluator algorithm, particularly onthe locking policies that such algorithms must implement in orderto guarantee the consistency of the shared graphs without causingany loss of data for the collaborating parties. Within the domain ofdatabase systems this would be equal to a DBMS that guaranteesdatabase integrity without any transaction abort.

A lock evaluator algorithm can be modelled with a function(see formula below) that has a workflow graph (G) and an orderedset of lock request (RS

= R1, R2, . . . , Rn) as its input, and returnsa partitioning of the graph as output (G1,G2, . . . ,Gn denotelocked partitions, GU denotes an unlocked partition). Workflowdevelopers join collaborative development sessions independentlyfrom each other: any user can join or leave a session any time.Joining a sessionmeans that the user generates a locking request inhis/her editor,which is then submitted to the central lockmanager.The request includes those vertices and edges that the developerwould like to modify (extend, change or delete) and thus wants toaccess exclusively. In the modelling function, the manager servercollects the requests that belong to the same collaborative session(i.e. target the same graph at the same time), creates an orderedset based on the time of arrival, then feeds the set into the lockevaluator algorithm. In reality, the manager server feeds each ofthe requests into the evaluator algorithm separately from eachother, without waiting for all the requests to arrive (it cannot be


known howmany users will be involved in a session). Our focus ison the algorithm that decides about the locks and it can be betterstudied in this way.

The lock evaluator algorithm has to evaluate the requests andmust determine the sub-graphs that should be locked for eachof the requestors. Such a sub-graph should obviously containthose graph components that the specific user requested to lock(i.e. the vertices and edges that are in his/her lock request). Itwill be shown in the next sections that this is not always enoughand additional components also have to be locked. If any of therequested components cannot be locked then the requestor mustbe informed about lock denial. In such cases the requester canmodify the request or submit it again at a later time. The wayhow this could be done or how resubmission of the requests couldbe better automated is outside the focus of this paper. Obtaininga lock on a component before the component can be edited iscompulsory.

G, RS→ Lock evaluator algorithm→ G = G1 ∪ G2 ∪ · · · ∪ Gn ∪ GU .

In the formula, Gi denotes the sub-graph that becomes lockedfor the submitter of the Ri lock request. GU is the sub-graph thatremains unlocked even after all the n users’ requests are satisfiedand the users started the concurrent editing of the graph. Notethat each of the sub-graphs contains some vertices and some edgesfromG, but aGi sub-graph is not necessarily connected. If e.g. a userintends tomodify the first and the last vertices of a pipe-line graph,then his/her locked sub-graphmay contain only these two vertices,so the sub-graph is disconnected. Because of using exclusive locksGi ∩Gj = ∅, ∀i, j, 1 ≤ i, j ≤ n, i = j and Gi ∩GU

= ∅, ∀1 ≤ i ≤ n.After a sub-graph is successfully locked, the owner is the only

person who can make updates on these components. His/hermodifications can be propagated in real-time to other users eitherindirectly (e.g. through the lock manager), or directly in a peer-to-peer fashion. Once the user finished editing the graph he/she savesthe changes, propagating the final state of the modified sub-graphto all the other collaborators, but most importantly to the centralworkflow storage, so the permanent image can be updated.

4. Consistency of workflow graphs

Collaborative workflow editors must ensure that editing ses-sions bring graphs from one consistent state to another con-sistent state. Consistency of a workflow can be defined at twolevels: (1) component-level consistency: consistency of individualvertices, and individual edges; (2) graph-level consistency: consis-tency ofmultiple, connected components, or even thewhole graph.

Component-level consistency defines the valid parametercombinations of a given workflow vertex or edge (i.e. whatthe valid parameter combinations are to describe a service ora channel in the workflow). Component-level consistency isplatform specific. Each workflow language and system has itsown data structure with consistency rules, even though some ofthem show similarities. Because in our model none of the edgesand vertices can be split among multiple users, every parameterof a component is controlled by the same editor and thereforethe maintenance of component-level consistencies does not differfrom the single-user case.

Our research focuses on the graph-level consistency rulesbecause in a multi-user editing scenario no party has thecomplete view of the whole workflow and maintaining graph-level consistency is not self-evident.We identified three graph-levelconsistency criteria for workflow graphs.1. There can be no dangling edge in the graph, i.e. an edge that

refers to nonexistent (already deleted) vertex as its sourceand/or sink. Dangling edges would stuck the execution of theworkflow.

2. Maximum one input edge can be connected to any inputchannel of a vertex. Ifmultiple input edgeswere connected to thesame input channel, then the execution of the workflow wouldbe unpredictable, data sent through these edgeswould competeor overwrite each other. (This criterion still allows a vertex tohave more than one input channels, each served by a differentinput edge.)

3. The graph must be acyclic. While there are several workflowmanagers that can handle cyclic graphs, we restrict our scope toacyclic graphs. Our primary interest is extending the P-GRADEPortal, an editor of acyclic graphs towards a collaborativedeveloper environment.

These consistency rules are critical in those workflow lan-guages, environments and managers that do not support cyclesand/or cannot handle broken and multiple connections betweenvertices. Several workflow tools require these criteria, for exam-ple GriPhyn (Pegasus), Taverna (SCUFL), Grid Service Flow Lan-guage, Condor DAGMan, Workflow Enactment Engine, P-GRADEPortal just to name a few.Moreover, the approach is also applicablein other domains where collaboratively edited entities are repre-sented as acyclic graphs, e.g. in mind mapping tools or automatedproduct design processes [30].

In a collaborative editing scenario that is described in Section 3,no party has the complete view of the workflow at any pointin time. Even if all the collaborators share their changes witheach other in real-time, network delays prohibit instant updates.The problems related to the synchronisation of different views ingroupware environments are well understood [15]. Maintainingconsistency of shared entities in this setting is not self-evident.The rest of the paper introduces a method that can prevent graph-level inconsistencies to appear in shared workflows. The approachuses intelligent lock evaluator algorithms to generate partitioningof acyclic graphs. Within the generated partitions none of thethree graph-level consistency rules can be broken by any party.No matter which vertices or edges are added, changed or deletedinside any of the locked sub-graphs, the new versions of the sub-graphs can be integrated into the complete graphwithout breakingany of the three graph-level consistency criteria and withoutdropping or compensating anybody’s changes.

4.1. Preventing dangling edges and multiple incoming edges

Adangling edge appears in the graphwhen a user deletes a nodewithout the removal of the connected edges.2 Multiple incomingedges come into existence when concurrent users connect inputedges to the same input channel of a vertex. A lock evaluatoralgorithm used in a collaborative workflow environment canprotect against dangling edges and multiple incoming edges if itimplements the following protocol (see also Fig. 2).

1. An edge can be locked for a user only if both of its end verticescan be locked for the sameuser. This ensures that aGi sub-graphis always enclosed by nodes.

2. The user side editors can check for dangling and multipleincoming edges within their own locked sub-graphs. (In thesame way as single-user workflow editors do.)

3. Only the owner of a locked vertex can connect edges to thatvertex. This rule implicitly declares that no vertex can be sharedbetweenmultiple users, locks are not used at a finer granularity.

4. When the user saves the his/her changed, locked sub-graph,then the complete graph residing in the central workflow

2 The other way to create a dangling edge would be to define a new edge withouta valid source or sink. We assume that the workflow editor environment does notallow such operations and edges can be defined only between existing vertices.


Fig. 2. Graph partitioning protocol that prevents dangling edges and multipleincoming edges.

Fig. 3. Example: two editors break the acyclic consistency of the graph.

storagemust be updatedwith the sub-graph from the user side.If the user deleted a vertex that was connected to other sub-graphs, then these connected edges must be set to invalid (ormust be deleted) as part of the update. (If for example vertexA is deleted from Fig. 2, then the server must set the ab edgeinvalid.)

Because of step 1 edges that connect two locked sub-graphstogether remain unlocked and are not involved in the activedevelopment session. However, they are results of manual workthat has been performed in the previous development sessions,so their permanent deletion from the graph (in step 4) would stillcause wasted work to the group. The server therefore should notpermanently delete these edges from the graph, it should only flagthem as ‘‘invalid’’ for the current graph configuration. The invalidedges can be ignored during workflow execution, but allow theusers to re-validate them if they wish. This re-validation obviouslyrequires the addition of new vertices to the workflow, otherwisethe edges would become dangling edges. In the current paper, weassume that edges that are set to invalid by the server are ignoredby the users and are not involved in the rest of the workflowdevelopment.

This protocol guarantees that workflow developers can removeany vertex from the graph without resulting dangling edges,multiple incoming edges and aborted changes to others. If anedge is removed from within a sub-graph then its source and sinkvertices can be removed by the client side editor in the same wayas it happens in a single-user environment. Because of point 3, theedges that connect sub-graphs together are removed by the server.Because not more than one user can connect new edges to anygiven vertex at a time, connecting multiple incoming edges to avertex is impossible.

4.2. Preventing cycles

Collaborative workflow editors can recognise and eliminatecycles within their own sub-graphs, however none of the editorsor even the lock manager knows the current state of the wholeworkflow. In extreme cases it can happen that nonetheless no cycleexists in any of the locked sub-graphs, a cycle exists in the wholeworkflow. Such a situation is shown in Fig. 3, where two developerswork on their locked sub-graphs and without creating cycle in anyof the sub-graphs they create a cycle in the complete graph.

To resolve this issue one could introduce a central componentto the collaborative architecture to validate every graph update

operation and accept only edges that do not create cycle in thegraph. However, it is obvious that the central component wouldslow down client side editors and would cause annoying delays.Without a central component the solution will be the following.1. Abort one of the transactions that added an edge to the cycle.

This would result wasted effort for the developer and must beavoided—as it has been stated before.

2. Use an intelligent lock evaluator algorithm that partitionsworkflows in such away that no edge creation operationwithinthe sub-graphs can result cycle in the complete graph. Thenext subsections introduce three different algorithms with thisfeature (called A1, A2, A3 algorithms).

5. Consistency aware lock evaluator algorithms

Three different lock evaluation algorithms, called A1, A2 andA3 are introduced in this section. The algorithms implement theprotocol of Section 4.1 – thus they prevent dangling and multipleincoming edges – but each of them uses a different approach toprovide protection against cycles.

As earlier, Gi denotes the sub-graph that gets locked for useriand GU denotes the remaining part of the G graph (GU

= G \ Gi).GU contains those elements from G that are still available for otherusers to lock. The aim is to define an algorithm that implements theprotocol from Section 4.1 and results Gi and GU partitions in suchway, that none of the possible changes/extensions of Gi and GU canintroduce cycle in G.

5.1. Locking complete branches: A1 algorithm

The first algorithm extends the users’ lock requests to fullbranches of the graph and tries to lock these extended sub-graphs.Such an extended sub-graph is closed for its children, i.e. it containsevery vertex and every edge that can be reached within the graphfollowing directed edges. The formal description of this algorithm(A1 algorithm) is given later in this paper.

The algorithm generates and returns a Gi sub-graph that hasbeen created from the components of the Ri lock request and theirchildren. The result Gi and GU

= G \ Gi sub-graphs represent aspecial partitioning of G in which every vertex and every edge ofG is either in GU or Gi, but none of them is in both. Moreover,a consequence of step 3 is that Gi is enclosed by vertices, so theprotocol from Section 4.1 is implemented.

For a simple example on how A1 can be used to lock sub-graphsfrom a shared graph, please see the second column of Fig. 8. Thegraph consists of two vertices (A, B) and one edge (ab). The firstuser requests the A vertex to lock (R1 = {A}). Because A1 allocatescomplete branches, the R1 set is extendedwith B and ab. Thewholegraph becomes locked for the first user. When the second userrequests the B vertex for locking (R2 = {B}) this vertex is alreadylocked so the second user has to delay the development until thefirst user completes his/her work and unlocks the graph.

Theorem (Correctness of the A1 Algorithm). The A1 algorithm yieldsa partitioning of G such that, if none of the editing users is allowedto create cycles within his/her own sub-graph, then cycles cannot becreated in the whole graph.

Proof. The proof shows that if a cycle is created in G, then everyelement of the cycle (every vertex and edge) must belong tothe same sub-graph, or in other words no cycle can span acrossmultiple sub-graphs. Because cycle within a single sub-graph iseliminated by the editor environment that owns the sub-graph,such local cycles are removed and cannot become part of thecomplete graph.

As it is shown in Fig. 4, the Gi sub-graph is locked for user i.Assume, that user i adds a new edge ba to Gi and this edge resultsa cycle in G. In this case:


A1 algorithm:Input: Ri—The lock request of user i (List of objects from the

shared G = (V , E) = G1 + G2 + · · · + Gn + GU graph that useri wants to write)

Output: The Gi sub-graph that needs to be locked for user i. If Giis empty, then the lock request must be denied.

(1) Gi = Ri//Temporary variables. A component can be either an edge or

a vertex:(2) edge e; vertex N; component c;(3) For (every edge of Gi) {

(a) e = current edge of Gi(b) add e.source to Gi(c) add e.sink to Gi

}(4) For (every vertex of Gi) {

(a) N = current vertex of Gi(b) For (every component of G) {

(i) c = current component of G(ii) if (pathExists (N, c)==TRUE) then add c to Gi

}}

//Check lock compatibility, in case of incompatibility empty Gi:(5) For (every component of Gi) {

(a) c = current component of Gi(b) If (c.isLocked ()==TRUE) then {

(i) Gi = {}(ii) Exit loop

}}

(6) Return Gi

Fig. 4. The creation of the ba edge results cycle in G.

• Because useri is able to create a new edge between the B and Avertices, A, B ∈ Gi. At this point, we exploit the protocol fromSection 4.1: a user can own an edge only if it owns both ends ofthe edge.

• Because ba ∪ G results a cycle, there must be a directed routefrom A to B. The route is denoted as [A, B].

• [A, B] must have been created in one of the following ways.1. [A, B] existed before Gi got locked. In this case, [A, B] ∈ Gi

because Gi was defined by the A1 algorithm thus it is closed(see step 4.b of A1). Consequently, every element of the cycleis within the Gi sub-graph.

2. [A, B] was created by useri. In this case, [A, B] ∈ Gi becauseany new element added to a sub-graph becomes automati-cally locked for the creator. Consequently, every element ofthe cycle is within the Gi sub-graph.

Because in either cases a cycle can be created only within asingle sub-graph and such cycles are eliminated by the editors ofthe sub-graphs, concurrent transactions cannot create cycle in thegraph. �

Any workflow editor groupware that implements the A1 lockevaluator algorithm protects shared workflows against danglingedges, multiple incoming edges or cycles. However, this has a cost.Because the algorithm extends the users’ requests with additionalcomponents, many of the collaborators lock bigger segments of thegraphs then he/she wants to. Meanwhile, this does not harm theuser’s intention (he/she gets the components but may also get afew extra components that do not have to be used), there are lesscomponents left for others to lock. This effect reaches itsmaximumwhen the sharedworkflow contains only a few branches andwhenthe locking request of an early arrival involves components thatare close to the root of the graph. (Such as in the example inFig. 8.) In such situations, the algorithm extends the sub-graphsignificantly. The next two subsections introduce two other lockevaluator algorithms to overcome this problem.

5.2. Predicting cycles with system locks: A2 algorithm

Assume that a sub-graph GB needs to be locked for userB butsome part of the sub-graph is already locked for userA. In this case,the A1 algorithm indicates lock collision and does not allow userBto lock (see step 5 of the A1 algorithm). UserB must wait for userAto finish editing the graph. The A1 algorithm reports lock collision ineven those situations when two users’ work actually targets differentparts of the workflow, but they need to lock overlapping sub-graphsbecause of the extension of their locking sets. The A2 algorithm usestwo types of locks to distinguish components by the reason theybecame locked for: because they were in the locking requests(i.e. the owner reallywants tomodify them), or because the systemadded them to the locked sub-graph to guarantee consistency(i.e. the owner does not want to modify them). For the firsttype of components, the A2 algorithm applies ‘‘user lock’’, whilethe second type of components are marked with ‘‘system lock’’.Properties of these locks are the following.User lock3

• Used for components that are locked for a user because the usermarked these components as subject of his/her editing work.

• Exclusive lock: only the owner of a user locked component canedit the component (modify, delete, and extend).

• A newly added workflow component becomes locked for itscreator with user lock.

• When a new edge is added to the graph then its source andsink verticesmust become locked for the creator with user lock.A new edge can be created between two vertices only if thevertices can be locked for the creator with user lock. (Otherwisethe vertices could be later locked and deleted by another user,leaving a dangling edge behind.)

System lock4

• Used for components that must be locked by the system for theuser to guarantee graph consistency.

• System locks are not visible for users.• System locks do not have to be stored on the graph. They are

needed only when a new lock request must be evaluated; thusall the system locks can be generated ‘‘just-in-time’’.

Given a user A, who owns some components from a graph anda user B, who requests some components from the graph. Assumethat B’s request causes lock collision in the system. It can happenbecause of the following reasons.

3 Sub-graphs that are lockedwith user lock for a user A, B or C will be representedas GA,GB,GC in figures.4 Sub-graphs that are locked with system lock for a user A, B or C will be

represented as SA, SB, SC in figures.


Fig. 5. Possibility of creating a cycle if both 1.b and 2.a lock collisions would beallowed by the A2 algorithm.

Fig. 6. Two lock collision situations on a single graph.

1. The colliding components are in A’s sub-graph because he/shemarked them in his/her editor for editing, so A has userlock on these components. Two further subcategories can bedistinguished in this case.a. The components need to be locked for B because he/she

marked them in his/her editor for editing, so B needs user lockon these components. In this case, B’s locking request mustbe denied because A and B would like to modify the samecomponents and their contributions could result lost updatesor aborted transaction.

b. The colliding components are in B’s locking set because thesystem wants to lock them to guarantee graph consistency.In this case, B requires system lock on the components. If wedeny the lock for B then we result consistent graph, howeverwe are too restrictive. The lock can be granted, but only if wedeny the locking in case of a 2.a collision situation (see 2.a casebelow). If locking would be allowed in both the 1.b and 2.acollision situations, then A’s and B’s concurrent changes canadd cycle to the graph. Such a situation is presented in Fig. 5.As the figure shows, if locking is allowed in both the 1.b andthe 2.a situations, then an inconsistent (cyclic) graph couldbe created by the concurrent users without creating a cyclewithin any of the sub-graphs. The optimal solution is to allowlocking in either 1.b or 2.a cases, but only in one of them. Afterthe analysis of the remaining collision situations a proof ofthis statement is given.

2. The colliding components are in A’s sub-graph becausethe system added them there. Consequently, A has systemlock on these components. Two further subcategories can bedistinguished in this case.a. The components need to be locked for B because he/she

requested them for locking, so B also needs user lock on thesecomponents. If locking is allowed in this case then it must bedenied in case 1.b. If locking is denied in this case, then it canbe allowed in case 1.b.

b. The components become part of B’s locking set becausethe system wants to lock them to protect the consistencyof the graph. Consequently, B requires system lock on thecomponents. The lock can be granted in this case becauseneither A nor Bwants to actually modify the components.

The following lock compatibility table summarises the aboveidentified four cases (‘‘!’’ marks the negation operation):

Existing lockUser lock System lock

Newlyrequested lock

User lock Case 1.a:No

Case 2.a:!1.b

System lock Case 1.b:!2.a

Case 2.b:Yes

Theorem (Correctness of the A2 Algorithm). With the above definedlock types and compatibility table the A2 algorithm results such apartitioning of G that, if none of the editing users is allowed to createcycles within their own sub-graphs, then cycles cannot be created inthe whole graph.

Proof. It is evident that no cycle can be created if the 1.a or the 2.block collision occurs: in the 1.a case one of the users is denied tolock. In the 2.b case the concurrent users hold system lock on thecomponents, thus they cannot add edges to the graph.

The situation is more complicated in the 1.b and 2.a cases.Assume, that A and B are two userswho concurrently edit the samegraph. Assume, that their work produces a cycle in the graph andij and kl are the edges that the A user and the B user, respectively,adds to the cycle. Both users must possess user locks on at leasttwo, previously disconnected vertices of the graph in order to becapable of adding the new edges. The situation is presented inFig. 6, where Ga and Gb mark the user locked sub-graphs of userA and B, respectively.

Because the ij and kl edges result a cycle in the graph, theremustbe a directed route from GA to GB and another directed route fromGB to GA. These routes must have existed before GA and GB becamelocked, otherwise these sub-graphswould include some vertices ofthe routes. This is impossible, because then one of the users wouldnot be able to hold any lock of the graph due to the 1.a type of lockincompatibility.

As it can be seen in Fig. 5, the system-locked parts of the graphoverlap with the GA and GB sub-graphs (GA ∪ GB = ∅;GB ∪ GA =

∅). Therefore, both a 1.b and a 2.a type of lock collision must havehappenedwhen the second users’ lock requestwas evaluated. If forexample, A’s request arrived first, then B’s request generates a 2.acollision in the upper-left part of the graph and a 1.b collision inthe bottom-right part (see Fig. 6). If B’s request arrived first, thenA’s request generates a 1.b and a 2.a collision. (With opposite layoutthan earlier: 1.b in the upper left corner, and 2.a in the bottom-rightcorner.)

The situation would be similar with more than two simultane-ous users being involved in the creation of the cycle: the last users’lock request generates a 1.b and a 2.a lock collision. Consequently,if either the 1.b or the 2.b lock collision is denied, then this last usercannot start editing the graph, one edge will be missing from thecycle, the graph remains acyclic. �

Because there are actually two variants of the locking table (onethat allows 1.b lock collision but denies 2.a and another one thatallows 2.a lock collision but denies 1.b), two variants of the A2 lockevaluator algorithm can be defined (see A2 algorithm, variants 1and 2).

Both variants of the A2 algorithm protects the consistency ofworkflow graphs. One can use either the first or the second variantin a lock manager implementation. Moreover, the two variantscan be used in a mixed way, evaluating some lock requests withthe first, other requests with the second variant. The reason ofthis flexibility is: when multiple users create cycle in the graphtogether, then one of these lock requests causes both 1.b and2.a collisions at the same time—as it has been proven earlier.Because neither variants of the A2 algorithm allocates locks forsuch requests, graph consistency cannot be broken even with themixed usage of the A2 algorithm variants.


Fig. 7. Demonstrating the difference between the two variants of the A2 algorithm.

Fig. 8. Development scenario when the A2 algorithm provides better collaborativeperformance than A1.

Meanwhile, either the first or the second variant can be used,the choice has a very visible effect for the users: in a givenlocking situation one variant may allow the locking, while theother does not. Such a situation is shown in Fig. 7. UserA anduserB request locks on a relatively simple graph that contains threevertices (K , L,M) and two edges (kl, lm). UserA would like to editthe L vertex, userB would like to edit the K vertex → RA = {L},RB = {K}. The upper part of the figure shows the USER and SYSTEMlocked sub-graphs generated by the A2 algorithm for theserequests. (Both variants generate the same pattern!.) The bottompart of the figure shows the decisions of the two variants in thecase when the requests arrive in the RS

= (RA, RB) order (lefttable) or in the RS

= (RB, RA) order (right table). (For the sakeof simplicity the tables do not show the decisions concerning thelocking of edges.) In the first case, the evaluation of the RB requestcauses a 1.b type of lock collision (putting an S lock on theU-lockedL vertex). This is allowed by the first variant, but denied by thesecond variant of A2. Consequently, if the requests are evaluatedby the first variant, then userA and userB can work simultaneously.If the second variant of A2 is used then userA can work but userBhas to wait. In the RS

= {RA, RB} case, the situation is the opposite:the first variant denies the concurrent work and the second variantallows it. Similar cases can of course happen with more than twoconcurrent users and on more complex graphs.

Consequence of the above described behaviour is that acollaborative systembuiltwith the A2 lock evaluator algorithm canbe more effective, if it uses both variants at the same time. Whena lock request arrives, it should be evaluated with one, then withthe other variant. If at least one of the variants allows locking, thelocks can be granted. The locks are denied only if both A2 variantsdeny. This integrated A2 algorithm can be described using a verysimple meta-code (see A2 algorithm, integrated version).

5.3. Predicting cycles with contiguity graphs: A3 algorithm

A1 extended the users’ sub-graphs to protect graph consistency.A2 used SYSTEM locks to recognise and deny those collaborativesessions that could potentially break graph consistency. This

section introduces a third algorithm: A3. A3 uses only one lock:the same type of lock that is used in A1 or used as USER lock in A2.A3 implements the protocol from Session 4.1, so it protects againstdangling andmultiple incoming edges. To recognise collaborationsthat threatenwith the possibility of resulting cyclic graphs, A3 usesa new concept, called ‘‘contiguity graph’’. Before describing the v3algorithm, the meaning of the ‘‘contiguity graph’’ is defined.

A contiguity graph is a meta-graph that represents theconnections of locked sub-graphs and unlocked components of aworkflow. In the GC

= GC (V C , EC ) contiguity graph of the sharedG = G(V , E) = G1 + G2 + · · · + Gn + GU workflow:

• Locked sub-graphofG appear as vertices inGC :G1,G2, . . . ,Gn ∈

G → g1, g2, . . . , gn ∈ V C .• Edges that connect two locked sub-graphs of G appear as edges

in GC that connect the g1, g2, . . . , gn vertices.• Unlocked components (vertices and edges) of G appear as

vertices and edges in GC .

The A3 algorithm generates the contiguity graph of theworkflow when a new lock request must be evaluated. Thealgorithm checks whether there is a cycle in the contiguity graph.Cycle in the contiguity graph predicts dangerous collaborativesituation, so the lock request must be denied. The A3 algorithm isdescribed using a meta-code (see A3 algorithm).

A3 starts with similar steps than A1 and A2 in order to protectagainst dangling and multiple incoming edges (steps 1–4). Thecontiguity graph is created in steps 5–7. The contiguity graph iscreated from the original graph (step 5). First, the already lockedsub-graphs are replaced with vertices (step 6), then the sub-graph that should be locked for the current user gets replacedwith a vertex (step 7). These replacements are performed by the‘‘graphReduce’’ function. The code of this function is obvious, notgiven here. If the resulting contiguity graph includes a cycle, thelock is denied (an empty locking set is returned) (steps 8–9).

The v3 lock evaluator algorithm ensures that users who areallowed to modify the graph cannot break any of the graph-levelconsistency rules. An important step in the A3 algorithm is step 8,as it claims that a lock request must be denied if a cycle exists in thecontiguity graph. This statement is proven now.

Statement (Correctness of A3 Algorithm). If a user is able to create acycle in a workflow, then a cycle must exist in the contiguity graphof the workflow when the user’s locking request is evaluated.

Proof. Assume, that user A, user B, . . . , user M concurrently edita G graph. Assume, that the modifications made by some of theseusers (user 1, user 2, . . . , user i; i ≤ M) result a cycle in G. Denotewith e1, e2, . . . , ei the edges that were added by user 1, user 2, . . . ,user i to the cycle. Observations are given below.


A2 algorithm, variant 1—allows lock collision 1.b and denies lockcollision 2.a:

Input: Ri—The lock request of user i (List of objects from theshared G = (V , E) = G1 + G2 + · · · + Gn + GU graph that useri wants to write)

Output: Ui—sub-graph that has to be locked for user i (with USERLOCK) If Ui is empty then the lock request must be denied.

(1) Gi = Ri; Si = {}//Temporary variables:(2) edge e; vertex N; user T ; sub-graph[] S[lockedSubgraphs];

integer j; component c;(3) For (every edge of Gi) {


}//Storing the SYSTEM locked sub-graphs in S[].(4) For (every already locked sub-graph of G) {//Iterating through the sub-graphs in the order as they started:

T = current sub-graphS[j + +] = generateSystemLocks (T )

}// Storing the SYSTEM locked sub-graph of Gi in Si:(5) For (every vertex of Gi) {

(a) N = current vertex of Gi(b) For (every component of Gi) {

(i) c = current component of Gi(ii) if ((pathExists (N, c)==TRUE) and (c /∈ Gi)) then

add c to Si}

}// Checking lock U − U and S − U incompatibility:(6) For every component of Gi

(a) c = current component of Gi {(b) If ((c.isUserLocked ()==TRUE) or (c ∈ S[])) then

Gi = {}}

(7) Return GiA2 algorithm, variant 2—denies lock collision 1.b and allows lockcollision 2.a:

Input and output:Same as above(1) Gi = Ri; Si = {}// Temporary variables:(2) edge e; vertex N; user T ; sub-graph[] S[lockedSubgraphs];

integer j; component c;(3) For (every edge of Gi) {


}// Storing the SYSTEM locked sub-graphs in S[]:(4) For (every already locked sub-graph of G) {//Iterating through the sub-graphs in the order as they started:

T = current sub-graphS[i + +] = generateSystemLocks (T )

}// Storing the SYSTEM locked sub-graph of Gi in Si:(5) For (every vertex of Gi) {

(a) N = current vertex of Gi(b) For (every component of Gi) {

(i) c = current component of Gi(ii) if ((pathExists (N, c)==TRUE) and (c /∈ Gi)) then

add c to Si}

}

// Checking lock U − U incompatibility:(6) For every component of Gi

(c) c = current component of Gi {(d) If (c.isUserLocked ()== TRUE) then {

(i) Gi = {}(ii) Return Gi

}}

// Checking lock U − S incompatibility:(7) For every component of Si

(e) c = current component of Si {(f) If (c.isUserLocked ()== TRUE) then {

(i) Ui = {}(ii) Return Gi

}}

(8) Return Gi

A2 algorithm, integrated version:Input: Ri—The lock request of user i (List of objects from the


Output: Gi—sub-graph that has to be locked for user i with USERLOCK. If Gi is empty then the lock request must be denied.

(1) Gi = v2_variant1(Ri)(2) If (Gi == {}) then Gi = v2_variant2 (Ri)(3) Return Gi

A3 algorithm:Input: Ri—The lock request of user i (List of objects from the


Output: The Gi sub-graph that needs to be locked for user i.(1) Gi = Ri//Temporary variables:(2) edge e; component c; sub-graph Gt ;(3) For (every edge of Gi) {


}(4) For every component of Gi {

(g) c = current component of Gi(h) If (c.isLocked () ==TRUE) then {

Gi = {}; Return Gi}

//Creating contiguity graph:(5) graph GC

= G;(6) For every locked sub-graph of G {

(i) Gt = current sub-graph of G(j) GC

= graphReduce(GC ,Gt );}

(7) GC= graphReduce (GC ,Gi);

//Check if cycle exists in contiguity graph:(8) If (cycleExist (GC ) ==TRUE) then

Gi = {}(9) Return Gi

• Because the users are able to add new edges to their sub-graphs(G1,G2, . . . ,Gi) theremust be at least two–twovertices in everysub-graph. (If a user holds lock on an edge then he/she musthold locks on the source and sink vertices too—see step 3 of theA3 algorithm.)


• Because adding the e1, e2, . . . , ei edges to the G1,G2, . . . ,Gisub-graphs results a cycle inG, theremust have existed directedroutes among the G1,G2, . . . ,Gi sub-graphs before the usersstarted working on the graph. If this would not be true, andthe route between some Ga and Gb sub-graphs was createdby some userx, then the Gx sub-graph should have commonnodeswithGa andGb sub-graphs. This is impossible, because A3denies locking the same component for multiple sub-graphs, soit would deny the simultaneous work of userx, usera and userb.

Consequently, when the Ri request was evaluated by A3, thenalready at least 2–2 nodes existed in G1,G2, . . . ,Gi from the cycleand there were already directed routes between these sub-graphs.In the continuity graph each of these sub-graphs are representedby vertices, so there must be a cycle in the contiguity graph. �

Two examples of how A3 can be used to lock sub-graphs froma shared graph are shown in Fig. 9. The middle column shows aG graph and two lock requests evaluated on it (R1 and R2). Thecontinuity graph generated by A3 is shown below the graph. Thisgraph is generated by replacing the A vertex with a G1 vertexand the {B,D} sub-graph with a G2 vertex. The C vertex and theab, bc, cd edges are simply copied from the original graph to thecontiguity graph. Because the introduction of G2 generates a cyclein the contiguity graph, A3 denies the lock for the second user. Thethird column of the table shows another graph (F ) and how threelock requests (R1, R2, R3) are served on it by A3. The contiguitygraph of F is shown below the original graph. Because there isno cycle in the contiguity graph, the G1,G2,G3 sub-graphs areallocated for the three users.

6. Performance analysis of lock evaluator algorithms

The three lock evaluator algorithms (A1, A2 and A3) providesuch partitioning of acyclic graphs that the consistency rules ofthe graphs cannot be broken by any of the collaborative users. Thethree algorithms use different approaches to evaluate lock requestsand consequently, can result different lock patterns. In the samesituation one algorithm may deny locking for a user, while anotheralgorithm may grant locks. From the users’ perspective the algorithmthat allows the highest number of persons to concurrently work ona graph provides the best performance. The more users can accessthe workflow at the same time the sooner they can contribute tothe graph and the sooner they can finish the development phase toproceed with workflow execution. In this section, the algorithmsare analysed from this perspective.

The decision of a lock evaluator algorithm –whether to deny orto grant locks for a user i on a graph G – depends on the following.

1. The state of G as it is known by the lock evaluator machine.This state is the permanent view of the workflow, it containsonly the saved components. The recently added, not yet savedcomponents are not (necessarily) known for the lock evaluator.

2. The topology of locks that are already on the graph (theG1,G2, . . . ,Gi−1 sub-graphs).

3. The topology of the requested locks (the Gi sub-graph).

The decision is independent of several other factors, such asthe unsaved parts of the graph (these are visible only in the clientside editors of the already collaborating users, but not necessarilyto the lock manager), the start time and finishing time of eachcollaboration, etc.

When an algorithm evaluates the RS= R1, R2, . . . , Rn sequence

of lock requests on a G graph, then, besides partitioning G tolocked sub-graphs (G1,G2, . . . ,Gn) and an unlocked GU sub-graph,the algorithm implicitly returns a 0 or a 1 value for each lockrequestor. 0 means that the lock request is denied, 1 means thatthe request can be satisfied, locks can be granted. The more 1 digits

are returned by an Ax algorithm for an RS lock request on a G graph,the more users are allowed by that algorithm to concurrently edit theworkflow and the better performance the Ax algorithm has in thatparticular situation. Consequently, by comparing the binary vectors ofthe algorithms in a given editing situation, the performance of thesealgorithms can be compared for that situation.

Definition 1. Given a G graph and an RS= R1, R2, . . . , Rn ordered

set of lock requests. An Ax lock evaluator algorithm has bettercollaborative performance than an Ay algorithm, if there are more1 digits in the vector returned by Ax, than in the vector returnedby Ay.

Definition 2. An Ax lock evaluator algorithm has better overallcollaborative performance than an Ay algorithm, if for any G graphand any RS

= R1, R2, . . . , Rn ordered set of lock requests there areat least as many 1 digits in the vector returned by Ax, than in thevector returned by Ay and there is at least one F graph and oneSS = S1, S2, . . . , Sn ordered set of lock requests where more 1digits are in the vector returned by Ax, than in the vector returnedby Ay.

Defining the performance of algorithms in this way is a unique,but reasonable decision. Traditional performance evaluationmethods focus on the scalability, and computational complexityof algorithms. These terms are not relevant in the case ofcollaborative workflow development: the size of collaborativeteams or the size of workflow graphs are not extremely large,they do not require highly scalable solutions. Several case studiesshow that typical collaborative teams consists of 10–15 members,large workflows contain maximum a few hundred individuallyprogrammable vertices [18,20,31,32]. The number of userswho areallowed to share a graph is a much more important metric for agroupware environment.

6.1. Comparing the A1 and A2 algorithms

It is easy to see that the A2 algorithm provides a better overallcollaborative performance than the A1 algorithm. In any situationwhere a user’s lock request does not require an S lock on thegraph (the requested sub-graph is closed) the A2 algorithm resultsexactly the same lock topology than the A1 algorithm. In thesecases the two algorithms allow the same persons to work on thegraph and they return identical binary vectors.

However, when A2 uses S locks and only these S locks collideduring the evaluation of the requests, then A2 allows more peopleto edit the workflow. See a simple example for this in Fig. 8. Conse-quently, the A2 algorithm provides better user experience than the A1algorithm in any collaborative workflow developer environment.

6.2. Comparing the A2 and A3 algorithms

The comparative evaluation of the A2 andA3 algorithms ismorecomplicated. In some editing scenarios the A2 algorithm allowsmore users to work on the graph, while in other cases the A3algorithm provides better collaborative performance. Fig. 9 givesexamples for both situations.

The second column of Fig. 9 shows two users who request lockson a G graph that consists of four vertices and three edges. WhileA2 allows both users to work with the requested components, A3grants locks only for the first person because the second user’srequest results cycle in the contiguity graph. Consequently, in thiscase A2 provides better collaborative performance than A3.

The third column shows three users requesting locks on an Fgraph. In this case, A2 denies locks from the third user, because thethird request puts U lock on S lock and – at the same time – puts Slock on U lock. In this case, A3 grants locks for all the three usersand provides better collaborative performance than A2.


Fig. 9. Collaborative workflow development scenarios to demonstrate the difference in the collaborative performance of the A2 and A3 lock evaluator algorithms.

The examples demonstrate that depending on the topology ofthe workflow, the topology of locked sub-graph and the orderof lock requests, sometimes the A2, sometimes the A3 algorithmallows more users to work on a graph. Because the users’ actionscannot be predicted, it cannot be known in advance whether A2 orA3 provides better solution in a given case. To be prepared for anyediting situation, a new, integrated lock evaluator algorithm mustbe prepared from A2 and A3. (A1 should not be used any longer,because A2 provides better overall performance than A1.)

Because both A2 and A3 holds only the exclusive locks (USERlocks) on the graph, the two algorithms can be simply connectedto an A4 algorithm. This is the same method that was used at theend of Section 5.2 to create the integrated A2 algorithm from thetwo A2 variants. The A4 algorithm first uses the A2 algorithm topredict dangerous collaborations. If the locks can be granted, thenA4 returns with success. If A2 cannot allocate locks then the A3algorithm is called. A3 generates the contiguity graph and checksfor cycle in it. If A3 is able to grant the locks then A4 returns withsuccess. A4 allows locks if either A2 or A3 allows them. A4 denieslocks only if both A2 and A3 denies them. Because both A2 andA3 prevents inconsistencies to appear in the workflow, it does notmatter for a user whether the A2 or the A3 part of A4 granted thelocks.

7. Discussion and implementation

All the four described lock evaluator algorithms (A1, A2, A3and A4) provide such a partitioning of acyclic graphs that none ofthe three graph-level consistency rules are broken by any editor.However, none of the solutions guarantee deadlock free editing.It can happen that a user A locks sub-graph Ga, user B holds sub-graph Gb and they both wait for the other sub-graph to becomeunlocked in order to complete their work. Prohibiting users to holdlocks on more than one workflow component could be a solution

as it is applied in the GroupGraph system [20]. The problem withthis approach is that operations that affect multiple componentscannot be performed. (E.g. the definition of a new edge requirestwo vertices; setting the same set of parameters for multiplecomponents.) Deadlock situations can be also resolved if thesystem includes awareness tools in the users’ editor environments.The awareness tools could show the topology of locks on thewholeworkflow, could help users recognise deadlock situations, contacteach other, discuss and manually resolve the deadlock. This is atypical solution in groupware systems. Widgets, such as the MAUIToolkit [33] are available for this purpose.

To demonstrate the introduced concepts we created withcolleagues from MTA SZTAKI and the University of Readinga groupware prototype by extending a single-user workflowenvironment with collaborative capabilities. We choose P-GRADEPortal [34,35] for this purpose, because it is a widely used tool inproduction environments (e.g. in the European Grid Infrastructure,various national and international grids in Europe, Asia andAmerica) and because it uses a client–server architecture thatis similar to the architecture presented in Fig. 1. The servercomponent of P-GRADE Portal can be accessed from JavaWebstartbased graphical editors. One can define a workflow in the editorby connecting sequential and parallel batch jobs to data drivenapplications. The P-GRADE Portal server uses an extended versionof the Condor DAGMan workflow engine to schedule workflowsto computational resources. The acyclic property of graphs andthe proper connection between vertices are important consistencyrequirements in the system. We extended both the client and theserver side of P-GRADE Portal with collaborative features [5].

Users can request locks on components of a workflow in thecollaborative editor. Requests are propagated by the editors tothe server side lock manager. The manager uses a lock evaluatoralgorithm to estimate which components of the graph needto be and can be locked. Multiple users can possess locks ondifferent components of the same graph, simultaneously. Fig. 1


demonstrates this by showing the different users’ sub-graphswithin boxes,while keeping the rest of the graph semi-transparent.Users can share their graphmodifications with each other throughthe server in real-time and, if they wish, they can see each others’modifications aswell. Because locked components can bemodifiedlocally, the system provides good responsiveness for users. Theimplementation uses the file system of the portal server to storeworkflows and locks, however any other storage could be used forthis purpose.

Our implementation does not maintain any waiting queue fordenied lock requests. Users with denied requests must manuallyre-submit their requests once they see that other users finishedworking with the components they need.

8. Conclusions and future work

The paper presented a concept for the collaborative editingof workflows that must be acyclic with correctly linked vertices.The solution is a locking based approach which ensures thatworkflow graphs are partitioned for users in such a way thatthese users cannot create cycles or dangling edges in the graph.A remarkable property of the solution is that no user’s editingtransaction is aborted and no user’s development effort is wastedwhile the consistency of workflows is guaranteed. Four lock evaluatoralgorithms have been described. These algorithms can be used inthe collaborative architecture to decide about lock requests. Thefirst three algorithms use three different approaches to protectgraph consistency: extension of locks, system locks, and contiguitygraphs.

An evaluation method to compare the performance of the algo-rithms has been introduced in the second part of the paper. Perfor-mance is defined from the users’ perspective: howmany users areallowed to share a G graph if the Ax algorithm evaluates the lockrequests? The analysis of the three algorithms revealed that thesecond algorithm performs better than the first algorithm. It wasalso shown that one cannot easily decide between the second orthe third algorithm. Consequently, the fourth algorithm has beendefined as an integration of the second and third solutions.

A possible direction for future work is to decide whether thefourth algorithm can be improved in some way, for example witha different cycle-prediction method or by using locks with a finergranularity. Vertices and edges could be shared among multipleusers with finer granularity locks. A major disadvantage of finegranularity locking is that it requires complex views and wouldsignificantly complicate user interfaces. The presented algorithmsresult clean and easy-to-understand interfaces as this has beenconfirmedby theusers of the prototype implementationwithin theP-GRADE Portal.

The described groupwaremechanisms have been implementedin the prototype version of the Collaborative P-GRADE Portal andit was used by the Grid Application Support Centre (GASuC) [36] ofMTA SZTAKI to enable scientific applications on the European GridInfrastructure. The extension of an existing single-user workflowtool demonstrates that an originally single-user software can betransformed to a groupware application. Although our tool istargeted at grid application developers, the graph partitioningalgorithms are independent from grid computing and could beused in other workflow based groupware environments.

A two year long project, titled ‘‘Sharing Interoperable Work-flows for Large-Scale Scientific Simulations on Available DCIs’’(SHIWA), co-funded by the 7th Framework Programme of theEuropean Commission, has started in 2010. The goal of SHIWAis to integrate grid computing workflows designed by the mostwidely used scientific workflow environments [37]. The integra-tion is foreseen through the nesting of different workflows andpromises with the interoperability of workflow systems without

rewriting existing applications and without learning new work-flow languages. According to the SHIWA concept legacy work-flows would be represented as vertices within higher level‘‘super-workflows’’ that hide the internal specification and struc-tures of these embedded entities. The development of super-workflows would be most convenient in a collaborative editorenvironment. The SHIWA project is led by the Laboratory of Par-allel and Distributed Systems of MTA SZTAKI (Hungarian Academyof Sciences) and will also investigate whether the capabilitiesof the Collaborative P-GRADE Portal could be reused by theproject.

Acknowledgements

I am grateful to my colleagues at MTA SZTAKI and at theUniversity of Reading for their valuable advices on the describedresearch and for their contribution to the collaborative extensionof P-GRADE Portal.

References

[1] D. Georgakopoulos, M. Hornick, A. Sheth, An overview of workflowmanagement: from process modeling to workflow automation infrastructure,Journal of Distributed and Parallel Databases 3 (2) (1995) 119–153.

[2] W.M.P. van der Aalst, A.H.M. ter Hofstede, M. Weske, Business ProcessManagement: A Survey, in: Lecture Notes in Computer Science, vol. 2678,Springer, Berlin, Heidelberg, 2003, pp. 1–12.

[3] A. Barker, J. van Hemert, Scientific Workflow: A Survey and ResearchDirections, in: LNCS, vol. 4967, Springer, Berlin, Heidelberg, 2008, pp. 746–753.

[4] I.J. Taylor, E. Deelman, D.B. Gannon, M. Shields, Workflows for E-Science:Scientific Workflows for Grids, Springer-Verlag New York, Inc., Secaucus, NJ,USA, 2006.

[5] G. Sipos, G.J. Lewis, P. Kacsuk, V.N. Alexandrov, Workflow-oriented collabora-tive grid portals, in: Proc. of European Grid Conference, EGC 2005, in: LNCS,vol. 3470, Amsterdam, The Netherlands, 2005, pp. 434–443.

[6] Z. Zhao, S. Booms, A. de Laat Belloum, B.C. Hertzberger, VLE-WFBus: ascientific workflow bus for multi e-science domains, in: Proc. of Second IEEEInternational Conference on E-Science and Grid Computing, e-Science’06,Amsterdam, The Netherlands, 2006.

[7] J.M. Müller, G. Zhang, J.C. Lapayre, P. Müller, Service-oriented support ofcooperative workflows. Considerations for urban planning processes, in: Proc.of 11th Conference of the Association for Information and Management,Luxemburg, 2006.

[8] M. Held, W. Blochinger, Structured collaborative workflow design, FutureGeneration Computer Systems 25 (6) (2009) 638–653.

[9] T. Friese, M. Smith, B. Freisleben, J. Reichwald, T. Barth, M. Grauer,Collaborative grid process creation support in an engineering domain, in: Proc.of High Performance Computing—HiPC, 2006, pp. 263–276.

[10] G. Sipos, P. Kacsuk, Collaborative workflow editing in the P-GRADE portal,in: Proc. of Microcad 2005 International Conference, Miskolc, Hungary, 2005,pp. 353–358.

[11] G. Sipos, P. Kacsuk, Efficient partitioning of graphs in collaborative workfloweditor systems, in: Proc. of IADIS International Conference CollaborativeTechnologies, Freiburg, Germany, 2010, pp. 69–76.

[12] G. Sipos, P. Kacsuk, Maintaining consistency properties of grid workflows incollaborative editing systems, in: Proc. of Grid and Collaborative ComputingConference, GCC09, IEEE-Publishing, Lanzhou, China, 2009, pp. 168–175.

[13] D. Chen, A survey of real-time collaborative editing systems, in: Proc. of theEighth International Workshop on Collaborative Editing Systems, ACM CSCW2006, Banff, Canada, November 4, 2006.

[14] C.-L. Ignat, M.C. Norrie, Multi-level editing of hierarchical documents,Computer Supported Cooperative Work 17 (5–6) (2008) 423–468.

[15] C. Sun, X. Jia, Y. Zhang, Y. Yang, D. Chen, Achieving convergence, causalitypreservation, and intention preservation in real-time cooperative editingsystems, ACM Transactions on Computer–Human Interaction (TOCHI) 5 (1)(1998) 63–108.

[16] A.M. Nacar, et al., VLab: collaborative grid services and portals to supportcomputational material science, Concurrency and Computation: Practice andExperience 19 (12) (2007) 1717–1728. John Wiley & Sons.

[17] O. Yu, A. Lia, Y. Caoa, L. Yina, M. Liaoa, H. Xua, Multi-domain Lambda griddata portal for collaborative grid applications, Future Generation ComputerSystems 22 (8) (2006) 993–1003.

[18] C.A. Goble, D.C. De Roure, MyExperiment: social networking for workflow-using E-scientists, in: Proc. of the 2nd Workshop on Workflows in Support ofLarge-Scale Science, Monterey, California, USA, 2007.

[19] M. Held, W. Blochinger, Structured collaborative workflow design, FutureGeneration Computer Systems 25 (6) (2009) 638–653.

[20] H.A.S. Lima Filho, C.M. Hirata, Groupgraph: a collaborative hierarchicalgraph editor based on the Internet, in: Proc. of the 35th Annual SimulationSymposium, 2002.


[21] K. Lin, D. Chen, C. Sun, R.G. Dromey, Maintaining constraints expressedas formulas in collaborative systems, in: Proceedings of the Third In-ternational Conference on Collaborative Computing: Networking, Applica-tions and Worksharing, CollaborateCom 2007, New York, USA, November,2007.

[22] D. Li, J. Patrao, Demonstrational customization of a shared whiteboard tosupport user-defined semantic relationships amongst objects, ACMGROUP’01,Boulder, Colorado, USA, September 2001, 97–106.

[23] K. Lin, D. Chen, C. Sun, R.G. Dromey, Maintaining constraints in collaborativegraphic systems: the CoGSE approach, in: Proceedings of the 9th EuropeanConference on CSCW, Paris, France, September 2005.

[24] K. Lin, D. Chen, C. Sun, R.G. Dromey, Maintaining multi-way dataflow con-straints in collaborative systems, in: Proceedings of IEEE 2005 InternationalConference in Collaborative Computing: Networking, Applications andWork-sharing, San Jose, CA, USA, December 2005.

[25] D. Pinelle, C. Gutwin, A review of groupware evaluations, in: Proc. of NinthIEEE WETICE 2000 Workshops on Enabling Technologies: Infrastructure forCollaborative Enterprises, Gaithersburg, Maryland, 2000, pp. 86–91.

[26] R.M. Araujo, F.M. Santoro, M.R.S. Borges, The CSCW Lab for groupwareevaluation, in: J. Haake, J. Pino (Eds.), Groupware: Design, Implementation andUse, Proceedings of the 8th InternationalWorkshop, La Serena, Chile, in: LNCS,vol. 2440, 2002, pp. 222–231.

[27] R. Baeza-Yates, J. Pino, A first step to formally evaluate collaborative work, in:Proc. of the International ACM SIGGROUP Conference on Supporting GroupWork: The Integration Challenge, November 16–19, Phoenix, Arizona, USA,1997, pp. 56–60.

[28] J.A. Preston, Rethinking consistency management in real-time collaborativeediting systems, Ph.D. Thesis, Georgia State University, 2007.

[29] C.A. Ellis, S.J. Gibbs, Concurrency control in groupware systems, in: Proc. ofthe ACM SIGMOD’89 Conference on theManagement of Data, ACM, New York,1989, pp. 399–407.

[30] C.J. Huang, L.M. Liao, An intelligent agent-based collaborative workflow forinter-enterprise PCB product design, in: Proc. of the IEEE International Con-ference on Industrial Engineering and Engineering Management, Singapore,2007, pp. 189–193.

[31] A. Khetawat, H. Lavana, F. Brglez, Collaborative workflows: a paradigm fordistributed benchmarking and design on the Internet, NCSU Technical Report,February 1997.

[32] D. Baker, D. Georgakopoulos, D. Schuster, A.R. Cassandra, A. Cichocki,Providing customized process and situation awareness in the collaborationmanagement, in: Proc. of IFCIS International Conference on CooperativeInformation Systems, CoopIS’99, Edinburgh, UK, 1999, pp. 79–91.

[33] J. Hill, C. Gutwin, The MAUI toolkit: groupware widgets for group awareness,Journal of Computer Supported Cooperative Work (CSCW) 13 (5–6) (2004)539–571.

[34] Z. Farkas, P. Kacsuk, P-GRADE portal: a generic workflow system to supportuser communities, Future Generation Computer Systems 27 (5) (2011)454–465.

[35] P-GRADE Portal project on Sourceforge:http://sourceforge.net/projects/pgportal (last accessed: 12.09.11).

[36] MTA SZTAKI Grid Application Support Centre (GASuC). www.lpds.sztaki.hu/gasuc (last accessed: 12.09.11).

[37] Sharing interoperable workflows for large-scale scientific simulations onAvailable DCIs (SHIWA) Project: www.shiwa-workflow.eu (last accessed:12.09.11).

Gergely Sipos received hisM.Sc. and Ph.D. degrees in Com-puter Science from the University of Miskolc in 2003 and2010, respectively. He became involved in grid comput-ing in 2002 and researched high-level user environmentsand collaborative design tools. Between 2006 and 2009Gergely also worked in training, consultancy and usersupport for the EGEE project from his base in Budapest,where he promoted grid technology and distributed com-puting practices to scientific communities. Since 2010Gergely works for EGI.eu in Amsterdam, supporting themulti-national user communities of the European Grid

Infrastructure.

http://sourceforge.net/projects/pgportal

www.lpds.sztaki.hu/gasuc





http://www.shiwa-workflow.eu

Documents

Protecting the consistency of workflow applications in collaborative development environments