dynamic cloud service selection using an adaptive learning mechanism in multi-cloud computing

Accepted Manuscript

Title: Dynamic cloud service selection using an adaptivelearning mechanism in multi-cloud computing

Author: Xiaogang Wang Jian Cao YangXiang<ce:collaboration id="colb0005"></ce:collaboration>

PII: S0164-1212(14)00239-8DOI: http://dx.doi.org/doi:10.1016/j.jss.2014.10.047Reference: JSS 9408

To appear in:

Received date: 21-7-2014Revised date: 24-10-2014Accepted date: 27-10-2014

Please cite this article as: Wang, X., Cao, J., Xiang, Y.,Dynamic cloud service selectionusing an adaptive learning mechanism in multi-cloud computing, The Journal of Systemsand Software (2014), http://dx.doi.org/10.1016/j.jss.2014.10.047

This is a PDF file of an unedited manuscript that has been accepted for publication.As a service to our customers we are providing this early version of the manuscript.The manuscript will undergo copyediting, typesetting, and review of the resulting proofbefore it is published in its final form. Please note that during the production processerrors may be discovered which could affect the content, and all legal disclaimers thatapply to the journal pertain.

http://dx.doi.org/doi:10.1016/j.jss.2014.10.047

http://dx.doi.org/10.1016/j.jss.2014.10.047

of 19

Accep

ted

Man

uscr

ipt

1

Dynamic cloud service selection using an adaptive learning

mechanism in multi-cloud computing Xiaogang Wanga,b,∗, Jian Caoa, and Yang Xiangc, Senior Member, IEEE

aDepartment of Computer Science and Engineering, Shanghai Jiao Tong University, Shanghai, 200240, P.R. China bSchool of Electronics and Information, Shanghai Dianji University, Shanghai, 200240, P.R. China

cSchool of Information Technology, Deakin University, 221 Burwood Highway, Burwood, VIC 3125, Australia

Abstract—Cloud service selection in a multi-cloud computing environment is receiving more and more attentions. There is an abundance of emerging cloud service resources that makes it hard for users to select the better services for their applications in a changing multi-cloud environment, especially for online real time applications. To assist users to efficiently select their preferred cloud services, a cloud service selection model adopting the cloud service brokers is given, and based on this model, a dynamic cloud service selection strategy named DCS is put forward. In the process of selecting services, each cloud service broker manages some clustered cloud services, and performs the DCS strategy whose core is an adaptive learning mechanism that comprises the incentive, forgetting and degenerate functions. The mechanism is devised to dynamically optimize the cloud service selection and to return the best service result to the user. Correspondingly, a set of dynamic cloud service selection algorithms are presented in this paper to implement our mechanism. The results of the simulation experiments show that our strategy has better overall performance and efficiency in acquiring high quality service solutions at a lower computing cost than existing relevant approaches.

Keywords—Dynamic cloud service selection; cloud service broker; service registration; initial clustering; adaptive learning mechanism

1. Introduction

Cloud services describe various computing collections that indicate different abilities to run the applications of users across the systems or platforms of multiple enter-prises over the Internet. In cloud computing businesses, there are different types of cloud services, e.g., storage services, computing services and application services, which are respectively accommodated by many cloud service providers, e.g., GoGrid’s Cloud Platform (2013), Amazon S3 (2013), Google App Engine (2013), Windows Azure (2013) and Salesforce-Cloud (2013) etc. More and more users establish applications by using a pattern of hybrid cloud services which integrate local cloud services with public cloud services, e.g., we constructed our own photo sharing application in which we developed a mod-ule of picture inputting, and then selected software on a cloud picture editor for online editing from some cloud application providers. We finally selected a cloud storage service for storing the substantial number of pictures into the cloud disks where we made some different selections of cloud services for integrating the application. With

growing demands from users, as this example demon-strates, a lot of services accessed through interface invoca-tion in the Internet can also be extended into common cloud services, i.e., cloud services can be viewed as a kind of Web services in a cloud computing environment. Due to increasingly preferred requirements of users for cloud services and differentiated quality of cloud services from numerous cloud service providers in terms of running performance (e.g., the number of CPUs or the storage capacity) and using price, it is no wonder users become slightly perplexed. Thus, how to select the most appropriate cloud services to satisfy users’ various online applications becomes very important. The general practice of cloud service providers is to advertise or publish various levels of cloud services based on their different performance and the quoted prices on their Web sites. Users are then left to select one or more services for the required tasks. This method has some drawbacks in that selections of users are passive and the running statues of cloud services selected are changing, even though providers promise the quality of their cloud services are the best. However, for users, many online applications need higher stability as well as lower prices in terms of the selected services. To let the cloud service selection automatically adapt to the diverse cloud service environments, a natural choice would be to adopt brokers to manage the cloud service resources and to help users fulfill the work of the service selection by means of using an adaptive method. The brokers may look like agents,

———————————————— • ∗ Corresponding author at: Department of Computer Science and

Engineering, Shanghai Jiao Tong University, Shanghai, 200240, P.R. China. Tel.: +86 13651963843.

• E-mail addresses: {[email protected], [email protected]} (Xiaogang Wang), [email protected] (Jian Cao), [email protected] (Yang Xiang).

of 19

Accep

ted

Man

uscr

ipt

2

which are the concept in the field of distributed artificial intelligence, but they can solve distributed tasks for dif-ferent fields, and own some autonomous and pro-active characteristics that cloud services do not have (Huhns, 2003; Huhns et al., 2005).

Many applications (e.g., some daily activities (Isern et al., 2011) and theoretic and engineering problems) use agent technologies to process their contained services. Agents may make optimized selections for continuous service demands according to current statuses and any changes to services managed by them. The existing work of (Sim, 2009, 2012) used autonomous agents to manage cloud resources and employed an agent-based distributed problem solving approach to support the cloud service selection and composition. The method (Gutierrez-Garcia and Sim, 2013) presented horizontal and vertical selection and composition through using consumer agents, broker agents, service provider agents and resource agents, and the self-organizing approach based SCTs and SR-CNP regulated the selection and composition process at the time of service failures.

