A Resource Model for Cloud-based Workﬂow Management Systems

Enabling Access Control, Collaboration and Reuse

Sebastian G

org

, Ralph Bergmann

, Sarah Gessinger

and Mirjam Minor

Department of Business Information Systems II, University of Trier, Trier, Germany

Wirtschaftsinformatik, Goethe University of Frankfurt a. M., Frankfurt am Main, Germany

Keywords:

Access Control, Workﬂows, Collaboration, Experience Reuse.

Abstract:

Cloud-based workﬂow management systems provide platforms for modeling and execution of workﬂows

while offering the common beneﬁts of cloud computing. Additionally, the opportunity for workﬂow reuse

and collaborative modeling could support agile business, as better workﬂows can be created according to a

particular demand of the business with less effort. This paper addresses the issue of workﬂow reuse and col-

laborative modeling within a community of users. We present a new resource model for workﬂow related

resources as well as a proposal for an access control mechanism. The proposed methods are currently under

development within the workﬂow management system CAKE.

1 INTRODUCTION

During the last years the cloud-based computing par-

adigm emerged. It allows a shift from local IT-

systems and information to the internet-cloud. In the

cloud, service provider can offer web-based applica-

tions which replace local distributed and heteroge-

neous systems. As high network bandwidths become

available, the usage of cloud-based applications de-

livers the same speed and response times as local ap-

plications. Compared to traditional IT-infrastructures

cloud computing has attractive features (Liu et al.,

2011): It leads to lower maintenance costs, more re-

sources can be shared, they are easier to scale and

more reliable.

The Workﬂow Management Coalition (WfMC)

deﬁned a workﬂow as “The automation of a business

process, in whole or part, during which documents,

information or tasks are passed from one participant

to another for action, according to a set of procedu-

ral rules” (Coalition, 1999). Respectively, a Work-

ﬂow Management System (WfMS) deﬁnes, creates

and manages the execution of workﬂows. In general a

WfMS is an information system for the management

of business processes.

A cloud-based Workﬂow Management System

provides a web-based platform for the modeling

and execution of workﬂows. There are different

trends and professional goals for current cloud-based

WfMS. There are WfMS with a focus on a particu-

lar market, e.g. cﬂow

on jewelry retailers and health

care, nowwecomply.com on compliance, or Taverna

on scientiﬁc workﬂows. These systems are easy to

understand and to setup for their customers. On

the other hand, there are more comprehensive sys-

tems like RunMyProcess.com or Visual Workﬂow by

SalesForce

, which allow to develop applications by

modeling a ﬂow of custom software components or

web services. Both trends show that cloud-based

WfMS are an emerging market.

Nevertheless, today’s cloud-based WfMS have in

common that they do not take full advantage of the

collaboration and experience reuse features the cloud

paradigm can provide. They provide the basic secu-

rity features of classical WfMS, but omit the oppor-

tunities of collaborative workﬂow modeling and of

sharing and reuse of the procedural knowledge within

the workﬂows.

An example for the beneﬁt of collaborative work-

ﬂow modeling in cloud-based WfMS is the opportu-

nity in gaining better workﬂows. Many enterprises

especially small and medium-sized enterprises have

only a few employees with the skills to design and

maintain business processes and related workﬂows.

This is a big issue when enterprises grow and need to

http://cavintek.com/

http://taverna.org.uk/

http://www.salesforce.com/platform/cloud-

platform/workﬂow.jsp

263

Görg S., Bergmann R., Gessinger S. and Minor M..

A Resource Model for Cloud-based Workﬂow Management Systems - Enabling Access Control, Collaboration and Reuse.

DOI: 10.5220/0004371302630272

In Proceedings of the 3rd International Conference on Cloud Computing and Services Science (CLOSER-2013), pages 263-272

ISBN: 978-989-8565-52-5

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

shift from pure operational business to a more strate-

gic alignment. Workﬂow modeling is a tedious task

which growths with the size of the enterprise. Work-

ﬂow modelers must have expert knowledge on the

business of the enterprise in order to model the work-

ﬂow. Usually, the workﬂow modeler cannot have

such complete in-depth knowledge of an expert. A

better approach for this problem would be that the

business-experts are more involved in the modeling

while being empowered to model the workﬂow by

themselves. Therefore the workﬂow modeler can ben-

eﬁt from a cloud-based WfMS which supports col-

laborative modeling. The workﬂow modeler can in-

vite an expert by granting access to him/her to the

affected workﬂow. Thereby the expert can use the

workﬂow modeling user interface with an arbitrary

browser without installing additional software. The

workﬂow modeler and the expert can then collabora-

tively model the workﬂow.

Another example for the beneﬁt of cloud-based

WfMS is the possibility to share best-practice work-

