IEEE TRANSACTIONS ON SERVICE COMPUTING 1 ...web.science.mq.edu.au/~qsheng/papers/tsc-bourne-2018.pdfCloud comput-ing has become a popular paradigm for delivering a wide range of services,

1939-1374 (c) 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for moreinformation.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TSC.2017.2667662,IEEE Transactions on Services Computing

IEEE TRANSACTIONS ON SERVICE COMPUTING 1

Transactional Behavior Verification inBusiness Process as a Service Configuration

Scott Bourne, Claudia Szabo, Member, IEEE , Quan Z. Sheng, Member, IEEE

Abstract—Business Process as a Service (BPaaS) is an emerging type of cloud service that offers configurable and executablebusiness processes to clients over the Internet. As BPaaS is still in early years of research, many open issues remain. Managingthe configuration of BPaaS builds on areas such as software product lines and configurable business processes. The problem hasconcerns to consider from several perspectives, such as the different types of variable features, constraints between configurationoptions, and satisfying the requirements provided by the client. In our approach, we use temporal logic templates to elicittransactional requirements from clients that the configured service must adhere to. For formalizing constraints over configuration,feature models are used. To manage all these concerns during BPaaS configuration, we develop a structured process thatapplies formal methods while directing clients through specifying transactional requirements and selecting configurable features.The Binary Decision Diagram (BDD) analysis is then used to verify that the selected configurable features do not violate anyconstraints. Finally, model checking is applied to verify the configured service against the transactional requirement set. Wedemonstrate the feasibility of our approach with several validation scenarios and performance evaluations.

Index Terms—Business Process as a Service, formal methods, verification, transactional requirements, model checking

F

1 INTRODUCTION

In recent years, cloud services have had dramaticimpacts in both the research [1] and industry [2] land-scapes of service-oriented computing. Cloud comput-ing has become a popular paradigm for delivering awide range of services, such as software applications,computing capacity, storage, and virtual platforms [3].Cloud service providers can offer these utilities toclients over the Internet in a pay-by-use manner. Thedistinctive properties of cloud services include:

• On-demand availability through public or privatenetwork access, most commonly the Internet [3].

• Utilization of pooled resources such as servers,applications, CPU time, or storage.

• Dynamic response to workload by elastically pro-visioning and releasing resources [3][4].

• Configurability of service behavior of propertiesto meet individual client requirements [5][6][7].

The traditional hierarchy of cloud service typesis comprised of three layers, where each layer canprovide the base (infrastructure or platform) for run-ning services within the layer above [3]. Infrastruc-ture as a Service (IaaS) is the bottom service layer,providing access to virtualized physical resources,such as storage and computation capacity. Computingcapacity offered by Amazon EC21 or IBM SmartCloud

• S. Bourne and C. Szabo are with the School of Computer Science, theUniversity of Adelaide, SA 5005, Australia.E-mail: {scott.bourne, claudia.szabo}@adelaide.edu.au

• Quan Z. Sheng is with the Department of Computing, MacquarieUniversity, NSW 2109, Australia. E-mail: [email protected]

1. https://aws.amazon.com/ec2/

Enterprise+2 are examples of IaaS offerings. Platformas a Service (PaaS) provides access to utilities such assoftware development and hosting frameworks. Forexample, Google App Engine3 and Microsoft Azure4

both contain PaaS features for web application de-velopment and hosting. Finally, Software as a Service(SaaS) are software applications deployed in a waythat is Internet accessible, automatically scaling, andmulti-tenant. SaaS enables clients to remotely use soft-ware complex systems, such as customer relationshipmanagement through Salseforce5.

A proposed fourth layer of the cloud service archi-tecture residing above SaaS has been in the form ofBusiness Process as a Service (BPaaS), which has had in-creasing research interest in recent years [8][9][10][11].The driving idea behind BPaaS is to mash-up servicesfrom numerous providers into a business processstructure, which can then be offered to clients as itsown service. BPaaS providers will naturally targetcommon or proven business processes that apply toa large potential market, or require management ofseveral complex components. This is appealing toclients as it provides a low-cost, low-risk outsourceoption for integral business operations.

Figure 1 shows an abstract example that demon-strates the structure and variety of services and re-sources that a BPaaS can utilize. In this example,the BPaaS is composed of heterogeneous componentservices from the service provider and third parties.Two SaaS services (i.e., SaaS 1 and SaaS 2) used by the

2. http://www-07.ibm.com/au/managed-cloud-hosting/3. https://cloud.google.com/appengine/docs4. https://azure.microsoft.com/en-gb/5. www.salesforce.com/au/




Fig. 1. An abstract BPaaS example

BPaaS are hosted and managed by the same provider.Private internal software exclusive to the BPaaS is alsorequired. Two of the SaaS services are from externalsources - SaaS 3 is from a third party, while SaaS 4 isanother service of the BPaaS provider, but hosted onan external PaaS.

Configurability is a key property for BPaaS, similarto all services in the cloud hierarchy. The use ofconfigurable business processes can affect the actualproperties of the business process, such as the work-flow structure [12][13], resources used [14][15], andvariables [16]. In contrast, the use of configurableBPaaS, due to their service-based nature, ensures thatclients can align BPaaS services with their internalbusiness operations and policies, while providers canexploit economies of scale by offering their serviceto a larger potential market. Moreover, BPaaS intro-duces third-party services and with this additionaltransactional concerns when compared to traditionalconfigurable business process mainly stemming fromthe fact that transactional requirements will span morethan one service provider and will have to adhereto various provider constraints. The inclusion of theclient’s perspective to the traditional configurablebusiness process paradigm by allowing the client toconfigure more than just selected features or controlflow variations makes BPaaS services appealing toa variety of client types [8][9][10][11], while at thesame time introducing challenges as discussed below.For example, some business clients may have internalsystems already in place to handle certain steps, whilesmaller businesses may outsource these services.

However, when a BPaaS has a large number ofconfigurable components, the verification that the be-havior is correct and/or meets client requirementscan be challenging, as state space explosion hin-ders the verification of large models [17][18], andthe requirements provided by clients can be com-plex [19]. Existing approaches in managing businessprocess configuration ensure domain constraints overconfiguration choices, while allowing basic client re-

quirements such as selected features or control flowvariations. One area that has yet to receive researchattention is ensuring both domain constraints and clienttransactional requirements during BPaaS configuration.These requirements can include conditions for accept-able process commit or abortion, required recoveryoperations for key activities, or valid forms of processcompensation, and are difficult to verify in a cloud-based scenario where multiple stakeholders are in-volved. A configuration method that ensures complexrequirements within a feasible runtime will be ableto provide service clients with increased trust foroutsourcing potentially sensitive business operations.

To address these problems, we propose a three-stepconfiguration and verification process which relies ona modeling paradigm. Such paradigm allows us tocapture transactional requirements and subsequentlyverify them. Our approach is expressive and relativelyeasy to use by stakeholders, while at the same timebeing sufficiently rigorous to allow us to apply formalmethods for verification.

The remainder of this paper is organized as fol-lows. Section 2 provides the details of our config-urable BPaaS model, with formalization of domainconstraints and client transactional requirements. Aconfiguration process outlined in Section 3 appliesformal methods to these models to determine a config-uration solution. Section 4 contains a report of our im-plementation, validation scenarios, and performanceanalysis with large models. Section 5 discusses futuredirections for our work. Finally, Section 6 overviewsthe related research and Section 7 provides someconcluding remarks.

2 TRANSACTIONAL BPAAS MODELING