However, current technologies of the service selection of multiple tasks still encounter new challenges regarding certain problems: (i) most of the managed cloud service information on some functions and their performance remains static once they are registered into broker agents by respective providers, and there is little possibility of updating their abilities to fulfill the work of selection. Because of the relative independence of cloud service providers and the changeability of services provisioned, successful services performed at current time may not be useful the next time, and new or better services may also emerge. As the centralized processing model for cloud service selections cannot deal with the above situations, we must use a distributed method to solve the dynamic service selections; (ii) the search cost of cloud services is very high due to the shortcomings of some models, and the existing centralized or distributed methods ((Liu et al., 2004; Hwang et al., 2008; Channa et al., 2005; Oh et al., 2007) still need to cost much more to find service selection solutions to complete the required tasks of users; and (iii) current methods lack an efficient mechanism on service selection when changes of service status happen. We should take advantage of a dynamic method to handle this troublesome problem.

In terms of the above motivation, a dynamic cloud ser-vice selection model and strategy are proposed, which will help users efficiently realize their cloud service re-quirements. In contrast to existing work, we take the per-formance (e.g., the number of CPUs or the stor-age capacity) and corresponding price of different cloud services into consideration, and let the cloud service bro-kers dynamically select the cloud services with the best ratio of performance to price. The model proposed in this paper uses a kind of adaptive learning approach to con-duct cloud service selections at a smaller cost in the runtime.

The contributions of this paper are as follows: (1) A cloud service selection model that adopts cloud

service brokers is provided. It runs the process of dy-

namic cloud service selection and contains three layers, the user layer, cloud service broker layer and cloud ser-vice resource layer. Each of the cloud service brokers manage some cloud service information registered by the cloud service providers.

(2) A dynamic cloud service selection strategy de-ployed in the cloud service brokers is devised. It provides a real time selection of services and an adaptive learning mechanism that supports dynamic service selection. The mechanism involves incentive, forgetting and degenerate functions that can realize the self–adaptive regulation for optimizing next service selection according to the status of current service selection.

(3) Based on the proposed strategy, a set of dynamic cloud service selection algorithms are presented, which provide detailed steps of the cloud service selection.

(4) Through elaborate simulation experiments, we evaluated the performance of our method, and the multi-profile results demonstrate its advantages and efficiency.

The remainder of this paper is organized as follows. Section 2 introduces a problem scenario and our cloud service selection model. In Section 3, a dynamic cloud service selection strategy is proposed. Section 4 describes the cloud service selection algorithms based on the cloud service selection model and strategy. Experimental setups and results are shown in Section 5, and Section 6 provides summaries of related work. The conclusion to this paper and future work is presented in Section 7.

2. Problem scenario and cloud service selection model

Cloud services can be viewed as special Web services (computing units) under a cloud computing environment, such as computing services, storage services and applica-tion services, etc. These cloud services may be selected to satisfy the users’ tasks in terms of service integration where it is slightly difficult for semantic service technolo-gies to directly handle the dynamic service selection. Adopting service broker technology is an efficient means to carry out the intermediary service management and self-learning to facilitate the cloud service selection.

Thus, we construct a cloud service broker-based service selection model (CBRSM) whose aim is to conduct cloud service management and selection. Encapsulating one or more piece of cloud service information into a cloud ser-vice broker (CBR) makes the cloud service selection flexi-ble and controllable. Subsequently, an adaptive learning mechanism is used to carry out the work of dynamic cloud service selection for the requirement tasks of users. The CBRSM is composed of three parts: user layer, cloud service broker layer, and cloud service resource layer as shown in Fig. 1. Many cloud service resources supply users through opening their invocation APIs on the Inter-net, and cloud users may efficiently select their desired services by using cloud service brokers. Hence, our focus is how to help users dynamically select the best matching services through adopting the CBR when facing so many cloud providers. Let’s illustrate the structure of the CBRSM as follows.

(1) The user layer consists of worldwide users accessed

of 19

Accep

ted

Man

uscr

ipt

AUTHOR ET AL.: TITLE 3

by the Internet and their respective user agents (UAs). The tasks with different preferred performance (e.g., the number of CPUs or the storage capacity) and correspond-ing prices from different users can be submitted to their user agents who are in charge of collecting respective re-quirement tasks, sending them to the CBR in the cloud service broker layer, collecting the selected cloud services, and outputting the service invocations to users. Before sending the requests of users to the cloud service broker layer, the UA must select an appropriate CBR to push an optimal cloud service for each of the tasks.

(2) The cloud service broker layer is the key part of the en-tire model which carries out the cloud service selections. It consists of many cloud service brokers (CBRs) being clustered into different service levels (see Section 4) in terms of the performance (such as the number of CPUs or the storage capacity) and prices of the different cloud ser-vices through our algorithms. Each CBR manages some registered cloud service information.

SMi

Cloud Users

CS11

CS12

CS21

CS22 CS23

CSn1

Cloud Service Resource Providers

User1 User2 UserK Userl

CBRjCBR1

UserLayer

CloudServiceBrokerLayer

CloudServiceResource Layer

SM1 SM2 SMn

CSi2 CSi3 CSn2

CSi1

CBRm

CSAPIs

CSAPIs

CSAPIs

CSAPIs

Dynamic cloud serviceselection

CBR2

Invoke cloud service APIs

UA1 UA2 UAk UAl

Fig. 1. The cloud service selection model.

A cloud service broker is selected by a user agent to

perform the work of cloud service selection, where the purpose of using different levels of clustered CBRs is to improve the efficiency of cloud service selections. This is because it can optimize the selection by the adaptive learning according to the dynamic change of cloud ser-vice statuses. In these cloud service brokers, the currently appropriate one is selected to execute our adaptive learn-ing algorithm (see Section 4) to search for a best matching cloud service. Meanwhile, each of the CBRs may also re-ceive registration messages for the cloud service from the cloud service resource layer. Since more and more tasks are requesting a guarantee that the CBR will search the optimal cloud service as quick as possible, the informa-tion of one or more cloud services registered in the CBR may be removed due to going beyond the time limitation used or waiting. Other updated or new cloud service in-formation can be registered into the CBR to attend the

next round of service selection. Finally, the result of the cloud service selection executed by the selected CBR is returned to the UA whose user may invoke the service by the service API. Other tasks of service selections may be fulfilled simultaneously or successively.

(3) The cloud service resource layer involves substantial cloud services supplied by many cloud service providers, with service monitors (SMs) surveiling cloud services subordinate to respective providers. Cloud services are general public clouds as well as Web services being en-dowed cloud computing properties and units, which are called CS. The SMs can help respective providers register cloud service information into the CBRs, and monitor current statuses on whether the failures (offline) of some cloud services occur. Besides, each of the providers de-fines CS interfaces (called CS APIs) as the means invoked by users. The CS APIs are used after finishing the process of cloud service selection.

In terms of the above depiction, the formal definition of the CBRSM is given as follows. Definition 1. The cloud service selection model based on the cloud service broker is defined as a tuple CBRSM = (UA, CBR, SM, DCS), where

— UA is a set of user agents, UA = {UA1, UA2, …, UAk, …, UAl }.

— CBR defines a set of cloud service brokers having been clustered, CBR= { 1CBR , 2CBR , …, jCBR , …,

mCBR }, a jCBR ∈ CBR denotes a level of service group

and manages some cloud service information regis-tered.

— SM is a set of service monitors, SM = {SM1, SM2, …, SM i, …, SMn}, and the number of providers is gener-ally much more than that of cloud service brokers, i.e., n >> m.

— DCS:{ , , }

with updated xx I F D

jCBR CBR f∈

→ ∑ denotes a

dynamic cloud service selection strategy that in-volves an adaptive learning mechanism of the clus-tered CBR set and related algorithms, and its function is to select a best matching jCBR from the CBR set,

where I F D

xx

f{ , , }∈∑ is the sum of adaptive learning

functions’ value, and the I, F, D respectively denotes incentive, forgetting and degenerate strategies consti-tuting the learning mechanism as described in the next section.

3. Dynamic cloud service selection

In light of the proposed model, we further provide a dy-namic cloud service selection strategy (DCS) used in each cloud service broker. It mainly encompasses the initializ-ing cluster, the basic process of cloud service selection and the adaptive learning mechanism.

of 19

Accep

ted

Man

uscr

ipt

4

3.1. Initializing cluster of CBR

The cloud service broker is the main body performing DCS and its algorithms, and the related definitions are given below. Definition 2. A cloud service broker is defined as a tuple

jCBR = (AID, CS, jZ , ,M jCS ) ∈ CBR, where

— AID is the identity of a cloud service broker jCBR ,

and it is the unique symbol in the distributed running environment.

— CS is a set of cloud services containing some basic

information (e.g., ,( ) ritPei jPr , see definition 3) managed

by jCBR .

— jZ denotes the clustered center of the CS set.

— ,M jCS is the cloud service iCS ∈ CS with Max{ ,( ) ritPei jPr }.

The service information table (SIT) of jCBR is described

in Table 1.

Table 1 Service information table (sit) of jCBR .

The cluster-ing center

The set of regis-tered CS

The iCS with

Max{ ,( ) ritPei jPr }

jZ { iCS | i ∈ [1, n] } ,M jCS

Definition 3. The CS is a set of cloud services in a cloud

service broker jCBR , denoted as CS = { 1CS , 2CS , …,

iCS , …, nCS }, where a cloud service iCS is a 4-tuple (URL,

,( ) ritPei jPr , rit , Fit ), which is the basic information of a cloud

service iCS registered by a service monitor SM i, where

— URL denotes the link address and access interface of

iCS offered by its provider. The invocating mode of

cloud services is considered feasible in a hybrid cloud application, and a cloud user can use the cloud ser-vices offered by the cloud provider through the web address links and interface invocation.

— When selecting a cloud service, users are generally concerned about its current running performance and price. Users prefer the cloud service to have higher performance and lower price, therefore a preferred requirement of a user is in direct proportion to the performance, but inverse proportion to the price. In

view of this idea, PePr is defined as a value set of the

ratio of performance to price on the cloud services,

i.e., PePr = { 1

1( ) rtPe

Pr , 2

2( ) rtPe

Pr , …, ( ) ritPeiPr , …, ( ) rn

n

tPePr }.

( ) ritPeiPr is the ratio of performance to price on the

cloud service iCS registered by the service monitor

SM i, and there are n cloud service basic information corresponding to each of the elements of the CS set.

,( ) ritPei jPr is the ratio of performance to price ( ) ritPe

iPr of a

cloud service iCS registered into a cloud service bro-

ker jCBR .

— tri is the registration time of iCS .

— Fit is the first used time of iCS .

A user may submit a preferred performance (e.g., the number of CPUs or the storage capacity) and correspond-

ing price on iCS . Its user agent then calculates the ratio of

the preferred performance to price and sends the value to an appropriate service broker jCBR . Finally, the jCBR se-

lects the cloud service that best matches the value ,( ) ritPei jPr .

The information of iCS is shown in Table 2.

Table 2 Basic information of each registered iCS in jCBR .

The invoked address of iCS URL

The ratio of performance to price

on iCS registered by iSM ,( ) ritPei jPr

The registration time of iCS rit

The first used time of iCS Fit

Definition 4. The clustered center of a set of cloud ser-

vices is defined as jZ =

,

1,

( )

( ) rij tPe ri

i jP jr

tPei jPr

i BnC Rn

∑ , where nj is

the number of cloud services registered into the clustered class set jCBR , jZ is the clustered center of the cloud ser-

vice broker jCBR . There are m clustered classes that con-

tain their respective value set ,( ) ritPei jPr denoting the ratio of

performance to price ( ) ritPeiPr in jCBR , and 1 ≤ j ≤ m.

Let’s consider an example of a network map which needs three types of cloud service applications, such as the directly accessed web application service, the cloud map computing service and the cloud data storage service. Each type of service has a lot of choices, and we need to assist the user to select the optimal cloud services from the different jCBR . We give the specific expression of the

web application service from the example detailed data and symbols from definition 1 to 4 as follows.

Assuming the web application service set managed by the unclustered CBR in the beginning is {a1, a2, a3, a4, a5,

a6} registered by different iSM , i.e., the set

of 19

Accep

ted

Man

uscr

ipt


{ 1SM , 2SM , 3SM , 4SM , 5SM , 6SM }, initial ratio of per-

formance to price ( ) ritPeiPr of the corresponding elements of

the service set is {6.000, 6.250, 1.500, 2.333, 2.500, 2.833},

the corresponding registration time rit is the set {1, 3, 8, 5,

2, 10} and the corresponding first used time Fit is the set

{13, 15, 18, 14, 16, 20}. And let the number of the clustered set be 3, so the clustered sets become 1CBR = {a1, a2},

2CBR = {a3} and 3CBR = {a4, a5, a6} whose entire value sets

are 1CBR = { 1

1,1( ) rt

PePr = 6.000, 2

2,1( ) rt

PePr = 6.250}, 2CBR =

{ 3

3,( ) rt

2

PePr = 1.500} and 3CBR = { 4

4,( ) rt

3

PePr = 2.333, 5

5,( ) rt

3

PePr =

2.500, 6

6,( ) rt

3

PePr = 2.833} and the corresponding clustered

center of CBRs is the set { 1Z = 6.125, 2Z = 1.500, 3Z = 2.555}

derived by definition 4. The calculating methods of the other two types of cloud services are similar to the web application service but only their data is different.

3.2. The basic process of cloud service selection

Each of the users from the Internet may send some cloud service requirements with preferred performance and price to its user agent UA. The UA collects the requests from the user and forms some independent tasks. The UA then needs to select an appropriate cloud service broker CBR for each of the tasks because the CBR has been clus-tered into m class jCBR and the user agent only needs to

use a best matching one to achieve each task. By doing this, we may greatly reduce the searching time and cost of cloud services. Thus, to achieve the above aim, the defini-tion of best distance computing is given below. Definition 5. The distance between a user agent’s re-quirement task and a cloud service broker jCBR is defined

as ,k j k jT ZD −= , and the Min{ ,k jD } is the best distance,

where kT is a task with a preferred ratio of performance

to price sent by the user agent UAk , and jZ is the clus-

tered center of the jCBR .

jCBR corresponding to the Min{ ,k jD } will be selected,

and after this, the cloud service ,M jCS in the jCBR is

fetched by searching the service information table SIT of the jCBR , where all of jCBR (1 ≤ j ≤ m) are distributed. An

optimal service selection of each of the tasks is dynami-cally conducted, and the service objects selected are a set of cloud services registered in the best jCBR that match

with each task respectively. The selected services are sent to the user agent UA, and then returned together to the user. Finally, the user may invocate these services’ APIs

by their URL. The basic process of cloud service selection for each task from users is shown in Fig. 2.

UAk

CBRjCBR1 CBRmCBR2

selects an appropriate CBR

CBRj

gets a desired CBR

manages some CSs registered

CS11 CS2

2

CSi2 CSn

2CSi1

CS23

CSix

selects the best cloud service

SMi Adaptive learning

updates CBRj

SM1

SM2

SMn

registercloud services

finished

started

optimizescloud services

has no available cloud service

Fig. 2. The basic process of cloud service selection.

3.3. Adaptive learning mechanism of clustered CBR

The selected cloud service broker jCBR can calculate the

optimal cloud service with a maximum ratio of perform-

ance to price ,( ) ritPei jPr managed by itself to the user. How-

ever, due to the changing situation in the dynamic cloud computing environment, e.g., the failure of some cloud services and the CBR’s capacity limitation, and previous cloud services selected may not be available to the user again. To guarantee the quality of cloud service selection and avoid processing the blind search of the system, an adaptive learning mechanism of clustered CBRs is de-vised, which involves the following three strategies. (1) Incentive strategy for earlier registration A cloud service broker jCBR ∈ CBR should manage a

certain amount of cloud services to meet users’ demands in case failure of some managed cloud services occurs or the capacity of these services becomes lower. We may consider a case where some people’s daily business is similar to intermediary services in which service brokers often provide an incentive mechanism to attract registra-tion of a third party or individual owning respective ser-vices. This is because they intend to obtain more service resources to increase the selected chances of user re-quirements, thereby gaining more profit. Moreover, those service providers must register their service information into suitable service brokers as early as possible, since earlier registration means less competition, and increased likelihood of being selected by users.

of 19

Accep

ted

Man

uscr

ipt

6

Based on the above ideas, an incentive function for ear-lier registration of providers in each jCBR is defined by

an exponent measure method as follows:

,1( ) ( ) ( )trit riR tPe

I R i jPref t−

= + ⋅ (1)

where tR is the time point carrying out the adaptive learn-ing algorithm for each cloud service in the jCBR due to

the failure of previous cloud service selection and optimi-zation of the next selection. We define the function must satisfy tri ≤ tR, since these are generally the actions of reg-istration prior to those of adaptive learning. When tR con-

tinually increases, ri

R

tt ∈ (0, 1] and

I Rf t( ) ∈ [1+ e

1 ,

2) ,( ) ritPei jPr⋅ . It is obvious that if tR is relatively fixed, for

smaller tri, I Rf t( ) is greater. This implies that if the regis-

tered time of a cloud service is earlier, its ratio of per-

formance to price PePr can be bigger. Here, the cause for

adopting the definition of equation (1) is that the function containing a single e exponential function possesses some excellent natures such as monotonicity, continuity and derivability throughout the rest of the paper. (2) Forgetting strategy for delaying use The processing capacity of a cloud service broker jCBR

cannot exceed its upper bound, so we should keep the fitting number of cloud services managed in the jCBR .

Since the invoked work of a cloud service is dynamic, we cannot instantly remove a piece of cloud service informa-tion not being used in current time. We should gradually

reduce the ratio of performance to price PePr of a cloud

service and remove it only if it exceeds the limitation. Therefore, a forgetting function for delaying use is de-fined as

,1

2( )( ) ( )

t tR rit tFi ri

ritPeF R i jPr

ef t−− −

= ⋅ (2)

in which we define tFi > tR ≥ tri because a jCBR only se-

lects an optimal cloud service the first time if it completes a round of adaptive learning and value regulation. When

tR continually increases, R riFi ri

t tt t

−− ∈ [0, 1) and

F Rf t( ) ∈

[0, e 12− ) ,( ) ritPe

i jPr⋅ . It is also obvious that if tR is relatively

changeless, the bigger tFi, is, the smaller F Rf t( ) will be. It

denotes that if the first used time of a cloud service is later,

its PePr can be smaller.

(3) Degenerate strategy for frequent use The performance of a cloud service broker jCBR may de-

cline due to frequent use of cloud services in some time, thus we may conduct the appropriately degrading work for cloud services in the jCBR to alleviate the running

load. For this, a degenerate function for frequent use is given as

,( ) ( ) ritPeD R i jPrf t = ⋅δ , and 1

tR tNit trit tR rieδ− ∑

=− += (3)

where Rt tNit tri∑

= is the used frequency of cloud services

managed by the jCBR from its registration time to adap-

tive learning time. When tR continually increases,D Rf t( ) ∈

[triiNe−

, 1] ,( ) ritPei jPr⋅ . We can see that if the

Rt tNit tri∑

= of the

cloud services is greater, the ratio of performance to price PePr may be less, i.e., D Rf t( ) becomes smaller.

Theorem 1. The adaptive learning system using the dynamic

cloud service selection strategy (DCS) in CBRSM is stable. Proof. In light of the Lyapunov stability theory, any deci-

sion about whether a dynamic system is stable requires searching an energy function E that varies with system changes related to state and time, and whose value is positive. The state space point corresponding to the minimal value of E is just the asymptotically stable equilibrium point, i.e., let E x t( ) 0, > denote the energy

function of a system, and if dE x t dt( ), 0< means the

system energy gradually reduces, the system tends to-

wards stability, and if dE x t dt( ), 0> denotes that the

system constantly absorbs the energy from the external world, the system cannot be stable. Based on this con-cept, we construct the energy function of the adaptive learning system in each round of cloud service selection according to equation (1), (2) and (3) as follows:

,1( ) 1) ( (1, (( ( ) ( )) ( ))) ( ) riR I R F R D RtPe Pei jPr PrE t f t f t f t−= − + − ⋅ + .

On the right side of the above equation, it expresses, in the extreme case of all three functions taking effect, the sum of the adding, reducing and degrading value PePr of each cloud service in a used cloud service broker

jCBR through incentive, forgetting, and degenerate

functions respectively. The entire inference process of the energy function is described below.

1

,

,

1( ) / ( 1) ( (1, (( ( ) ( )) ( )))

1)

2

) ( )