ﬂows. Sharing of workﬂows means that a work-

ﬂow modeler allows other modelers or employees to

see and to reuse a best-practice workﬂow for their

own purposes. In particular, administrative work-

ﬂows are very similar throughout different depart-

ments, e.g. the deployment of software-updates or

escalation workﬂows. If the knowledge of such inter-

nal workﬂows is easy to obtain and to discover, there

is a chance for synergy because the departments are

more informed about the internal workﬂows of other

departments and thus could beneﬁt from the shared

knowledge.

The remainder of this paper is organized as fol-

lows. In the next section the requirements for a cloud-

based WfMS are depicted considering different ap-

plication domains. Section 3 describes the CAKE

system, the cloud-based WfMS, and its system archi-

tecture. The next two sections describe the resource

model and the access control mechanism. Section 6

describes the workﬂow reuse and collaborative work-

ﬂow modeling. We conclude by discussing the cur-

rent state of development.

2 REQUIREMENTS

The presented concept for collaboration and reuse of

workﬂows was developed based on the experience in

different application domains for workﬂows and their

according requirements: ofﬁce/administrative work-

ﬂows (Minor et al., 2009a), chip design (Minor et al.,

2009b), scientiﬁc workﬂows (Minor and G

org, 2011),

cooking workﬂows (Walter et al., 2011), construction

workﬂows and personal/social workﬂows (G

org et al.,

2012). In the focus of the developed resource model

are no speciﬁc characteristics of these application do-

mains. It is a generic concept which we expect to be

applicable in all of these application domains.

In summary, the following general requirements

for a cloud-based WfMS have been observed in the

above mentioned application domains. Section 5.2

and 6 describe how the resource model fulﬁls these

requirements.

1. Support for modeling of workﬂows.

2. Support for the execution of workﬂows including

human and automated tasks.

3. Support for collaborative workﬂow modeling and

sharing of resources.

As mentioned in the introduction, normal WfMS

are local information systems. Only few people in

an organization are committed to model and maintain

workﬂows. In such a case, some accounts for work-

ﬂow modelers are sufﬁcient. Employees, involved in

the execution of tasks, would just need a login to their

worklist in order to verify their identity. This corre-

sponds to the classical role distinction of the WfMC

between workﬂow modelers and workﬂow partici-

pants (Coalition, 1999). In a cloud-based WfMS this

clear role allocation is blured, because former work-

ﬂow participants can be proactively involved in the

modeling of workﬂows enabled by the easy acces-

sibility of the technology. The postulated collabora-

tion and sharing requirement for a cloud-based WfMS

leads to the development of a resource model for col-

laboration and reuse.

Collaboration and reuse of workﬂows have been

found useful in all application domains which require

extensive and diverse expert knowledge. The sharing

feature (see section 6.1) is particularly important in

many domains.

3 CAKE THE CLOUD-BASED

WFMS

Based on the requirements of section 2 the resource

model has been developed as part of the Collaborative

Agile Knowledge Engine

(CAKE) system. The fol-

lowing sections brieﬂy describe workﬂows in CAKE

and parts of the system architecture.

3.1 Workﬂows in CAKE

CAKE is a prototypical generic software system for

http://cake.wi2.uni-trier.de

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

264

integrated process and knowledge management.

CAKE integrates selected research results on agile

workﬂows

, case-based reasoning, and web technolo-

gies into a common platform that can be conﬁgured to

different application domains and needs. Agile work-

ﬂow technology (Weber and Wild, 2004; Reichert and

Dadam, 1998) means that a workﬂow can be mod-

eled and changed on demand and that even a running

workﬂow can be paused and adapted to new require-

ments. Thus, agile workﬂow technology dissolves the

clear separation between the build- and runtime of a

workﬂow (Coalition, 1999).

In general, a workﬂow consists of tasks which are

linked by a control ﬂow, and data objects which are

linked by a data ﬂow (van Der Aalst et al., 2003).

The control ﬂow consists of a sequence of tasks and

routing constructs. There are several routing con-

structs, and of these the parallel execution of se-

quences (AND-Split and AND-Join), the exclusive

choice of sequences (XOR-Split and XOR-Join) or

the multi-choice (OR-Split and OR-Join) are often

supported by WfMS. Tasks can be executed by hu-

mans or automatically by an invoked application. The

data ﬂow consists of interlinked data objects. Data ob-

jects can be linked amongst others between tasks, be-

tween tasks and routing constructs, or between tasks

and sub-workﬂows.

During workﬂow enactment, tasks can be exe-

cuted by services (e.g. web services or speciﬁc im-

plementations of automated tasks) or certain activi-

ties may require human workﬂow participants (e.g.

experts). In Figure 1, a very simple workﬂow in

