In today's IT industry resource-intensive tasks are playing an increasing role in business processes. By the emergence of Cloud computing it is nowadays possible to deploy such tasks onto computing resources leased in an on-demand fashion from Cloud providers. This enabled the realization of so-called Elastic Processes (EPs). These are able to dynamically adjust their used resources in order to meet varying workloads. Till now, traditional Business Process Management Systems (BPMSs) do not consider the needs of Elastic Processes such as monitoring the current system load, reasoning about optimally utilized resources, in order to ensure given Quality of Service constraints while executing required actions such as starting, stopping servers or moving services from one server to an other. This paper focuses on our current work on ViePEP, a research BPMS for the Cloud capable of handling the aforementioned requirements of EPs.
Business Process Management is a multifaceted approach which covers the
organizational, management and technical aspects of business processes. Further,
it “includes methods, techniques, and tools to support the design, enactment,
management, and analysis of operational business processes” [
Such workflows are becoming more and more relevant in business processes in several diferent industries. Examples are coming from the finance industry, managing of smart grids or from the energy domain. In the latter one, data from a very large extend of sensors have to be gathered, processed and analyzed in almost real time. Further, this data has to be stored in order to be retrievable to a later moment for the generation of reports or statistical analysis.
It is a common service provider problem that acquired resources are hardly
fully utilized, which is not very cost eficient. While this enables the provision of
a high quality of service, it ends up in unwanted waste of resources. In contrast,
if too many requests are forwarded to a particular Virtual Machine (VM) it
may crash or the services being executed may produce faulty results. As this
example is very specific for computer engineering, it is a common problem in
economy. In computational processes in the context of Cloud computing, this
can be described as the problem of Elastic Processes (EPs). EPs are “precisely
defining the various facets of elasticity that capture process dynamics in cloud
computing [...]. The main properties for modeling EPs’ economic and physical
dynamics are resource elasticity, cost elasticity, and quality elasticity” [
Therefore, a technology is needed which is able react to a dynamic change of needed computing resources, while still ensuring the faultless business process execution. This means, this kind of technology has to be able to provide additional resources when needed, such that, the business process execution will not wait, stuck or even crash at a critical moment. For that reason, research scientists from the field of Business Process Management and software engineering have put a remarkable focus on the solution of such a problem in recent years.
In this paper, we present the ongoing research on Elastic Processes in the Cloud. More precisely, we present our extensive work on ViePEP – the Vienna Platform for Elastic Processes. ViePEP is a research-driven BPMS for the Cloud, capable of cost-efective workflow processing while monitoring their underlying service executions in order to provide a certain level of Quality-of-Service (QoS) and ensure no Service Level Agreement (SLA) violations.
The remainder of this paper is organized as follows: After a brief introduction of ViePEP’s architecture including its functionality (Sect. 2) we will give some information about our current research on workflow scheduling (Sect. 3.1) and resource optimization (Sect. 3.2). Sect. 4 will give an overview of the related work and Sect. 5 will conclude this paper and give a short outlook on our future work. 2
In this section we want to introduce ViePEP. In general, ViePEP can be seen as
a broker middleware which accepts workflow requests by a customer (Client in
Fig. 1) and takes care of its execution. By the upcoming of Cloud computing and
the new paradigm of Software-as-a-Service (SaaS) [
Client API
t1 BPMS VM
Load Balancer
R
R t3
t4 t2
R
Workflow Manager
R
Scheduler Reasoner
R
R Service Repository
Application Server Application Server Service
Monitor Service
MoRnitor
Action Engine
R Action Engine
Backend VM 1
Backend VM N
Shared Memory
cost-eficient as possible, ViePEP was designed according to the MAPE-K cycle
(Monitor, Analyze, Plan and Execute) which is used for autonomic computing[
As shown in Fig. 1, ViePEP has five top level entities: First, the Client models service-based workflows and can optionally define Service Level Agreements. Clients may request additional workflows consecutively or even many simultaneously. In addition, ViePEP is able to serve several diferent clients in parallel.
Second, the BPMS VM ofers the core functionality of ViePEP. It is responsible of accepting new workflow requests ( Workflow Manager ) and stores them for a later or immediate execution. The exact execution time is computed by the Scheduler, which creates a schedule plan according the given deadlines defined in the given SLAs within the workflow requests. A first version of this scheduling plan is forwarded to the Reasoner which computes the amount of required resources. This can be done by reasoning on historical data from the Shared Memory. As this is the core functionality it will be further discussed in Sect. 3. Thus acquired resources are used equally, the single service invocations are balanced and distributed to the single service instances running on diferent VMs (Backend VM). Beside of the workflow executions, the Workflow Manager also measures the execution time of single service invocations, which is a prerequisite to detect possible deviations from the expected QoS attributes. By doing so, it is able to issue corresponding countermeasures if required.
Third, the Backend VM hosts an Application Server on which a particular service instance is deployed. In order to monitor the services’ QoS, a Monitoring component is deployed. It measures the VM’s CPU and RAM load and stores this information in the Shared Memory. The Action Engine is able to perform actions issued by the Reasoner such as deploy, undeploy a particular service, or move a running service to another Backend VM.
Fourth, both, the Shared Memory and Service Repository are helper
components and their functionalities are simple. The latter hosts all available services in
form of deployable Web application ARchive (WAR) files. The Shared Memory
is used to store the monitored data from each single Backend VM and share it
with the BPMS VM. For a more detailed description about ViePEP please be
refereed to [
As ViePEP is a fully functional BPMS for the Cloud it takes care of workflow scheduling (Sect. 3.1) and its actual workflow execution. However, in contrast to common BPMSs, ViePEP is considering the future workflow executions and reasons in order to achieve a cost-efective optimized system (Sect. 3.2). For that, we will discuss in this section our ongoing work on the core functionality of ViePEP: the reasoning about current and future workflow execution including the computation of the resource demand and how ViePEP achieves a resource optimized system landscape. 3.1
The core functionality of a common BPMS is to process workflows. In order to
know when a particular workflow execution should be started, several diferent
procedures have been established. In many cases the incoming workflows are
ifrst ordered according their priorities before being processed. This allows the
processing of workflow requests with a higher priority before workflows with a
lower priority. These diferent techniques have already been discussed by many
researchers and are not focus of this work [
Clients can issue a workflow request and define a specicfi deadline, i. e. a point
of time defining when the execution has to be ended. This can be defined either
for the whole workflow or for a particular single step in a workflow. ViePEP’s
task is to process the workflow while ensuring this deadline. Since ViePEP is a
BPMS serving several hundred or even thousand clients in parallel, the workflow
scheduling is a complex task. Hoenisch et al., [
This scheduling is a straight forward task for sequential workflows (which are the only one supported in ViePEP at the moment). However, it gets a much more complicated challenge if the workflow is more realistic, e. g. if it involves branches such as XORs, ANDs or loops. While ANDs are quite easy to implement, i. e. both branches have to be considered, XORs are much more complicated. In the latter one, a BPMS, considering XORs has to deal with probabilities. This means, it has to calculate how high is the chance that a workflow follows either the one path or the other one (but not both). This can either be done static, e. g. the probability that a workflow follows the one path is always a fix value and the other direction is always 1 minus that value, or dynamically. Of course, in a real world scenario, those values are not static, but may change dynamically, e. g. they depend on the output or input of previous steps. Therefore, a “smart” BPMS has to be able to learn from historical executions and predict the probabilities. While the scheduling itself might not be the biggest challenge, as already a lot of research has happened in this field, the combination with computing the demand of resources is much more complicated. 3.2
As ViePEP is a smart BPMS it tries to consider all of the three properties of EPs equally. This means, the acquired resources are fully utilized in order to be as cost-eficient as possible. However, in the current version, the quality of a service is hardly defined by the services’ output, rather than ensuring the given SLAs, i. e. ensuring that a workflow is processed in time.
As mentioned before, ViePEP tries to utilize the acquired resources as eficiently as possible. This means, the Reasoner computes the required amount of resources from historical data. In the current version, ViePEP makes use of Ordinary Least Squares (OLS) Linear Regression. At the moment, the provided services are only CPU intensive. Therefore, a high CPU load would influence a hosted service the most. Therefore, OLS is a perfect choice for the current scenarios as it is limited to two variables (2-dimensional optimization). While this is only the case in our selected services, in the case of image processing, the limiting factor may be the internal memory or RAM. For that reason, we are working on a multi-dimensional resource prediction mechanism considering several QoS aspects of a service. As in real-world scenarios, service invocations do not produce a linear resource consumption, and may last several minutes or even hours, a linear regression is not applicable anymore. Therefore, we propose to approach this problem from the other way around and make use of online reasoning approaches (e. g. Kalman Filters) in order to compute how many service invocations are possible on a particular resource and to predict the future demand of resources. In general, a Kalman Filter aims at providing the means of a mathematical equation to estimate a state of a process or a stream of updated data. In addition, a Kalman iflter makes use of historical and life data and is able to predict a future state even if the precise nature of the system is not known. Therefore, by “feeding” a Kalman Filter with monitored data, e. g. such as how many invocations happened in parallel, producing a certain load in CPU and used a particular amount of RAM, it is possible to compute how many invocations the monitored VM is able to handle in the future.
The result of the resource prediction (see Sect. 3.1) is a detailed plan of which service invocation is assigned to which VM and if additional VMs are required or if unneeded once can be released. The execution of this task is simple software engineering.
However, in many cases, companies manage an own private Cloud. Which means, neglecting the energy costs, these are free resources and ready to use. Therefore, the Reasoner should consider allocating private resources first until the demand is reached. However, it may be the case, that not enough resources are available in the private Cloud. Therefore, additional resources can be bought from an external Cloud provider (public Cloud). The result is a so called Hybrid Cloud. As the resource allocation on its own is not such a complicated task, the Reasoner has to consider the diferent pricing schemes of the public Cloud. Amazon’s EC2 for example charges their customers on an hourly model. This means, it is not economic to acquire such a resource for just 20 minutes. Therefore a rescheduling might be necessary. In addition, several Cloud infrastructure providers ofer diferent kind of VM types having a diferent amount of computing resources such as a multi-core CPU or more RAM and cost diferently. 4
To the best of our knowledge, so far, surprisingly little efort has been investigated
into the field of elastic processes in the sense of dynamic resource allocation
and elastic process execution [
In both cases, scalability and cost-efective allocation of single tasks and
services have been the only focus by many researchers. Most research eforts are
focusing on minimizing the costs for the consumers (clients) while taking into
account a maximum allowed execution time or other QoS attributes [
In contrast to that, more recent research eforts are focusing on the
infrastructure perspective, i. e. a higher resource utilization [
Similar to our work, a workflow model, i. e. workflows are composed from
single software services which can be deployed in the Cloud, has been considered
by Wei and Blake [
In this paper we have presented our current state and work on ViePEP – the
Vienna Platform for Elastic Processes. ViePEP was already evaluated by simplified
use cases in [
Acknowledgements. This work is partially supported by the Commission of the European Union within the SIMPLI-CITY FP7-ICT project (Grant agreement no. 318201).