( )ʹ (1 )ʹ (1 )ʹ) ( )

(

R

ri

t tt tR ri Nit t t tt Fi ri riri

t tt R ri riR

R R I R F R D R R

ri

tPe Pei jPr Pr

tPei jPr

t

d d ddE t t f t f t f t t

ee e

− − ∑− =

− +−

−= − + − ⋅

⋅

+ /

= (−

( + − + −

= 12 2 ,

12( ) ( 1)

( ))

RtR tNit t t tt R ri ririt t t tt Fi ri R ri riR

R

tti

t tri

Fi ri R ri

tPei jPr

N

t tt t te e e

− ∑− =− − +=−

− − +⋅ −

∑⋅ − ⋅ ⋅

Because of tri ≤ tR and tFi > tR, we can derive

( ) /, 0R RPePr ddE t t ≤ .

of 19

Accep

ted

Man

uscr

ipt


Therefore, the adaptive learning system adopting DCS in CBRSM is stable, and the jCBR does not ex-

haust its storage and computing resources when it dynamically receives cloud services registered by pro-viders and when it carries out the adaptive learning algorithm for the cloud service selec-tion.

Theorem 2. If the cloud service resource providers are rational

when registering their cloud services under the adaptive learning mechanism, and the probabilities of users’ require-ments are uniform distribution in a period of time, then se-lecting solutions for cloud services can certainly be obtained through a cloud service broker.

Proof. If the cloud service resource providers are rational when registering their cloud services into a cloud ser-vice broker jCBR , they should comply with the three

strategies of the adaptive learning mechanism. Let iN

and kN be respectively the number of cloud services

registered by a service monitor iSM and that of the

ones requested by a user agent UAk. pN and uN are

expressed as the average number of cloud services registered by providers and that of the ones requested by the users in △t respectively so that

1( )ip

nitN

N =Δ= ∑

, 1( )ku

lktN

N =Δ= ∑

, and tFi - tri ≤ △t.

In addition, assuming that a user sends one require-ment task one time, since the probabilities of users’ requirements are the uniform distribution and equa-tion (1), (2) and (3), we can derive the respective ex-

pected ,( ) ritPei jPr in the time interval [0, △t] below.

1

, 0

1(1

2( )( ) )

tR tt tR ri Nit t t tt Fi ri riri

t ttri R riRp

ttPei j pPr N e

eE e− − ∑− =

− +−=

−⋅ ⋅ + − −∑ ,

and , 011( ) ( )ri

u

ttPei j uPr lNE −= ⋅ ⋅ ∑ .

There is the intuitive fact that the number of various cloud service resource providers is generally more than the number of users having valid requirements in some time, e.g., △t, therefore, it exists n ≥ l, and further

has p uN N≥ .

According to the value interval of xf in Section 3.3,

and { , , }I F Dx ∈ , we can reason below.

0

0

,

,

1(

2

(2

2 1)

3)

( )

( )

ri

ri

t

p p

t

p

tPei jPr

tPei jPr

N

N

e

e

E −⋅ − −

−⋅

> ⋅

= ⋅

∑

∑

Since there is l 1 in the expression of uE , it has

le 1

12

3−

−> .

Thus, we derive p uE E> from the reasoning process

above, and this result indicates that cloud service re-source providers can offer enough cloud services to us-ers for selecting their cloud service solutions through a cloud service broker.

Let’s continue the example presented in Section 3.1.

Suppose that after 1 round of adaptive learning among

each clustered set jCBR , the value ,( ) ritPei jPr of each regis-

tered cloud service and their clustered center value jZ

will be updated by using the adaptive learning mecha-nism. Their new value will be used in the next round of selection. Therefore, we may, in real time, select an opti-

mal web application service with the new value ,( ) ritPei jPr .

According to updated jZ , the corresponding data is cal-

culated below. Assuming that before the first round of learning among jCBR occurs, the data of all different variables is

shown, as in the example from Section 3.1. When com-

pleting this round of learning and the time point Rt is 12,

the results of all variables are updated, such as 1CBR =

{ 1

1,1( ) rt

PePr = 10.310, 2

2,1( ) rt

PePr = 12.500}, 2CBR = { 3

3,( ) rt

2

PePr = 3.000}

and 3CBR = { 4

4,( ) rt

3

PePr = 4.009, 5

5,( ) rt

3

PePr = 4.296, 6

6,( ) rt

3

PePr =

5.666}, and the corresponding clustered center of allCBRs

is the set { 1Z = 11.405, 2Z = 3.000, 3Z = 4.656}. At this time,

a new web application task from a user with its preferred demands (e.g., requesting the number of qualified CPU units (Pe) is 3 and the price per CPU unit hour (Pr) is

$0.280. Therefore, the task value PePr is 10.714) is submit-

ted. From the updated new data of jCBR , our system se-

lects the optimal clustered center value ( 1Z = 11.405) of

1CBR as it is the closest to the user’s desired value ( PePr =

10.714) by definition 5, and further fetches the web appli-

cation service a2 whose maximum value 2

2,1( ) rt

PePr is 12.500

among the 1CBR . (4) The adaptive learning utility of jCBR

The adaptive learning algorithm adopting DCS can obtain certain rewards due to completing the requirement tasks of users as well as paying for costing the computing and communication resources. So the adaptive learning utility

,j kU of a cloud service broker jCBR is defined as

of 19

Accep

ted

Man

uscr

ipt

8

, , , ,j k j k j R j MU Cost CostReward= − −

where ,j kReward denotes the reward obtained by the

jCBR after successfully completing the cloud service se-

lection of the kUA ’s tasks, e.g., 10 cents per task, that is,

,j kReward = 10 kjN , where k

jN is the cloud selection number

of the kUA ’s tasks completed successfully.

And ,j RCost is the total cost of adaptive learning of

jCBR and is defined as

, ,, , ,

I F Dj R Me j k P j kCost MC C P= ⋅ + ⋅∑ ∑

where MeC means the communication cost per message,

e.g., 0.05 cent, ,j kM∑ defines the number of exchanged

messages when completing the cloud selection of the kUA ’s tasks, PC is the processing cost per millisecond,

e.g., 0.05 cent, and , ,

,I F D

j kP∑ denotes the processing time

when achieving the cloud selection of the kUA ’s tasks by

three adaptive learning functions. Finally,

,j MCost is the management cost of jCBR and is

defined as

,j M Ma jCost CSC= ⋅

where MaC defines the management cost of the internal

memory of table information per cloud service jCS , e.g.,

0.01 cent, and jCS denotes the total number of jCS table

information.

4. Dynamic cloud service selection algorithms

In this section, we provide the detailed dynamic cloud service selection algorithms. These are comprised of ini-tial clustering of the cloud service broker CBR, selection of a clustered set jCBR , dynamic cloud service selection,

adaptive learning in a clustered jCBR , and registering and

monitoring behavior of the service monitor set SM.

4.1. Service registration and initial clustering

In the initial time of completing the construction of the cloud service selection model CBRSM, a service monitor

iSM ∈ SM (1 ≤ i ≤ n) sends the message Register( iSM . iCS ,

( ) rii

tPePr ) to a cloud service broker jCBR , and the jCBR can

receive the basic cloud service information of iSM to form

a set of cloud service samples. The CBR is the cloud ser-vice broker set which can be initially clustered into some fixed number of jCBR (1 ≤ j ≤ m) representing different

levels of service groups. Fig. 3 shows the initial clustering view of a CBR, with its detailed algorithm omitted here since it is not the emphasis of this paper.

CBRjCBR1 CBRm

CBR

Cluster

Fig. 3. The clustering process of a CBR .

This clustering process uses the shortest distance

method by running m rounds of clustering, which clus-ters the CBR into m different groups who have dissimilar clustering centers. This process finally stores each group

of information of cloud service iCS into the service in-

formation table (SIT, see Table 1) of their respective cloud service broker jCBR .

4.2. Dynamic cloud service selection and adaptive learning of clustered CBR

4.2.1. Dynamic cloud service selection After performing the initial clustering process, a user can submit its cloud service requirements to the user agent

kUA on behalf of it. The kUA executes algorithm 1 which

initiates the computing process of dynamic cloud service selection, and outputs the cloud service selection result

set kICS regarding all tasks requested by the user, where

1 ≤ k ≤ l. Algorithm 1: The decomposition of a user’s requirement task

setT and selection of a cloud service iCS of each clustered set

{ jCBR |1 ≤ j ≤ m }

Input: A user’s cloud service requirement task setT with the preferred performance (e.g., the number of CPUs or storage capacity) and corresponding to price.

Output: The cloud service selection result set kICS of all

tasks from the user.

1: for any kUA , k ∈ [1, l] do

2: receives its user’s cloud service requirement task setT ;

3: decomposes T into kN number of task kT and cal-

culates the different preferred ratio of perform-ance to price of these tasks;

4: sets kICS = null;

5: for each task kT do

6: queries the clustered center jZ in the service infor-

mation table of each clustered set jCBR and calcu-

of 19

Accep

ted

Man

uscr

ipt


lates ,k j k jT ZD −= ;

7: selects jCBR corresponding to the Min{ ,k jD };

8: sends the Notify( kUA . kT , jCBR ) message to the se-

lected jCBR ;

9: receives the ResponseCS( iCS , kUA ) message from

jCBR ;

10: kICS ← kICS ∪ iCS ;

11: end for

12: returns kICS ;

13: end for

Each kUA receives all cloud service results of iCS (i ∈ [1,

n]) from each jCBR notified. These selected cloud services

may form an integrated solution based on the tasks sent by the user.

Each selected jCBR performs cloud service selection by

running algorithm 2, and outputs corresponding cloud

service result ,M jCS , i.e., the cloud service with the maxi-

mum ratio of performance to price. Algorithm 2: Dynamic cloud service selection in a cloud ser-vice broker jCBR

Input: The user’s cloud service requirement task kT and

the selected jCBR .

Output: The cloud service result ,M jCS .

1: If jCBR has received a registration message from a

service monitor iSM then

2: receives the new Register( iSM . iCS , ( ) rii

tPePr ) message

from iSM , where i ∈ [1, n];

3: saves the information ( iSM . iCS , ( ) rii

tPePr ) into the

service information table (SIT) of jCBR ;

4: end if 5: for any k ∈ [1, l] do

6: receives the Notify( kUA . kT , jCBR ) message from kUA ;

7: fetches the iCS with Max{ ,( ) ritPei jPr } in jCBR by searching

the SIT of jCBR ;

8: sends the ConfirmCS( iCS ) message to iSM ;

9: receives the IsavailableCS( iCS ) message from iSM ;

10: if IsavailableCS( iCS ) is equal to true then

11: sends ResponseCS( iCS , kUA ) to kUA ;

In algorithm 2, the cloud service broker jCBR firstly

monitors new registration messages from any iSM and

stores the information into its service information table (SIT). Then, it receives notification messages of a request-

ing cloud service selection from any kUA , searches the

best cloud service iCS in its SIT, and inquires the iSM of

whether the failure of the iCS has happened. A further

decision is made as to whether to invoke algorithm 3 to process adaptive learning strategies for optimizing the selected result at this time. Finally, it records the relevant information and carries out adaptive learning strategies by invoking algorithm 3 to optimize cloud service selec-

tion in next time. t

Ni denotes the used frequency of the

cloud service iCS from its registration time to the adap-

tive learning time of the jCBR , i.e., tri ≤ t ≤ tR.

4.2.2. Adaptive learning in a clustered CBR

Performing the adaptive learning process of cloud ser-vices managed by a cloud service broker jCBR is the core

of DCS. This is invoked by algorithm 2 at the time of cloud service failure and when the next service selection is optimized. In this algorithm, three learning strategies, i.e., incentive, forgetting, and degenerate functions from Section 3 are applied.

of 19

Accep

ted

Man

uscr

ipt

10

Algorithm 3: Adaptive learning in a cloud service broker

jCBR

1: for each iCS in a cloud service broker jCBR do

2: gets tri, tFi, tR, and t

Ni of each used iCS in the ser-

vice information table (SIT) of jCBR and the

cache respectively; 3: if tri ≤ tR then

4: ʹ,( ) ritPei jPr ← ,1( ) ( )

trit riR tPe

i jPre−

+ ⋅ ;

5: ʹjZ ← jZ + ,1 ( )

trit riR tPe

i jPrjne

−⋅ ;

6: updates ʹ,( ) ritPei jPr and ʹjZ into the SIT of jCBR ;

7: end if 8: if tFi > tR then

9: ʹ,( ) ritPei jPr ← ,

1

2

( ) ( )t tR rit tFi ri

ritPei jPr

e−− −

⋅ ;

10: if ʹ,( ) riPei j jPrt Z− > θ then

11: ʹjZ ← jZ − ,1 ( ) ritPe

i jPrjn;

12: removes the iCS with ,( ) ritPei jPr from jCBR ;

13: else

14: ʹjZ ← jZ − ,1 1

21

( )( ) ( )

t tR rit tFi ri

ritPei jPrjn

e−− −

− ⋅ ;

15: end if


17: end if

18: if RtNi > η then

19: ʹ,( ) ritPei jPr ← ,( ) ritPe

i jPr⋅δ ; 1

tR tN it trit tR rieδ

− ∑=− +← ;

where, 0 <δ < 1;

20: if ʹ,( ) riPei j jPrt Z− > θ then

21: ʹjZ ← jZ − ,1 ( ) ritPe

i jPrjn;

22: removes the iCS with ,( ) ritPei jPr from jCBR ;

23: else

24: ʹjZ ← jZ − ,1 1( ) ( ) ritPe

i jPrjn− ⋅δ ;

25: end if


27: end if 28: end for

29: selects the cloud service ,M jCS with Max{ ,( ) ritPei jPr } in

jCBR and updates it into the SIT of jCBR ;

Each iCS in a cloud service broker jCBR firstly acquires

the four condition parameters (see line 2), uses them to process the conditional judgement, and then further de-cides whether to carry out the three adaptive learning strategies in which each strategy must update the service

information table of the jCBR using the new value ,( ) ritPei jPr

at the end of its conditional sentence body. Finally, the service information table of the jCBR has the current op-

timal cloud service information managed by the jCBR ,

which will be used in the next round of cloud service se-lection.

A service monitor iSM registers and monitors its cloud

services using algorithm 4. This algorithm calculates the best distance from the clustered center jZ of jCBR and

selects the best jCBR to send new cloud service registra-

tion information for its providers. We assume that a cloud service is only registered into one selectedCBR every time.

In addition, the iSM monitors the statuses of its cloud

services and responds to the confirmation message about

the status of iCS requested by the jCBR .

Algorithm 4: Registering and monitoring behavior of iSM re-

lated to its cloud services Input: The cloud services for registering or the Con-

firmCS( iCS ) message for monitoring its cloud services.

Output: The IsavailableCS( iCS ) message to the cloud ser-

vice broker jCBR that has sent the confirmation message.

1: for each iSM and i ∈ [1, n] do

2: if there is any cloud service to register from its pro-vider then

3: ,xi jtmp ← MAX_VALUE;

4: queries jZ in the service information table of each

clustered class jCBR ;

5: for each jCBR , and j ∈ [1, m] do

6: ,i jD ← ( ) riPejPr

ti Z− ;

7: if ,i jD < ,i jtmp then

8: ,i jtmp ← ,i jD ;

9: end if 10: end for 11: (i ,j) ← Arg( ,i jtmp );

12: sends a new Register( iSM . iCS , ( ) rii

tPePr ) message to

jCBR ;

13: end if

of 19

Accep

ted

Man

uscr

ipt


14: receives ConfirmCS( iCS ) from requesting jCBR ;

15: if the iCS is found to be a failure by monitoring

cloud services then

16: sets IsavailableCS( iCS ) = false;

17: else

18: sets IsavailableCS( iCS ) = true;

19: end if

20: sends the IsavailableCS( iCS ) message to the jCBR

that has sent the confirmation message; 21: end for

Our adaptive learning mechanism and algorithms en-

sure there is the optimal cloud service set in each used clustered CBR. However, whether an updated cloud ser-vice broker jCBR , through its adaptive learning, has low-

er overhead and resources consumption depends on the overall evaluation of its performance and cost. About this, we give a theoretical proof as below. Lemma 1. Any used cloud service broker can make its compos-ite performance to cost ratio tend towards slow increase when it processes multi-round of adaptive learning with our DCS for optimizing next cloud service selection due to the changing states (failure or be available) of some cloud services managed by it. Proof. A used cloud service broker jCBR will run a round

of adaptive learning and value regulation through us-ing our DCS strategy for optimizing next cloud service selection due to the changing states of some cloud ser-vices managed by it. In light of Theorem 1, the adap-tive learning process of the cloud service broker is sta-ble, and it does not exhaust its storage and computing resources when it dynamically receives cloud services registered by providers. Meanwhile, with users’ re-quests constantly coming, according to Theorem 2, the cloud services can certainly be obtained through the optimal selection of the cloud service broker. Let jEP

denote the expected composite performance of a cloud service broker jCBR during its adaptive learning and

value regulation, namely, expected ratio of perform-ance to price of the clusetered center of the jCBR as be-

low:

,

,( )

1

( ( ( ) ( ) ( ))

( ) )

njt

R ii

ri

ri

tPe rii jjPr

j

j

t N

j I R F R D Rt t

tPei jPr

i RnCB

n

n

EP f t f t f t=

− −∑

= ⋅

⋅

∑

∑

where tiN is used frequency of the cloud service i

managed by the jCBR from its registration time tri to

adaptive learning time tR, and nj is the number of cloud services managed by the jCBR . Let

( ) ( ) ( )f I R F R D Rf t f t f t− −Δ = denotes the adaptive

learning mechanism of a cloud service broker, i.e., a changed probability of the ratio of performance to price.

On the other hand, we define total cost of adaptive learning process of the jCBR based on Section 3.3 (4) as

follow:

, ,

, ,

, ,

1( 1) ( )

njt

R Rii

ri ri

I F D

j R j Mj

Me j k P j k Ma j

t tN

Me j P R ri Ma jt t t tjn

Cost Cost

CS

Cost

M C

mn t t C n

C C P

C C= =

+=

= ⋅ + ⋅ + ⋅

∑ = ⋅ ⋅ + + ⋅ − + ⋅

∑∑ ∑

∑ ∑where m is the number of cloud service brokers, and 1rit is the first early registration time of a cloud service

in the broker jCBR .

Thus, a used cloud service broker’s composite per-formance to cost ratio can be derived as

1,

( ) ,

1

,

( ) ,

( ( ) )

( 1) ( )

( ) ( ) )

(

nj tt NR i ti Pe rif i jn n Prj j tt t Pe riri inj i jPr

nj tt tj NR Rii

Me j P R ri Ma jnjt t t tri ri

nt jR tt Pe rii

CBRj

CBRj

f i jPrtt t i Pe riri ini jPr

tMe i

EP

Cost

C mn C t t C n

N

C N

∑

=

∑

= =

=

⋅Δ ⋅

⋅ ⋅ + + ⋅ − + ⋅

⋅Δ ⋅

⋅

∑ ∑=∑

∑ ∑

∑ ∑ ∑ =

2 1 2 3) ( ) ( )nt tjR R

j j P R ri j Ma jt t i t tri ri

mn n C t t n C n= =

⋅ + + ⋅ − + ⋅∑ ∑ ∑

From the above equation, we make a qualitative analy-sis that, with increasing users’ requests, the probability of failure of cloud services managed by a broker jCBR goes

up, and our system needs to run multi-round of adaptive learning and value regulation for optimizing the next cloud service selection. This process will cause some cloud services with poor performance to be removed from the jCBR , in other words, the current total used fre-

quency nj

ti

iN∑ and number jn of the cloud services man-

aged by the jCBR will decrease. The denominator

jCost∑ of the above equation reduces more than the nu-

merator jEP , because the coefficient variation 2jn and

of 19

Accep

ted

Man

uscr

ipt

12

3jn in the former decrease much faster than the variation

njti

iN∑ in the latter. Thus, the composite performance to

cost ratio j

j

EP

Cost∑ tends towards slow increase, i.e., there

is lower overhead and resources consumption in a cloud service broker jCBR for optimizing its composite per-

formance by means of adaptive learning and value regula-tion.

Due to the involvement of many interactions of indi-viduals between different layers of the proposed model, the quantitative complexity analysis of all our algorithms is given by the form of empirical evaluation in the next section.

5. Empirical evaluation

In this section, eight groups of experiments were de-signed and conducted to evaluate the performance of the proposed DCS and its algorithms. All of the simulation experiments were implemented on the JADE 4.3.0 plat-form (Bellifemine et al., 2013), and on a computer whose configuration was an Intel Core i5-3337U CPU 1.80GHz, 4.0GB RAM, Windows 7 (64 bits) operating system, Ser-vice Pack 1. We first provided the experimental settings, detailed the performance measures, conducted all the experiments and finally analyzed the experimental results.

5.1. Experimental settings

We compared the cost and efficiency of DCS with the strategies of the service capability tables (SCTs) (Gutierrez-Garcia and Sim, 2013) and the central directory (CD) in the field of agent-based cloud service selection and composition. Agents in the SCTs strategy have in-complete information about other agents’ service capabili-ties, and ones in the CD strategy own all the knowledge about other agents’ service capabilities (Sim, 2012).

There are seven input data designed in our algorithms as shown in Table 3. All of them are given some specific value that is meaningful. Thereinto, the cloud services’ probability of failure is designed to evaluate various as-pects of performance of DCS similar to the SCTs strategy in Gutierrez-Garcia and Sim (2013). To facilitate the ex-perimental comparison, we also let the changing range of the cloud services’ probability of failure range from 0.0 to 1.0, and the incremental step was set at 0.1.

Table 3 Experimental settings.

Input data Given possible values The number of

user agents kUA ,

k ∈ [1, l]

A possible random number of

UA1 to lUA submitting cloud ser-

vice tasks

The number of less moderate more

iSM correspond-

ing to cloud service providers, i ∈ [1, n]

5 10 20

low moderate high The number of cloud service re-quests from users per second

5 50 100

The number m of the clustered set

jCBR , j ∈ [1, m]

5

The max distance θ of an internal clustered set

jCBR

5.000

The upper limita-tion η of used cloud services’ frequency in

jCBR

100

The cloud ser-vices’ probability of failure, i ∈ [1, n]

The changing range is from 0.0 to 1.0, and the incremental step is 0.1.

In addition, the testing data of the ratio of performance

to price of each cloud services PePr derives from the pub-

lished websites of Google GAE, Amazon EC2, Windows Azure, and Force.com Platform. We still added some simulated data and totally normalized them into a stan-

dard form as ( ) rii

tPePr . We give a part of the sample data as

shown in Table 4. Since PePr is a ratio value, if the number

of qualified CPU units (Pe) is bigger, the price per CPU unit hour (Pr) will cost more. Thus, it is not necessary to give too big number of the qualified CPU unit. In case a cloud service provider wants to offer a higher ratio value PePr for a cloud service, he may reduce the price of the ser-

vice or enhance the performance of running the service, and register the updated service’s information into a suit-able cloud service broker jCBR . Due to limited space in

this paper, more detailed data is omitted here but is shown in our appendix as supplemental material.

Table 4 The sample of testing data.

of 19

Accep

ted

Man

uscr

ipt


In simulation experiments, the proposed DCS was

compared with the SCTs and CD strategies. We devised allUA ,CBR and SM as different agents working at respec-tive layers of our model, and used the JADE platform to generate an assigned number of agents. This is shown in Table 3 where the SMs monitoring the cloud services were similar to the RAs in the SCTs strategy. However, to en-hance the running rapidity of the simulated program, our quantity of SMs was set approximately one percent time as much as that of the RAs in the SCTs strategy. This means the scales of our experimental data on average cloud service selection time for successful selections and average number of messages was compared with one percent of scales from the SCTs strategy. This does not influence our performance comparison on the general scale. In our experiments, we also conducted 10 rounds for comparison, and each round comprised 5, 50 and 100 cloud service requests per second from users under the conditions of 0.0 to 1.0 cloud services’ probabilities of failure.

5.2. Performance measures

Performance measures were devised and used in our ex-periments as shown in Table 5. Because there may be fail-ure of cloud services during the process of running dy-namic service selection algorithms, the work of entire cloud service selections cannot be completely successful, however we can use the successful rate of cloud service selections as a performance measure.

Besides the successful rate, we also need to compare the number of messages exchanged between different layers of agents devised and the cloud service selection time during the service selections. The average cloud ser-vice selection time for successful selections is used, which is the result of all successful selection time being divided by the number of successful cloud service selections.

The adaptive learning capability is an important aspect for a cloud service broker jCBR using the DCS strategy,

and we use the ratio of total adaptive learning utility to total the adaptive learning reward obtained by a cloud

service broker jCBR for all cloud service selections of a

user agent kUA .

Table 5 Performance measures. Successful rate of cloud service selections suc allN N/

Average num-ber of messages

1( ) / all

lkk

NM=∑

Average cloud service selection time for suc-cessful cases 1 ,( ) /l

k suc k sucT N=∑

Adaptive learn-ing utility ,

,_

1= j k

j kAv

lk

allNsuc

self

U

N RewardU =∑∑

sucN The number of successful cloud service selections

allN The number of all cloud service selections

,suc kT

The successful cloud service selection

time for a user agent kUA (k ∈ [1, l]) in a

cloud service broker jCBR

sucN The number of successful cloud service selections

kM

The number of exchanged messages for all cloud service selections of a user agent

kUA in a cloud service broker jCBR

,j kNsuc

Reward∑

The total reward obtained by all jCBR at-

tending selection tasks when completing all successful cloud service selections of a

user agent kUA

,j kU

The adaptive learning utility of a cloud service broker jCBR for all cloud service

selections of a user agent kUA

5.3. The analysis of results

5.3.1. Comparison 1 In this group of experiments, the successful rate of cloud service selections of the DCS strategy was compared with the SCTs and CD strategies, and varies with the increas-ing number of cloud services’ probability of failure. There are three comparative results under circumstances of dif-ferent cloud service request rates and the same number of service monitors (SMs).

The experimental results in Fig. 4 show that the suc-cessful rates of cloud service selections for all strategies decrease with an increase in the cloud services’ probabil-

Cloud computing service providers

Registered number of qualified CPU unit corre-sponding to its price (Pe)

Price per CPU unit hour (Pr)

Performance /Price

(Pe/Pr)

CCSP1 2 $0.200 10.000

CCSP2 4 $0.240 16.667

CCSP3 4 $0.320 12.500

CCSP4 3 $0.210 14.286 CCSP5 5 $0.250 20.000 … … … …

of 19

Accep

ted

Man

uscr

ipt

14

ity of failure. This is especially so when the probability of failure is greater than 0.6, and all successful rates rapidly drop to 0. This occurs because it is very difficult for a sys-tem with 0.6 cloud services’ probability of failure to ob-tain the services for meeting users’ demands.

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Cloud Services’ Probability of Failure

Successful Rate of Cloud Service Selections

DCSSCTsCD

5 cloud service requests per second and 10 SMs

(a)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

100

200

300

400

500

600

700


Average Number of Messages

DCSSCTsCD


(a)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1



DCSSCTsCD


(b)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

100

200

300

400

500

600

700



D C S

SC Ts

C D


(b)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1



DCSSCTsCD


(c)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

100

200

300

400

500

600

700

Cloud Services' Probability of failure


DCSSCTsCD


(c) Fig. 4. Comparison of successful rates of cloud service selections.

Fig. 5. Comparison of average number of messages.

From Fig. 4(a) to 4(c), we can see that: (i) when the

probability of failure is less than and equal to 0.6, the suc-cessful rates are all very high and even the DCS strategy achieves the highest 1, and (ii) when there are 5 and 50 cloud service request rates and moderate (10) SMs, the successful rate of the DCS strategy is always equal to or a little less than that of the SCTs strategy, and generally greater than that of the CD strategy. However, when the requests rate is 100, the successful rate of the DCS strat-egy is higher than the other two strategies. This is because, in the case of low (5) or moderate (50) cloud service re-quest rates, the self-organization of the SCTs strategy can better deal with the service integrations among agents than that of the DCS strategy. However, when the request rate is very high (e.g., 100), the DCS strategy can always maintain the nicer performance of its adaptive learning mechanism, whereas the SCTs strategy cannot. Since the CD strategy uses a central directory that exists of an obvi-ous performance bottleneck, its successful rate is worse.

5.3.2. Comparison 2 Fig. 5 indicates that with the increase of cloud services’ probability of failure, changes in the average number of messages are small in general. However, those of the SCTs strategy rise sharply when the probability of failure is greater than 0.7, and then decreases when the probability of failure is from 0.9 to 1. It can be seen from Fig. 5(a) to 5(c) that the average number of messages of the DCS strategy is far lower than those of the SCTs and CD strategies in the case of three kinds of cloud service re-quest rates and 10 SMs, which is only from 15 to 30. This is because when proceeding to the cloud service selec-tions, the service selection of each task only needs to han-dle a little message exchange between UAs and CBRs. UAs find their best CBRs to do the service selection (or between CBRs and SMs) when new cloud services are registered into a cloud service broker CBR. Besides, the key work is performed inside each selected CBR which runs the algorithms of the DCS strategy. The CBR can always rapidly obtain the best cloud service through exe-cuting the adaptive learning mechanism and internally sorting its managed (clustered) cloud services informa-tion. Therefore, the work does not need to exchange mes-sages. 5.3.3. Comparison 3 It can be seen from Fig. 6 that in case of three kinds of cloud service request rates and 10 SMs, the average cloud service selection time for successful cases increases in the three strategies. With growing cloud services’ probability of failure, those of DCS and SCTs strategies increase slowly when probability of failure is less than 0.8, where-as that of the CD strategy rises faster. The selection time of the SCTs strategy increases sharply when the probability of failure is greater than 0.8. From Fig. 6(a) to 6(c), we can see that the average cloud service selection time of the DCS strategy is between the SCTs and CD strategies when probability of failure is less than 0.8. This is because, during the cloud service selection, each CBR is selected to perform the cloud service selection, and needs to consume more time than the SCTs strategy to run the adaptive learning algorithm of the DCS strategy and in-ternally sort the managed cloud services information in-side itself. However, when cloud services’ probability of failure is greater than 0.8, the selection time of the DCS strategy becomes the lowest because the DCS strategy is stable and its adaptive learning and value regulation does not aggravate the computing burden of the system.

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.90

200

400

600

800

1000

1200

1400


Average Cloud Service Selection Time

for Successful Cases (

Milliseconds)

DCSSCTsCD


(a)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.90

200

400

600

800

1000

1200


Average cloud Service Selection Time


Milliseconds)