Before transactional requirements can be verified, theyneed to be modeled within the BPaaS context. Tobetter illustrate our approach, we consider the sce-nario of a configurable Web store checkout BPaaS. Theclients of this process will be small and medium sizedWeb stores, while the users will be customers. ThisBPaaS targets businesses selling physical or digitalgoods, as standard orders or pre-orders. The processplaces shipping orders for physical goods and re-trieves download links for digital goods. Specific tasksin the process include validating customers, obtainingpayment details, updating inventory and accountingsystems, and processing customer payment amongstothers. Clients can configure the structure of thisprocess to suit their business requirements. For ex-ample, stores only selling digital goods can removeall tasks related to product shipping, while stores thatdo not store customer details can restrict the processto handling unregistered guest customers.

This process provisions both constant and config-urable external resources. Examples of configurableresources include the optional payment services used




A

B

A

B

A

B1 B2

A

B1 B2 A B A B

Mandatory Optional OR XOR Implication Exlcusion

Fig. 2. Feature model constraints used in our approach

by the BPaaS, such as Paypal6, or Epoch7 and eWay8

credit card transactional managers. Data objects canalso be configured as appropriate, such as includingor excluding fields in customer and product details.

2.1 Modeling Domain ConstraintsDomain constraints are rules that allow providersto restrict BPaaS configuration to valid choices. Forexample, several credit card transaction managementresources may be available for a given payment oper-ation, but at least one must be selected in any config-uration. Our BPaaS modeling approach adapts featuremodels from the software product line engineeringdomain [20]. Feature models are tree-like structuresbeing able to express domain constraints formally andvisually. Typically, feature models are used to expressvariability in a configurable system, by modeling theconstraints between optional features. In our approach,we adapt them to formalize constraints between theconfigurable activities, resources, and data objects ofa BPaaS. Furthermore, by using one feature model todefine all BPaaS domain constraints, we are able todefine constraints that cross these configuration per-spectives. For example, certain configurable activitiesmay require the selection of specific resources.

We apply six feature model relationship structures,shown in Figure 2, to model domain constraints. Thefirst four relationships apply to one or more leaffeatures if the head feature is selected. For example,the Mandatory and Optional structures define that iffeature A is selected, then feature B is essential oroptional respectively. Implication and Exclusion canbe defined between any two features in the model,regardless of their level in the tree structure.

A feature model capturing the domain constraintsfor the configuration of the checkout BPaaS is shownin Figure 3. The root Checkout Service featurecontains all other features as children, and allows con-straints to cross between activity, resource, and dataobject perspectives. For example, Validate Loginis an optional feature, but it requires RegisterUser, Retrieve User Details, either PrivateCustomer Repository or Provider Storage,and enables Store Payment Details to be se-lected. A selection of features that satisfy all con-straints in this model, therefore conforming to allconfiguration requirements of the provider, is a validconfiguration of the BPaaS.

6. https://developer.paypal.com/7. https://www.epoch.com/en/index.html8. http://www.eway.com.au/developers/api/overview

Fig. 4. BPMN model of the configurable checkoutBPaaS

TABLE 1Configurable resources for the BPaaS

Resources Activities

Private Inventory System, Mi-croguru

Update Inventory, Hold Order,Hold Product, Release Order,Release Product

International Shipping, Toll Pri-ority, AusPost, Client Notifica-tion

Place Shipping Order

Provider Storage, Private Cus-tomer Repository

Store Payment Details, Validate Lo-gin, Confirm Shipping Details, Reg-ister User, Store Shipping Details

Private Accounting System,SaaSu Update Accounts

External Cloud Storage, Exter-nal Server, Provider Storage Retrieve Download Link

FTP, FTPS Transfer File

2.2 Modeling Activities and Control Flow

We use BPMN for modeling activities and controlflow, as it formalizes the BPaaS structure while re-maining easily readable for clients (see Figure 4 forcheckout BPaaS). Furthermore, BPMN is a widelyused notation for formalizing and executing businessprocesses, which increases the potential client andprovider base of our approach. Configuring BPMNis also less complex than alternatives such as C-EPC,as the alternation events and functions does not needto be maintained [16].

Numerous activities in the checkout BPaaS utilizeconfigurable resources and data objects, which areshown in Tables 1 and 2 respectively. The configurable




Record Fraud

Report

Initiate Order

Initiate Pre-Order

ReleaseProduct

HoldProduct

ReleaseOrder

HoldOrder

MicroguruPrivate

InventorySystem

SaaSuPrivate

AccountingSystem

eWay Epoch Paypal ValidateLogin

DigitalProductDetails

PhysicalProductDetails

RetrieveUser

Details

StorePaymentDetails

RegisterUser

PrivateCustomerRepository

ProviderStorage

CustomerRepository

PaymentDetails

PhysicalProductDetails

ShippingAddress

ObtainShippingDetails

PlaceShipping

Order

QuantityConfirmShippingDetails

AusPostToll

PriorityInternational

ShippingClient

NotificationStore

ShippingDetails

DigitalProductDetails

RetrieveDownload

Link

TransferFile

ExternalCloud

Storage

ExternalServer

ProviderStorage

Checkout Service

Fig. 3. Feature model of the domain constraints of our example BPaaS

TABLE 2Configurable data objects for the BPaaS

Data Objects ActivitiesPhysical Product De-tails, Digital ProductDetails, Quantity

Initiate Order, Initiate Pre-Order

Shipping AddressStore Shipping Details, Place Shipping Order,Obtain User Details, Retrieve User Data, Ob-tain Shipping Details

Payment Details Process Payment, Retrieve User Data, ObtainUser Details, Reconfirm Payment Information

resources include Microguru9 for inventory manage-ment, SaaSu10 for accounting, and FTP or FTPS fordigital product file transfer. Cloud storage is offeredby the provider for a customer repository and digitalproduct hosting. Data object configurability includesphysical and digital product details, enabling productquantities, and payment and shipping details.

2.3 Modeling Transactional RequirementsWhile BPMN provides lifecycle statecharts that rep-resent the transactional state of individual activi-ties, a view of the transactional state of the entireprocess is necessary for verification against process-level transactional requirements. Such requirementsinclude specifying the activities critical for success-ful execution, necessary activities to execute prior toaborting, or requirements for valid process compensa-tion. We adapt the separated behavior model of ourprevious work in transactional Web service compo-sitions [19], and use a transactional behavior model torepresent the global transactional state of the process.

The transactional behavior model of the BPaaS isrepresented using a statechart, as shown in Figure 5.This model contains various transactional states theBPaaS can be in at a given point, from prior to acti-vation by a client (Not Activated), to termination

9. http://www.microguru.com/10. http://www.saasu.com/

[Condition]

Action

Sync

[Fail]

[Fail]

[Success]

[Success]

Recover

[Fault]

Recover

[Syncreq | Fault | timeout]

Sync[Syncreq]

[Syncreq]Sync

[cannot retry]

Not Activated

Activated

Suspended

Done

Rollback

Aborted

Compensated

Fig. 5. Transactional behavior model of the BPaaS

through the Done, Aborted, or Compensated states.A Compensated state occurs after the effect of anoperation is undone through a successful Rollback.

Cloud service providers can indicate changes in thetransactional state of the BPaaS by modeling inter-behavior messages [19] between transactional behaviorstates and BPMN activities. These messages are ex-changed between the transactional and BPMN activitymodels and are used for their coordination and tofacilitate transactional behavior verification:

• Sync to trigger an activity execution,• Recover to initiate activities for fault recovery,• Delay to indicate that an unacceptable delay has

occurred during execution,• Ping to test the liveness of an activity,• Success to commit a successful execution of the

BPaaS,• Fail to abort execution,• Syncreq to request a Sync message for retrial

following a fault or recovery,• Fault to indicate the presence of a fault that