Figure 1: A simple workﬂow.

Cake Flow Cloud Notation (CFCN) (Minor et al.,

2011) is illustrated. CFCN is a workﬂow modeling

language which is derived from UML activity dia-

grams. We think it will receive more acceptance by

the users of the CAKE system. This assumption is

based on current HCI research where ’enchantment’

is an important aspect and beauty is part of enchant-

ment in using UIs (Wright et al., 2008). Further-

more many HCI researchers state that the visual ap-

For more information on agile workﬂow technology

please refer to (Minor et al., 2008).

peal inﬂuences factors as (perceived) reliability, us-

ability, information quality, trustworthiness and use-

fulness (Lindgaard et al., 2011). In this simple exam-

ple two subsequent tasks are executed. The ﬁrst task

is delegated to an employee. The employee will create

a report and upload it to the workﬂow. When the data

object ’Report-2012.xlsx’ becomes available, the ex-

ecution of the preconﬁgured automated ’Encrypt and

Send’ task is triggered. This automated task may send

the report to a list of speciﬁed recipients.

3.2 System Architecture

In Figure 2, the overall CAKE system architecture is

illustrated. The server component consists of a stor-

age layer which handles persistency, an interface layer

for the communication with web applications and two

central engines, which are brieﬂy described in the fol-

lowing.

Figure 2: The CAKE system architecture.

The workﬂow engine is used for the enactment of

workﬂows. Its internal architecture is strongly tied

to the reference architecture of the WfMC (Coalition,

1999). Thus, the workﬂow engine provides inter-

faces for modeling and execution of workﬂows (Agile

Workﬂow Execution), for invoking applications (Ser-

vice Connector), and an interface for the delegation of

tasks (Worklist Manager).

The knowledge engine supports process-oriented

case-based reasoning (Bergmann et al., 2006;

Bergmann and Gil, 2011; Madhusudan et al., 2004;

Chinthaka et al., 2009) and aims at intelligent meth-

ods for reusing experiential knowledge. It supports

similarity-based retrieval of workﬂows based on se-

AResourceModelforCloud-basedWorkflowManagementSystems-EnablingAccessControl,CollaborationandReuse

265

mantic descriptions as well as the automatic adapta-

tion of workﬂows (Minor et al., 2010). The aim is to

support unexperienced workﬂow modelers with gath-

ered and structured knowledge in a database. This

experiential knowledge can then be discovered and

reused in order to build or to improve a workﬂow un-

der construction. The reuse of procedural knowledge

is closely linked to the possibility to share and spread

workﬂows. Though a detailed description of this sce-

nario would go beyond the extent of this paper

The interface layer provides communication

means which encapsulate the functions of the two en-

gines and it enables the development of complex web

applications such as a workﬂow modeling and execu-

tion environment.

The proposed resource model for collaboration

and reuse has been integrated by an access control

mechanism in the storage layer. This layer has to en-

sure that any stored resource (a workﬂow, a task, and

any further resources) is accessible and possesses a

clear ownership. From an abstract point of view the

access control mechanism is a decentralized Discre-

tionary Access Control (dDAC) (Downs et al., 1985)

with subject-object relationships speciﬁed in Access

Control Lists (ACLs). From a detailed point of view

it is a workﬂow speciﬁc access control concept which

fulﬁls the given requirements of section 2 with a set

of default access rules to ensure operation (see section

5). By decentralized we mean that an user can trans-

fer access rights to another subject. The basic idea

is that every resource in the system has a dedicated

owner who is allowed to manage the access rights for

the resource.

4 THE ACCESS CONTROL

MECHANISM

In the following section, the access control mecha-

nism is described. It starts with the resource model in

general. Then, the access control mechanism for re-

sources is described. Afterwards logical structures are

introduced which facilitate an efﬁcient control over

resources and ensure an easier usage of the system.

4.1 The Resource Model

The resource model is illustrated in the UML class

diagram of Figure 3. Everything in the CAKE sys-

tem is considered as a Resource and the access con-

trol mechanism aims at specifying the access rights

For more information please refer to (G

org et al., 2012;

Bergmann et al., 2006).

for each resource. A resource has exactly one owner.

Participants are resources as well, and hence we

need to avoid that an Object, e.g. a task or a data

object, gets access rights to a participant. The sub-

classes of participant are Account and Participant

Group, which is a group of an arbitrary set of ac-

counts. Accounts have a unique identiﬁer. The re-

source model does not prohibit that a participant can

get access rights to another participant. As a conse-

quence, a participant can have or give access rights to

another participant. For instance the membership of

an account in a participant group does not necessarily

mean that the person who is a member may see the

members of the participant group. Only if the person

has also got the right to read the content of the partic-

