Due to the increasing specialization of companies in a globalized world, inter-organizational process enactments have become increasingly relevant in recent years. Nevertheless there are hardly any scheduling approaches that meet the requirements of these inter-organizational processes, especially in terms of privacy aspects. In this paper we present a privacy-aware scheduling approach for hybrid clouds, which represents a vital starting point to design a holistic execution environment for inter-organizational process enactments.
The remainder of this paper is structured as follows: In Sect. 2 we state the motivation for our work and discuss some preliminaries in Sect. 3. We further present our privacy-aware scheduling approach in Sect. 4 and Sect. 5 concludes the paper with an outlook on our future work. 2
Business process enactments are usually triggered by process requests. These
process requests are issued by external events, e.g., customer interactions, which
lead to alternating amounts of business process requests respectively changing
resource requirements. In peak-times, when external events issue an extraordinary
amount of process requests, a BPMS may run into an underprovisioning scenario,
since there are not enough resources to enact the process requests according to
their Service Level Agreements (SLAs) [
Public clouds, e.g., Amazon EC2, offer a promising solution to the resource
usage challenges for varying process requests. A cloud-aware BPMS is able to
obtain the required resources on demand in an utility like fashion. This enables
the BPMS to obtain resource elasticity by scaling the computational resources up
and down, based on the changing requirements. Measured services further allow an
exact billing of the computational resources based on the actual resource usage [
Besides the resource allocation there are also other challenges for BPMS,
like privacy issues for service instantiations of inter-organizational processes, i.e.,
service choreographies. Inter-organizational processes are structured similarly to
business processes. The major difference is that their process steps are assigned
to software services which are provided by different companies instead of only one.
Therefore software services for inter-organizational processes can be executed
on a community cloud [
Common
Data VMVMVMVVMMVMVMVMVM VM
Sensitive Data
Sensitive
Data
In our previous work we presented the Service Instance Placement Problem
(SIPP) [
The execution environment for inter-organizational processes consists of a a community cloud and dedicated private clouds for privacy sensitive services, as illustrated in Fig. 1. The community cloud hosts all non privacy sensitive services as well as the BPMS. The BPMS schedules process steps, provisions resources for the software-based services on the community cloud and also triggers the deployment of the privacy sensitive services in the dedicated private clouds, based on the privacy restrictions issued for the services. These restrictions are described in detail in Sect. 4.2. In terms of computational resources, we assume that the private clouds offer a limited amount of computational resources, which are only sufficient to run the privacy sensitive services whereas the community cloud offers theoretically unlimited resources.
The inter-organizational processes are composed of multiple process steps that represent the software-based services provided by the participating companies. Fig. 2 represents an exemplary inter-organizational process, which shows the collaboration among 3 companies. Step 3 and 5 are annotated as privacy sensitive and must only be executed in the dedicated private clouds, whereas all other steps can be executed in the community cloud. To execute a process step, the BPMS triggers the deployment of the software-based service on a Virtual Machine (VM) either on the community cloud or on a private cloud. This deployment results in a service instance that can be invoked by the BPMS to execute the service and therefore execute the process step. ya1n p m o C yan2 p m o C y3an p m o C
Step 1 privacy sensitive
Step 6 Step 2
Step 3 Step 4
Step 5
The SIPP is represented by a set of different constraints and equations, which are
described in detail in [
min
X cv · γ(v,t) + X X v∈V −
X X
X p∈P ip∈Ip jip ∈Ji∗p p∈P ip∈Ip
1 DLip − τt
v∈V kv∈Kv x(jip ,kv,t) cip · eipp + p
X X (ωfC · fkCv + ωfR · fkRv ) 4.2
Privacy Extensions Since SIPP is designed for a single cloud, we introduced additional constraints and additional SLA policies to enable the enactment of inter-organizational processes while respecting the privacy constraints of the services.
We extended the set of VM types to distinguish between different deployment locations with their different privacy policies.
V = K =
[ loc∈Loc
[ loc∈Loc
Vloc Kloc (1) (2) (3)
This differentiation is possible by introducing the identifier loc (loc ∈ Loc), which represents the type of the cloud, e.g., community cloud or 1 of the private clouds. The new set of available VMs is then defined by the union of all VMs, which can be instantiated in the different clouds (Eq. 2). Analogously we also extended the set of all currently instantiated VMs (Eq. 3).
In terms of privacy restrictions, there are 2 specification possibilities to restrict the execution of services regarding the type of the cloud. The first approach is blacklisting: the SLA lists for every process all services, which must not be executed on specific clouds. The major downside of this approach is that the SLA needs to be updated when additional clouds are added.
The alternative approach is whitelisting, i.e., the SLA for each process lists all service instantiation possibilities in the different clouds. Since this SLA pursues a defensive permission approach, there is no need to update the SLA in contrast to the blacklisting approach, when the cloud environment grows by additional private or community clouds. Eq. 4 shows an exemplary SLA for the process presented in Fig. 2. communityCloud (Service 1, Service 2, Service 4) privateCloud1 (Service 3) privateCloud2 (Service 5)
Based on this SLA for services, a MILP-solver for the optimization problem is able to generate the instantiation possibilities according to Eq. 5. The constraints in Eq. 5 evaluate whether a specific process step jip can be instantiated on a specific VM kvloc by querying whether the process step is listed on the whitelist for the given cloud loc. If the SLA does not explicitly allow the instantiation of the process step on the specific VM, the constraint rules out the deployment option. Otherwise the MILP-solver decides based on other constraints whether the service is deployed on the specific VM (1) or not (0) as stated in the alternative branch of the constraint.
x(jip ,kvloc ,t) = (0 {0, 1} , if jip ∈/ SLAPloc , loc ∈ Loc , else (4) (5) 5
In this paper we focused on the formalization of privacy constraints for the
deployment and enactment of inter-organizational processes in hybrid cloud
environments. Although these privacy extensions are relevant for process
enactment, they only represent a small step towards a holistic process scheduling
and resource allocation approach for inter-organizational processes in hybrid
cloud environments. Other relevant topics are data transfer aspects among the
different clouds, which become increasingly relevant for big data applications or a
cost-efficient resource allocation across the cloud environment. In our future work
we will evaluate the proposed privacy constraints in a hybrid cloud environment
based on the Vienna Platform for Elastic Processes (ViePEP) [
Acknowledgments This paper is partially supported by TU Vienna research funds and supported by the European Union within the SIMPLI-CITY FP7-ICT project (Grant agreement no. 318201).