requires recovery, and• Ack to acknowledge a received Ping message.

Figure 6 shows an example of how the controlbehavior model can direct and communicate withthe checkout BPMN using inter-behavior messages.In this conversation session, the process becomes sus-pended after processing payment fails, but the processis able to commit successfully after the user is askedto reconfirm their payment information.




Activated Suspended

Prepare Order

ProcessPayment

Not Activated

Sync Syncreq

Control Behavior

Checkout BPMN

Reconfirm Payment

Information

Activated Done

ConfirmOrder

Sync Success

... ...

Fig. 6. Inter-behavior messages enabling communica-tion between BPMN and transactional behavior models

1. BDD Analysis2. Model CheckingActivity Selection

3. Model CheckingResource and Data Objects

Feature SelectionTransactionalRequirementTemplates

ImplementedTemplates



ReconfigureReconfigure

BPaaS Provider

Client

Configuration and Verification Process

TransactionalRequirements



BPMN ModelFeature ModelConfigurationSolution

Desired Features

Configure

Fig. 7. Overview of the BPaaS configuration andverification process

Transactional requirements can be used by clientsto ensure that provisioned BPaaS conform to theirexpected behavior and internal business rules. Theserequirements can include specifying satisfactory re-covery operations for certain critical activities, con-ditions for compensating the process, or valid statesfor aborting execution.

We adapt our work in verifying Web service compo-sitions against developer transactional requirements[19]. This approach allows common or useful trans-actional requirements to be formalized using tempo-ral logic templates, in order to reduce human errorand effort. Our proposed template set is dividedinto component-level and composition-level, as shownin Table 3. Component-level templates are used forrequirements specific to individual activities, whilecomposition-level templates apply to the transactionalbehavior of the entire BPaaS.

3 CONFIGURATION AND VERIFICATION

In this section, we propose a BPaaS configuration pro-cess that applies formal methods to ensure that i) theconfiguration is valid with respect to provider domainconstraints, and ii) the process satisfies transactionalrequirements drawn from the business rules of theclient. First, we provide an overview of the processwhich guides clients through BPaaS configuration,then we provide details on how Binary Decision

Diagram (BDD) analysis and model checking are usedat certain steps.

The structure of our configuration and verifica-tion process is shown in Figure 7. The aim of thisprocess is to produce a configuration solution thatsatisfies transactional requirements provided by theclient while respecting domain constraints. Our con-figuration process applies formal methods and simpleclient interaction to identify a configuration that i)is valid with respect to domain constraints, and ii)conforms to the client transactional requirements set.This increases client trust that the service will behavein a manner consistent with internal business policiesand requirements, without having to perform theirown analysis of the service behavior. The BPaaS clientprovides the following input:

• Transactional Requirements: A specification on thefine-detailed transactional behavior that they re-quire the business process to conform to.

• Desired Features: Additional configurable activi-ties, resources, and data objects.

The service provider provides the following input:• Feature Model: A formalization of the domain

constraints for valid BPaaS configurations.• BPMN Model: A BPMN model of the complete

configurable BPaaS with associated resources,data objects, and transactional behavior model.

Our configuration process uses a series of tasks andformal methods, as shown in Figure 7:

• Transactional Requirement Templates: The templatesshown in Table 3 for specifying transactionalrequirements.

• Implemented Templates: The requirements imple-mented using the templates and mapped to con-crete temporal logic properties.

• Feature Selection: A task where the client selectsconfigurable features of the BPaaS from the fea-ture model. This is used to add features to theconfiguration, or adjust the BPaaS behavior fol-lowing failed verification.

• BDD Analysis: Verifies that the domain con-straints are not violated, given a feature modeland a selection of features.

• Model Checking Activity Selection: Formally verifiesthe activity structure of the BPaaS against theformalized transactional requirements, with theexception of requirements with resource and dataobject concerns.

• Model Checking Resources and Data Objects: For-mally verifies the complete BPaaS model againstthe transactional requirements with resource ordata object concerns.

3.1 BDD Analysis

The first verification step in our approach identifies allfeatures required for the client transactional require-




TABLE 3Component-level and Process-level Transactional Requirement Templates

Type Template Description

Component-

CompensateFailure

Specifies an activity and a condition. The failure of the activity requires the condition to be satisfied in thefuture, in order to recover from the failure.

level

CompensateSuccess

Specifies an activity, and a condition that semantically undoes the effect of the completed activity. Whenthe execution of the process must be aborted or compensated, the nominated condition must be satisfied toconfirm that the activity has been undone.

Alternative Following the failure of an activity, one or several alternative activities are considered acceptable replacements.NonRetriable Following failure of an activity, retrial is either not possible, or the client is not interested in it.

RetriablePivotSpecifies an activity that may be retried, but not undone. Following its successful completion, the servicemust commit.

NonRetriablePivot

Specifies an activity that may not be retried or undone. The service must commit or abort depending on theactivity’s success.

Process-

TransactionalStateCritical

A condition that must be satisfied prior to entering a certain transactional state.

level

TransactionalStateTrigger

A condition that must trigger the entering of a transactional state in the future.

TransactionalStateReachable

A condition that indicates that a transactional state is reachable.

TransactionalStateUnreachable

A condition that indicates that a transactional state should not be reachable in the future.

CompensationSpecifies a condition that must be met during any compensation process. A compensation process is anactivity or series of activities to undo an execution of the service that has committed.

ConditionalCompensation

Specifies a condition for compensation and a condition for execution, such that the compensation conditiononly applies when the execution condition has been satisfied previously.

TABLE 4Propositional logic representations of the feature

model constraints of Figure 2Constraint Propositional LogicMandatory A ↔ B

Optional B → AOR A ↔ (B1 ∨ B2)

XOR (B1 ↔ (¬B2 ∧ A)) ∧ (B2 ↔ (¬B1 ∧ A))Implication A → BExclusion ¬(A ∧ B)

ments, and determines whether they can all be se-lected while satisfying the feature model constraints.This implies that at least one valid configuration mustexist using the activities, resources, and data objectsspecified in the requirements set, or extra features re-quired by the client. We employ BDD-based analysis,which has been proven as an effective method fordetermining feature model satisfiability [21].

A BDD is an acyclic graph visualization of a propo-sitional logic formula. Variables of the formula arerepresented as nodes with two outgoing branches,indicating their true or false assignment. The graphis constructed in such a way that each completepath from head node to terminal node representsthe assignment of boolean variables. All paths termi-nate at a final true or false node, which determineswhether the variable assignments of that path satisfythe propositional logic formula.

Our analysis transforms the feature model withselections into a propositional logic formula, theninto a BDD which can be checked for satisfiability. Afeature model can be transformed into a propositionallogic formula according to the constraint conversionsin Table 4. We use the JDD library11 to automaticallyconstruct BDDs from these propositional logic formu-las to check their satisfiability.

Figure 8 shows an example of the transformation

11. http://javaddlib.sourceforge.net/jdd/index.html

RetrieveDownload

Link

TransferFile

ExternalCloudStorage

ExternalServer

ProviderStorage

(a)

(b)

(c)

Fig. 8. A selection of domain constraints as a featuremodel (a), propositional logic (b), and a BDD (c)

steps using a part of the checkout feature model.The BDD in Figure 8(c) uses acronyms of featurenames for space considerations, and 0 and 1 nodesfor the false and true respectively. A solid line from anode indicates true assignment, while a dashed lineindicates false. By traversing solid lines from selectedfeatures, and dashed lines from unselected features,the 1 and 0 nodes indicate whether the preceding pathwas a valid or invalid selection. The steps in the BDDanalysis module in our BPaaS configuration processare:

1) Select all features included in the transactionalrequirements set,

2) Select any extra features specified by the client,3) Automatically select all target features of

mandatory relationships from those already se-lected,

4) Verify that all XOR relations with a selectedparent feature have exactly one feature selected,

5) Verify that all OR relations with a selected parenthave one or more features selected,

6) Construct propositional logic property fromdepth-first traversal of feature model,

7) Append selections to property with ∨ operators,




8) Construct Binary Decision Diagram from prop-erty using JDD library,

9) Verify that BDD has a reachable true node.BDD analysis is able to efficiently solve satisfiability

problems, but the size of the BDD dependent on vari-able ordering in the underlying propositional logicproperty. While finding the most efficient ordering isan NP-complete problem [21], ordering variables froma depth-first traversal of the feature model has beenapproved as an effective strategy [22]. Therefore, weadopt this approach in our work when transformingthe feature model to propositional logic.

3.2 Model CheckingModel checking [23] is a formal method that exhaus-tively verifies that the behavior of a given modelconforms to a set of properties. We use the NuSMVmodel checker [24] to verify BPaaS configurationsagainst the temporal logic forms of conversation rulesand transactional requirements. Our verification usesthe symbolic BDD-based model checking feature ofNuSMV. This constructs BDDs from the input modelto apply several verification techniques, including fairCTL model checking and LTL model checking (byan algorithm that reduces the problem to CTL modelchecking). We use NuSMV as it provides support forproperties formulated in both LTL and CTL.

As model checking is an exhaustive technique, itis subject to the state space explosion problem, inwhich the state space of the system under verifica-tion increases exponentially in relation to the num-ber of processes and variables. This greatly impactsverification time and feasibility for complex models.Therefore, prior to verifying BPaaS configurations, weaim to reduce their state space as much as possible.We employ two approaches to curb the impact of statespace explosion during BPaaS configuration:

• Applying model checking in two phases, reduc-ing the complexity and size of the model andtransactional requirements for each phase. Eachphase aims to verify a different configurationperspective, namely, activity selection, and resourceand data object selection. These phases also allowthe client to focus on each perspective separately.This simplifies the configuration process, espe-cially when configuring a service with a largenumber of features: if a requirement has no spec-ification of resources and data objects, it onlyneeds verification during activity selection.

• Reducing state space prior to model checkingby transforming the model into a minimal Kripkestructure [25]. Kripke structures are concise rep-resentations of system events and are commonlyused in formal verification. A Kripke structure isa finite-state system model with a directed graphstructure, where each node represents a systemstate where one or more properties are satisfied.

Initiate OrderActivated

Hold ProductActivated

Validate LoginActivated

Register UserActivated

Release ProductRollback

Retrieve User DataActivated

Store Payment DetailsActivated

Retrieve Download LinkActivated

Transfer FileActivated

Commit OrderDone

BPMN ActivityTransactional State

Atomic Propositions

Fig. 9. Kripke structure example for verifying theactivity selection

We formally define a Kripke structure as K =⟨Sk, T k,L⟩, where Sk is a finite set of states, I ⊆ Sk isthe set of initial states, Tk ⊆ Sk × Sk is the transitionfunction, and L is the labelling function that assignsatomic propositions to each state. Atomic propositionsare the unique set of properties that are true for eachstate. For transactional requirement verification, theset of complete atomic propositions AP contains theactivities, resources, data objects, and transactionalstates included in the implemented templates pro-vided by the client. Figure 9 shows the Kripke struc-ture generated to verify the single requirement thatRetrieve User Data or Register User is neces-sary before entering the Done transactional state. Theatomic propositions included in this Kripke structurecontain the activities and transactional state necessaryfor verifying the requirement.

The algorithm to generate these minimal Kripkestructures is adapted from our previous work inverifying transactional Web service compositions [19].Kripke structures are generated by i) identifying theatomic propositions that must be included in thestructure, and ii) traversing the BPaaS model in adepth-first order, constructing the structure as thoseproperties are encountered. All configurable featuresincluded in the model are also included in the Kripkestructure, in order to help the client revise violatingbehavior with reconfiguration.

Initiate OrderActivated

-Digital Product Details

Hold ProductActivatedMicroguru

-

Process PaymentActivated

eWayPayment Details

Process PaymentActivatedPayPal

Payment Details

Release ProductRollback

Microguru-

Retrieve Download LinkActivated

Provider Storage-

Transfer FileActivated

FTP-

Commit OrderDone

--

Process Payment.FaultSuspended

--

BPMN ActivityTransactional State

ResourceData Objects

Atomic Propositions

Fig. 10. Kripke structure example for verifying resourceand data object selection




3.2.1 Activity SelectionIn this phase, if a requirement specifies the inclusionof resources or data objects for an activity, only thepresence of the activity in the configured process isverified. This reduces the state space of the processmodel verified by the model checker, simplifies theproperties, and allows the client to focus primarilyon activity configuration. To verify activity selectionagainst transactional requirements, the atomic propo-sitions of interest include configurable activities se-lected from the feature model, and other activities ortransactional behavior states used by the implementedset of temporal logic templates.

Model checking verifies the Kripke structureagainst the temporal logic forms of the client’s trans-actional requirements. If a violation is found, theclient must reconfigure the service by interpreting themodel checking output; otherwise, the second modelchecking phase can be undertaken.

3.2.2 Resource and Data Object SelectionIn this model checking phase, only transactional re-quirements with resources or data objects in theirspecification need to be verified. All other require-ments have been ensured in the activity selectionphase. This phase is necessary because an activitycan have more than one resource provisioned, inorder to defer the selection to the user at runtime.For example, a configuration may include several re-sources for the Process Payment activity, as shownin Figure 10. When verifying the activity selection,Process Payment will be treated as a single state.However, when considering resources, it becomesseveral states in an XOR structure, as the choiceof resource is deferred to runtime. Data objects areassumed to apply to every runtime instance and donot require process restructuring during verification.If a violation is found, the client must reconfigure theservice by interpreting the model checking output.

4 EXPERIMENTAL EVALUATION

We have implemented our BPaaS configuration pro-cess in a prototype toolset. In this section, we providean overview of the implementation, before evaluatingour approach with configuration scenarios and anextensive performance analysis.

4.1 ImplementationFigure 11 shows the architecture of our prototype toolfor BPaaS configuration. The architecture comprises offive modules, which serve the following purposes:

• Client Interface: This provides an interface forBPaaS clients to configure services according toour configuration process.

• Configuration Controller: This controls the steps ofthe configuration process as shown in Figure 7. It

Kripke StructureTransformation

Temporal LogicTemplates

BehaviorInterpreter

Temporal LogicMapping

DefinedTemplates

BDD Analysis

JDDJDDJDD Interface

Configuration Controller

FeatureSelection

VerificationResults

Client Interface

RequirementSpecification

Verification Controller

BPMN Model Feature Model

ConfigurationProcess

Domain ConstraintManager

BPMNConfiguration

SMV Writer NuSMV Interface

Model Checking

NuSMV

Fig. 11. Overview of the implementation architecturefor our BPaaS configuration process

also handles configuration of BPMN models andfeature model interpretation.

• Verification Controller: The steps to implementtemporal logic templates and reduce the BPaaSmodel to a minimal Kripke structure are handledby this module.

• BDD Analysis: The JDD library is used by an in-terface in this module to verify that a selection offeatures does not violate the domain constraints.

• Model Checking: This is a wrapper for the NuSMVmodel checker that handles input parsing, invo-cation, and output interpretation.