ipant group the group members become visible to the

person.

For the retrieval of resources the enrichment with

semantic information is a means to simplify and im-

prove the discovery of resources. The Semantic Meta

Data can be realized via Ontologies which should be

speciﬁed in a public standard format such as OWL to

enable inference mechanisms.

The left four main types of resources are the

Adaptation Case (for case-based automatic adapta-

tion of workﬂows (Minor et al., 2010)), Data, Work-

ﬂow and Task. Due to the nature of workﬂow man-

agement systems, tasks are connected with partic-

ipants by a speciﬁed Execution. In the reference

model of the WfMC it is the role of the Worklist

which controls the Human Execution and task del-

egation. The Assignment differentiates between al-

lowed and assigned participants. The modeler may

deﬁne several allowed participants to execute a task,

but only one participant can be assigned in the end. If

a participant group is allowed to execute a task, each

member may be asked to execute the task but no one

is assigned. A participant group can be a set of col-

leagues or experts who fulﬁl a predeﬁned role in an

organization. Besides the human execution, we also

support automated tasks, which can be executed with-

out user interaction. For these tasks, the Service Exe-

cution is responsible. Automated tasks which use the

service execution are custom software components.

The automatic sending of an e-mail or the retrieval

of data from a database are examples for this.

A concrete workﬂow consists of a control ﬂow

with tasks and data objects linked with tasks. Be-

fore the specializations of the data, workﬂow and task

classes will be explained (see section 5.2), the terms

of instance and prototype are deﬁned. These deﬁni-

tions are a generalization of the common workﬂow-

schema/instance separation in WfMS to ﬁt to any re-

source of the resource model.

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

266

Figure 3: The resource model.

• A Prototype is a template which cannot be ex-

ecuted. We have prototypes for workﬂow, task,

and data items. We distinguish between system

prototypes and derived prototypes. System proto-

types are reusable entities. The usage of a system

prototype leads to a derived prototype. A derived

prototype is conﬁgurable and editable.

• An Instance is a copy of a derived prototype. The

instantiation creates an executable copy of a de-

rived workﬂow prototype. Only instances can be

executed. Hence, we have instances for workﬂow,

task and data items.

The reasons for the restrictions on derived prototypes

as well as the reason why only instances may be used

for execution are explained later on in section 5.3.

The common workﬂow artifacts (tasks and data) and

their workﬂow environment are described in more de-

tail in section 5.2 together with some default access

rights, which are needed to meet the requirements of

section 2.

The last unexplained part of the diagram shows

the Resource Group. There are two reasons why it is

different from the participant group. The ﬁrst reason

is the durability of the group members. If a resource

group is deleted, all of its members should also van-

ish, because they are no longer needed. A group of

participants needs another behavior. The deletion of

a participant group may never entail the deletion of

its group members, i.e. the accounts. The second

reason is the need to give a hierarchical structure to

resources. In contrast to the participant group, the re-

source group should be able to form tree structures.

Objects might be grouped by participants in order to

organize and share personal libraries of resources. For

instance, a new secretary shall see all administrative

workﬂows for a certain division of a company. Then,

the secretary only needs the read right to the folder

where these workﬂows are.

4.2 Access Control Mechanism

Access Rights are deﬁned between participants and

resources. Thus, a set of people (participant group)

or a single person (account) can get access rights to

an object resource. This also means that every person

can control his/her visibility to the public by restrict-

ing read rights about himself to a certain person or a

group of persons. Access rights regulate three kinds

of access: read, write, and execute. The access to a

resource is managed by the access rights, but the ac-

cess rights can only be assigned by the owner. The

resource model only regards positive access rights. It

is not possible to explicitly deny a right. Hence, in-

consistent access rights due to the membership of par-

ticipants in different participant groups cannot occur.

The access rights that a single account possesses, is

a union of all access rights for this account and all

participant groups in which the account has a mem-

bership. On certain resources, not all access rights are

AResourceModelforCloud-basedWorkflowManagementSystems-EnablingAccessControl,CollaborationandReuse

267

applicable. For instance the execute right is only ap-

plicable to workﬂow instances, but not to individual

task or data items.

4.3 Logical Structures

Before the access rights and their default application

are described in more detail, some logical structures

are explained. These logical structures are based on

the resource group and facilitate the organization of

owned resources as well as rights management. Fur-

thermore, the logical structures are a means to de-

velop useful and coherent user interfaces. In this sec-

tion we describe how logical structures are used to

ensure the ownership over resources.

In Figure 4, a Workspace is illustrated. It is

a logical structure which is intended to accommo-

date an arbitrary set of other logical structures. The

workspace is the root for all owned resources of an

account. Every account has at least one workspace.

The workspace has exactly one owner. All subgroups