DCSSCTsCD


(b)

of 19

Accep

ted

Man

uscr

ipt


0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.90

200

400

600

800

1000

1200




Milliseconds)

DCS

SCTs

CD


(c)

Fig. 6. Comparison of average cloud service selection time for suc-cessful cases. 5.3.4. Comparison 4 Fig. 7 shows that the DCS strategy’s successful rates of cloud service selections of the three number levels of SMs decrease with increasing cloud services’ probability of failure in the case of the moderate (50) cloud service re-quest rates.

From this figure, we can also see that the successful rate of the DCS strategy in the case of 10 SMs is always higher than the other two cases when cloud services’ probability of failure is from 0 to 0.7. In this condition, the three cases all have higher successful rates from 0.7 to 0.95. This indi-cates that the adaptive learning mechanism of the DCS strategy can also maintain its robustness even when there is a lower probability of failure.

5.3.5. Comparison 5 From Fig. 8, the changes of the average number of mes-sages of the DCS strategy with different SMs are all small when cloud services’ probability of failure is less than 0.6. However, the changes of curves having 10 SMs and 20 SMs become large when the probability of failure is greater than 0.6. This is because when greater failure of cloud services occurs, a cloud service broker CBR needs to remove more invalid cloud service information. Meanwhile, it uses the adaptive learning mechanism to attract SMs to register new cloud services so the ex-changed messages become greater than those of the other two cases. This figure also depicts that the total amount of the average number of messages of the DCS strategy in all kinds of cases is always lower than 30. This is especially so in case of 5 SMs or 10 SMs, where it is only about 16 when the probability of failure is less than 0.6. 5.3.6. Comparison 6 Fig. 9 shows that the average cloud service selection time for successful cases of the DCS strategy with different SMs increases as a whole when the cloud services’ prob-ability of failure increases.