4.2 Validation ScenariosTo validate our BPaaS configuration approach, wedemonstrate two scenarios using the Web store check-out service. These scenarios show two clients withquite different transactional and configuration re-quirements, to demonstrate how our configurationprocess is suitable for highly configurable BPaaS.Scenario A: The client is a medium-sized business lookingto expand into online sales with a Web store. The businessoffers physical products only, and does not do pre-orders.Inventory and accounting are to be managed with SaaS (seeFigure 1), but the client has an existing customer repositorythat will be used. Payment may be made with Paypal andeWay services. The business is looking to outsource thecheckout service to an external SaaS provider (SaaS 3 inFigure 1).

This client has provided 8 transactional require-ments that the checkout service must satisfy:SA1: Release Product is necessary prior to

Aborted after Initiate Order withPhysical Product Details.

SA2: Place Shipping Order should alwayslead to Done.

SA3: Update Accounts using SaaSu is neces-sary prior to Done.

SA4: Once the activities Update Accounts,Place Shipping Order, or UpdateInventory have completed, the processcannot abort.

SA5: Obtain Shipping Details is necessaryprior to Done.

SA6: Reconfirm Payment Information orCancel Order must be executed followingthe failure of Process Payment.




Fig. 12. Violating stack trace produced by NuSMV

SA7: Process Payment using Paypal cannotbe undone.

SA8: Process Payment using eWay cannot beundone.

The BDD generated from the domain constraints ofFigure 3 and the configurable activities, resources, anddata objects included in these requirements indicatethat these features selections are valid. In additionto the features specified in these requirements, theclient also selects the additional features AusPost,International Shipping for handling shippingorders, and the Confirm Shipping Details activ-ity to streamline the process for recurring customers.BDD analysis confirms that these selections satisfy thedomain constraints. It should be noted that the sizeand complexity of the BDD generated for this analysisis too large to be included in this paper.

During the activity selection model checking phase,NuSMV identified a Kripke stack trace violating SA5,shown in Figure 12. From analyzing the stack traceand the BPMN structure in Figure 4, it can be de-termined that the inclusion of Confirm ShippingDetails is enabling Obtain Shipping Detailsto be bypassed, thereby violating the requirementthat it is critical for successful execution. In order tocomplete this verification step successfully, the clientcan i) remove Confirm Shipping Details fromthe configuration, or ii) revise the violating require-ment to include it. Following either of these revisions,both model checking phases are successful and aconfiguration solution is identified.

Scenario B: An online music store offers digital down-loads, CDs, and merchandise of local artists, with shippingcurrently restricted to domestic customers. The checkoutprocess must be able to handle pre-order sales of upcomingreleases. Payment must be handled through the owner’sPaypal account, who also maintains customer details, ac-counting, and inventory.

This client provides the following transactional re-quirements for the BPaaS:SB1: For sales that are not pre-orders, Transfer

File or Place Shipping Order must besuccessful before the process commits.

SB2: A receipt must be sent to customers follow-ing every successful sale.

SB3: Customers must be able to re-enter theirPaypal details and retry if payment is ini-tially unsuccessful.

SB4: Process Payment cannot be undone.BDD analysis conducted of the configurable fea-

tures included in this requirement set confirms thatthey are valid with respect to the domain constraintsof the service provider. In addition, the client selectsInitiate Pre-Order, Store Payment Detailsfor configurable activities, Private InventorySystem, Private Accounting System, PrivateCustomer Repository, Provider Storage, andAusPost for resources, and Digital ProductDetails and Physical Product Details fordata objects.

Once these features are added, the constructed BDDis not satisfiable, as this specific selection of featuresviolates the domain constraints. From analyzing thefeature model in Figure 3, we can see that the clienthas omitted Validate Login, but has selected sev-eral features that are directly dependent on it. Theclient plans to handle all customer details manage-ment internally, but the BPaaS requires the security ofa login procedure in order to conduct sales. To satisfythis constraint, the client removes integration witha Private Customer Repository and the StorePayment Details activity from the configuration.This activity and resource will be managed completelyinternally, due to a manageable level of anticipatedcustomers. BPaaS running and provisioning costs mayalso be reduced if a smaller number of features areincluded.

After removing those two features from the con-figuration, BDD analysis passes successfully. Next,the configuration is verified against the transactionalrequirements across our two model checking phases.Both phases are successful, confirming that the con-figured BPaaS model satisfies the domain constraintsand transactional requirement set.

Scenario C: A small software development studio has arange of tools to offer consumers through a Web storeinterface. The products offered by the client are all in theform of digital downloads. Payment must be made usingcredit card. The client already has an accounting systemin place, while inventory management is not required fortheir exclusive focus on digital products. All sales will beprocessed as guest transactions.

The requirements obtained from the client are:SC1: Customer email addresses must be obtained

and verified for the store mailing list.SC2: Once Process Payment has successfully

completed, the sale must be finalized.SC3: Every completed sale must deliver a soft-

ware product to the customer from anExternal Cloud Storage.




In addition to the activities obtained from therequirements set, the client nominates RecordFraud Report and Initiate Order. The con-figurable resources and data objects included areDigital Product Details, SaaSu, ExternalCloud Storage, and Epoch. A concern for thisclient is that the Update Inventory activity is notconfigurable, despite not being relevant to their re-quirements. Provisioning a BPaaS that uses excessiveactivities or resources outside the client’s require-ments may have an impact on the overall serviceperformance or cost. As the domain constraints areunder the control of the provider, it is the client whomust decide if this risk is tolerable for their operations.

If the client persists with the service, by select-ing either the Microguru or Private InventorySystem resources, the configuration is confirmed tobe valid by the BDD analysis. Furthermore, bothmodel checking phases successfully guarantee theirrequirements set.

4.3 Performance AnalysisThere are several reasons that our configuration pro-cess must be able to handle large and complex sce-narios in an efficient way. Firstly, the impact statespace explosion has on model checking performanceis exponential as the size of the model increases.Clients may also have large and complex sets of trans-actional requirements to be verified. Furthermore,model checking may need to be applied by the clientseveral times, if a configuration solution is difficult toobtain. Therefore, long verification times are likely tocompound and become a bigger problem for clients.

4.3.1 Temporal Logic TemplatesThe first step in our performance analysis is to verifythe impact each individual temporal logic templatehas on model checking performance. Table 5 showsthe verification time for minimal Kripke structures,as generated by our Kripke structure reduction algo-rithm, against one requirement specified using eachtemplate. The Scope variable required by every tem-plate is set to Global in each test in order to obtain aneven comparison. These results indicate that the tem-plates with the greatest model checking performancedemand are CompensateSuccess, Alternative,NonRetriablePivot, and Compensation. Ourevaluation utilizes these templates in an even ratio.

4.3.2 BPaaS ConfigurationWe perform two series of performance verificationtests for our BPaaS configuration process. The first setof tests aims to validate the performance benefit of ourapproach using a straightforward model with smallerrequirements sets. The configured BPaaS model con-tains a total of 100 activities (30 configurable), anda combined total of 30 configurable resources and

TABLE 5NuSMV execution times for individual templates

Template NuSMV (ms)CompensateFailure 7.3CompensateSuccess 7.8Alternative 7.4NonRetriable 7.1RetriablePivot 7.2NonRetriablePivot 7.5ControlStateCritical 7.1ControlStateTrigger 7.1ControlStateReachable 6.5ControlStateUnreachable 6.4Compensation 7.4ConditionalCompensation 7.3

Fig. 13. Verification times during configuration with andwithout reduction for 10 to 100 requirements

data objects. This model is a BPaaS that has alreadybeen configured through feature selection, rather thana configurable BPaaS with 100 total possible activi-ties. Using this model, we compare our multi-stepmodel checking approach against a single step modelchecking approach that does not apply any statespace reduction measures. When verifying withoutstate space reduction, the NuSMV input is manuallywritten based on a complete implementation of themodel.

