Melane Sebenhaar, Ulrch Lampe, Tm Lehrg, Sebastan Zöller, Stefan Schulte, Ralf Stenmetz: Complex Servce Provsonng n Collaboratve Cloud Markets. In: W. Abramowcz et al. (Eds.): Proceedngs of the 4th European Conference ServceWave, no. LNCS 6994, p. 88-99, Sprnger, October 2011. ISBN 978-3-642-24754-5. Complex Servce Provsonng n Collaboratve Cloud Markets Melane Sebenhaar, Ulrch Lampe, Tm Lehrg, Sebastan Zo ller, Stefan Schulte, and Ralf Stenmetz Multmeda Communcatons Lab (KOM) Technsche Unversta t Darmstadt, Germany Today s cloud consumers gan a hgh level of flexblty by usng externally provded cloud-based servces. However, they have no means for requestng combned servces from dfferent clouds or for enforcng an ndvdual qualty level. Layng the foundaton for market-based cloud collaboratons ncludng the negotaton of ndvdual qualty parameters s an mportant aspect for future cloud computng. Cloud consumers, especally enterprses are then able to request complex servces wth consumer-drven qualty guarantees accordng to ther ndvdual needs and are not concerned wth the problem on how to make the dfferent components work together. In ths paper, we present an approach for collaboratve complex servce provsonng n cloud computng and an evaluaton of selected mechansms for the negotaton of qualty parameters n such a collaboratve market-based scenaro. 1 Introducton Cloud computng has recently attracted a lot of attenton wth respect to IT archtectures and ams to provde computng resources n a hghly dynamc and flexble manner. In 2010, the cloud computng market reached a large market volume and ts sze wll grow further n the next years [11]. Nevertheless, cloud computng s stll n a very early stage concernng open standards and nterfaces [13], so that consumers cannot change selected cloud provders very easly. A vson amng at these ssues s a global cloud marketplace [1], whch does not depend on the specfcs of a certan vendor offerng standardzed nterfaces. Such a cloud marketplace would also facltate the combnaton of dfferent servces from varous cloud provders and enable cloud federaton scenaros [8]. Hence, t can be consdered as a frst step towards the Future Internet [7]. To realze the vson of a global cloud marketplace, several requrements have to be fulflled. Qualty parameters, such as relablty or avalablty, are especally crucal n a busness envronment. In order to retan control of the servce qualty, so-called Servce Level Agreements (SLAs) can be negotated between the servce consumer and the cloud provder to ensure a level of qualty consumers can rely on. Bascally, an SLA represents a contract between two partes and defnes the objectves (e.g., qualty parameters) the cloud provder has to fulfll and the The documents dstrbuted by ths server have been provded by the contrbutng authors as a means to ensure tmely dssemnaton of scholarly and techncal work on a non-commercal bass. Copyrght and all rghts theren are mantaned by the authors or by other copyrght holders, not wthstandng that they have offered ther works here electroncally. It s understood that all persons copyng ths nformaton wll adhere to the terms and constrants nvoked by each author's copyrght. These works may not be reposted wthout the explct permsson of the copyrght holder.
penaltes n case the provder volates the agreement. At present, cloud provders offer no or only lmted support for the negotaton of ndvdual qualty parameters [1]. Thus, consumers, especally enterprses are not able to obtan Qualty of Servce (QoS) guarantees accordng to ther specfc busness constrants. But enablng consumer-drven QoS guarantees would ncrease the flexblty and effcency when usng cloud-based servces. Furthermore, consumers wsh to dynamcally combne servces from dfferent cloud provders wthout further effort for the nterconnecton of the dfferent components. Ths requres the collaboraton between multple cloud provders. Hence, an automated mechansm s requred to negotate ndvdual QoS guarantees and to dynamcally select collaboraton partners from a set of multple cloud provders. In ths paper, we present a collaboratve cloud market model for complex servce provsonng. The collaboraton allows cloud provders to share ther resources and to offer complex servces on the cloud computng marketplace. Besdes the selecton of collaboraton partners, negotatng ndvdual QoS parameters s also a major ssue that we address n the paper. The remander of the paper s structured as follows. Secton 2 descrbes the requrements for collaboratve complex servce provsonng, Secton 3 ntroduces our collaboratve market model and Secton 4 presents ntal expermental results of our approach. The paper closes wth a dscusson of related approaches n Secton 5 and wth a concluson and future drectons n Secton 6. 2 Problem Statement Our work focuses on a mechansm for collaboratve complex servce provsonng, n whch servces from dfferent cloud provders can be combned to a bundle. Defnton 1 (Bundle) A bundle B s a set S of m dfferent functonal servces. Each component c n the bundle has communcaton relatonshps wth a subset of S\ {c},.e., wth some of the other components n the bundle. For example, an enterprse could request a set of servces from multple cloud provders to fulfll nternal busness actvtes, e.g., a Customer Relatonshp Management soluton, data storage, vrtual machnes for data processng, and a database [8]. In ths scenaro, multple provders offer heterogeneous servces on the envsoned global cloud marketplace, where the followng assumptons hold: Specalzaton: Each provder has specalzed n provdng specfc servce types. The provders partcpate n the market, because they are unable to provde all the requred servces on ther own [9]. Comparablty: We assume that the servces can be classfed accordng to ther functonalty. Hence, all provders n a sngle category are competng wth the other provders n the same category. Standardzed Interfaces: There are no consumer swtchng costs due to specfc servce propertes when changng cloud provders. The development of cloud standards s currently addressed by several actvtes 1. 1 An overvew can be obtaned from http://cloud-standards.org/
Scalablty: In our basc model, we further neglect resource constrants n the frst nstance. Thus, we assume that each provder has unlmted resource capactes concernng the provder s specfc servce types. Collaboraton: After the determnaton of the collaboraton partners, the provders are responsble for provdng the bundle. Snce the several components n the bundle must be able to drectly communcate wth each other accordng to ther communcaton relatonshps, the provders must establsh connectons between the components comng from multple clouds. Such a so-called sky computng scenaro [5] typcally requres to lay a vrtual ste over the dstrbuted resources among the dfferent admnstratve domans. Adaptablty: Fnally, we assume that the cloud provders can vary the QoS levels that they provde accordng to ther cost functons. Snce they have prvate nformaton, e.g., concernng ther cost factors, a negotaton of QoS parameters s necessary. Relatonshps: Although cloud provders are located worldwde, they cannot establsh data centers everywhere. Thus, they may have dffcultes n fulfllng all QoS requrements, e.g., due to network delays. Hence, the relatonshps between the dfferent components must be taken nto account snce they have a drect mpact on the QoS parameters. Two major ssues that have to be addressed arse n such a collaboratve cloud market scenaro: How to negotate the QoS parameters of a bundle wth multple cloud provders and how to select the collaboratng partes? Cloud consumers must specfy ther requrements (e.g., upper or lower bounds) for the whole bundle and for each servce that s part of the bundle. A market model s requred to maxmze the consumer s utlty and the cloud provders utlty (n terms of cost), whle consderng the boundares for the dfferent parameters. 3 Approach 3.1 System Model and Notaton Our model conssts of three man actors: servce consumers, cloud provders and a market platform. Servce consumers SC can request a bundle of servces at the market platform and specfy ther requrements concernng the non-functonal propertes of the bundle,.e., QoS parameters and prce. These requrements are used by the market platform to compose the bundle. The composton s structured nto two phases: the negotaton between the market platform and the cloud provders and the selecton of the collaboraton partners for the provson of the bundle. The two phases are descrbed n the followng. To perform a frst analyss, we assume a sequental order of the m servces wthn the bundle B. The consderaton of more complex communcaton relatonshps wll be part of our future work. Furthermore, the servces can be grouped nto functonal categores Cat wth (1,..., m). Each category conssts of a set of cloud provders CP wth p elements, where each element represents a cloud provder offerng a servce wth the same functonalty. The cloud
SC SC SC Market platform Cat1 Cat Catm CP11... CP1... CPm1... CP1j... CPj... CPmj... CP1p CPp CPmp Propertes CPm1: CFQ1m1 and CFQ2m1 Servce Sm1: Prm1, Q1m1 and Q2m1 SC: Servce Consumer CP: Cloud Provder Bundle B Fg. 1. Market system provders are denoted wth CP,j and the servce a cloud provder CP,j delvers wth S,j, where (1,..., m) and j (1,..., p). We assume that a servce S,j s, besdes ts functonalty, descrbed wth three propertes: prce P r,j and two QoS parameters Q1,j and Q2,j, whch are generc representatons of possble QoS parameters (e.g., avalablty). From the servce consumers pont of vew, prce s a negatve attrbute and QoS parameters are postve attrbutes. Servce consumers specfy ther requrements wth two elements: thresholds and utlty functons. Both are provded for the functonal category level as well as for the whole bundle. The thresholds on category level are T hcatp r, T hcatq2 and T hcatq2 for prce and QoS parameters. In addton, the servce consumer uses a utlty functon U Cat (S,j ), whch shows the consumer s utlty dependent on the non-functonal propertes of a servce. The utlty functon s descrbed n Secton 3.2. Durng the negotaton, the goal of the market platform s to maxmze the utlty of the servce consumer for each functonal category whle keepng the provded thresholds. Analogously, the cloud provders have a cost functon, whch specfes what effort s requred to provde the QoS propertes at a certan qualty level for a gven servce. Therefore, each cloud provder CP,j has two cost factors CF Q1,j and CF Q2,j for the two QoS parameters. The cost functon U CP,j (S,j ) reflectng the utlty of a cloud provder s descrbed further n Secton 3.2. The overall model wth ts actors s shown n Fgure 1. It s not suffcent to specfy only the requrements of sngle servces of the bundle, but also the overall bundle must fulfll certan requrements. Therefore, the thresholds and an addtonal utlty functon for the servce consumer
are specfed at bundle level. Ths nformaton comprses the three thresholds T hbup r, T hbuq1 and T hbuq2 and the utlty functon of the servce consumer for the bundle UBu(B). The goal of the market platform for the composton of the overall bundle s to fulfll the thresholds and to maxmze the consumer s utlty for the bundle. Ths problem s based on the prevous negotatons n the functonal categores and deals wth the optmal selecton among the resultng offers of the negotaton process. 3.2 Negotaton of Qualty of Servce Negotaton takes place between the cloud provders and the market platform. The market platform uses the utlty functon of the servce consumer and the provded thresholds for the negotaton. A servce S,j fulflls all thresholds f: T hcatp r P r,j and T hcatq1 Q1,j and T hcatq2 Q2,j (1) The utlty functon s assumed to be addtve and has a decreasng margnal utlty (shown by the square roots) for both QoS parameters [2]. Each nonfunctonal property of a servce has an ndvdual weght. The weght of the prce s negatve, whereas the weghts of the QoS parameters are postve to express the utlty for the servce consumer. The weghts are denoted wth wcatp r, wcatq1 and wcatq2. The utlty functon of the servce consumer s as follows: UCat (S,j ) = wcatp r P r,j + wcatq1 Q1,j + wcatq2 Q2,j (2) As already stated, each cloud provder has a cost functon. In ths functon, every provder makes use of other cost factors to enforce certan QoS parameters, whch are both negatve, snce the cloud provders have hgher costs for provdng better (hgher) QoS values. Hence, the cost functon represents the utlty of the cloud provders. The utlty functon for the cloud provder CP,j s as follows: UCP,j (S,j ) = P r,j + CF Q1,j Q1,j + CF Q2,j Q2,j (3) The two partes fulfll the requrements for a negotaton, snce they have dfferent preferences for the gven propertes and want to maxmze ther utlty. For the negotaton, a mechansm s requred that specfes the protocol and the strategy of the partes on both sdes. The gven scenaro wth the market platform on the one sde and p cloud provders n a functonal category on the other sde and three negotaton domans (prce and QoS parameters) requres support for one-to-many negotatons and multple attrbutes. After an analyss of dfferent negotaton protocols based on [12], whch can be used n automated negotatons, we decded to use the contract net protocol [15] and the Englsh aucton [2] for an ntal evaluaton of the negotaton n the model. The contract net protocol s a smple protocol orgnally used for dstrbutng tasks n computer systems. The tasks are specfed by a central manager and sent to provders. The provders return an offer for the specfcaton wth the smallest prce they can provde. After one round, the central manager
assgns a task to the provder wth the best offer. Usng the contract net protocol, the prce of the offer s calculated as follows: P r CNP,j = CF Q1,j T hcatq1 CF Q2,j T hcatq2 (4) The cloud provders make a bd, f the QoS parameters they can provde meet the desred thresholds,.e., an offer s vald, f P r,j CNP T hcatp r. Snce the utlty functon of the servce consumer s prvate, the cloud provders only optmze the prce of ther offers accordng to the gven thresholds. The assumpton s that they are wllng to make a bd untl they gan no utlty from the offer anymore. Hence, the value of the utlty functon s mnmzed n order to maxmze the probablty for a bd to get accepted. In the Englsh aucton, bdders may bd for a partcular good durng several rounds, untl no bds can be made anymore. A bd s vald, f t exceeds the currently hghest ranked bd. Fnally, the hghest bd wns the aucton. We use the Englsh aucton as a reversed aucton (.e., the cloud provders makng offers whch can be accepted by the marketplace) wth a mult-attrbute extenson that enables the consderaton of all requrements. In the orgnal verson of the Englsh aucton, cloud provders can be outbd durng a sngle round. In our scenaro, the market platform chooses the best offer after each sngle round and sets t as lowest bd for the next round. The domnant strategy for the cloud provders s to ncrease ther offers n each round by a mnmal dfference DffOff between two offers. The ncrease does not refer to the prce, but to the utlty of the servce consumer. Ths enables to consder not only the prce, but all non-functonal attrbutes for the aucton. The calculaton of the values for the ncrease and the prces s adapted from [2]. The QoS parameters are calculated as follows: ( wcatq1 ) 2 ( wcatq2 ) 2 Q1 EA,j = and Q2 EA,j = (5) wcatp r 2 CF Q1,j wcatp r 2 CF Q2,j Based on these values and the utlty of the current best offer S BestOffer, the prce s calculated as follows: P r EA,j = wcatq1 2 wcatp r 2 CF Q1 + wcatq2 2 wcatp r 2 CF Q2 UCat (S BestOffer ) DffOff (6) wcatp r However, there s a major dfference between a standard Englsh aucton and the scenaro n ths work: the thresholds for the non-functonal propertes. These thresholds lmt the propertes and can lead to nvald solutons. Therefore, the approach used n ths work adjusts the QoS parameters, f the calculated values are below the thresholds, and uses the new values for the calculaton of the prce. Both negotaton protocols lead to a number of offers n each functonal category. These offers must be composed to a bundle n the next step, whch s descrbed n the next secton.
3.3 Partner Selecton for Collaboraton The second part of the collaboraton process s the selecton of collaboraton partners from the set of vald offers S V al for each Cat after the negotaton. The sze of S V al s less or equal p, because not every cloud provder must make an offer. The selecton of the collaboraton partners s desgned as optmzaton problem, whch selects one servce from each functonal category. Each vald servce S,j has a bnary decson varable x,j, whch s 1 f the servce s part of the optmal soluton and 0 f not. The selecton s based on the propertes of the servces as well as the connectons between the servces. Connectons between servces only exst f the servces are neghbors n the sequental order of the bundle. A connecton between servces S,j and S +1,k s denoted wth Con,j,+1,k and has the non-functonal propertes CP r,j,+1,k, CQ1,j,+1,k and CQ2,j,+1,k. The connectons have an addtonal decson varable y,j,+1,k, whch s 1 f each varable x,j and x +1,k s 1. The aggregaton operators of the non-functonal propertes are assumed to be summatons. The second QoS parameter uses two addtve functons to separate between servces and connectons. Other aggregaton operators lke multplcaton or mn-operators are also possble and can be consdered n future research. The utlty functon of the servce consumer for the bundle s as well addtve and uses dfferent weghts to ncrease the flexblty just as the utlty functon of the servce consumer for the functonal categores. The weghts wbup r( 0), wbuq1( 0) and wbuq2( 0) are used for both, servces and connectons. The weghted utlty and objectve functon and constrants are defned n Model 1, whch s a lnear optmzaton problem that can be solved optmally wth a branch-and-bound approach [4]. 4 Expermental Results For the evaluaton, the prevously descrbed model has been mplemented. The mplementaton s agent-based and descrbes the behavor of the market platform and the cloud provders durng the negotaton and soluton of the optmzaton problem. The evaluaton s a proof-of-concept for the developed model and, at the same tme, analyzes the nfluence of the amount of cloud provders on the negotaton. The tests have been performed on a laptop wth a 64bt dual core 2.53 GHz processor wth 4 GB RAM and Wndows 7 as operatng system. For the smulaton of the agents, Repast Smphony 2 has been used and the optmzaton problem has been modeled and solved wth LPSolve 3. The number of cloud provders wthn a category s vared between 2, 4, 6, 8, and 10 cloud provders. For each varaton, 20 test cases have been generated. The scenaro has been tested exemplary for 5 functonal categores. The values for the parameters of the followng evaluaton are shown n Table 1. The table shows the ranges of the random numbers or f no range s gven the fxed values of the parameters. Besdes these parameters, the Englsh aucton uses a mnmal dfference between offers of 0.5 utlty unts. 2 http://repast.sourceforge.net/ 3 http://lpsolve.sourceforge.net/5.5/
Model 1 Collaboraton Partner Selecton Problem Objectve Functon (Maxmze): m =1 m 1 x,j(wbup r P r,j + wbuq1 Q1,j + wbuq2 Q2,j) + =1 k S V al +1 y,j,+1,k (wbup r CP r,j,+1,k + wbuq1 CQ1,j,+1,k + wbuq2 CQ2,j,+1,k ) (7) Constrants: T hbup r T hbuq1 m =1 m =1 T hbuq2 m 1 x,j P r,j + =1 m 1 x,j Q1,j + T hbuq2 m 1 =1 k S V al +1 =1 m =1 k S V al +1 k S V al +1 k S V al +1 y,j,+1,k CP r,j,+1,k (8) y,j,+1,k CQ1,j,+1,k (9) x,j Q2,j (10) y,j,+1,k CQ2,j,+1,k (11) x,j = 1 (1,..., m) (12) y,j,+1,k = 1 (1,..., m 1) (13) x,j + x +1,k y,j,+1,k 1 (1,..., m 1) j S V al k S V al +1 (14) The medan run tmes of the two negotaton protocols are shown n Fgure 2. They are dstrbuted from 1.9 to 13.6 ms. For both protocols, the run tme ncreases wth a growng number of cloud provders. The contract net protocol shows slghtly hgher run tmes than the Englsh aucton. The reason for ths s that the contract net protocol produces a larger set of vald servces than the Englsh aucton, whch ncreases the tme to solve the optmzaton problem. The servce consumer s utlty consdered n the problem s measured on two levels: for each category and for the overall bundle. For the former, the absolute and the relatve utlty of the consumer s measured and for the latter, we only measure the absolute utlty, snce the relatve utlty s 100% for all the offers. The relatve utlty s calculated by usng the Lagrange method [4] to evaluate the maxmal possble utlty a cloud provder can provde wthout gven boundares and wthout achevng an own utlty. The result s set as maxmum and the acheved utlty s set n relaton to t. The results for the relatve utlty are shown n Fgure 3(a). They show that the contract net protocol reaches a relatve
Run Tme (ms) 14 12 10 8 6 4 2 0 Contract Net-Protocol Englsh Auc on 2 4 6 8 10 Number of Cloud Provders n Category Fg. 2. Run tme of negotaton protocols utlty of 60% and remans on the same level for all scenaros. The Englsh aucton acheves a smlar level, but the relatve utlty decreases for a hgher number of cloud provders wthn the categores. The reason for ths decrease s that more provders lead to a hgher probablty that one provder cannot reach the optmal values for the non-functonal propertes. Thus, ths provder ncreases the utlty faster, whch leads to earler dscards of other provders and lowers the value. Another result, the best absolute utlty wthn a category, s shown n Fgure 3(b). Concernng the utlty, the contract net protocol does not depend on the number of cloud provders and remans on the same level. In contrast, the Englsh aucton shows a postve correlaton between the number of cloud provders and the best acheved utlty. The reason for ths s, that more provders lead to a hgher competton and, therefore, a hgher utlty value. The probablty that the two best provders have smlar cost factors and ncrease ther offers to the maxmum s hgher n scenaros wth many provders. The evaluaton of the servce consumer s utlty for the bundle s shown n fgure 4. The medan utlty acheved wth the Englsh aucton s much hgher for the chosen weghts than the utlty acheved wth the contract net protocol. Ths can be explaned wth the low values for the two QoS parameters resultng from the contract net protocol n contrast to the hgh values resultng from the Englsh aucton. Low values lead to a low utlty, snce the acheved prce cannot compensate them. Table 1. Values of the parameters for the evaluaton Category Bundle Parameter Values Parameter Values CF Q1,j and CF Q2,j [0; 1] wcatp r 1 wbup r 1 wcatq1 and wcatq2 2 wbuq1 and wbuq2 0.5 T hcatp r [15; 20] T hbup r [15; 20] m T hcatq1 [0; 5] T hbuq1 [0; 3] m T hcatq2 [0; 5] T hbuq2 [0; 1]
Rela ve U lty (%) 100 80 60 40 20 Contract Net Protocol Englsh Auc on Servce Consumer U lty 10 8 6 4 2 Contract Net-Protocol Englsh Auc on 0 2 4 6 8 10 Number of Cloud Provders n Category 0 2 4 6 8 10 Number of Cloud Provders n Category (a) Medan relatve utlty (b) Medan best utlty Fg. 3. Servce consumer medan utlty of negotaton protocols for categores Servce Consumer U lty 180 160 140 120 100 80 60 40 20 0 Contract Net Protocol Englsh Auc on 2 4 6 8 10 Number of Cloud Provders n Category Fg. 4. Servce consumer medan utlty of negotaton protocols for bundle It can be observed from the evaluaton that both negotaton protocols show small medan run tmes and thus, are applcable n a dynamc collaboratve envronment. Concernng the utlty of the bundle, the Englsh aucton acheves hgher medan utlty values than the contract net protocol. However, the Englsh aucton depends on the amount of the provders. In summary, the contract net protocol s preferable n scenaros, where the servces must only satsfy mnmal requrements and the prce s consdered as the most mportant crtera. In contrast, the Englsh aucton should be appled n case of a large number of provders n order to acheve a hgh utlty. Nevertheless, no negotaton mechansm outperforms the other n all settngs. 5 Related Work A lot of research has been done n cloud computng. Yet, only a few approaches focus on market-based scenaros. To the best of our knowledge, ths s the frst work that combnes the negotaton of ndvdual consumer-drven QoS guarantees and the selecton of collaboraton partners from sets of competng cloud provders n a market-based cloud computng scenaro. In contrast, Buyya et al. [1] present a vson of a cloud market for tradng resources n order to establsh a balance between supply and demand. The authors also consder the negotaton
of QoS parameters between a consumer and a provder. However, collaboratons are not consdered n ther work. Based on the market model of Buyya et al., Sm [14] focuses on QoS negotatons to allow for flexble prcng. He dvdes hs scenaro nto two dsjunct markets for cloud servces and cloud nfrastructure resources nterconnected va brokers. Agan, collaboratons are not part of hs work. Concernng the selecton of collaboraton partners, Hassan et al. [3] propose a mult-objectve optmzaton model wth multple target functons that depend on each other. The authors goal s to mnmze the prce and to maxmze the servce qualty and the performance of collaboratve past relatonshps. The collaboratons are ntated by prmary cloud provders, who dentfy a specfc busness opportunty and search for approprate partners. In the second step, the resultng groups of collaboratng cloud provders use the market to offer a set of servces to consumers, who can bd a prce for the set of servces. Negotatng ndvdual consumer-drven QoS guarantees s not consdered n ther approach. In ther work n [6], Brscoe and Marnos descrbe a communty cloud market model, where communty members provde and manage the resources. The authors also dscuss the enforcement of certan QoS levels wth the help of a communty currency servng as a means for admsson control. However, collaboratve resource provsonng s n the focus of ther work, dsregardng the negotaton of ndvdual QoS guarantees. 6 Concluson In ths paper, we have presented an approach for collaboratve complex servce provsonng n cloud computng and ntroduced a correspondng market model. The model provdes a good soluton for market-based collaboratons n cloud computng and consders ndvdual consumer-drven QoS guarantees. Furthermore, the model can be adapted to dfferent negotaton mechansms and consumer and/or provder requrements. Hence, t serves as a foundaton for future nvestgatons concernng collaboratve cloud markets. In addton, we have explored the applcablty of dfferent QoS negotaton mechansms n the desgned market model. The results revealed that both nvestgated negotaton mechansms are applcable n a dynamc collaboratve settng. Although each strategy offers advantages n some stuatons, no sngle negotaton mechansm outperforms the other n all settngs. Thus, further negotaton mechansms (e.g., Vckrey aucton 4 ) wll be explored n future work. Also, smaller cloud provders wll not be able to offer an unlmted amount of resources. Hence, a small amount of resources could also be consdered as an ncentve for collaboratons. Therefore, further drectons for future work are the consderaton of restrcted resource capactes of the provders as well as tme constrants, whch evolve through parallel consumer requests for the same resources and the temporary allocaton of the resources. 4 The Vckrey aucton s a sealed-prce sealed-bd aucton, where the best strategy s to bd the best estmate value of a good [10].
References 1. Buyya, R., Yeo, C.S., Venugopal, S., Broberg, J., Brandc, I.: Cloud Computng and Emergng IT Platforms: Vson, Hype, and Realty for Delverng Computng as the 5th Utlty. Future Generaton Computer Systems 25(6), pp. 599 616 (2009) 2. Davd, E., Azoulay-Schwartz, R., Kraus, S.: An Englsh Aucton Protocol for Multattrbute Items. In: Revsed Papers from the Workshop on Agent Medated Electronc Commerce on Agent-Medated Electronc Commerce IV, Desgnng Mechansms and Systems. pp. 52 68. Sprnger (2002) 3. Hassan, M.M., Song, B., Yoon, C., Lee, H.W., Huh, E.N.: A Novel Market Orented Dynamc Collaboratve Cloud Servce Infrastructure. In: 2009 World Conference on Servces - II (SERVICES-2 09). pp. 9 16 (2009) 4. Hller, F., Leberman, G.: Introducton to Operatons Research. McGraw-Hll, New York, 8th edn. (2005) 5. Keahey, K., Tsugawa, M., Matsunaga, A., Fortes, J.: Sky Computng. IEEE Internet Computng 13(5), pp. 43 51 (2009) 6. Marnos, A., Brscoe, G.: Communty Cloud Computng. In: 1st Internatonal Conference on Cloud Computng. pp. 472 484. Sprnger (2009) 7. Müller, P., Reuther, B.: Future Internet Archtecture A Servce-orented Approach. t Informaton Technology 50(6), pp. 383 389 (2008) 8. Nar, S.K., Porwal, S., Dmtrakos, T., Ferrer, A.J., Tordsson, J., Sharf, T., Sherdan, C., Rajarajan, M., Khan, A.U.: Towards Secure Cloud Burstng, Brokerage and Aggregaton. In: 8th IEEE European Conference on Web Servces (ECOWS 10). pp. 189 196 (2010) 9. Paletta, M., Herrero, P.: A MAS-Based Negotaton Mechansm to Deal wth Servce Collaboraton n Cloud Computng. In: 2009 Internatonal Conference on Intellgent Networkng and Collaboratve Systems (INCOS 09). pp. 147 153 (2009) 10. Parsons, S., Rodrguez-Agular, J.A., Klen, M.: Auctons and Bddng: A Gude for Computer Scentsts. ACM Computng Surveys 43(2), pp. 1 59 (2011) 11. Pettey, C., Tudor, B.: Gartner Says Worldwde Cloud Servces Market to Surpass $ 68 Bllon n 2010 (June 2010), http://www.gartner.com/t/page.jsp? d=1389313, [last access: 2011.05.07] 12. Sandholm, T.: Dstrbuted Ratonal Decson Makng. In: Weß, G. (ed.) Multagent Systems: A Modern Introducton to Dstrbuted Artfcal Intellgence, chap. 5, pp. 201 258. MIT Press, Cambrdge (1999) 13. Schnedermann, R.: For Cloud Computng, the Sky s the Lmt. Sgnal Processng Magazne 28(1), pp. 15 144 (2011) 14. Sm, K.M.: Towards Complex Negotaton for Cloud Economy. In: 5th Internatonal Conference on Advances n Grd and Pervasve Computng (GPC 2010). pp. 395 406 (2010) 15. Smth, R.G.: The Contract Net Protocol: Hgh-Level Communcaton and Control n a Dstrbuted Problem Solver. IEEE Transactons on Computers 29(12), pp. 1104 1113 (1980)