and their group members, i.e. object resources, get

their inherited ownership by the workspace owner. A

workﬂow may only be started if it is part of a sub-

group within a workspace and a person has the right

to execute it. This ensures that there is always at least

one responsible person for its execution, even if the

executor is not the owner. To organize resources in

Figure 4: The Workspace - A logical structure.

a workspace, different logical tree structures can be

mounted in the workspace. Mounted means that the

workspace resource group gets new members which

are also resource groups.

5 APPLICATION OF ACCESS

RIGHTS

This section is about access rights and their default

application in the context of workﬂows and resources

in general, based on the requirements in section 2.

First, the term of ownership is explained and how it is

related to a workspace. Then, default access rights to

resources are described from different views in order

to give a recommendation for a cloud-based WfMS.

In the end, the instantiation of derived prototypes is

explained in more detail.

5.1 Ownership

Access rights can only be assigned or removed by the

resource owner. Ownership can only be taken by a

single account. According to the workspace structure

all resources in a workspace have the same owner.

The concept of access rights could also allow to trans-

fer the ownership of a resource to another participant

or group of participants, but this will not be supported

for the following reasons.

If there is a workﬂow on which several people

collaboratively work, it is not intended that a user

can lose the ability to read, write, or execute his/her

formerly owned workﬂow, because someone else has

taken the ownership. In such a case, the owner of the

logical structure in which the workﬂow lies would dif-

fer from the workﬂow owner and this would violate

the concept of the workspace. Also non-executable

resource objects, such as data (documents), must meet

this requirement of the workspace. If a transfer of

ownership would be allowed it would cause a resource

to switch the workspace.

If the ownership of a resource could be taken by

a participant group, then it would be possible that an

empty group is the owner of an already running work-

ﬂow instance, which would also lead to the conse-

quence that no one is responsible for the execution

of the workﬂow and its monitoring. Therefore, only

accounts may have a workspace.

5.2 Default Access Rights

After the explanation of the resource model, the ac-

cess control mechanism in general and its derived log-

ical structures, the data, tasks, and their workﬂow en-

vironment are described by the terms of prototypes

and instances.

Data within a workﬂow can consist of documents,

ﬁles, or primitive types such as integer or string val-

ues. Their system prototypes can be stored in a doc-

ument management system which uses versioning to

provide the proper release of data objects. By using

a data system prototype in the context of a derived

workﬂow prototype / workﬂow instance, it becomes a

derived data prototype / data instance.

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

268

Tasks within a workﬂow can either be automated

tasks, which are executed without user interaction or

human tasks which needs to be executed by a person.

Their system prototypes are speciﬁed descriptions of

concrete implementations or web-services. By insert-

ing a task system prototype into the control ﬂow of

a derived workﬂow prototype / workﬂow instance it

becomes a derived task prototype / task instance.

Workﬂows combine tasks by control ﬂow struc-

tures and data objects with tasks by data links (van

Der Aalst et al., 2003). The system prototype of a

workﬂow is not comparable with the ones for data

objects or tasks. For workﬂows, only one type of sys-

tem prototype exists. It is an empty container which is

able to accommodate data objects and tasks in order to

link these to form a logical sequence of activities. By

modeling the control ﬂow, it automatically becomes a

derived prototype. If we talk of workﬂow prototypes,

it is indeed a derived workﬂow prototype already.

An operational cloud-based WfMS would need

much time to check the access to every resource or

even more granular for every attribute of a resource.

For this reason this section explains where particular

access rights are necessary, considering the modeling

and the execution of workﬂows. The ﬁrst scenario is

described from the perspective of a workﬂow mod-

eler. Table 1 is a sample instance of the table ’Access

Rights’ in Figure 3 and explains which rights have

to be assigned explicitly. The second scenario is de-

scribed from the view of a workﬂow participant who

receives a delegated task. It explains why some rights

have to be set implicitly for the ’Assignment’ of the

’Human Execution’ (see Figure 3).

Table 1: Access rights during workﬂow modeling.

read write execute

System data prototypes x

System task prototypes x

(Derived) workf. proto. x x

Workﬂow instances x x x

Modeling of Workﬂows. Table 1 shows the ac-

cess rights which are relevant for workﬂow model-

ing. Read rights to system data and task prototypes

are required in order to see available data items and

tasks which the workﬂow modeler can use to create

the new workﬂow, i.e. a derived workﬂow prototype.

Hence, read access to these items enable to control

which items are available to a certain user for mod-

eling a workﬂow. These rights may, for example, be

A derived workﬂow prototype is equivalent to the

common term of a workﬂow schema/template/deﬁnition in

WfMS.

speciﬁc to a certain participant group. In order to edit

the new workﬂow, the user needs the read and write