From the figure, the average selection time of the DCS strategy with 10 SMs is lower than that of the other two cases when the probability of failure is less than 0.6. However, all of the curves do have some fluctuation when the probability of failure is greater than 0.6. This is because the DCS strategy with 10 SMs manages the mod-erate cloud service information in which a cloud service broker CBR can use less time for adaptive learning and select the best cloud service for users. In addition, when

high probability of failure is likely because of the complex adaptive learning process in which more interactions with SMs or UAs need to be made, a fluctuation of selection time will take place.

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1



DCS 5 SMsDCS 10 SMsDCS 20 SMs

50 cloud service requests per second and different SMs

Fig. 7. Comparison of successful rates of cloud service selections of DCS with moderate cloud service request rates and different number levels of SMs.

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

Cloud Services' Probability of Failure

Adaptive Learning Utility

DCSSCTsCD


(a)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 114

16

18

20

22

24

26

28

30





Fig. 8. Comparison of average num-ber of messages of DCS with moder-ate cloud service request rates and different number levels of SMs.

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1



DCS

SCTsCD


(b)

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.960

80

100

120

140

160

180

200



for Successful Cases (Milliseconds)



Fig. 9. Comparison of average cloud service selection time for successful cases of DCS with moderate cloud service request rates and different number levels of SMs.

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1



