Lightweight Web Services Migration Framework in Hybrid Clouds
Saadaoui Alaeddine
Department of Computer Sciences
Tennessee Technological University
Cookeville, Tennessee, USA
asaadaoui42@students.tntech.edu
Abstract— Service-oriented architectures allow the deployment
of loosely coupled services that are platform independent. An
enterprise can take advantage of service-oriented architecture
in two different directions. On one side, the abstraction of
technology implementation allows the deployment of web
services in disparate systems. On the other side, the flexibility
and independence of services from each other makes scalability
easier to achieve. This paper presents a migration solution of
web services in hybrid clouds. The adoption of hybrid cloud
solutions is valuable for dynamic workloads to maintain the
availability of web services during periods of spikes in demand.
The migration solution is a lightweight framework composed of
web services to manage cloud instances and the migration task
of web services deployed on Java-based web containers. The
peak management process is based on Java Management
Extensions (JMX) technology to monitor resources and
deployed web services. In addition, the framework dynamically
integrates a set of JMX metrics to synchronize enterprise
demand for resources with the migration process. Finally, a
design of the framework prototype is described and a real case
of CPU intensive web service is presented to test the migration
process and show an improvement of CPU usage and execution
time.
Keywords-component; web services; hybrid cloud; migration;
JMX; monitoring
I. INTRODUCTION
Enterprises have been trying to reduce costs by adopting
scalable infrastructures that fit their needs; cloud computing
offers such an elastic and flexible infrastructure. The National
Institute of Standards and Technology (NIST) defines cloud
computing as a model for enabling on-demand network access
to a shared pool of computing resources that can be rapidly
provisioned and released [1]. NIST presents three types of
clouds: public, private, and hybrid clouds. A public cloud
offers off-site services over the Internet on a pay-for-use basis.
A private cloud is maintained on a private network of the
enterprise for exclusive management and usage. The hybrid
cloud is a composition of two or more distinct clouds (private
or public). One of the major challenges of cloud solutions is
security and data privacy. Outsourcing services and data to a
public cloud provider makes data integrity and privacy hard to
maintain [2]. A typical cloud solution for enterprises such as
banks, insurance companies, etc., that have safety regulations
Stephen L. Scott
Department of Computer Sciences
Tennessee Technological University
Cookeville, Tennessee, USA
and
Oak Ridge National Laboratory
Oak Ridge, Tennessee, USA
sscott@tntech.edu
and concerns, is a private cloud where all the services are
exclusively managed and accessed by the company. When a
private cloud is unable to handle peak periods of workloads,
it can be expanded through the adoption of a public cloud to
outsource services that need more resources and can accept
the offered security features. The public and private clouds
form a hybrid cloud and dealing with such a heterogeneous
platform requires solving service, data, compatibility and cost
challenges. The move from a private to a public cloud to get
additional resources and to avoid service interruption is called
cloud bursting. When an application, initially deployed in a
private cloud, requires resources that are not available in the
private cloud it bursts to the public cloud.
A survey shows that research work about cloud bursting
addressed different aspects like cloud infrastructure [3],
service integration, control, sharing [4], [5] and resource
optimization [6], [7]. However, there is no cloud bursting
work focused on web service migration. In fact, most cloud
bursting work targets the infrastructure layer [8-14]. At the
platform level, Tekin et al. [15] proposed a framework for
data-intensive computing to balance the computation in
hybrid cloud, and Philipp et al. [16] proposed a cloud bursting
solution to enable elastic applications to run across private
cloud boundaries. However, the latter work lacks predictive
capabilities and it limits the bursting and consolidation to the
application performance parameters.
The scope of this work is service migration on hybrid
cloud platforms. Initially, the services are installed on a
private cloud, and during peak periods they are migrated
within the private cloud or to a public cloud platform. The
migration process is composed of three steps: (1) selection of
candidate web services managed by a web service controller,
(2) selection of web service JMX metrics associated to each
candidate web service and web container JMX metrics
associated to cloud instances and (3) definition of migration
task associated to each candidate web service in step (1). The
migration process should be simple and should maintain the
cloud infrastructure scalability.
This paper presents a framework to migrate web services
in hybrid cloud platforms. Web services are platform
independent services and best candidates to be used in cloud
environment [17]. The framework is composed of three web
services: A Controller WS (Web Service), a Migrator WS and
a Cloud WS (see Figure 1). The Controller WS monitors
candidate web services to be migrated based on a set of web
service JMX metrics and manages the dynamic endpoints of
migrated web services. The migrator WS creates duplicates of
a candidate web service or transfers the latter to a different
cloud instance. The Cloud WS manages the cloud instances
based on web container JMX metrics. The Migrator WS uses
the instances returned by Cloud WS to execute migration tasks
requested by Controller WS.