right to the respective derived workﬂow prototype be-

ing modeled, as the main purpose of modeling is writ-

ing a new workﬂow. These rights are automatically

passed to all derived data and task prototypes created

as part of this workﬂow. Hence, a certain right to a

derived workﬂow prototype implies the same right to

all of its components. Consequently, there is no need

to explicitly specify individual rights for derived data

and task prototypes. This simpliﬁes the rights man-

agement and avoids incomplete access to a workﬂow.

Once the workﬂow prototype is completely mod-

eled, the user has to create a workﬂow instance as

only the workﬂow instance is executable. In order

to actually execute the created instance, the execute

right is necessary. The additional write right for the

instance speciﬁed in the table entitles the user also

to modify the executed workﬂow after it has been

started. As for derived workﬂow prototypes, the ac-

cess rights for workﬂow instances are also passed im-

plicitly to the task and data instances. Hence, there is

also no need to explicitly specify individual rights for

data and task instances.

Execution of Human Tasks. Human task instances

are used for the delegation of tasks to participants by

the human execution and the speciﬁed assignment.

Thus the description of tasks must be readable for the

assigned or allowed participants as well as provided

input data and the ability to write output data. So the

assignment of the human execution implies the access

rights for task and data instances. Task instances are

limited to a read right, because their content and their

structure within the control ﬂow is not inﬂuenced by

the person who is assigned to a human task. Dur-

ing delegation, the task instance will always be in the

same position in the control ﬂow and all incoming and

outgoing data links will remain unaltered. Data in-

stances need an additional write access for assigned

persons if the assigned person has to change a data

object or if the creation of a new data object is re-

quired for fulﬁlling the task (see ﬁrst task in Figure

1).

5.3 Instantiation of Derived Prototypes

A participant needs a read right to a workﬂow pro-

totype in order to create a workﬂow instance. The

owner of the workﬂow instance is the person who en-

gaged the instantiation process and thereby the work-

ﬂow instance is part of the workspace of that person.

The resource model allows to instantiate all work-

ﬂow prototypes which are readable for a participant.

AResourceModelforCloud-basedWorkflowManagementSystems-EnablingAccessControl,CollaborationandReuse

269

This is useful if a workﬂow needs to be executed only

one time for a participant and the participant used a

workﬂow prototype from a public repository of work-

ﬂows. If the participant needs to adapt the workﬂow

instance to his/her needs, the agile workﬂow technol-

ogy (see section 3.1) of the CAKE WfMS even allows

to change a running workﬂow instance.

Alternatively, the participant can copy the work-

ﬂow prototype into his/her own workspace before the

instance is created and the workﬂow is started. The

copied workﬂow prototype is then owned by the par-

ticipant and thereby she/he also receives read and

right access rights to the workﬂow prototype. This

enables him/her to adapt the workﬂow to his/her par-

ticular needs, which is useful in cases multiple equiv-

alent instances of this workﬂow prototype have to be

executed.

6 COLLABORATION AND

SHARING

In this section, the processes of sharing resources and

the collaborative workﬂow modeling are brieﬂy de-

scribed. Afterwards a general issue on copying work-

ﬂows is discussed in the context of collaboration and

sharing.

6.1 Sharing of Resources

Sharing of resources is the reuse of resources by other

participants. This means that not only a read right

is passed from one participant to another participant

but that a resource is copied from one workspace to

another. Every resource which is copied this way is

recorded in a table which is part of the access control

mechanism. This sharing table can be seen as a his-

tory for resources and their provenance in a network

of participants. Especially, sharing of workﬂows is of

interest because they contain much procedural knowl-

edge. The sharing table (see bottom of Figure 7)

allows tracing the provenance of workﬂows. This

serves several purposes. First, in case that workﬂows

contain illegal data or an user misuses the system, it

allows us to deactivate all undesired resources and

their copied derivations in the cloud-based WfMS.

Second, in the scenario of personal/social workﬂows

org et al., 2012) people can see if their workﬂows

are reused. Socializing, besides communication, is

the most important motivational factor for using so-

cial network sites (Brandtzæg and Heim, 2009) and

approval and feedback of other people are part of so-

cializing. The opportunity to see who is not only read-

ing my work but also reusing it, is known as feedback

mechanism (Bellotti and Sellen, 1993). This mech-

anism leverages the access control model to a more

transparent model in which a user not only knows to

whom resources are passed, but also who is reusing

the resources.

In the following the process of sharing a workﬂow

prototype is shown in an example, in which user A

wants to share a workﬂow prototype with user B.

Figure 5: Sharing a workﬂow prototype - part I.

Figure 6: Sharing a workﬂow prototype - part II.

In Figure 5, user A has a workﬂow prototype in a