DCSSCTsCD


(c) Fig. 10. Comparison of adaptive learning utility.

5.3.7. Comparison 7 From Fig. 10, we can see that with the increase of cloud services’ probability of failure in the case of three kinds of cloud service request rates and 10 SMs, the adaptive learning utilities of all three strategies decrease. When the probability of failure is less than 0.7 or 0.8, the adaptive learning utilities reduce slowly. However, when the prob-ability of failure is over 0.7 or 0.8, the utilities drop sharply. This is because in case with a very high probabil-ity of failure, the successful rates of cloud service selection for all strategies become very low. Due to the communica-tion and processing costs increasing, the utilities drop rapidly. Fig. 10(a) to 10(c) shows that the adaptive learn-ing utilities of the DCS strategy are always higher than those of the SCTs and CD strategies. This is because when

of 19

Accep

ted

Man

uscr

ipt

16

successfully completing the work of cloud service selec-tion at the same request rate and SMs’ number, the DCS strategy is less than the SCTs and CD strategies on the communication cost per message and the processing time cost, thus the utility is highest (see Section 3.3 (4) and Ta-ble 5). 5.3.8. Comparison 8 Expected composite performance (ratio of performance to price of the clusetered center of a cloud broker jCBR ) to

cost ratio evaluates the extent of the overhead and re-sources consumption in a cloud service broker jCBR . For