We perform 10 tests, verifying the configured BPaaSmodel given sets of requirements from sizes 10 to 100.The requirements use the same four templates thatare used in the previous section. Figure 13 plots theverification times of both the reduced and unreducedmodels. In the case of unreduced, the verificationtime is determined from the sum of both modelchecking phases, and the applications of the state spacereduction (SSR) algorithm applied at each phase. Theseresults indicate that our approach provides a signifi-cant performance benefit in verification time, and thatthe benefit becomes greater as the requirements setsbecome larger.




TABLE 6Verification time (in seconds) of increasingly complex configuration scenarios

BPaaS Configuration NuSMV with reduction NuSMV withAct. Config. Act. RDO Reqs Act. SSR Act. NuSMV RDO SSR RDO NuSMV Total no reduction

100 30 3025 0.007 0.141 0.006 0.107 0.261 1.52050 0.007 0.308 0.008 0.280 0.603 2.963100 0.008 0.725 0.008 0.599 1.340 6.264

200 60 60100 0.015 0.835 0.015 0.715 1.580 13.512150 0.022 1.324 0.017 0.963 2.326 20.164200 0.023 1.921 0.021 1.591 3.556 28.365

300 90 90200 0.027 2.116 0.022 1.782 3.947 46.538250 0.027 2.775 0.022 2.290 5.114 60.972300 0.030 3.468 0.026 2.788 6.312 73.553

500 150 150300 0.053 4.246 0.042 3.391 7.732 191.103400 0.053 5.861 0.045 4.636 10.595 256.413500 0.057 7.643 0.047 5.963 13.710 323.896

4.4 DiscussionOur work is a first step towards a comprehensiveBPaaS management framework that is capabale ofresponding to changes in the environment and man-aging client transactional requirements. However, sev-eral limitations still exist. Firstly, we recognize that theinterface exposed to the client might have significantcomplexities, which are not easy to tackle by non-system experts. An interface to hide the details andcomplexity of the service aside from the transactionalrequirement specification and feature selection wouldensure that this work is widely used. As BPaaS is stillan emerging technology, this framework especiallyone that enables clients to ensure complex transac-tional requirements, would be a significant contribu-tion to the field. Existing approaches that managecloud service evolution focus on requirements suchas process structure fairness [6], and preserving elas-ticity [11] and multi-tenancy [26]. To the best of ourknowledge, complex properties such as transactionalrequirements are yet to receive attention in this area.The work presented in this article will hopefully pro-vide avenues for addressing a host of opportunitiespresent in the early stages of BPaaS research.

5 RELATED WORK

There is an increasing research interest in relatedareas such as configurable cloud service applications[26][27], and configurable or adaptive business pro-cess models [14][16][17]. Based on our analysis ofrelated work as well as the various uses of BPaaS asoutlined by the scenarios in Section 4, we identify a setof criteria as shown in Table 7, and group them in twocategories, namely, Support, focused on the modelingof the business process, and Correctness, focused onthe verification of process correctness.

The Support criteria is related to the business pro-cess expressiveness enabled by the approach. TheProcess Formalism criterion identifies how the ap-proach expresses business processes. If business pro-cess structures are not explicitly incorporated in theapproach, the value is left blank. The next criteriaspecify whether it is capable of modeling resource and

TABLE 7Comparison criteria overview

Category Criteria Values

Support

ProcessFormalism Petri-nets, BPMN, statecharts

Resources√

or -Data

√or -

DomainConstraints

Feature model, OVM,hierarchy model

Correctness

Process Model Syntax, Soundness, Deadlock-freedom

Criteria Configurability Circular dependency-free,contradiction-free

ClientRequirements

Feature selections, businessrules, QoS parameters

data and configurability. Finally, the means of express-ing domain constraints are identified for comparison.Correctness Criteria identifies the properties that areensured during the configuration or adaptation ap-proach. Process model criteria refers to structural orbehavioral correctness of the process model, such assoundness [28] or syntactical correctness [12]. Someapproaches may also analyze the configurability of themodel to identify issues such as contradictions or cir-cular dependencies [29]. The final criterion identifiesthe client requirements that are input into the process,such as selections of features [5][30], or more complexbehavioral requirements [15].

Approaches to managing cloud service configura-tion has so far mostly focused on SaaS [5][26][30].These approaches share many concerns with BPaaSconfiguration, such as managing domain constraints,and eliciting requirements from clients. The config-urable features of SaaS can include user interface, pro-gram structure, data, access control, and other prop-erties [26][30]. Several approaches have addressedthe problem of evolving multi-tenant SaaS at run-time [5][27][31]. Multi-tenant services are able to han-dle several clients with a single software instance,in a way that prevents any interference between thespecific configurations of each client. As new clientsprovision the service at runtime, the service mustevolve its behavior to meet new requirements, whilestill supporting the existing clients.

While configurable BPaaS is still a new area ofresearch, work in related domains such as config-




TABLE 8Support criteria for comparing work related to BPaaS configuration

Approach Process Formalism Resources Data Domain ConstraintsMietzner et al. [26] -

√ √OVM

Lizhen et al. [30] -√ √

Metagraph relationshipsSchoreter et al. [7] -

√ √QCL Contracts

Banerjee [31] -√ √

Variation pre and post-conditionsKumara et al. [5] -

√ √Feature model

Schroeter et al. [27] -√ √

Extended feature modelMendling et al. [12] C-EPC - - XPath Statementsvan der Aalst et al. [32] Workflow nets - - -van der Aalst et al. [13] Workflow nets, C-EPC - - -Kumar and Yao [15] WS-BPEL

√ √If-then statements

La Rosa et al. [33][16] C-iEPC√ √

Hierarchy modelLa Rosa et al. [29] - - - Configuration ModelWang et al. [34] WS-BPEL

√ √-

van der Aalst [35] C-nets - - C-net bindingsTsai and Sun [36] Customizable workflow

√ √OVM

Liu et al. [6] Petri-nets - - -van Dongen et al. [28] EPC, Petri-nets - - -Groner et al. [14] BPMN

√ √Feature Model

van der Aalst et al. [17] Petri-nets - - -Jiang et al. [37] Dependency structures - - -Hallerbach et al. [38] Workflow model - - Basic logicGottschalk et al. [39] LTS, C-EPC - - -

urable business processes [15][16][17] and referencemodels [13][14] has been ongoing for several years.Most approaches are enabled during the configura-tion of business processes [12][13][32], while othersverify configurable business process models againstcorrectness properties [14][28], or obtain a set of allvalid configurations for clients to select from [17][37].

Table 8 shows that among 22 approaches we iden-tified, only 65% apply themselves to business pro-cess structures. Furthermore, only one third of thoseapproaches support resource and data configuration.As indicated by the configurable cloud service ap-proaches in our survey, resource and data configura-bility is an important feature for allowing clients totailor services towards their requirements. Allowingclients to configure resources can have an impacton the running costs of the service, in addition toincreasing the potential market with greater config-urability. Data object configuration allows clients tomake the service more similar to existing or expectedbusiness practises. Therefore, we consider it impor-tant for research into BPaaS configuration to considerconfiguration from these perspectives.

Also, as the Client Requirements field in Table 9indicates, most approaches only support simple re-quirements such as selecting and removing features.Feature selections are all the client provides in 26%percent of our surveyed approaches, while other basicbinary selections, such as blocking or hiding activities,make up a further 39%. Other approaches providesome business rule support [15][34], such as basic if-then conditions. To the best of our knowledge, trans-actional requirements important to clients, such asthose supported by our template set, are not yet sup-ported by any business process configuration method,and this is one of the major contributions of this workcompared to existing works.