folder of his/her workspace. Only User A has read

and write access to the folder and to the workﬂow pro-

totype. User B cannot see anything else than his/her

own workspace. In Figure 6, user A has given the

read right for the workﬂow prototype and its parent

folder to User B. For User B the readable folder and

the workﬂow appear in a space for readable resources.

In Figure 7, user B decides to reuse the workﬂow pro-

totype. Therefore it needs to be copied in his/her own

workspace. A new workﬂow prototype is created,

which is owned by User B and which is not visible

for User A. User A gets feedback about this through

access to the provenance information.

6.2 Collaborative Workﬂow Modeling

The access control mechanism allows collaboration

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

270

Figure 7: Sharing a workﬂow prototype - part III.

on different levels. Not only workﬂows can be edited

collaboratively but also all logical structures which

are based on the resource group. So an owner can give

write access to a folder to different participants. Then,

each of these participants must also get the write right

to all workﬂows which are organized below the con-

cerned logical structure. If such a write-released re-

source is modiﬁed by inserting a new resource, the

access rights must also be assigned to the owner of

the parent structure and all participants which have

write rights to the parent structure.

Figure 8: A collaboration example.

Figure 8 shows an example for collaboration. The

workspace owner, User A, has granted User B read

and write rights to ’Folder 1’. Thus, User B has read

and write access to all resources within this folder, i.e.

’workﬂow prototype 1’. User B may create ’work-

ﬂow prototype 2’ in ’Folder 1’ because she/he has a

write right. User B is not the owner of the new work-

ﬂow prototype but she/he has the inherited rights of

’Folder 1’ to the new workﬂow. Then, both users can

collaboratively model ’workﬂow prototype 2’.

6.3 Issues on Copying Workﬂows

The invitation of participants for a desired collabora-

tion on the design of a workﬂow and the process of

sharing a workﬂow are quite similar processes up to

the point where a new workﬂow prototype is created.

In both situations at least a read right to the workﬂow

is granted to another participant. This read right is

the authorization to see all data and tasks in the work-

ﬂow. However, because of the possible connection of

human tasks with participants through the execution

assignment, the visibility of allowed or assigned par-

ticipants must be restricted. This problem is similar

to information leakage in Service Oriented Architec-

tures and Cloud-Services. The resource model can

handle this issue, because there is a access right re-

lationship between participants (see Figure 3). If a

workﬂow is readable for other participants the assign-

ment on human tasks is only visible for them if there

is an explicit read right between these participants and

the participants in the assignment.

7 DISCUSSION

Due to the extent of this paper, some issues of the re-

source model and the access control mechanism can-

not be discussed: The modeling and access of hierar-

chical workﬂows and the reuse of workﬂow instances

requires a version management for the produced data

during the runtime, especially in the context of ag-

ile workﬂows (Minor et al., 2008). Of course, col-

laborative workﬂow modeling also requires a lock-

mechanism to avoid read-write conﬂicts.

The access control mechanism described in the

paper is fully implemented in the CAKE system; an

appropriate graphical user interface that enables to as-

sign rights to resources in the manner described is

currently under development. Future work will par-

ticularly include an empirical evaluation of the CAKE

cloud-based workﬂow management system, including

the sharing and collaboration features.

The problem of access control and security issues

is also widely known in the ﬁeld of SOA. The ac-

cess control mechanism in this work is based on the

identity of a user and in a ﬁrst step it cannot meet

the requirements to fulﬁl Service Level Agreements,

a trustworthy service invocation or can guarantee au-

tomatically compliance to public or internal policy re-

quirements. Though, the ﬁeld of SOA has a bigger

AResourceModelforCloud-basedWorkflowManagementSystems-EnablingAccessControl,CollaborationandReuse

271

scope. Inter-organizational processes and heteroge-

neous IT-infrastructures are not yet in the focus of the

CAKE system.

ACKNOWLEDGEMENTS

This work is part of the WEDA project. WEDA is

funded by Stiftung Rheinland-Pfalz f

ur Innovation,

grant no. 974.

REFERENCES

Bellotti, V. and Sellen, A. (1993). Design for privacy

in ubiquitous computing environments. In ECSCW,

pages 75–.

Bergmann, R., Fremann, A., Maximini, K., Maximini, R.,

and Sauer, T. (2006). Case-based support for collabo-

rative business. In Roth-Berghofer, T., G

oker, M. H.,

and G

uvenir, H. A., editors, Advances in Case-Based

Reasoning, 8th European Conference, ECCBR 2006,

Fethiye, Turkey, September 4-7, 2006, Proceedings,

volume 4106 of LNCS, pages 519–533. Springer.

Bergmann, R. and Gil, Y. (2011). Retrieval of semantic