this, we make a quantitative analysis under the condition of different cloud service requests and 10 SMs as shown in Fig. 11.

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 10

0.5

1

1.5

2

2.5

3

3.5


Expected Composite Performance to Cost Ratio

Different cloud service requests per second and 10 SMs

5 cloud service requests /s50 cloud service requests /s100 cloud service requests /s

Fig. 11. Comparison of expected composite performance to cost ratio.

From the figure above, we can see that with the in-

crease of cloud services’ probability of failure, expected composite performance to cost ratios related to three kinds of cloud service request rates (5, 50 and 100) all gradually decline. This is because, when cloud services’ probability of failure rises, more and more cloud services managed by a cloud service broker are removed, and ex-pected composite performance reduces and the number of messages exchanged decreases. On the other hand, with growing cloud service requests per second from 5 to 100, the whole expected composite performance to cost ratio however gets slow increase (total ratio relevant to 100 cloud service requests per second is maximum), this cause can be well explained from the proof of Lemma 1.

In light of the multi-aspects of experimental analysis above, we have verified that our model and strategy are more advantageous and effective than existing relevant strategies in most of the performance and utility of cloud service selection.

6. Related work

Cloud service selection for integration has received in-creasing attention. If we consider the working individuals in different layers of our model as the agents and view the cloud services as general Web services over the Internet, the work of service selection for integration may be con-sidered as the service selection and composition in the special condition. There is a lot of current work regarding agent-based service selection and composition that has been conducted as follows.

Work on service selection and composition based on agent technology and semantics has been conducted. McIlraith and Son (2002) proposed an approach to build the service selection and composition agent based on the notion of generic procedures and customizing user con-straint. Korhonen et al. (2003), Wang et al. (2006) and Blake and Gomaa (2005) presented a way to automatically compose Web service workflow which adopts component web services described by the transactional workflow ontology and lets a reasoning agent to automatically find a composed workflow that fulfills all given constraints. Maamar et al. (2005) proposed an agent-based and con-text-oriented approach supporting the selection and com-position of Web services, in which the conversations be-tween agents take into account the execution context of the Web services. However, the above work almost ad-dresses semantic services and uses agents as the coordina-tors to help the service selection and composition. Nor does it consider the adaptive learning capabilities of agents and dynamic regulation based on the running situation among agents for optimizing the service selec-tion.

Many research approaches on agent-based service se-lection and composition adopt artificial intelligence plan-ning to perform the selection and composition work as in Menasce (2004), Lazovik et al. (2005), Peer (2004) and Na-rayanan and McIlraith (2002). These methods may be classified as a centralized service orchestration which se-lects and composes the services through the process plan-ning. However, the key content of their work is a static definition of the service planning which is a centralized computing mode that runs a composition engine. This means it is easy to encounter the performance bottlenecks. Zou et al. (2010) proposed a framework of service selec-tion and composition in cloud computing and three dif-ferent cloud combination methods based on artificial in-telligence planning and combinatorial optimization. However, this work is still a centralized method and needs to have complete knowledge about cloud environ-ments. A distributed planning algorithm for Web service composition using a service agent model is presented in Tong et al. (2009, 2011). This algorithm formalizes Web service composition into a graph search problem in light of the dependence relations among service agents. How-ever, the search cost of their algorithms is still high and there are no adaptive learning actions inside agents to optimize the selecton and composition of services for re-ducing the cost.

Some interactive research methods focus on integrating agents with cloud services, and provide some negotiation strategies of service configuration and composition (Preist et al., 2003; Cao et al., 2005). An agent-based testbed sup-porting the discovery of cloud resources and SLA (ser-vice-level agreements) negotiation (Yan et al., 2007; Buyya et al., 2009) is proposed in Sim (2009). Sim (2010, 2013) proposed several complex cloud negotiation mechanisms that support negotiation activities among three types of participants, i.e., consumer agents, broker agents and provider agents, in interrelated e-markets for dynamic SLA negotiation. This is the earliest proposal for a com-

of 19

Accep

ted

Man

uscr

ipt


plex cloud negotiation mechanism. An et al. (2011) pre-sented the concurrent negotiation of agents with other entities for acquiring multiple resources in electronic commerce markets. The above approaches mainly em-phasize the automating management of multiple cloud resources using interactive agents. However, they do not conduct the management of cloud service resources, and the adaptive learning and value regulation among agents for optimizing the cloud service resource selection.

An agent-based approach is proposed to select cloud services in multi-cloud environments. These environ-ments consist of a semi-recursive contract net protocol (SR-CNP), service capability tables (SCTs, i.e., information catalogs about cloud participants), and endowed agents to select suitable services for consumer requirements as in Gutierrez-Garcia and Sim (2013, 2010a, 2010b). Besides, Sim (2012) presented the cloud service composition based on focus selection contract net protocol (FSCNP) and SCTs that also carries out the coordination and interaction among cloud participants (consumers, brokers, and pro-viders) and performs the automation of service selection. Their work enhances the efficiency of cloud service selec-tion in contrast to previous approaches. We pay signifi-cant attention to the approaches of Gutierrez-Garcia and Sim (2013) and Sim (2012), and our work also constructs working individuals in multi-layer like agents to select cloud services. However, our research differs from the SR-CNP, FSCNP and SCTs because our method lets each cloud service broker manage some cloud service resource information from different providers and select the best one from these cloud services for users. Our method also uses a dynamically adaptive learning mechanism to op-timize the cloud service selection, which further improves the performance and efficiency of the cloud service selec-tion.

7. Conclusion and future work

Assisting users to dynamically select suitable cloud ser-vices that match their preferred tasks is a complex and valuable topic. This paper proposes a cloud service selec-tion model called CBRSM which uses cloud service bro-kers. Based on this model, a dynamic cloud service selec-tion strategy called DCS is presented. Our model and strategy use an adaptive learning mechanism performed by the clustered cloud service brokers in which a set of dynamic cloud service selection algorithms are imple-mented. The detailed simulation experiments demon-strate the advantages and efficiency superior to existing approaches. Our strategy has better applicability and can also be used in other automatic Web services’ selection.