We also identify that little research so far hasaddressed BPaaS explicitly. Approaches such as [6]target their configuration method towards SaaS thathas a business process structure of activities, whilesome configurable business process methods considervariability of resources and data associated with activ-ities. However, BPaaS has their own unique concernssuch as configurable use of third-party services, andthe inherent transactional concerns.

Our approach manages BPaaS configuration in away that addresses the issues identified above. Firstly,our BPaaS model enables configuration from numer-ous perspectives important to BPaaS clients, namely,activities, resources, and data objects, as shown in thescenario examples. Our configuration method aims toelicit and ensure complex transactional requirementsfrom clients, by adapting the temporal logic templateset as shown in Section 4. This is in contrast tothe approaches proposed in [17][37] but it has theadvantage of a reduced runtime when configuringservices with many configuration options and values.

6 CONCLUSIONThe increase in cloud computing adaptations in recentyears has produced the concept of Business Processas a Service (BPaaS), whereby service providers areable to offer common or proven business processes toclients looking to automate and/or outsource parts oftheir operations. We address the problem of managingBPaaS configuration in a way to ensure that theresulting service i) is valid with respect to config-uration constraints of the provider, and ii) satisfiestransactional requirements drawn from the businessrules of the client. Our approach utilizes several mod-elling techniques, including BPMN for business pro-cess structure, statecharts for transactional state, fea-ture models for configuration constraints. Using these




TABLE 9Correctness Criteria for comparing work related to BPaaS configuration

Approach Process Model Configurability Client RequirementsMietzner et al. [26] - - Feature selectionsLizhen et al. [30] - - Feature selectionsSchoreter et al. [7] - - Feature selectionsBanerjee [31] - - Required servicesKumara et al. [5] - - Feature selectionsSchroeter et al. [27] - - Feature selectionsMendling et al. [12] Syntax - Function and connector variantsvan der Aalst et al. [32] Syntax and Soundness - Blocked and hidden activitiesvan der Aalst et al. [13] Syntax and Soundness - Blocked and hidden activitiesKumar and Yao [15] Syntax - Business rules

La Rosa et al. [33][16] Syntax -Blocked and optional functions,

resources, data objects,connectors

La Rosa et al. [29] - No circular dependenciesor contradictions Boolean questionnaire answers

Wang et al. [34] - - Set of business policy typesvan der Aalst [35] - - Blocked activities

Tsai and Sun [36] - - Structure, GUI, resources, data,QoS

Liu et al. [6] Fairness, deadlock-free,reachability - Adding, deleting, modifying

elementsvan Dongen et al. [28] Relaxed soundness - Termination states

Groner et al. [14] - Control flow and domainconstraint conflicts Feature selections

van der Aalst et al. [17] Weak-termination - Blocked and hidden activitiesJiang et al. [37] Deadlock-free - Blocked activities

Hallerbach et al. [38] Soundness - Security, maintenance, andworkload context variables

Gottschalk et al. [39] - - Blocked, hidden, and optionalactivities

models, we develop a BPaaS configuration processthat applies Binary Decision Diagram (BDD) analysisand model checking. BDD analysis ensures that BPaaSfeatures selected during configuration do not violatethe domain constraints of the service provider, whilemodel checking verifies the configured BPaaS againsttransactional requirements provided by the client. Toreduce the impact of state-space explosion, we employa state-space reduction algorithm and split the modelchecking into two phases. These phases verify differ-ent configuration perspectives separately, and allowfor the state space and temporal logic properties to bereduced further. Our performance analysis shows thatthe proposed configuration method is capable of ver-ifying models with hundreds of activities, resources,data objects, and requirement sets within seconds.

ACKNOWLEDGMENTS

Quan Z. Sheng’s work has been partially supportedby Australian Research Council (ARC) DiscoveryGrant DP0878917 and FT140101247. The authorswould like to thank the anonymous reviewers fortheir valuable feedback on this work.

REFERENCES

[1] S. Bouchenak, G. Chockler, H. Chockler, G. Gheorghe, N. San-tos, and A. Shraer, “Verifying cloud services: present andfuture,” SIGOPS Operating Systems Review, vol. 47, no. 2, 2013.

[2] S. Marston, Z. Li, S. Bandyopadhyay, J. Zhang, and A. Ghal-sasi, “Cloud Computing The Business Perspective,” DecisionSupport Systems, vol. 51, no. 1, pp. 176–189, 2011.

[3] Q. Zhang, L. Cheng, and R. Boutaba, “Cloud Computing:State-of-the-Art and Research Challenges,” Journal of InternetServices and Applications, vol. 1, no. 1, pp. 7–18, 2010.

[4] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. Katz,A. Konwinski, G. Lee, D. Patterson, A. Rabkin, and I. Stoica,“A View of Cloud Computing,” Communications of the ACM,vol. 53, no. 4, pp. 50–58, 2010.

[5] I. Kumara, J. Han, A. Colman, and M. Kapuruge, “RuntimeEvolution of Service-Based Multi-Tenant SaaS Applications,”in Service-Oriented Computing. Springer, 2013, pp. 192–206.

[6] Y. Liu, B. Zhang, G. Liu, M. Zhang, and J. Na, “EvolvingSaaS Based on Reflective Petri Nets,” in Proceedings of the7th Workshop on Reflection, AOP and Meta-Data for SoftwareEvolution. ACM, 2010, pp. 7:1–7:4. [Online]. Available:http://doi.acm.org/10.1145/1890683.1890690

[7] J. Schroeter, S. Cech, S. Gotz, C. Wilke, and U. Aßmann,“Towards Modeling a Variable Architecture for Multi-TenantSaaS-Applications,” in Proceedings of the 6th International Work-shop on Variability Modeling of Software-Intensive Systems. ACM,2012, pp. 111–120.

[8] R. Accorsi, “Business Process as a Service: Chances for RemoteAuditing,” in The 35th Annual Computer Software and Applica-tions Conference Workshop. IEEE, 2011, pp. 398–403.

[9] S. Bourne, C. Szabo, and Q. Sheng, “Managing ConfigurableBusiness Process as a Service to Satisfy Client TransactionalRequirements,” in Proceedings of the 11th International Confer-ence on Services Computing. IEEE, 2015, pp. 154–161.

[10] T. Lynn, J. Mooney, M. Helfert, D. Corcoran, G. Hunt, L. VanDer Werff, J. Morrison, and P. Healy, “Towards a Frameworkfor Defining and Categorising Business Process-As-A-Service(BPaaS),” in 21st International Product Development ManagementConference, 2014.

[11] M. P. Papazoglou and W. van den Heuvel, “Blueprinting theCloud,” IEEE Internet Computing, vol. 15, no. 6, pp. 74–79, 2011.

[12] J. Mendling, J. Recker, M. Rosemann, and W. M. P. van derAalst, “Generating Correct EPCs from Configured C-EPCs,”




in Proceedings of the Symposium on Applied Computing. ACM,2006, pp. 1505–1510.

[13] W. M. P. van der Aalst, M. Dumas, F. Gottschalk, A. H. M. terHofstede, M. La Rosa, and J. Mendling, “Preserving Correct-ness During Business Process Model Configuration,” FormalAspects of Computing, vol. 22, no. 3-4, pp. 459–482, 2010.

[14] G. Groner, M. Boskovic, F. S. Parreiras, and D. Gasevic, “Mod-eling and Validation of Business Process Families,” InformationSystems, vol. 38, no. 5, pp. 709–726, 2013.