workfows with knowledge intensive similarity mea-

sures. In Case-Based Reasoning. Research and De-

velopment, 19th International Conference on Case-

Based Reasoning, ICCBR 2011, volume 6880 of

LNCS, pages 17—31. Springer.

Brandtzæg, P. and Heim, J. (2009). Why people use so-

cial networking sites. Online Communities and Social

Computing, pages 143–152.

Chinthaka, E., Ekanayake, J., Leake, D., and Plale, B.

(2009). Cbr based workﬂow composition assistant.

In Services - I, 2009 World Conference on, pages 352

–355.

Coalition, W. M. (1999). Terminology and glossary.

http://www.wfmc.org/standards/docs/TC-1011 term

glossary v3.pdf. [Online; accessed 14-Nov-2012].

Downs, D., Rub, J., Kung, K., and Jordan, C. (1985). Issues

in discretionary access control.

org, S., Bergmann, R., Minor, M., Gessinger, S., and

Islam, S. (2012). Collecting, reusing and executing

private workﬂows on social network platforms. In

WWW’12 Workshop Proceedings.

Lindgaard, G., Dudek, C., Sen, D., Sumegi, L., and Noo-

nan, P. (2011). An exploration of relations between vi-

sual appeal, trustworthiness and perceived usability of

homepages. ACM Transactions on Computer-Human

Interaction (TOCHI), 18(1):1.

Liu, X., Yuan, D., Zhang, G., Li, W., Cao, D., He, Q., Chen,

J., and Yang, Y. (2011). The Design of Cloud Work-

ﬂow Systems. SpringerBriefs in Computer Science.

Springer.

Madhusudan, T., Zhao, J., and Marshall, B. (2004). A case-

based reasoning framework for workﬂow model man-

agement. Data and Knowledge Engineering, 50(1):87

– 115. Advances in business process management.

Minor, M., Bergmann, R., and G

org, S. (2011). Adaptive

workﬂow management in the cloud - towards a novel

platform as a service. In Proceedings of the ICCBR

2011 Workshops, pages 131—138.

Minor, M., Bergmann, R., G

org, S., and Walter, K. (2010).

Towards case-based adaptation of workﬂows. In

Montani, S. and Bichindaritz, I., editors, Case-Based

Reasoning. Research and Development, 18th Interna-

tional Conference on Case-Based Reasoning, ICCBR

2010, Alessandria, Italy, July 19-22, 2010. Proceed-

ings, LNAI 6176, pages 421–435. Springer.

Minor, M. and G

org, S. (2011). Acquiring adaptation cases

for scientiﬁc workﬂows. In Case-Based Reasoning.

Research and Development, 19th International Con-

ference on Case-Based Reasoning, ICCBR 2011, vol-

ume 6880 of LNCS, pages 166–180. Springer.

Minor, M., Schmalen, D., Kempin, S., and Kempin, S.

(2009a). Demonstration of the agile workﬂow man-

agement system cake ii based on long-term ofﬁce

workﬂows. In BPM (Demos).

Minor, M., Schmalen, D., and Koldehoff, A. (2009b). Fall-

studie zum einsatz agiler, prozessorientierter metho-

den in der chipindustrie. In Hansen, H. R., Kara-

giannis, D., and Fill, H.-G., editors, Business Ser-

vices: Konzepte, Technologien, Anwendungen, 9. In-

ternationale Tagung Wirtschaftsinformatik, 25. - 27.

Februar 2009, Wien, volume 1, pages 193 – 201.

Oesterreichische Computer Gesellschaft.

Minor, M., Tartakovski, A., Schmalen, D., and Bergmann,

R. (2008). Agile workﬂow technology and case-

based change reuse for long-term processes. Inter-

national Journal of Intelligent Information Technolo-

gies, 4(1):80–98.

Reichert, M. and Dadam, P. (1998). Adept ﬂexsupporting

dynamic changes of workﬂows without losing control.

Journal of Intelligent Information Systems, 10(2):93–

129.

van Der Aalst, W., Ter Hofstede, A., Kiepuszewski, B., and

Barros, A. (2003). Workﬂow patterns. Distributed and

parallel databases, 14(1):5–51.

Walter, K., Minor, M., and Bergmann, R. (2011). Workﬂow

extraction from cooking recipes. In Diaz-Agudo, B.

and Cordier, A., editors, Proceedings of the ICCBR

2011 Workshops, pages 207–216.

Weber, B. and Wild, W. (2004). An agile approach to

workﬂow management. Proceedings of Modellierung

2004, pages 187–201.

Wright, P., Wallace, J., and McCarthy, J. (2008). Aesthetics

and experience-centered design. ACM Transactions

on Computer-Human Interaction (TOCHI), 15(4):18.

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

272