Future research will further increase the scale of our experiments and make our strategy even more complete and sound. Meanwhile, an interactive mechanism be-tween cloud service brokers will be conducted to extend our research.

Acknowledgments

This work is partially supported by the National Natural Science Foundation of China under grant number

61073021, 61272438 and 61472253, the Research Funds of Science and Technology Commission of Shanghai Mu-nicipality under grant number 14511107702 and 12511502704, and the Computer Application Technology Academic Discipline Project of Shanghai Dianji Univer-sity under grant 13XKJ01.

References

GoGrid’s Cloud Platform, 2013. On-demand compute, network, and storage resources on 1 unified platform. http://www. gogrid. com/cloud-platform

Amazon S3, 2013. Amazon simple storage service. http://aws. ama-zon.com/cn/s3

Google App Engine, 2013. Google app engine platform as a service. https://developers.google.com/appengine

Windows Azure, 2013. Windows azure unlimited possibilities. http://www.windowsazure.com/en-us

Salesforce-Cloud, 2013. One platform to sell from anywhere, anytime. http://www.salesforce.com/sales-cloud

Liu, Y., Ngu, A.H.H., Zeng, L., 2004. QoS computation and policing in dynamic web service selection. In: Proceedings of 13th Inter-national Conference on World Wide Web (WWW), Alternate track papers & posters, pp. 66-73.

Hwang, S., Lim, E., Lee, C., et al., 2008. Dynamic web service selec-tion for reliable web service composition. IEEE Trans. Serv. Comput. 1(2), 104-116.

Channa, N., Li, S., Shaikh, A.W., et al., 2005. Constraint satisfaction in dynamic web service composition. Asian J. Info. Tech. 4(10), 957-961.

Oh, S., Lee, D., Kumara, S.R.T., 2007. Web service planner (WsPr): an effective and scalable web service composition algorithm. Int. J. Web Serv. Res. 4(1), 1-23.

Huhns, M.N., 2003. Software agents: the future of web services. In: Agent Technologies, Infrastructures, Tools, and Applications for E-Services. Carbonell, J.G., Siekmann, J., Kowalczyk, R. et al. eds., Berlin: Springer-Verlag, pp. 1-18,

Huhns, M.N., Singh, M., Burstein, M., et al., 2005. Research direc-tions for service-oriented multi agent systems. IEEE Internet Comput. 9(6), 65-70.

Sim, K.M., 2009. Agent-based cloud commerce. In: Proceedings of IEEE International Conference on Industrial Engineering and Engineering Management, pp. 717-721.

Isern, D., Moreno, A., Sánchez, D., et al., 2011. Agent-based execu-tion of personalised home care treatments. Appl. Intell. 34(2), 155–180.

Sim, K.M., 2012. Agent-based cloud computing. IEEE Trans. Serv. Comput. 5(4), 564-577.

Gutierrez-Garcia, J.O., Sim, K.M., 2013. Agent-based cloud service composition. Appl. Intell. 38(3), 436-464.

Bellifemine, F., Caire, G., Trucco, T., et al., 2013. JADE-bin-4.3.0. http://jade.tilab.com

McIlraith, S., Son, T.C., 2002. Adapting golog for composition of semantic web services. In: Proceedings of International Confer-ence on Principles of Knowledge Representation and Reasoning (KRR), pp. 482-496.

Korhonen, J., Pajunen, L., Puustjarvi, J., 2003. Automatic composition of web service workflows using a semantic agent. In: Proceed-ings of IEEE/WIC/ACM International Conference on Web Intel-ligence (WI’03), pp. 5663–5666.

Wang, S., Shen, W., Hao, Q., 2006. An agent-based web service workflow model for inter-enterprise collaboration. Expert Syst. Appl. 31(4), 787-799.

of 19

Accep

ted

Man

uscr

ipt

18

Blake, M., Gomaa, H., 2005. Agent-oriented compositional ap-proaches to services-based cross-organizational workflow. Decis. Support Syst. 40(1), 31–50.

Maamar, Z., Mostefaoui, S.K., Yahyaoui, H., 2005. Toward an agent based and context-oriented approach for web services composi-tion. IEEE Trans. Knowl. and Data Eng. 17(5), 686-697.

Menasce, D., 2004. Composing web services: a QoS view. IEEE Inter-net Comput. 8(6), 88-90.

Lazovik, A., Aiello, M., GennariI, R., 2005. Encoding requests to web service compositions as constraints. LNCS 3709., pp. 782-786.

Peer, J., 2004. A PDDL based tool for automatic web service compo-sition. In: Proceedings of 2th International Workshop on Princi-ples and Practice of Semantic Web Reasoning (PPSWR), pp. 149-163.

Narayanan, S., McIlraith, S., 2002. Simulation, verification and auto-mated composition of web services. In: Proceedings of 11th In-ternational Conference on World Wide Web (WWW), pp. 77-88.

Zou, G., Chen, Y., Yang, Y., et al., 2010. AI planning and combinato-rial optimization for web service composition in cloud comput-ing. In: Proceedings of the Annual International Conference on Cloud Computing and Virtualization (CCV), pp. 1-8.

Tong, H., Cao, J., Zhang, S., et al., 2009. A distributed agent coalition algorithm for web service composition. In: Proceedings of IEEE Congress on Services, pp. 62-69.

Tong, H., Cao, J., Zhang, S., Li, M., 2011. A distributed algorithm for web service composition based on service agent model. IEEE Trans. Parall. and Distr. Syst. 22(12), 2008-2021.

Preist, C., Byde, A., Bartolini, C., 2003. Agent-based service composi-tion through simultaneous negotiation in forward and reverse

auctions. In: Proceedings of 4th ACM Conference on Electronic Commerce, pp. 55- 63.

Cao, J., Wang, J., Zhang, S., et al., 2005. A multi-agent negotiation based service composition method for on-demand service. In: Proceedings of IEEE 2005 International Conference on Services Computing (SCC 2005), pp. 329-332.

Yan, J., Kowalczyk, R., Lin, J., et al., 2007. Autonomous service level agreement negotiation for service composition provision. Future Gener. Comput. Syst. 23(6), 748-759.

Buyya, R. Yeo, C.S., Venugopal, S., et al., 2009. Cloud computing and emerging IT platforms: vision, hype, and reality for delivering computing as the 5th utility. Future Gener. Comput. Syst., 25(6), 599-616.

Sim, K.M., 2010. Towards complex negotiation for cloud economy. LNCS 6104., pp. 395–406.

Sim, K.M., 2013. Complex and concurrent negotiations for multiple interrelated e-markets. IEEE Trans. Cybernetics. 43(1), 230-245.

An, B., Lesser, V., Sim, K.M., 2011. Strategic agents for multi-resource negotiation. Auton. Agents and Multi-Ag. Syst., 23(1), 114-153.

Gutierrez-Garcia, J.O., Sim, K.M., 2010a. Agent-based service com-position in cloud computing. In: Proceedings of 2010 Interna-tional Conference on Grid and Distributed Computing, pp. 1-10.

Gutierrez-Garcia, J.O., Sim, K.M., 2010b. Self-organizing agents for service composition in cloud computing. In: Proceedings of 2th IEEE International Conference on Cloud Computing Technology and Science, pp. 59-66.

Xiaogang Wang is currently a PhD student of the Department of Computer Science and Engineer-ing at Shanghai Jiao Tong University and also a staff member at Shanghai Dianji University. His main research interests include service comput-ing, cloud computing, multiagent system and network protocol.

Jian Cao received his PhD degree from Nanjing University of Science and Technology in 2000. He is currently a professor of the Department of Computer Science and Engineering at Shanghai Jiao Tong University. His main research interests include service computing, cloud computing, cooperative information system and software engineering. He has published more than one hundred papers. He is a senior member of China computer federation.

Yang Xiang received his PhD degree in Com-puter Science from Deakin University, Australia. He is currently a full professor at School of In-formation Technology, Deakin University. He is the Director of the Network Security and Com-puting Lab (NSCLab) and the Associate Head of School (Industry Engagement). His research interests include network and system security, distributed systems, and networking. He has published more than 150 research papers in ma-

ny international journals and conferences, such as IEEE Transac-tions on Computers, IEEE Transactions on Parallel and Distributed Systems, IEEE Transactions on Information Security and Forensics, and IEEE Journal on Selected Areas in Communications. Two of his papers were selected as the featured articles in the April 2009 and the July 2013 issues of IEEE Transactions on Parallel and Distrib-uted Systems. He has published two books, Software Similarity and Classification (Springer) and Dynamic and Advanced Data Mining for Progressing Technological Development (IGI-Global). He has served as the Program/General Chair for many international confer-ences such as ICA3PP 12/11, IEEE/IFIP EUC 11,IEEE TrustCom 13/11, IEEE HPCC 10/09, IEEE ICPADS 08, NSS 11/10/09/08/07. He has been the PC member for more than 60 international confer-ences in distributed systems, networking, and security. He serves as the Associate Editor of IEEE Transactions on Computers, IEEE Transactions on Parallel and Distributed Systems,Security and Communication Networks (Wiley), and the Editor of Journal of Net-work and Computer Applications. He is the Coordinator, Asia for IEEE Computer Society Technical Committee on Distributed Processing (TCDP). He is a senior member of the IEEE.

of 19

Accep

ted

Man

uscr

ipt


Highlights:

A cloud service selection model that adopts cloud service brokers is proposed.

We devise a dynamically adaptive learning mechanism for cloud service selections. The incentive, forgetting and degenerate strategies optimize cloud service selections. The dynamic cloud service selection algo-rithms show the adaptive characteristics. Our mechanism possesses better overall per-formance and efficiency.

dynamic cloud service selection using an adaptive learning mechanism in multi-cloud computing

Documents