[15] A. Kumar and W. Yao, “Design and Management of FlexibleProcess Variants using Templates and Rules,” Computers inIndustry, vol. 63, no. 2, pp. 112–130, 2012.

[16] M. La Rosa, M. Dumas, A. H. M. ter Hofstede, J. Mendling,and F. Gottschalk, “Beyond Control-Flow: Extending BusinessProcess Configuration to Roles and Objects,” in Proceedings ofthe 27th International Conference on Conceptual Modeling, 2008,pp. 199–215.

[17] W. M. P. van der Aalst, N. Lohmann, M. Rosa, and J. Xu,“Correctness Ensuring Process Configuration: An ApproachBased on Partner Synthesis,” in Proceedings of the 8th Interna-tional Conference on Business Process Management (BPM 2010),ser. Lecture Notes in Computer Science, vol. 6336, pp. 95–111.

[18] C. Baier and J.-P. Katoen, Principles of Model Checking. MITpress, 2008.

[19] S. Bourne, C. Szabo, and Q. Sheng, “Verifying TransactionalRequirements of Web Service Compositions using TemporalLogic Templates,” in Proceedings of the 14th International Con-ference on Web Information System Engineering. Springer, 2013.

[20] K. C. Kang, J. Lee, and P. Donohoe, “Feature-Oriented ProductLine Engineering,” IEEE Software, vol. 19, no. 4, 2002.

[21] D. Benavides, S. Segura, and A. Ruiz-Cortes, “AutomatedAnalysis of Feature Models 20 Years Later: A Literature Re-view,” Information Systems, vol. 35, no. 6, pp. 615–636, 2010.

[22] W. Zhang, H. Yan, H. Zhao, and Z. Jin, “A BDD-Based Ap-proach to Verifying Clone-Enabled Feature Models Constraintsand Customization,” in High Confidence Software Reuse in LargeSystems. Springer, 2008, pp. 186–199.

[23] E. Clarke, “Model Checking,” in Foundations of Software Tech-nology and Theoretical Computer Science. Springer, 1997.

[24] A. Cimatti, E. Clarke, E. Giunchiglia, F. Giunchiglia, M. Pistore,M. Roveri, R. Sebastiani, and A. Tacchella, “NuSMV 2: AnOpensource Tool for Symbolic Model Checking,” in ComputerAided Verification. Springer, 2002, pp. 241–268.

[25] S. Kripke, “Semantical Considerations on Modal Logic,” ActaPhilosophica Fennica, vol. 16, no. 1963, pp. 83–94, 1963.

[26] R. Mietzner, A. Metzger, F. Leymann, and K. Pohl, “Variabil-ity Modeling to Support Customization and Deployment ofMulti-Tenant-Aware Software as a Service Applications,” inProceedings of the ICSE Workshop on Principles of EngineeringService Oriented Systems. IEEE, 2009, pp. 18–25.

[27] J. Schroeter, P. Mucha, M. Muth, K. Jugel, and M. Lochau,“Dynamic Configuration Management of Cloud-based Appli-cations,” in Proceedings of the 16th International Software ProductLine Conference (SPLC 2012), pp. 171–178.

[28] B. F. van Dongen, M. H. Jansen-Vullers, H. M. W. Verbeek,and W. M. P. van der Aalst, “Verification of the SAP Refer-ence Models using EPC Reduction, State-Space Analysis, andInvariants,” Computers in Industry, vol. 58, no. 6, 2007.

[29] M. La Rosa, W. M. P. van der Aalst, M. Dumas, and A. H. M.ter Hofstede, “Questionnaire-Based Variability Modeling forSystem Configuration,” Software & Systems Modeling, vol. 8,no. 2, pp. 251–274, 2009.

[30] L. Cui, H. Wang, J. Lin, and H. Pu, “Customization ModelingBased on Metagraph for Multi-Tenant Applications,” in The 5thInternational Conference on Pervasive Computing and Applications.IEEE, 2010, pp. 255–260.

[31] A. Banerjee, “A Formal Model for Multi-Tenant Software-as-a-Service in Cloud Computing,” in Proceedings of the 5th ACMCOMPUTE Conference: Intelligent & Scalable System Technologies.ACM, 2012, p. 18.

[32] W. M. P. Van Der Aalst, M. Dumas, F. Gottschalk, A. H. M.ter Hofstede, M. La Rosa, and J. Mendling, “Correctness-Preserving Configuration of Business Process Models,” inFundamental Approaches to Software Engineering. Springer, 2008.

[33] M. La Rosa, M. Dumas, A. H. M. ter Hofstede, andJ. Mendling, “Configurable Multi-Perspective Business ProcessModels,” Information Systems, vol. 36, no. 2, pp. 313–340, 2011.

[34] M. X. Wang, K. Y. Bandara, and C. Pahl, “Process as a ServiceDistributed Multi-Tenant Policy-Based Process Runtime Gov-ernance,” in The International Conference on Services Computing.IEEE, 2010, pp. 578–585.

[35] W. M. P. van der Aalst, “Business Process Configuration in theCloud: How to Support and Analyze Multi-tenant Processes?”in Proceedings of the 9th European Conference on Web Services,2011, pp. 3–10.

[36] W. Tsai and X. Sun, “SaaS Multi-Tenant Application Cus-tomization,” in The 7th International Symposium on ServiceOriented System Engineering. IEEE, 2013, pp. 1–12.

[37] J. M. Jiang, S. Zhang, P. Gong, and Z. Hong, “Configur-ing Business Process Models,” SIGSOFT Software EngineeringNotes, vol. 38, no. 4, pp. 1–10, 2013.

[38] A. Hallerbach, T. Bauer, and M. Reichert, “GuaranteeingSoundness of Configurable Process Variants in Provop,” inIEEE Conference on Commerce and Enterprise Computing. IEEE,2009, pp. 98–105.

[39] F. Gottschalk, W. M. P. van der Aalst, and M. H. Jansen-Vullers,“Configurable Process Models A Foundational Approach,” inReference Modeling. Springer, 2007, pp. 59–77.

Scott Bourne received his PhD degree incomputer science from the University of Ade-laide in the School of Computer Science in2016. His research interests include service-oriented computing, formal methods, verifi-cation, and program analysis. Scott has pub-lished in several conferences (e.g., ICSOC,WISE, SCC) and international journals (e.g.,Information Sciences). He has recieved anumber of awards due to his research workincluding a Dean’s Commendation for Doc-

toral Thesis Excellence from the University of Adelaide in 2016.

Claudia Szabo is currently a lecturer atSchool of Computer Science, the Univer-sity of Adelaide. She is also an AssociateDean (DI) of Faculty of Engineering, Com-puter and Mathematical Sciences. Claudiareceived her PhD degree in computer sci-ence from National University of Singapore.Her research interests include model-drivenengineering, distributed and cloud comput-ing, verification and validation of distributedsystems. She is the author of more than 50

publications. She is a member of IEEE.

Quan Z. Sheng is a full professor and Headof Department of Computing, Macquarie Uni-versity. He received the PhD degree in com-puter science from the University of NewSouth Wales in 2006. His research interestsinclude service computing, distributed com-puting, Internet computing, big data analyt-ics, Internet of Things, and Web of Things.He is the recipient of ARC Future Fellowshipin 2014, Chris Wallace Award for Outstand-ing Research Contribution in 2012, and Mi-

crosoft Research Fellowship in 2003. He is the author of more than270 publications. He is a member of ACM and IEEE.

Documents

IEEE TRANSACTIONS ON SERVICE COMPUTING 1 ...web.science.mq.edu.au/~qsheng/papers/tsc-bourne-2018.pdfCloud comput-ing has become a popular paradigm for delivering a wide range of services,