Figure 2. Candidate Services Selection Modes

The Controller WS is loosely coupled with candidate web

services and both are supposed to be deployed in a distributed
way. The association decision of Controller WS with
candidate web services is left to the administrator to be able to
Figure 1. Migration Framework define migration policies in a flexible manner.
The next step is definition of JMX metrics associated to
The contributions of this research work are the following: candidate web services and cloud instances.
§ Simplify the migration process by proposing a
lightweight framework to migrate Java-based web services. Step 2. JMX Metrics Selection
§ The framework components are web services that are Java Management Extensions (JMX) is a technology
independent from each other and platform independent. included in Java Platform Standard Edition (J2SE). It is
§ The migration framework is distributed, flexible and generic and it enables monitoring of Java applications and
configurable. system resources [18]. JMX provides a set of metrics that can
§ The framework keeps independence and interoperability be monitored and managed. To display the dynamic state of
of the web services planned to be migrated. JMX metrics, JConsole is a graphic monitoring tool and a part
§ The framework can be extended to add web services of Java Development Kit (JDK) provided to monitor Java
management components and to support different cloud Virtual Machine (JVM) and Java applications on local and
platforms. remote machines (see Figure 3).
§ The web service client is updated to be resilient to JMX metrics are grouped within managed beans. A
dynamic endpoints change. Managed Bean (MBean) is a Java Bean that represents a
The remainder of the paper is organized as follows; resource running in JVM such as JDBC driver or Java
Section II details the different steps of the migration process. application. MBeans are used to collect statistics related to
Section III defines the migration problem. Section IV presents factors like performance, resources usage, thread pools etc.
different components of the migration framework. Section V [19].
explains the framework design. Section VI presents an
experimentation case to test the framework. Section VII
summarizes a list of related migration works. And section VIII
concludes this paper with a summary of work and outlines
future work to be implemented.
II. STEPS OF WEB SERVICE MIGRATION PROCESS
The migration process is composed of three steps:
candidate services selection, JMX metrics selection and
migration task definition. The three steps are detailed in the
following subsections.
Step 1. Candidate Services Selection
The Controller WS is configurable and flexible to support
two different management modes. The first mode consists in
having controllers, each associated to one candidate web
service. The second mode consists in associating a set of
candidate web services to one controller (see Figure 2). Figure 3. JConsole
 To monitor and manage web services we need to On a platform level, we will assume at least two classes
determine the MBeans that control web services and their of clouds, one public and the other private, each of which may
associated resources. Table 1 shows the list of web service be an originating source (S) platform or a target destination
JMX metrics used by the migration framework. (D) platform. Cloud migration may be both intra-cloud and
inter-cloud migration. Cloud computing environments may
Web Service MBeans
JMX Metrics
exhibit two types of migration: horizontal and vertical (see
currentThreadsBusy Catalina:ThreadPool:http-nio-8080 figure 4):
requestCount Catalina:Servlet://serverName/wsName
processingTime Catalina:Servlet://serverName/wsName a) Horizontal Migration: Horizontal migration
available Catalina:Servlet://serverName/wsName represents migration that does not change the cloud class
errorCount Catalina:Servlet://serverName/wsName from that of private or public. That which is running on the
maxTime Catalina:Servlet://serverName/wsName
private cloud S will migrate to private cloud D and likewise
hitCount Catalina:WebResourceRoot://serverName/
wsName that running on public cloud S will migrate to public cloud D.
maxTime Catalina:RequestProcessor: http-nio- In this scenario, neither S may cross over the public/private
8080:HttpRequest1 cloud boundary due to security or other enforced policy.
requestProcessingTime Catalina:RequestProcessor: http-nio- Sensitive services may only use horizontal migration while
8080:HttpRequest1 non-sensitive services may use either the horizontal or
vertical migration.
TABLE 1. WEB SERVICE JMX METRICS b) Vertical Migration: Vertical migration represents
The management of cloud instances uses memory, CPU migration that changes cloud class from either public-to-
and threads metrics. CPU metrics are managed by the MBean private or private-to-public. Here a public S may migrate to a
Operating System, memory metrics are managed by the private target D or vice versa, where a private S migrates to a
MBean Memory and threads metrics are managed by the public D. Here two different cloud classes may be joined
MBean Threading. Table 2 lists the JMX metrics associated together into a public/private partnership or hybrid cloud
to a cloud instance. class. Vertical migration is used when existing private cloud
resources are insufficient and are not able to scale up to meet
Cloud JMX Metrics MBeans demands. Policy must permit moving service off the private
HeapMemoryUsage Java.lang:Memory cloud. Likewise, policy must permit moving from public to
NonHeapMemoryUsage Java.lang:Memory an approved private cloud.
ProcessCpuTime Java.lang:OperatingSystem
SystemCpuLoad Java.lang:OperatingSystem
AvailableProcessors Java.lang:OperatingSystem
PeakThreadCount Java.lang:Threading
ThreadCount Java.lang:Threading
TotalStartedThreadCount Java.lang:Threading
CurrentThreadCpuTime Java.lang:Threading

TABLE 2. CLOUD INSTANCE JMX METRICS

Cloud WS management level is based on JMX metrics.

The monitors associated to cloud JMX metrics provide real
time data about the state of the cloud instance and the web
container.
Step 3. Candidate Services Migration
We suppose we have two cloud instances CIA and CIB and
a web service WS initially deployed on CIA. The migration
Figure 4. Cloud Services Migration Styles
process deals with two scenarios. The first scenario is moving
WS from CIA to CIB and updating WS endpoint to point to
Initially, when there are available private cloud resources,
CIB. The second scenario is duplicating WS to get WScopy and
we process horizontal migration at the private level and
deploying WScopy on CIB. In the second scenario, the client
will get the endpoint of WS or WScopy. To simplify the vertical migration from public to private to reduce public
migration process, the load balancing is limited to returning cloud provision. If there are no available private cloud
available web service endpoints to clients by using round- resources, vertical migration from private to public and
robin technique. Both scenarios require the service package, horizontal migration at the public level are processed.
its deployment descriptor, and the deployment destination
instance [20].
 III. WEB SERVICE MIGRATION PROBLEM DEFINITION
In this section, we present the methodology of web service
and resources selection to trigger the migration process. We
have a set of web services W initially deployed in the private
cloud. The web services are deployed in web containers and
we assume each virtual machine contains one web container.
To start a virtual machine in private or public cloud, we use a
snapshot of a virtual machine containing a web container.
We define two sets Spublic and Sprivate of virtual machines
deployed respectively on public and private cloud. The private
cloud has limited resources so we define MaxVM the maximum
number of virtual machines that can be created in the private
cloud. The number of virtual machines created in the public
cloud is unlimited and the resources are provisioned on a pay
as you go basis.
We assume both virtual machine and web service data are
collected at the same rate and they have the same sample size
n. The mean of a web service or cloud parameter is based on
n and the collected data. The parameter sample contains the
most recent collected data.
Suppose we have a web service wÎ W and we assume all
web services have the same set of normalized JMX parameters
P = {p1…pk}. Each parameter pÎP has a threshold θp and a
mean µp. We define the migration function Fws(w) in the
following way:
7 1
!"# (%) = ( )*+, − µ. 0 ; 34 ∈ 6 (1)
489 /
We use the function Fws to compute the distance of w’s
parameters means from their respective thresholds. We define
a migration threshold θw such that if Fws(w) < θw then w has to
be migrated. Each web service w has a defined threshold θw.
On the cloud level, we assume the virtual machines are
equal to receive web services to be deployed and they have
the same performance parameters set V={v1…vs}. Each
parameter vÎV has a threshold θv and a mean µv. We define
the performance function Fvm and a performance threshold θvm
of a virtual machine vmÎ Spublic ∪ Sprivate such that:
# 1
!<= (>?) = ( )*<, − µ< 0 ; >4 ∈ @ (2)
489 , metric has a corresponding String monitor, a variable numeric
If Fvm (vm) < θvm, vm cannot accept the deployment of new
web services. In fact, we want to maintain a minimum virtual
machine performance so that the deployed web services are
not negatively affected and to avoid overuse situations. We
define the set of available virtual machines on the private
cloud Savailable={vmÎ Sprivate | Fvm (vm) > θvm}.
The web services are ranked based on the function Fws. If
two services w1 and w2 are deployed on the same virtual
machine such that if Fws(w1) < Fws(w2), Fws(w1) < θw1 and
Fws(w2) < θw2 then w1 has the priority to be migrated over w2.
A migration task consists in transferring or duplicating a
web service. We monitor the web service JMX parameter
requestCount of a service w and we define the threshold
MaxReqw to limit the number of requests processed by w and
to avoid requests rejection. If Fws(w) < θw and requestCount <
MaxReqw then w will be duplicated, else if Fws(w) < θw and
requestCount = MaxReqw w will be transferred. We define the
set W'w containing a service w and its created duplicates. If
we have a client of the service w, we return the endpoint of a
service s such that: Fws(s)=Max(Fws(s') | s' Î W'w ʌ Fws(s') >
θs').
When a migration process is triggered, vm is selected such
that Fvm (vm)=Max(Fvm (vm') | vm'Î Savailable). If |Savailable|=0
and |Sprivate|< MaxVM we create a new virtual machine in the
private cloud otherwise in the public cloud.
To avoid underutilization situations and to reduce the
provision of public resources, we migrate web services from
public cloud to private cloud whenever there are available
resources in the private cloud. In other words, if |Savailable| 0
and |Spublic| 0 we select two virtual machines vm1 and vm2
such that Fvm (vm1)=Max(Fvm (vm') | vm'Î Savailable) and Fvm
(vm2)=Min(Fvm (vm') | vm'Î Spublic). If |Savailable|=0 and |Sprivate|<
MaxVM we create a new virtual machine vm1 in the private
cloud. We select the web service w to migrate from vm2 to vm1
such that Fws(w)=Min(Fws(w') | w' is deployed in vm2). The
selection of vm1, vm2 and w is done for each vertical migration
task from the public cloud to the private cloud.
IV. MIGRATION FRAMEWORK
The goal of the framework is to monitor web services and
enable the migration process in a decentralized, flexible and
configurable manner. The framework keeps the independence
property of web services from the cloud infrastructure.
The framework is composed of three configurable and
independent web services: Controller WS, Migrator WS and
Cloud WS to reflect three separated roles: monitoring,
migration and cloud management. The three web services are
detailed in the following sections.
1- Controller WS
The Controller WS automatically starts the monitoring
process once it is deployed. It performs the following tasks:
§ Monitoring task: for each JMX metric added to
controller WS, a monitor is created and registered in a
Management Bean Server (MBean Server). A String JMX
JMX metric has a corresponding Gauge monitor, and an
increasing numeric JMX metric has a corresponding Counter
monitor [21]. To receive notifications, a notification listener
is added to the monitor to take required actions. If a
notification satisfies the candidate web service migration
threshold, the monitor passes the notification to the listener to
trigger a migration task of the candidate web service (see
Figure 5).
§ Load balancing task: the Controller WS has a load
balancer that manages the endpoints of candidate web
services. The load balancer uses the defined selection criteria
to return available endpoints to candidate web service clients.
The migration task results in updating the web services list
used by the load balancer. To simplify the management
process, the control of resources availability is limited to the
JMX monitors loaded by the Controller WS.

Figure 5. Web Services Monitoring
2- Migrator WS
The Migrator WS executes deployment and uninstallation
tasks to transfer a candidate web service or deploy a duplicate
of the candidate web service in a destination cloud instance
(see Figure 6). In the transfer case, Migrator WS deploys a
duplicate of the candidate web service in the destination
cloud instance and uninstalls the original candidate web
service.
To maximize the configurability of Migrator WS, the
latter updates and uses a deployment WAR (Web application
ARchive) file of the candidate web service. The deployment
and uninstallation tasks are achieved by dynamically building
and executing corresponding deployment and uninstallation
URLs.
V. FRAMEWORK DESIGN
To implement the migration framework, a set of packages
are created to group the components of Controller WS,
Migrator WS, and Cloud WS. Each component is deployed
as a web service. Figure 8 shows the design of the migration
framework.
Initially, a candidate web service WScand is deployed on a
web container. To manage the migration of WScand, we
deploy Controller WS, Migrator WS and Cloud WS. Once
Controller WS is deployed, it automatically starts instances
of JMXMonitor class to control WScand. To migrate WScand,
Migrator WS contains a WAR file of WScand to duplicate
WScand. On the cloud level, Cloud WS manages a set of
virtual machine instances and returns an instance address to
Migrator WS to process duplication or transfer tasks (see
Figure 9).

Figure 6. Migrator WS Tasks

3- Cloud WS
The Cloud WS manages cloud instances requested by
Migrator WS. It uses a snapshot to create new virtual machine
instance. The snapshot is created from an instance containing
a deployed web container. Once a cloud instance is deployed,
its corresponding web container URL is returned to Migrator
WS (see Figure 7). Each cloud platform has one Cloud WS.

Figure 7. Cloud WS Components

Figure 8. Migration Framework Class Diagram
 To maximize the reusability of Controller WS and Cloud
WS, Factory design pattern is used to implement
MonitorFactory and CloudFactory to dynamically create
instances of JMXMonitor and Cloud classes. We aim the
automation of monitoring and cloud management levels. In
addition, the three framework web services can be separately
used. For example, besides the migration of web services,
Migration WS can be used to migrate WAR-based Java
applications.
to compute Fibonacci numbers. To keep the CPU busy, the
requests will be sent to WSFib for n=48. To deploy WSFib and
the migration framework, we used two web containers WC1
and WC2. WC1 is installed on a desktop machine and WC2 is
installed on a node of a HP server.
To simulate the high peak of demand case, we
implemented the client side of WSFib by using
java.concurrent.Executor to send parallel requests to WSFib.
Each request represents a new instance of WSFib client and
the requests are independent from each other.
The CPU performance analysis is based on three
scenarios. In the following graphs, the red color represents
the first scenario, the green color represents the second
scenario, and the blue color represents the third scenario. In
the first scenario, we just deployed WSFib on WC1. The
execution of the client side shows that the max CPU usage is
greater than 80% when the number of requests is greater than
6 parallel requests (see Graph 1).

Figure 9. Migration Framework Sequence Diagram

At the client level, Controller WS manages a load

balancer instance that dynamically returns endpoint address
of WScand to the client. The migration of WScand might result
in web service exceptions at the client level. Any caught
exception triggered by a request sent to WScand is treated
Graph 1. Max CPU Usage
through a Retry On Failure pattern shown in Algorithm 1.
To reduce the max CPU usage to 75%, in the second
scenario we limited the pool of parallel requests sent to WSFib
to 6 requests as a maximum. The limitation reduced the max
CPU usage to 74% but it had a negative impact on the total
execution time of the client side compared to the first
scenario (see Graph 2).

Algorithm 1. RetryOnFailure procedure

VI. EXPERIMENTATION
The goal of the experimentation is the management and
control of CPU usage during high peaks of demand. The
deployment of the migration framework will allow reduced
CPU usage and improve the overall execution time of web
service requests. To get accurate results, we will focus on the
web container where a migration candidate service is
deployed. We will collect and analyze information of
execution time, max and average CPU usage by using
JConsole.
To test CPU usage scenario, we coded a CPU intensive
web service WSFib that implements Fibonacci function F(n) Graph 2. Execution Time
 To improve the time performance of the client side, in the
third scenario we deployed Controller WS on WC1 and
Migrator WS on WC2 (see Figure 10). As WC2 has more
resources than WC1, we configured the load balancer so that
overall requests executed on WC2 are approximately twice
the requests executed on WC1 when Controller WS starts the
migration process. If the duplicate of WSFib is not active,
Controller WS sends a request to Migrator WS to undeploy
the duplicate of WSFib.
Figure 10. Deployment scenario
When Controller WS is deployed, it automatically starts a
monitor to watch the number of parallel requests Preqs
executed by WSFib. If Preqs=6, the controller triggers the
migration process and sends a request to Migrator WS to
deploy a duplicate of WSFib on WC2. The execution of the
third scenario shows an improvement of the execution time
when Preqs>12 requests (See Graph 2) while maintaining a
limit of max CPU usage to 74%. In addition, an analysis of
the average CPU usage shows an improvement in the third
scenario compared to the first and second scenarios (See
Graph 3).
Graph 3. Avg CPU Time
An analysis of Graph 1 shows the Max CPU usage when
Preqs>12 is the same in scenario 2 and scenario 3 due to the
non-deterministic aspect of the web services executing the
pool of parallel requests. In fact, Graph 4 shows for Preqs =70
all the pool parallel requests are executed by WC1 only during
a set of periods of time which results in Max CPU usage
approximately equal to 70%. However, the Graph 3 shows
the average CPU usage was reduced due to the fact that the
requests execution was split between WSFib and its duplicate
deployed on WC2. The split is shown in Graph 4 where the
number of parallel requests executed by WC1 is less than 6
requests.
Graph 4. Execution Time of Preqs=70 by WC1
VII. RELATED WORK
There have been several works dealing with cloud
services migration. Different frameworks were presented to
provide highly available services [22], [23] or to minimize
the migration cost [24]. Our goal is to provide a lightweight
and flexible framework. We focused on the migration
components rather than candidate web services or migration
cost. In particular, Mohanned et al. [25] described a web
service migration framework by means of migration
conditions. The framework is composed of three parts: a set
of services to be migrated, migration decision and migration
controller. This latter is responsible for services orchestration
while our controller is loosely coupled with web services and
limited to metrics control and migration tasks. In addition,
our migration strategy is flexible and uses dynamic monitors
to control web services and cloud instances. Mohanned [26]
also proposed a Restful-based framework for mobile web
service migration and provisioning on android-based devices
and Java-based devices. The framework enables provider and
service automatic discovery, system monitoring and adaptive
service migration. While the solution is based on Restful web
services, our framework supports Restful and SOAP web
services. In addition, our solution is web service centric to
maintain web service independence and framework
extensibility.
Different strategies were proposed to solve the migration
issue. Christoph et al. [17] addressed migration challenges by
defining a set of service migration patterns and a
methodology to explain the application of each pattern. Zibin
et al. [27] studied redundancy-based fault tolerance strategies
to achieve reliable service-oriented architecture and
introduced an evaluation selection framework for fault
tolerant web services. Helmut et al. [28] showed a
relationship between service level and utilization metrics in
the context of virtual machine live migration. The most
significant utilization metrics were identified to establish a
service level prediction model. We can use JMX metrics to
establish service and cloud levels prediction models. Also,
different replication methods were developed in [28]. Julio et
al. [29] used clusters to get highly available WSs by
replicating services. The solution consists in grouping one or
more web services inside a unique wrapper published as a
WS. The wrapper represents a virtual view and it is deployed
on an intermediate instance different from the client and the
provider. Instead of clusters, we used hybrid clouds to have
more control over both web services and deployment
resources. In addition, besides services replication we added
service transfer task to increase management flexibility of
deployment resources.
VIII. CONCLUSION
The paper discussed a lightweight migration framework
of web services on hybrid cloud platforms. The goal of the
framework is to simplify the migration process and keep
independence and interoperability of web services. We based
the framework on three web services: Control WS, Migrator
WS and Cloud WS to respectively represent three migration
levels: control level, migration level and cloud level. The
three framework web services are loosely coupled and
configurable. To control web services and cloud instances,
we used JMX technology that is a part of Java platform to
create dynamic web service and cloud monitors. Finally, we
did an experimentation to simulate high peak demand
scenario and we showed an improvement of execution time
and CPU usage by deploying a CPU intensive web service
and the migration framework. A future work will focus on
creating prediction models to automate the migration task and
the cloud management level. In addition, security policies
will be studied to deploy web services on public clouds.
REFERENCES
[1] Peter Mell et al., The NIST definition of cloud computing, 2011.
[2] Sultan et al., Data Security, Privacy, Availability, and Integrity in
Cloud Computing: Issues and Current Solutions, (IJACSA)
International Journal of Advanced Computer Science and
Applications, 2016
[3] Sandor Acs et al., A novel cloud bursting technique, IEEE 9th IEEE
International Symposium on Applied Computational Intelligence and
Informatics (SACI), 2014.
[4] Gerd Breiter et al., A Framework for Controlling and Managing Hybrid
Cloud Service Integration, IEEE International Conference on Cloud
Engineering (IC2E), 2013.
[5] Pritesh Jain et al., A Novel Cloud Bursting Brokerage and Aggregation
(CBBA) Algorithm for Multi Cloud Environment, Second
International Conference on Advanced Computing Communication
Technologies, 2012.
[6] Mohammad Reza Hoseiny Farahabady et al., Pareto-Optimal Cloud
Bursting, IEEE Transactions on Parallel and Distributed Systems,
2014.
[7] Hao Wu et al., Automatic Cloud Bursting under FermiCloud,
International Conference on Parallel and Distributed Systems, 2013.
[8] Young Choon Lee et al., Cloud Bursting Scheduler for Cost Efficiency,
IEEE 10th International Conference on Cloud Computing (CLOUD),
2017.
[9] Andrii Zhygmanovskyi et al, Distributed Cloud Bursting Model Based
on Peer-to-Peer Overlay, 3rd International Conference on Future
Internet of Things and Cloud, 2015.
[10] Song Wu et al., HybridScaler: Handling Bursting Workload for Multi-
tier Web Applications in Cloud, 15th International Symposium on
Parallel and Distributed Computing (ISPDC), 2016.
[11] Sriram Kailasam et al., Optimizing Ordered Throughput Using
Autonomic Cloud Bursting Schedulers, IEEE Transactions on
Software Engineering, 2013.
[12] Sriram Kailasam et al., Optimizing Service Level Agreements for
Autonomic Cloud Bursting Schedulers, 39th International Conference
on Parallel Processing Workshops, 2010.
[13] Djawida Dib et al., SLA-Based Profit Optimization in Cloud Bursting
PaaS, 14th IEEE/ACM International Symposium on Cluster, Cloud
and Grid Computing, 2014.
[14] Srijith K. Nair et al., Towards Secure Cloud Bursting, Brokerage and
Aggregation, Eighth IEEE European Conference on Web Services,
2010.
[15] Tekin Bicer et al., A Framework for Data-Intensive Computing with
Cloud Bursting, IEEE International Conference on Cluster Computing,
2011.
[16] Philipp Leitner et al., A Framework and Middleware for Application-
Level Cloud Bursting on Top of Infrastructure-as-a-Service Clouds,
IEEE/ACM 6th International Conference on Utility and Cloud
Computing, 2013.
[17] Christoph Fehling et al., Service Migration Patterns - Decision Support
and Best Practices for the Migration of Existing Service-based
Applications to Cloud Environments, Proceedings of the 6th IEEE
International Conference on Service-Oriented Computing and
Application (SOCA), 2013.
[18] Oracle, Trail: Java Management Extensions (JMX), available online at
https://docs.oracle.com/javase/tutorial/jmx/index.html.
[19] Oracle, Standard MBeans, available online at
https://docs.oracle.com/javase/tutorial/jmx/mbeans/standard.html.
[20] Joe Meehean et al., A Service Migration Case Study: Migrating the
Condor Schedd, 2005.
[21] IBM, JMX Monitors, available online at
https://www.ibm.com/support/knowledgecenter/en/SSDKXQ_6.3.0/c
om.ibm.itm.doc_6.2.3/agentbuilder623_user77.htm.
[22] Xinfeng Ye et al., A Middleware for Replicated Web Services,
Proceedings of the IEEE International Conference on Web Services
(ICWS’05), 2005.
[23] Jorge Salas et al., WS-Replication: A Framework for Highly Available
Web Services, Proceedings of the 15th international conference on
World Wide Web, 2006.
[24] Xuanjia Qiu et al., Cost-Minimizing Dynamic Migration of Content
Distribution Services into Hybrid Clouds, The 31st Annual IEEE
International Conference on Computer Communications (IEEE
INFOCOM 2012), 2012.
[25] Mohanned Kazzaz et al., A Web Service Migration Framework, The
Eighth International Conference on Internet and Web Applications and
Services (ICIW 2013), 2013.
[26] Mohanned Kazzaz et al., Restful-based Mobile Web Service Migration
Framework, IEEE 6th International Conference on AI & Mobile
Services, 2017.
[27] Zibin Zheng et al., A Distributed Replication Strategy Evaluation and
Selection Framework for Fault Tolerant Web Services, IEEE
International Conference on Web Services, 2008.
[28] Helmut Hlavacs et al., Predicting Web Service Levels During VM Live
Migrations, 5th International DMTF Academic Alliance Workshop on
Systems and Virtualization Management: Standards and the Cloud,
2011.
[29] Julio Fernández Vilas, High Availability with Clusters of Web
Services, 6th Asia-Pacific Web Conference (APWeb 2004), 2004