A decentralized self adaptation mechanism for service based applications in the cloud

1

A Decentralized Self-Adaptation Mechanism ForService-Based Applications in The Cloud

Vivek Nallur, Rami Bahsoon

Abstract—Cloud computing, with its promise of (almost) unlimited computation, storage and bandwidth, is increasingly becoming theinfrastructure of choice for many organizations. As cloud offerings mature, service-based applications need to dynamically recomposethemselves, to self-adapt to changing QoS requirements. In this paper, we present a decentralized mechanism for such self-adaptation,using market-based heuristics. We use a continuous double-auction to allow applications to decide which services to choose, amongstthe many on offer. We view an application as a multi-agent system, and the cloud as a marketplace where many such applications self-adapt. We show through a simulation study that our mechanism is effective, for the individual application as well as from the collectiveperspective of all applications adapting at the same time.

Keywords—Self-Adaptation, Market-Based, Multi-Agent Systems

✦

1 INTRODUCTION

Self-adaptation, as a concept, has been around for manyyears, in several domains like biology, chemistry, logis-tics, economics etc. Self-adaptivity in computer-basedsystems is relatively newer. Some of the first referencesto self-adaptive software systems are from [41], [35], [34]and [31] (where they are referred to, as autonomic sys-tems). By self-adaptivity in software systems, we meansoftware that monitors itself and the operating environ-ment, and takes appropriate actions when circumstanceschange. In web-applications, service-oriented architec-ture has often been used as a mechanism for achiev-ing self-adaptivity [19]. Web-services allow for dynamiccomposition, which enables applications to switch ser-vices, without going offline. A common instance of usingweb-services dynamically, is applications living on thecloud, asking for computing power and bandwidth tobe scaled up or down, depending on demand. However,one of the cloud’s major selling points, operational flex-ibility is of little use, if applications (or organizations)have to indicate at sign-up time, the kind of services thatthey intend to use. On Amazon, for instance, a customerspecifies during sign up whether she wants a Hi-CPUinstance or a Standard On-Demand instance or a Hi-Memory instance. This assumes that an application isable to forecast its demand for computing and storageresources accurately. However, this inability to forecastis precisely what the cloud claims to address throughelasticity in computing power. This is not to say thatthere are no flexible, demand-based pricing schemesavailable. Amazon’s Spot Instances [29] is an example ofhow cloud providers are trying to flexibly price theirservices, in response to fluctuating demand over time.Applications that can adapt to fluctuating prices willbe able to ensure a better return on investment. In thefuture, we surmise that service-pricing will depend notonly on demand but also on additional attributes like

performance, availability, reliability, etc.Current implementations of public clouds mainly focuson providing easily scaled-up and scaled-down comput-ing power and storage. We envisage a more sophisticatedscenario, where federated clouds with different special-ized services collaborate. These collaborations can thenbe leveraged by an enterprise to construct an application,that is self-adaptive by changing the specific web-serviceit utilizes. The notion of utilizing collaborative servicesto satisfy a business need, is not new in itself. Therecognition of Agile Service Networks (ASN) that springup in modern business practices, is testament to this.As ASNs mature and dynamic composition becomes thenorm, we posit that applications that are composed ofother applications will routinely adapt to changing QoSrequirements. In this paper, we propose a decentralizedmechanism to address the problem.

1.1 Problem Statement

Composite web-services are services that are composedof other web-services. Several web-applications are madeby composing web-services together. The effective QoSprovided by such an application is a function of the QoSprovided by the individual web-services. Hence, if theapplication wishes to exhibit a different level of QoS,it can do so by changing its constituent web-services.However this is not an easy task. Identifying the optimalweb-service, for each task that the application performs,is a hard problem. To illustrate, consider an applicationcomposed of five tasks, and its choices of web-services:In Table 1, if the application wanted to opti-

mize on Price, the set of selected services would be[S15, S21, S32, S41, S52]. On the other hand, if it wantedto optimize on Latency, the selected services would be[S11, S22, S34, S42, S54]. The calculations become moredifficult if the optimizations need to be done on mul-tiple QoS simultaneously, for e.g., Latency and Price

2

Task Web-Service Latency Availability Price

S1 S11 100 0.95 105S12 180 0.92 66S13 230 0.79 65S14 170 0.73 90S15 250 0.96 60

S2 S21 200 0.98 58S22 150 0.93 80S23 200 0.97 65

S3 S31 250 0.96 70S32 240 0.91 50S33 230 0.79 65S34 150 0.73 80S35 210 0.89 68

S4 S41 260 0.94 59S42 225 0.91 60

S5 S51 150 0.82 54S52 140 0.71 49S53 130 0.93 76S54 120 0.73 81S55 190 0.86 77

TABLE 1: Choice of services available

or Latency and Availability. As the number of tasks inthe workflow increase, the number of combinations alsoincrease correspondingly.The problem arises from the fact, that for each of

these tasks (AbstractService) in the application’s work-flow, there are several services (ConcreteService), thatcan be used. Each of these ConcreteServices exhibitsdifferent values of QoS, and each is priced differently.Determining the best combination of services to achievethe application’s overall target QoS, is an NP-Hardproblem [3]. There is a further complication. As dif-ferent jobs arrive, depending on the priority and QoSdemanded, the application has to either scale up ordown, on each of those QoS attributes. Not only doesit have to re-calculate the best value-for-money services,but the set of ConcreteServices that are available, alsochange with time. Since these services (possibly) belongto third-parties, they may or may not be available or,are available with different QoS or, for a different price.Thus, the application has to deal with all of these factors,while adjusting to the changed demand for QoS. Self-Adaptation, in this case, is the problem of dynamicallyselecting services, from the pool of services currentlyavailable. There are two conditions where an applicationthat has started off with a satisfactory level of QoS, needsto start adapting:

1) External Adaptation Stimulus: When a QoS violationis detected at any of the services, the applicationneeds to search for a new service to replace theold one.

2) Internal Adaptation Stimulus: When the application’sQoS target changes, the application needs to triggeran adaptation, to ensure that its constituent servicesare able to meet the target QoS level.

From the cloud provider’s perspective, any service thatcould potentially be used by an application, but is idleinstead, represents lost revenue. According to [9], inthe future, the cloud provider will have to invest in

self-managing resource management models that canadaptively service new QoS demands as well as exist-ing QoS obligations. It is this scenario, of self-adaptiveapplications on one side, and dynamic service provisionfrom the cloud provider on the other, that we addressin this paper. Current static models of provisioning andpricing will prove inadequate, as self-adapting applica-tions mature.

1.2 Contributions of this paper

In [38], we had proposed a preliminary design of amarket-mechanism for service-based application to self-adapt to changing QoS requirements. In this paper, weexplicate on the adaptation mechanism, its design interms of implementation units, and its efficacy. In thispaper, we also detail the adaptive generation of bids, andthe decentralized mechanism for selection of services.We then show that this approach scales to hundreds ofapplications, with thousands of services being evaluatedand selected. We show that the services thus selected,meet the QoS criteria of the application, and stay withinbudget.

2 OUR APPROACH

We would like to create a mechanism that allows mul-tiple applications, constructed across a federation ofclouds, to self-adapt. We chose a market-based approachto self-adaptation, not only because it is decentralized,but also due to its easy applicability to the problem do-main. Services in the cloud are moving from a fixed-pricepackage to a more flexible, auction-based approach [29].This enables a self-adaptive application to change theQoS exhibited, by switching to a different ConcreteSer-vice.

2.1 Market-Based ControlMarket-Based Control (MBC) essentially involves mod-elling the system as a marketplace, where self-interestedagents use economic strategies to compete for resources.Self-interested competition, along with well-designedutility functions, allow for a decentralized means ofdecision making. These agents, via their competitiveneed to get resources, perform a parallel search throughthe space of decision points. MBC has been used inseveral contexts, as a mechanism for computing a goodsolution in a decentralized manner. Notable examplesinclude Clearwater’s bidding agents to control the tem-perature of a building [16], Ho’s center-free resourcealgorithms [52] and Cheriton’s extension to operatingsystems to allow programs to bid for memory [25].Wellman’s WALRAS system [49], which is highly dis-tributed, reports high scalability. More examples includedistributed Monte-Carlo simulations [47], distributeddatabase design using market-methods for distributingsub-parts of queries [45] and proportional-share resourcemanagement technique [48]. All of these systems provideevidence of market-based control being a good candidatefor distributed decision making.

3

2.2 Auctions

Auctions, specifically Double Auctions (DA), have in-creasingly been studied in Computer Science, as a mech-anism of resource allocation. Daniel Friedman [22] re-ports on experiments where traders even with imperfectinformation, consistently achieve highly efficient alloca-tions and prices. The rise of electronic commerce natu-rally creates a space for efficient exchange of goods, andservices. There has been much work on the design spaceof market-institutions [51], [39], bidding strategies [17],[43], agent-based implementations of traders [30], [26],[27], [40], etc. Gupta et al [24] argue that network man-agement, specifically for QoS issues, must be done usingpricing and market dynamics. According to them, theflexibility offered by pricing mechanisms offers bene-fits of decentralization of control, dynamic load man-agement and effective allocation of priority to differ-ent QoS attributes. The continuous-time variant of aDA, called Continuous Double Auction (CDA), is usedin stock-markets and commodity exchanges around theworld [32]. In a CDA, the market clears continuously.That is, instead of waiting for all bids and asks to bemade, matches are made as the bids and asks come in.A new bid is evaluated against the existing asks and thefirst ask that matches, is immediately paired off for atransaction. A CDA is known to be highly allocativelyefficient [23], i.e., it achieves a very high percentage of allthe possible trades, between buyers and sellers. The mostimportant property of the work in [23], is that a CDA’sefficiency results from the structure of the mechanismused, rather than intelligence of the agents involved intrading. This is a very important result, since it providesus with encouragement regarding the efficiency of ourmechanism.

2.3 Use of MDA for QoS adaptation

We view an application as a directed graph of Ab-stractServices. A ConcreteService corresponds to a pieceof functionality described by the AbstractService, alongwith associated QoS levels. Thus, a data-mining appli-cation can be visualised as a directed graph of abstractdata-filtering service, a data-transformation service, aclustering service and visualization service. The totalQoS actually exhibited by the application, is a functionof the individual QoS exhibited by each of the Concrete-Services that have been used in the composition. Wedesign a marketplace that allows individual applicationsto select ConcreteServices. The cloud is designed to bean ultra-large collection of applications, web-servicesand raw computing power. Given this large scale, anysolution that is implemented, must not rely on centralknowledge or coordination. A market populated withself-interested trading agents is therefore suitable forour purpose. The design of the market that we chose,is the CDA. However, we are mindful of Eymann’scriticism [21] with regard to implicit centralization ofauctions, and hence we create multiple double auctions

(MDA), for each AbstractService. That is, each Abstract-Service is traded in multiple markets, and trading agentscan move amongst these markets to find the Concrete-Service they need. Each market is homogeneous, in thesense that all ConcreteServices trading in that market,pertain to one AbstractService only. This is analogous tocommodity markets in the real world. Thus, in a marketfor clustering web-services, each seller provides a Con-creteService that performs clustering, but offers varyingperformance and dependability levels. Varying levels ofQoS require different implementations, and dependingon the complexity of the implementations, will be eitherscarce, or common. This leads to a differentiation inpricing based on QoS levels.

2.3.1 Description of AgentsBuyerAgent: A trading agent that is responsible forfulfilling one AbstractService. The BuyerAgent bids for,and buys a ConcreteService. The amount that the Buyer-Agent is prepared to pay is called the bid price and thisis necessarily less than or equal to its budget. The combi-nation of bid price and the QoS attributes demanded, iscalled the Bid.SellerAgent: A trading agent that sells a ConcreteSer-vice. A SellerAgent is responsible for only one Concrete-Service. Based on demand and supply, the SellerAgentadjusts the price at which it is willing to sell the Con-creteService. The amount that a SellerAgent is preparedto accept, is called the ask price. This is necessarily greaterthan or equal to its cost. The combination of ask price andthe QoS attributes offered, is called the Ask.MarketAgent: A trading agent that implements tradingrounds for a Market. It accepts Bids from BuyerAgents,and Asks from SellerAgents. It performs matching ofBids and Asks.ApplicationAgent: An agent responsible for ensuringthat an application meets its QoS requirements. Itis responsible for distributing the budget, calculatingachieved QoS, and instructing BuyerAgents to start/stopadaptation.

2.3.2 Structure of the AuctionA CDA works by accepting offers from both buyers andsellers. It maintains an orderbook containing both, theBids from the buyers and the Asks from the sellers. TheBids are held in descending order of price, while theAsks are held in ascending order, i.e., buyers willing topay a high price and sellers willing to accept a lowerprice are more likely to trade. When a new Bid comesin, the offer is evaluated against the existing Asks inthe orderbook, and a transaction is conducted when theprice demanded by the ask is lower than the price theBid is willing to pay and all the QoS attributes of theAsk are greater than or equal to all the QoS attributes inthe Bid. After a transaction, the corresponding Bid andAsk are cleared from the orderbook.Table 2 shows the state of the orderbook at some time

t0. Maximizing the number of transactions would lead to

4

Bids Asks

[B1, 107, ssl=yes, framerate=24fps, latency=99ms] [S1, 97, ssl=yes, framerate=24fps, latency=99ms][B2, 105, ssl=yes, framerate=32fps, latency=105ms] [S2, 98, ssl=no, framerate=24fps, latency=99ms][B3, 98, ssl=yes, framerate=24fps, latency=99ms] [S3,103,ssl=yes,framerate=32fps,latency=105ms][B4, 91, ssl=yes, framerate=24fps, latency=105ms] [S4, 105, ssl=yes, framerate=24fps, latency=99ms][B5, 87, ssl=yes, framerate=24fps, latency=110ms] [S5, 110, ssl=no, framerate=32fps, latency=99ms]

TABLE 2: Orderbook at time t0

Bids Asks

[B1, 107, ssl=yes, framerate=24fps, latency=99ms] [S1, 97, ssl=yes, framerate=24fps, latency=99ms][B2, 105, ssl=yes, framerate=32fps, latency=105ms] [S2, 98, ssl=no, framerate=24fps, latency=99ms][B3, 98, ssl=yes, framerate=24fps, latency=99ms] [S3, 103, ssl=yes, framerate=32fps, latency=105ms][B4, 91, ssl=yes, framerate=24fps, latency=105ms] [S4, 105, ssl=yes, framerate=24fps, latency=99ms][B5, 87, ssl=yes, framerate=24fps, latency=110ms] [S5, 110, ssl=no, framerate=32fps, latency=99ms]

TABLE 3: Orderbook at time t1

a possible set like: [B1−S4, B2−S3, B3−S1]. Calculatingthis optimal set, however, quickly becomes infeasible asthe number of Bids and Asks increase, since the numberof pairwise comparisons increases exponentially. Witha CDA, the set of transactions is: [B1 − S1, B2 − S3].This is so because a CDA evaluates Bids and Asks, asthey appear, and the first possible match is set up asa transaction. Thus, [B1 − S1] is immediately matchedand removed from the orderbook, and then [B2−S3] ismatched. Since this procedure is carried out for everyoffer (Bid/Ask) that enters the market, the only Bidsand Asks that remain on the orderbook are those thathaven’t been matched (figure 3) yet. This procedure ismuch faster, and easily parallelizable. Although counter-intuitive, it has been shown that even when buyers andsellers have Zero-Intelligence, the structure of the marketallows for a high degree of allocative efficiency [23].Zero-Intelligence refers to a strategy, where the agents in-volved, do not consider any historical information abouttrades, and nor do they possess any learning mechanism.Thus, Zero-Intelligence marks the lower limit of theefficiency of a CDA market.There are many variations on the implementation of

a CDA, and each variation introduces changes in thebehaviour of both, markets as well as the trading agents.We now list the structural axes of a CDA, and ourposition on each of those axes:

1) Shout Accepting Rule: Bids and Asks are referredto, as shouts. When a shout is received, the marketevaluates it for validity. If valid, a shout is insertedin the appropriate place in the orderbook. Themost commonly used shout accepting rule is theNYSE rule. According to the NYSE rule, a shout isonly accepted, if it makes a better offer than thattrader’s previous offer [46]. We modify this rule toallow BuyerAgents to submit multiple Bids. Thismodification allows the BuyerAgents to explore theQoS-cost search space in a more efficient manner(see section 2.4).

2) Information Revelation Rule: This refers to themarket information that is available to the BuyerA-

gents and the SellerAgents. In our case, all marketparticipants have access to the last k transactions.

3) Clearing Rule: The market can either clear contin-uously, or at periodic time intervals. A market thatclears with periodic time interval of 1 time unitis equivalent to clearing continuously. A marketthat clears with a time interval of greater than 1,is also called a Clearing House. As soon as an Askmeets all the QoS constraints specified in a Bid,and its ask-price≤ bid-price, a potential transactionis identified. For a given Bid, all the Asks thatcould be potential transactions are called Candi-dateServices. The BuyerAgent is given the optionof choosing one amongst the CandidateServices,while rejecting the rest. Again, this is a departurefrom typical CDAs, but essential to our mechanism(see section 2.5). Once a transaction takes place, thecorresponding Bid and Ask are deleted from theorderbook.

4) Pricing Rule: This determines the price at which atransaction takes place. The most commonly usedmechanism is k-Pricing. The value of k determineswhich entity makes more profit, the buyer or theseller. We use k = 0.5 (i.e., 0.5∗bid price+(1−0.5)∗ask price) as the transaction price.

2.3.3 QoS Calculation

There are three types of QoS constraints that we considerin our services:

1) Numeric: These constraints pertain to those QoSattributes that are either numeric inherently (e.g.,Cost) or, are easily reducible to a scale such that nu-meric comparisons are possible (e.g. performance,reliability, etc.)

2) Boolean: Refers to those QoS attributes that arerequired to be definitely either present or absent(e.g., secure socket layer support = yes/no)

3) Categoric: Refers to those QoS attributes that areagain required to be definitively picked out of alist, but may end up being more than one (e.g.,

5

possible values for framerate = 16fps, 24fps, 32fps,48fps and acceptable ones are: 32fps and 48 fps)

We also allow each constraint to be tagged as hard orsoft. This allows the application to indicate that it prefersa certain QoS attribute value, but that the value is notcritical. For example, an application might specify aboolean QoS attribute, say SSL support = yes, as a softconstraint. This means that given a choice, it wouldprefer a CandidateService which has SSL support, butit is not an essential criterion. On the other hand, anapplication in the banking domain could specify SSL asa hard constraint, which means that a ConcreteServicethat does not support SSL, is not a CandidateService atall.Stochastic Workflow Reduction: Depending on the

pattern of the Workflow involved in the application,the same individual services with their correspondingQoS values, could result in differing end-to-end QoSexhibited by the application. To compute the QoS metricsfor the entire application, we employ Stochastic WorkflowReduction(SWR) [11]. Using this method, the Workflowis viewed as a graph which is reduced using a series ofreduction steps. Each time a reduction rule is applied,the structure of the graph changes, and the QoS metricsfor the affected nodes are aggregated. The reductioncontinues in an iterative manner, until only one taskremains in the graph. The QoS metrics aggregated forthis task represents the QoS metrics corresponding to theapplication Workflow. In Figure 1, we see that a set ofparallel tasks t1, t2, t3...tn, a split task (ta) and a join task(tb) can be reduced to a sequence of three tasks, ta, tN , tb.The incoming transitions of task ta and the outgoingtransitions of task tb remain the same. The reduction forthe QoS of the parallel tasks is computed as follows:

Cost(tN ) =∑

1≤i≤n

Cost(ti) (1)

Reliability(tN) =∏

1≤i≤n

Reliability(ti) (2)

t

t

t

t

t t t t

(a)

(b)

a b

1

2

n

Na b

Fig. 1: Reduction of parallel tasks(reproduced from [12]).For additive QoS, the attributes are summed up, whilefor multiplicative QoS, the attributes are multiplied to-gether

Thus, if the cost for each of the parallel tasks (t1...tn)is 5 units each, then the cost of tN would be 5 ∗ n.

Likewise, if the reliability for (say) three tasks (t1...t3)is 0.9 each, then the reliability for tN would be 0.729.Similar reduction formulae [12] are used for other typesof tasks, such as sequential tasks, loop tasks, conditionaltasks, etc.

2.3.4 Decomposing End-to-End constraints

QoS constraints are usually specified on an application-wide basis. That is, performance for an entire application(end-to-end) or a cost constraint that must be met. Toachieve these constraints in a decentralized manner, wedecompose the end-to-end constraints, into local ones(the reverse process of SWR). Local constraints can canbe handed over to individual BuyerAgents. Amongstthe three type of QoS that we consider, Boolean andCategoric constraints do not need to be decomposed atall. They are given to all agents, as is. For example, ifthere is a Boolean constraint like: For all services,SSL=yes, then every agent can be given the constraint,without any processing. On the other hand, Numericconstraints like total cost ≤ C need to be decom-posed on a per-Agent basis. Numeric constraints aredecomposed, as shown in Algorithm 1. It may happenthat none of the markets offer a service with the QoSneeded to satisfy a particular application’s constraints.In such a case, the mechanism terminates, and signalsa failure. The ApplicationAgent does not take decisionsabout overriding constraints imposed by the applicationdesigner. We assume that the human designer modifiesthe constraints, or takes any other suitable action.

Algorithm 1: Decomposition of Numeric Constraints

Data: Numeric Constraints LimitResult: Numeric Constraints Decomposedbegin

foreach Agent a doFind list of markets (M) corresponding toafx

Choose m ∈M

Register in m

a←− mlast k transactions

foreach ω ∈ NumericConstraints docalculate aω m

low , aω mmedian, aω m

high

foreach ω ∈ NumericConstraints doApply SWR ←− 〈ωf1 , ωf2 , ωf3 . . .〉if constraintMet then

foreach Agent a doaω

bid ∝ SWRω

Choose different m

if allMarketsExhausted thenTerminateWithFailure

6

2.4 Adaptation Using Bid Generation

Bids are the mechanism by which BuyerAgents explorethe search space of QoS-cost combinations that areavailable. Depending on the bids, potential transactionalmatches are identified by the MarketAgent. Thus, thereneeds to be a systematic way to generate Bids. Therelevant aspects in a Bid are given in Table 4.The most important part of deciding on a value for a

QoS attribute, is the constraint on each attribute. If theconstraint is hard, then, in each of the generated Bids,the value inserted into the Bid will remain the same.Else, the value inserted into the Bid is varied. The variedvalues depend on the type of QoS attribute. The rules forgenerating QoS values, on the basis of type of attributeare as follows:Boolean: In case of soft constraints, two Bids will begenerated for a particular QoS attribute. For example,for QoS attribute SSL support, one Bid is generated withthe value: yes and another with the value: noCategoric: In case of soft constraints, the number of Bidswill depend on the number of acceptable alternatives.For example, for QoS attribute framerate, the acceptablealternatives are: 24fps and 32fps. Therefore, two Bids willbe generated.Numeric: In case of soft constraints, the number of Bidswill be three. The BuyerAgent makes one Bid at its targetvalue, one at the median value obtained from the market,and the third Bid at the mid-point between the target andthe median value.Thus, the total number of Bids that a BuyerAgent

generates is given by:

Num(buyerbids) =2 ∗Num(BooleanQoS)

∗Num(AcceptableAlternatives)

∗3 ∗Num(NumericQoS) (3)

Thus, if a BuyerAgent has the QoS and preferences asgiven in Table 5:The total number of bids that it would generate would

be:

Num(buyerbids) = 2 ∗Num(SSLSupport)

∗Num(FrameRate)

∗3 ∗Num(Latency)

= 2 ∗ 2 ∗ 3

= 12

2.5 Decentralized Decision-Making Using Ask-Selection

According to the market mechanism that we have out-lined, a BuyerAgent can make multiple Bids. This ishow it searches the space of possible services, for itsstated budget. There might be multiple Asks in themarket that match these multiple Bids. To deal with this,the market mechanism moves on to its second-stage,

where the BuyerAgent has to select amongst the Can-didateServices. Since the mechanism for Bid-generationprecludes Bids that will violate hard constraints, noneof the CandidateServices will violate the application’shard constraints either. The task facing the BuyerAgent,is to choose amongst the possible transactions, in sucha way that the decision maximizes the possible benefits,while taking care to minimize the possible downsides.We use a multiple criteria decision making approachcalled PROMETHEE [6]The BuyerAgent needs to rank all the CandidateSer-vices, that have been returned by the MarketAgent asa potential transaction. Thus, for a transaction set (TS),the BuyerAgent needs to select one CandidateServicethat it will actually transact with. The preference ofCandidateService a over CandidateService b is calculatedby aggregating the preferences over each QoS attribute(and its weightage). The preference value (π) of a Can-didateService a over CandidateService b is calculated as:

π(a, b) =

n∑

i=1

Pi(a, b)wi (4)

where P is a preference function over a QoS attribute(see example in equations 8, 9 and 10). Using this prefer-ence value, each CandidateService is ranked vis-a-vis theother CandidateServices in the possible transaction set.Ranking is done by calculating the positive outranking(ø+) and the negative outranking (ø−):

ø+(a) =∑

x∈TS

π(a, x) (5)

ø−(a) =∑

x∈TS

π(x, a) (6)

Finally, the net outranking (ø) is created to get acomplete ranking of all the CandidateServices:

ø(a) = ø+(a)− ø−(a) (7)

Choice of the CandidateService is based on the follow-ing heuristic:

1) Based on the net outranking flow, choose the bestCandidateService.

2) If there is a tie, choose the cheaper CandidateSer-vice out of the pool of best CandidateServices

3) If using cost still leads to a tie, choose randomlyamongst pool of best CandidateServices

2.6 A Worked-out Example

Suppose that the MarketAgent returns the 4 Asks (asshown in Table 7), as possible transaction matches.Ranking amongst multiple asks is done on a per-QoS

attribute basis. That is, each ask is ranked on each QoSattribute.This effectively means that CandidateServices will be

evaluated on their QoS attributes as follows:

1) In case of a boolean attribute, a CandidateServiceA will be preferred over CandidateService B, if

7

Category Value

Types of QoS attributes Boolean, Categoric and NumericConstraint on each attribute Hard, SoftDirection on each attribute Maximize, Minimize, N.A.Bid Price Numeric

TABLE 4: Elements in a Bid

Name Type Median Target Direction

SSL Support Boolean No Yes/No N.A.FrameRate Categoric 24fps 24fps, 32fps MaximizeLatency Numeric 99ms 95ms MinimizeBudget Hard Constraint (From Market) 100 N.A.

TABLE 5: QoS preferences for a BuyerAgent

Attribute Value

Bid-Price 80SSL YesFramerate 24fpsLatency 99

Attribute Value

Bid-Price 80SSL NoFramerate 32fpsLatency 99

TABLE 6: Sample Bids

Attribute Value

Ask-Price 74SSL YesFramerate 24fpsLatency 99

(a) CandidateService A

Attribute Value


(b) CandidateService B

Attribute Value

Ask-Price 80SSL NoFramerate 24fpsLatency 90

(c) CandidateService C

Attribute Value


(d) CandidateService D

TABLE 7: Asks returned by MarketAgent as potential transactions

it has a desired boolean value. Else, there is nopreference.

2) In case of a categoric attribute, a CandidateServiceA will be preferred over CandidateService B, ifthe categoric value of A is better by k over thecategoric value of B. Else, there is no preference.The value of k is adjusted based on whether theattribute is a hard constraint or a soft constraint.For hard constraints, k is taken to be zero, i.e., theCandidateService with the better categoric value isstrictly preferred over the other.

3) In case of a numeric attribute, a CandidateServiceA will be increasingly preferred over Candidate-Service B, as the difference between their numericvalue approaches some m. After m, A is strictlypreferred. Again, the value of m is adjusted basedon whether the attribute is a hard constraint or asoft constraint.

The preference functions for the three QoS attributescan be given as follows:

Pssl(x) =

{

0 if x = (ssl = no),

1 if x = (ssl = yes)(8)

Pframerate(x) =

{

1

32x if x < 32fps,

1 if x ≥ 32fps(9)

Platency(x) =

0 if x > 103ms,1

2if 103 > x > 95ms,

1 if x ≤ 95

(10)

Based on the preference functions given (in 8, 9 and10), we can calculate the relative values of the 4 Candi-dateServices, as given Table 9 Once we have a relative

TABLE 8: Values of π(xi, xj)

A B C D

A — 0 + 0 + (-0.5) 1 + 0 + (-0.5) 0 + (-0.25) + (-0.5)B 0 + 0 + 0.5 — 1 + 0 + 0 0 + (-0.25) + 0C (-1) + 0 + 0.5 (-1) + 0 + 0 — (-1) + (-0.25) + 0D 0 + 0.25 + 0.5 0 + 0.25 + 0 1 + 0.25 + 0 —

8

per-attribute value, we can calculate the outranking val-ues based on equations 5, 6 and 7 (see Table 9).

A B C D

ø+ 0.5 1.5 0 2.25

ø− 1.25 0.25 2.75 0

ø -0.75 1.25 -2.75 2.25

TABLE 9: Calculation of outranking values

It is clear from Table 9, that CandidateService D is thebest amongst the potential transactions, and Candidate-Service C is the worst. The BuyerAgent now accepts thetransaction with CandidateService D, and rejects all theothers.

2.7 Post-Transaction

The BuyerAgent reports back to the ApplicationAgent,the cost and QoS being made available for thetransaction. The ApplicationAgent then performs aSWR calculation to ensure that the QoS of the servicebeing bought, does not violate any of the application’send-to-end constraints. Note that the ApplicationAgentneeds to calculate SWR for the numeric constraintsonly. The other types of constraints (boolean andcategoric) are specified in the bid prepared by theBuyerAgent, and therefore do not need checking. Thisgreatly reduces the computational effort required on thepart of the Application agent. The best case scenario,from a computational perspective, is when all theQoS attributes of the Application are either booleanor categoric. However, in the worst case scenario, allthe QoS attributes could be numeric. In this case, ithas to perform an SWR calculation for each of theQoS attributes and the distribution of computation toBuyerAgents is minimal.

In Figure 2, we show the various steps in the CDA asactivities carried out by the principal agents.

2.8 Re-starting Conditions

Once an application reaches a satisfactory level of QoS,all its agents will withdraw from the market. The agentswill re-enter the market, only in case of an adaptationstimuli. There are two kinds of adaptation stimuli:

1) External Stimuli: When a QoS violation is detectedat any of the CandidateService, the ApplicationA-gent informs the BuyerAgent that it needs to re-start its search for a new CandidateService. Thisevent is not propagated to all the BuyerAgent,but only to the particular one responsible for thatAbstractService.

2) Internal Stimuli: When the application’s end-to-end QoS target or available budget changes, theApplicationAgent informs all of its BuyerAgents,and restarts the adaptation. The agents stay in the

Fig. 2: Activity diagram for principal agents

adaptation phase, until the stopping criteria aremet.

Both these stimuli occur at different time scales. Theexternal check for QoS violation is a continuous checkand concerns itself with performance of the web-serviceacross relatively shorter periods of time. The internalstimulus, on the other hand, typically happens whenbudgets for operation change drastically or externalevents cause change in performance or reliability re-quirements. This happens at relatively rarer intervals.Hence, typically once an application reaches close to itsdesired level of QoS, the BuyerAgents stop trading.

2.9 Design and Implementation

We call our implementation of the proposed mechanism,clobmas (Cloud-based Multi-Agent System). We docu-ment clobmas using the object-oriented paradigm for allof the internal components of an agent. Thus, we showthe static structure of the system through package, com-ponent and class diagrams. We show agent-interactionusing Agent-UML (AUML). We envision our mechanismas a middleware, between service-based applicationsand multiple SaaS clouds. In Figure 3, we show clobmasas a middleware between two OpenStack-based cloudsand SOA-based applications. Note that OpenStack1 iscurrently an IaaS cloud solution. We envision the ad-dition of a UDDI-based Service Registry communicatingwith the Cloud Controller, to enable OpenStack to serveservices as well.

2.9.1 Architectural StyleThe design of clobmas is based on the publish-subscribearchitectural style. This style was chosen for its de-

1. www.openstack.org

9

SOA-basedApplication A

SOA-basedApplication B

OpenStack Layer

Market-basedMiddleware Layer

Application Layer

ComputeController

NetworkController

VolumeController

SchedulerController

CloudController

ServiceRegistry

ComputeController

NetworkController

VolumeController

SchedulerController

CloudController

ServiceRegistry

BuyerAgent BuyerAgent BuyerAgent BuyerAgent

SellerAgent SellerAgent SellerAgent SellerAgent

MarketAgent MarketAgent

Event-based communication

<<Agent>> <<Agent>> <<Agent>> <<Agent>>

<<Agent>> <<Agent>>

<<Agent>> <<Agent>> <<Agent>> <<Agent>>

<<Agent>> Trading Agent

Service-basedApplication

Subsystemsinside OpenStack

Advanced MessageQueueProtocol

Method Call

Fig. 3: Clobmas as middleware between SOA-based applications and two OpenStack-based clouds

coupling properties, such that each communicating en-tity in the system is independent of every other. Thisfits in well, with our notion of agents acting on thebasis of their own goals and their environment, in adecentralized manner. Each type of agent is both anevent publisher and an event subscriber. That is, eachApplicationAgent generates events that describe whenthe application’s QoS constraints have changed, whenthe budget has changed, etc. These events are subscribedto, by BuyerAgents belonging to that application. TheBuyerAgents, for their part, publish events relating to themarket that they are registered with. Similarly, the Mar-ketAgents publish events relating to the start of trading,transaction events, etc. The event-based paradigm fitswell with the QoS monitoring schemes, as well. BothZeng [55] and Michlmayer [37] use events to monitorand communicate SLA violations.

2.9.2 Class and Package DiagramThe class diagram shows the static relationships betweenthe main entities in clobmas. The Bid and Ask interfacesshown in Figure 4 are implemented by the BuyerA-gent and SellerAgent respectively, with the MarketAgentimplementing both of them. The packages with thestereotype “subsystems”, marked as Nova and Glance,belong to OpenStack.

2.9.3 Activity Diagram

The most difficult part of getting all the agents in anMAS to solve a problem, is the problem of communi-cation. The design of the communication protocol de-termines how much communication happens, at whattimes and how much computational effort it takes tocommunicate. If the agents communicate too little, thenthere is a danger of the MAS failing to solve the problemit was created for. On the other hand, if too muchcommunication takes place, then a lot of wastage occurs,not only in terms of bandwidth but also in computa-tional cycles and time. Thus, while communication is afundamental activity in an MAS, depicting this in UMLis difficult. We document the communication steps of ourmechanism through Agent-UML (AUML) diagrams.In the following figures, we show the communication foran application with two AbstractServices, A and B, andits corresponding BuyerAgents and the MarketAgent.The Setup Phase (Figure 5) is composed of two calcula-tions done by the ApplicationAgent and, two multicastmessages to the application’s BuyerAgents. The twocalculations involve decomposing the application’s end-to-end constraints into local constraints and, computingthe budget that each BuyerAgent will receive.

More figures showing the various scenarios of com-

10

Application

{leaf}

AgentStrategy

+calc_next_bid()

«implementation class»

ZIP

Buyer

«refines»


Buyer

ConcreteService

«refines»

«signal»

Constraints_Changed_Event«uses»

«signal»

TransactionEvent

+calc_next_bid()


ZIP

Seller

«refines»


Market

ConcreteService

«refines»

«uses»

Seller

ConcreteService

«refines»

«uses»

«uses»

Register

Bid

«uses»

Ask

«uses»

«uses»

«uses»

«subsystem»

MetricComputationEngine

«signal»

FailureEvent

«metaclass»

AbstractService

«uses»

«subsystem»

Nova-api

«uses»

«uses»

1 *

«subsystem»

Queue

«subsystem»

Nova-compute

«signal»

Accept

«uses»

«uses»

«uses»

«subsystem»

Glance-api

«subsystem»

Glance-registry

«uses»

«uses»

«subsystem»

Nova-network

«subsystem»

Nova-volume

«uses»«uses»

Fig. 4: Class and package diagram of clobmas and OpenStack subsystems

11

Buyer_A Market_A Application Market_B Buyer_B

local_constraints local_constraints

local_endowment local_endowment

Setup Phase

refDecompose_Constraints

refCompute_Endowment

Fig. 5: Setup phase for an application with two AbstractServices A & B

munication between the agents are shown in AppendixA.

2.10 Monitoring

Monitoring the actual QoS exhibited during runtime bythe CandidateService, is beyond the scope of the system.We assume that all the agents agree on the monitor-ing of a CandidateService, by a third-party mechanism.This could be market-specific or domain specific. Themonitoring of QoS cannot be done by our mechanism,since it needs to be neutral, and trusted by both parties:BuyerAgent and SellerAgent. The BuyerAgent needs toknow whether the SellerAgent’s service is providing theQoS that it promised, and the SellerAgent needs to knowthat the BuyerAgent’s application is not abusing theservice.

3 EVALUATION

3.1 The Current Scenario

The current form of service-selection is provider-driven.That is, in all commercial clouds, the cloud provider usesa posted-offer mechanism. A posted-offer is a form ofmarket where the supplier posts a certain price on a take-it-or-leave-it basis. Thus, on Amazon’s elastic cloud com-pute (EC2), there are several services that are functionallyidentical, but priced differently. This price differentiationexists due to different QoS being exhibited by theseservices. In Table 10, we show a slice of Amazon’spricing for its On-Demand Instances. Depending on thetype of job envisioned, customers purchase a basket ofcomputational power from Amazon. However, currently,there is no mechanism to automatically switch from onekind of On-Demand Instance to another. Customers haveto forecast the type of demand for their application inadvance, and appropriately chose their package fromAmazon. Any application that desires to use a partic-ular service, has to pay the posted price. There existsno mechanism to negotiate/bargain with Amazon, onpricing or QoS of the services being offered. This has thevery obvious effect of customers either over-provisioningor under-provisioning for their actual demand. If an

Association Rule Mining

Clustering

Data Filtering VisualizationJob Submission Cross-Validation

Fig. 6: BizInt’s workflow constructed using compositeservices from the hosting cloud

application under-provisions, then it risks losing cus-tomers due to lack of QoS. On the other hand, if it over-provisions, it loses money due to lack of productive use.In both cases, the customer faces a loss.

3.2 Empirical Study

BizInt, a small (fictional) startup company creates anew business intelligence mining and visualization ap-plication. It combines off-the-shelf clustering algorithmswith its proprietary outlier detection and visualizationalgorithms, to present a unique view of a company’scustomer and competitor ecosystem. In order to exhibit ahigh level of performance, it decides to host its applica-tion in the cloud. Also, instead of reinventing the wheel,it uses third-party services (for clustering, etc.) that arealso hosted in the same cloud. As seen in figure 6, BizIntuses composite web services (Data Filtering, Clustering,Association Rule Mining and Cross-Validation) from thecloud, along with its own services (Job Submission,Outlier Detection and Visualization) to create a com-plete application. Soon BizInt discovers that differentjobs emphasize different QoS. Some jobs want data tobe processed as fast as possible, others require a highamount of security and reliability. In order to exhibitdifferent QoS, BizInt needs to dynamically change itsconstituent services.SkyCompute is a new (fictional) entrant to the field ofCloud Computing. It wants to compete with Amazon,3Tera, Google, Microsoft and other established cloud-providers. In order to attract cost and QoS-consciouscustomers, SkyCompute will have to differentiate itscloud from the others. It plans to target the Software-As-A-Service market. Instead of providing specialist infras-tructural services (like Amazon) or application frame-

12

Linux/UNIX usage Windows usageStandard On-Demand Instances

Small (default) $0.085 per hour $0.12 per hourLarge $0.34 per hour $0.48 per hourExtra Large $0.68 per hour $0.96 per hour

Micro On-Demand InstancesMicro $0.02 per hour $0.03 per hourHi-Memory On-Demand Instances

Extra Large $0.50 per hour $0.62 per hourDouble Extra Large $1.00 per hour $1.24 per hourQuadruple Extra Large $2.00 per hour $2.48 per hour

TABLE 10: On-Demand Instance Pricing on Amazon EC2

work services (like Google and Microsoft),it is plan-ning to provide generically useful services like indexing,clustering, sorting, etc. Like most cloud providers, itplans to provide services with different QoS levels, sothat multiple types of clients can be attracted to use it.To differentiate itself, SkyCompute plans to provide anadaptive framework, so that companies like BizInt canchange their constituent services, dynamically.

3.3 Qualitative Criteria

Thus, clobmas must fulfill the following criteria:

1) Allows customers like BizInt to create adaptiveapplications

2) Generates a higher utilization of services than theposted-offer model currently followed (for Sky-Compute)

3.4 Quantitative Criteria

Since, SkyCompute is an ultra-large collection of ser-vices, clobmas must be able to scale to large num-bers of applications and ConcreteServices. Since thereis no public data about the kinds of workflows hostedon commercial clouds, and their corresponding servicechoices, we made assumptions about the variables in-volved in dynamic service composition. We make theseassumptions based on conversations with performanceconsultants at Capacitas Inc., and numbers gleaned fromthe literature review.We summarize the operational ranges that clobmas is

expected to deal with, in Table 11

Variable affecting performance From Lit. Review Target Goals

Number of AbstractServices 10 20Number of CandidateServices 20 50Number of QoS attributes 3 10Number of markets 1 10

TABLE 11: Operational range for scalability goals

3.5 Experimental Setup

Although open-source cloud implementations likeOpenStack2, and Eucalyptus3 are freely available

2. www.openstack.org3. http://www.eucalyptus.com/

for download, they are primarily targetted at theInfrastructure-As-A-Service market. Modifying these im-plementations for our purposes (to introduce the notionof markets, respond to transaction events, etc.), wouldbe expensive in terms of time. In the same vein, us-ing simulators such as CloudSim would require majormodifications, to those toolkits. CloudSim is a fairly newtoolkit, and does not have the ability to explore marketmechanisms in a sophisticated manner [7].Software: In this scenario, we wrote our own simulatorin Python (v. 2.6.5), using a discrete-event simulationlibrary, SimPy4. The operating system in use, was 64-bit Scientific Linux.Hardware: All experiments were run on an Intel Dual-cpu Quad-Core 1.5Ghz workstation, with 4MB of level-1cache and 2GB of RAM.Generating Randomness: We use Monte Carlo samplingto draw QoS values for each of the services in the marketand for the QoS values demanded by the applications. Acritical factor in ensuring the goodness of sampling usedfor simulations, is the goodness of the pseudo-randomnumber generator (PRNG). We use the Mersenne Twister,that is known to be a generator of very high-qualitypseudo-random numbers [36]. We use this generator dueto the fact it was designed with Monte Carlo and otherstatistical simulations in mind. 5

Reporting: All results are reported as an average of a100 simulation runs. Each simulation reported, unlessotherwise specified, was run with the following pa-rameters given in Table 12. In the section on scalability(subsection 3.8), we stress the mechanism by scaling upvariables to the target goals given in Table 11.

System Parameter Value

AbstractServices in Workflow 10CandidateServices per AbstractService 20QoS attributes 3Number of markets per CandidateService 1Tolerance Level (for numeric QoS) 0.1Applications simultaneously adapting 300

TABLE 12: System parameters and their standard values

4. http://simpy.sourceforge.net/5. For a k-bit word length, the Mersenne Twister generates an almost

uniform distribution in the range [0, 2k− 1]

13

3.6 Methodology

We simulate 300 applications, each application consistingof randomly generated workflows trying to achievetheir desired QoS levels, within a given budget. Thebudget that each application gets, acts as a constraintand the application’s constituent BuyerAgents can neverbid above their budgets. Each application generatesa random level of QoS that it must achieve. Once anapplication achieves its required QoS, it withdraws fromtrading until an internal or external stimulus occurs. Wemodel the probability of a QoS service violation basedon a study by Cloud Harmony [1].

3.7 Results

There are two perspectives from which to evaluate ourmechanism, BizInt’s and SkyCompute’s perspective.We present both perspectives, with an emphasis onSkyCompute’s view since it provides a better idea onthe scalability of our mechanism 6

3.7.1 BizInt’s Perspective

From BizInt’s perspective, a cloud provider that enabledapplications to self-adapt at the QoS level would beideal. BizInt understands that a typical adaptation pro-cess does not guarantee an optimal result. But, evenso, a self-adaptive mechanism would be a step-up fromthe current mechanism of manually selecting the serviceto be used. It evaluates the efficacy of the adaptivemechanism by two measures:

1) How close to the desired QoS level does the adap-tive mechanism reach?

2) How long does it take for an application to achieveits desired QoS?

Close to desired QoS: Like most research on dynamicservice composition, we evaluate the goodness of aparticular set of services, by means of a utility function.We use the application’s targetted end-to-end QoS as thebenchmark, against which the currently achieved QoSis measured. The application’s target QoS is normalizedand summed across all the QoS that it is interested in.This is taken to be the ideal utility level. The achieved QoSis fed through the same process, to attain the achievedutility level. Calculation of utility is done by summingup the value(s) of QoS. Hence, if w denotes the weightfor a particular QoS, K be the set of QoS, and V (x) bethe value function, then:

Utility =

K∑

k=1

wk ∗ V (k) (11)

whereωk ∈ R

10

6. Code for the simulation available at:http://www.cs.bham.ac.uk/∼vxn851/multiple-DA-sim.tar.bz2

The difference between the ideal utility level and achievedutility level is called the quality gap. Each applicationdefines a tolerance level, that specifies the magnitudeof quality gap that is acceptable. If the quality gapis within the tolerance level, the application is saidto be satisfied. We measure over a trading period, thenumber of rounds that the application is satisfied.

Time to Satisfaction: In the absence of a deterministicsolution (and therefore a deterministic notion of time),we must contend ourselves with evaluating whether theadaptive algorithm is ‘fast-enough’. The natural unit oftime in clobmas, is a trading round. We measure howmany trading rounds, application takes to be satisfied,from the start of an adaptation event. An adaptationevent occurs when an application notices that the qualitygap is beyond the tolerance level. Thus, the start ofthe simulation defines an adaptation event, since allapplications start off without any achieved utility level.In Figure 7, we see an average application’s achieve-

ment of QoS levels. The application starts off with aquality gap of minus 3. But it quickly adapts to theQoS demanded and reaches the tolerance zone, in about20 trading rounds. From this point on, the applicationstays satisfied. The application is satisfied for 280 outof 300 trading rounds. We see that the achieved utilitylevel does not stay constant. Instead, internal adapta-tion events cause the application to seek out differentservices. However, it stays within the tolerance zone.In Figure 7, we show the adaptation occurring underconditions of normal distribution of QoS demand andsupply in the cloud.

Fig. 7: Utility gained by adaptation by a single applica-tion

To compare the goodness of trading in a CDA market,we contrast its use in a posted-offer market.Posted Offer: This type of mechanism refers to a situ-ation where a seller posts an offer of a certain good ata certain price, but does not negotiate on either. That is,

http://www.cs.bham.ac.uk/~vxn851/multiple-DA-sim.tar.bz2

14

the buyer is free to take-it-or-leave-it. In such a scenario,the probability that an application will find services, atthe bid-price decreases.

0 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300Trading rounds

10

9

8

7

6

5

4

3

2

1

0

1

2

3

4

5

6

7

8

9

Ach

ievem

ent

of

requir

ed Q

oS

Ideal level of QoS

Tolerance Zone

Fig. 8: Utility gained by a single application in a postedoffer market

In Figure 8, we see that the application is able toadapt and acquire the QoS that it requires. It is obviousfrom the two figures, the application is able to reachthe tolerance zone a lot quicker in Figure 7, than inFigure 8. In fact, in the posted offer market, we see thatthe application takes 140 rounds to reach the tolerancezone, while in the CDA market, the application is able toreach its tolerance zone in under 20 rounds of trading.This difference can be attributed to the fact that sincethe sellers in a posted-offer market do not change theirprice, the buying agents have to search a lot longer tofind sellers that they are able to trade with. In a CDA,the search process is much faster, since both the buyersand the sellers adjust their Bids and Asks.

CDA PostedOffer

Number of rounds satisfied 282 160Time to reach QoS 18 140

TABLE 13: Comparative performance of adaptation inCDA vis-a-vis Posted Offer

3.7.2 SkyCompute’s PerspectiveSkyCompute would like to ensure that any mechanismthat it offers for self-adaptation results in high utilizationof its services. We define market satisfaction rate asa measure of the efficiency of the mechanism. Marketsatisfaction rate is the percentage of applications thatare satisfied with their QoS achievement. A satisfiedapplication would withdraw from trading and use theservice for a relatively long period of time. The morethe number of applications that are satisfied, the morethe number of services from SkyCompute that are beingutilized. Thus, market satisfaction rate is a measure that

SkyCompute would like to maximize.As a baseline, we first implement the Zero-Intelligencemechanism, as this represents the lower limit of the effec-tiveness of the CDA mechanism. The Zero-Intelligencescheme consists of agents randomly making bids andasks, with no history or learning or feedback(see figure9). As expected, it performs quite poorly, with a marketsatisfaction rate of about 10-20%. Clobmas, on the otherhand, achieves a much higher rate of market satisfac-tion(see Figure 10).

0 20 40 60 80 100 120 140 160 180 200 220 240 260 280Trading rounds

0

10

20

30

40

50

60

70

80

90

100

Perc

enta

ge o

f applic

ati

ons

succ

ess

fully

adapte

dusi

ng Z

ero

-Inte

lligence

Aggregate view of all applications

Fig. 9: Efficiency of adaptation in a CDA market withZero Intelligence

On the other hand, we see (in figure 10) that withadaptive bids, the number of applications that are ableto adapt rise to about 85% of the total market. This isa huge improvement with a very small improvement inthe intelligence of the agents.

Fig. 10: Efficiency of adaptation in a CDA market

Quite similar to the CDA, the posted-offer also per-forms well (approx 70% market satisfaction rate). In thiscase, the sellers never adjust their prices, but the buyersdo.

15

0 20 40 60 80 100 120 140 160 180 200 220 240 260 280 300Trading rounds

0

10

20

30

40

50

60

70

80

90

100Perc

enta

ge o

f applic

ati

ons

succ

ess

fully

adapte

dAggregate view of all applications

Fig. 11: Efficiency of adaptation in a Posted Offer market

3.8 Scalability Requirements for SkyCompute

There are no commonly accepted/standard definitionsof scalability, in self-adaptive, multi-agent systems. Toalleviate this, we use a definition of scalability from[20]: a quality of software systems characterized by the causalimpact that scaling aspects of the system environment anddesign have on certain measured system qualities as theseaspects are varied over expected operational ranges.According to this definition, when aspects of the en-vironment change, they have an impact on the systemqualities. In our case, the system quality that we wantto measure is performance, measured as the amount oftime taken to reach a defined level of market satisfactionrate. Although clobmas using a double-auction is betterthan clobmas using a posted offer, SkyCompute wouldlike to know if this mechanism scales well. To investigatethis, we pick a level of market satisfaction rate, thatis higher than posted-offer, and measure how long ittakes to achieve this level. The adaptation process canbe highly dependent on many variables. In this section,we tease out how each of these variables affect the timetaken for adaptation. To this end, we present the timetaken by the CDA market to achieve an 80% marketsatisfaction rate, while varying each of these variables.AbstractServices Vs. CandidateServices: Arguably,

these are the variables that change most often fromapplication to application. Every application has a dif-ferent workflow and therefore, a different number ofAbstractServices. As time passes, applications that havemet their QoS will retire from the market, and new ap-plications will come in. This changes the orderbook fromthe demand side. Also, the number of CandidateServicesis most susceptible to change. As time passes, someCandidateServices will no longer be available, and newones come into the market. This changes the orderbookfrom the supply side.We perform curve-fitting to analyze the growth of

10 15 20 25 30 35 40 45 500

50

100

150

200

250

300

350

400

CandidateServicesper AbstractService

Tim

e to

ada

pt(in

sec

onds

)

1 AbstractService3 AbstractServices5 AbstractServices10 AbstractServices

Fig. 12: CandidateServices increase

1 2 3 4 5 6 7 8 9 100

50

100

150

200

250

300

350

400

AbstractServices in Workflow

Tim

e to

ada

pt(in

sec

onds

)

10 CandidateServices per AbstractService30 CandidateServices per AbstractService50 CandidateServices per AbstractService

Fig. 13: AbstractServices increase in Workflow

the graphs. In the worst case, the polynomial growthof Time-to-MSR(y) when AbstractServices(x) increase, isgiven by

y = −0.0361x3 + 4.7619x2 − 5.4985x + 3.8978 (12)

Again, in the worst case, the polynomial growth ofTime-to-MSR (y) when CandidateServices (x) increase,is given by

y = 0.0012x3 − 0.0611x2 + 8.2678x− 16.6664 (13)

From Equation 12 and Equation 13, we see that Clob-mas is more sensitive to the number of CandidateSer-vices than to the number of AbstractServices (see Figures

10

20

30

40

50

0

2

4

6

8

100

50

100

150

200

250

300

350

400

CandidateServicesper AbstractService

AbstractServicesper Workflow

Tim

e ta

ken

to a

dapt

(in s

econ

ds)

Fig. 14: Both AbstractServices and CandidateServicesincrease

16

12, 13 and 14). Although, both equations are cubic innature, the cubic term in Equation 12 is negative. Thisindicates that it grows slower than Equation 13. Thismakes intuitive sense, since the increase in AbstractSer-vices merely increases the number of BuyerAgents.

CandidateServices Vs. QoS attributes: In the follow-ing figures (Figure 15 and 16), we see that increasingCandidateServices and QoS attributes, affect the time-to-MSR in slightly different ways. There is a difference inthe slope of the lines, when QoS attributes are increased(Figure 17).

1 2 3 4 5 6 7 8 9 100

10

20

30

40

50

60

Tim

e ta

ken

to a

chie

ve Q

oS(in

sec

s)

5 CandidateServices10 CandidateServices15 CandidateServices20 CandidateServices

Fig. 15: QoS increase

0 2 4 6 8 10 12 14 16 18 200

10

20

30

40

50

60

CandidateServices per AbstractService

Tim

e ta

ken

to a

chie

ve a

dapt

atio

n(in

sec

s)

1 QoS per AbstractService3 QoS per AbstractService5 QoS per AbstractService7 QoS per AbstractService9 QoS per AbstractService


We see from Figure 17 that the slope of QoS axisis greater than that of CandidateServices. That is, timetaken for adaptation increases faster when QoS attributesincrease, as compared to the number of CandidateSer-vices.

In the worst case, the polynomial describing thegrowth of Time-to-MSR (y) as QoS attributes (x) increase,is given by

y = 0.0303x4 − 0.7769x3 + 6.4554x2 − 14.4945x + 25.7250(14)

Whereas, the polynomial describing the growth ofTime-to-MSR (y) as CandidateServices (x) increase, isgiven by

y = 0.0030x2 + 2.3721x + 2.4722 (15)

Equations 14 and 15 indicate that it is preferable toincrease CandidateServices, than QoS attributes.

0 2 4 6 8 10 12 14 16 18

0

2

4

6

8

10

0

10

20

30

40

50

60

Number of Candidate Services per Abstract Service

QoS per Abstract Service

Tim

e (in

sec

)fo

r ad

apta

tion

Fig. 17: Both CandidateServices and QoS increase

3.8.1 The Cost of Decentralization

As discussed in [21], an auction-based mechanism, bydefault, leads to a centralized mechanism. The auction-eer becomes a single point of failure, and thus leads todecreased robustness. This can be remedied by introduc-ing multiple auctioneers. In clobmas, we use multiplemarkets for each AbstractService. This ensures that evenif one market is non-functional, the others continue tofunction. Decentralization of markets comes at a cost.BuyerAgents have to choose which market to place theirbids, to place them in multiple markets or a singlemarket. Placing bids in multiple markets increases thechances of getting Candidate Services, but it also placesa greater computational load on the BuyerAgent interms of decision making. We currently choose marketsrandomly.CandidateServices Vs. Number of Markets: Does de-centralization affect time taken for adaptation or numberof CandidateServices? In other words, should clobmasincrease the number of CandidateServices available permarket? Or would it be better to increase the number ofmarkets?

1 2 3 4 5 6 7 8 9 100

10

20

30

40

50

60

70

80

90

Markets per CandidateService

Tim

e ta

ken

to a

chie

ve Q

oS(in

sec

s)

1 CandidateService per AbstractService

3 CandidateServices per AbstractService




Fig. 18: Markets increase

The polynomial describing the growth of Time-to-MSR(y), as number of Markets increase (x), is given by

y = 8.3745x + 0.0800 (16)

17

1 2 3 4 5 6 7 8 9 100

10

20

30

40

50

60

70

80

90

CandidateServices per AbstractService

Tim

e ta

ken

to a

chie

ve Q

oS(in

sec

s)

1 market per CandidateService3 markets per CandidateService5 markets per CandidateService7 markets per CandidateService10 markets per CandidateService


02

46

810

02

46

810

0

20

40

60

80

100

Number of ConcreteServices per AbstractService

Number of Markets per AbstractService

Fig. 20: Both Candidate Services and Markets increase

The polynomial describing the growth of Time-to-MSR(y), as number of CandidateServices increase (x), is givenby

y = 7.5972x + 6.8222 (17)

We see from Equation 16 and Equation 17 thatthe slopes of both lines are linear. That is, increasingthe number of CandidateServices vis-a-vis increasingthe number of markets does not make a significantdifference to the time-to-adapt.

QoS attributes Vs. Number of Markets:Next we lookat how QoS attributes affect the time-to-adapt vis-a-visthe number of markets.

1 2 3 4 5 650

100

150

200

250

300

350

400

450

500

550

Number of QoS

Tim

e ta

ken

for

Ada

ptat

ion

(in s

ecs)

1 Market4 Markets7 Markets9 Markets

Fig. 21: QoS increase

In the worst case, the polynomial describing thegrowth of Time-to-MSR (y) as number of Markets (x)

1 2 3 4 5 6 7 8 950

100

150

200

250

300

350

400

450

500

550

Number of Marketsper CandidateService

Tim

e ta

ken

for

Ada

ptat

ion

(in s

ecs)

2 QoS4 QoS6 QoS

Fig. 22: Markets increase

12

34

56

78

1

2

3

4

5

60

100

200

300

400

500

600

Number of QoSper CandidateService

Number of Marketsper CandidateService

Tim

e ta

ken

for

Ada

ptat

ion

(in s

ecs)

Fig. 23: Both QoS attributes and markets increase

increase, is given by

y = −0.4595x2 + 65.0048x + 26.6683 (18)

In the worst case, the polynomial describing thegrowth of Time-to-MSR (y) as QoS attributes (x) increase,is given by

y = −0.1103x4+2.3380x3−14.9209x2+42.0606x+465.6389(19)

The increase in QoS attributes causes Time-to-MSRincrease in a biquadratic way, as opposed to increase innumber of Markets (Equation 18 and Equation 19).

3.9 Discussion

3.9.1 StrengthsA big strength of our mechanism is the high scalabilitythat it offers. As service-oriented applications matureand cloud offerings become more standardized, it is easyto envision applications being composed out of severalthird-party services. In such a scenario, a mechanismthat scales up to accommodate many concrete servicesis essential. None of the variables increased the time-to-MSR in an exponential manner. Rather, all of them arelow-order polynomials.Since the decision-making over which concrete serviceto instantiate is done in a de-centralized manner, theindividual agents are simple and easy to implement.Our mechanism implements a continuous adaptationscheme, thus leaving the system administrator free toattend to more critical tasks.

18

3.9.2 Weaknesses

The introduction of decentralization in the adaptivityprocess, while increasing robustness, also brings an in-creased cost in terms of time, and communication. Thereare two steps which are particularly affected. These are:

1) Decomposition of Constraints: Depending on thetype of QoS constraints, the time taken to decom-pose them, changes. If the constraints are booleanor categoric, then the time complexity for k con-straints in an application with n AbstractServices,is O(n· k). However, if the constraints are numeric,then the time increases substantially. Since eachmarket is queried for its historical data of trans-actions. The complexity of decomposition now be-comes O((n· k·m) + (k·SWR)), where m is thenumber of markets and SWR is the complexityof applying Stochastic Workflow Reduction on theapplication structure [12].

2) Calculation of achieved utility: To calculate thetotal achieved utility, all the BuyerAgents commu-nicate the QoS of the CandidateService that theyselected, to the ApplicationAgent. The Application-Agent applies SWR to the numeric QoS attributes,to check if all constraints are met. This costs O(n)in time, whereas the application of SWR dependson the structure of the application itself [12].

As the number of BuyerAgents for an application in-crease, or the number of markets increase (more likely),the time complexity of decomposition will increase.

3.9.3 Threats to Validity

Lack of Optimality: The market mechanism does notachieve optimum, either from the individual perspectiveor from the aggregate perspective. Since the self-adaptivemechanism merely attempts to satisfy the application’sQoS targets, it does not try to achieve optimal set of con-crete services, even if available. Rather, it stops adaptingas soon as all QoS constraints are met.Lack of Trust: In any market-oriented mechanism,

there is the issue of trust between the buyer of a serviceand the seller of a service. How does the seller reliablyensure that the buyer does not make more calls to theweb-service, than the number agreed upon? How is theprovenance of calls established? How does the buyerensure that the seller provides the QoS, that it haspromised in the SLA? What legal/technical recoursedoes it have, in case of violation of contract? Theseare all issues that are still open research problems.Ramchurn et al [42] provide a good overview of theseproblems in the specific case of multi-agent systems.However, a good amount of research needs to bedone, before all issues are acceptably resolved to thesatisfaction of both, buyer and seller.

Simulation Effects: Any simulation model is a con-strained version of reality, and as such, results fromsimulations should always be taken with a pinch of salt.

Given this caveat, simulations help us carry out con-trolled experiments that would be too cumbersome orexpensive to carry out in reality. Simulation toolkits are avaluable mechanism for testing out new, and sufficientlydifferent ideas. CloudSim [8] is a toolkit that aims tomake simulations of clouds easier to perform, and in theideal case, we would have liked to implement our ideason it. However, at its current level, it is insufficient tocapture market mechanisms and multiple types of QoSattributes. In future, we aim to port our market-modelto CloudSim, so as to enable richer modelling.

4 RELATED WORK

4.1 Dynamic Composition of Web-services

There has been a plethora of work on dynamic compo-sition of web-services. Much early work has been donein AgFlow [54] on Quality-Aware composition of web-services [5] and [53]. The authors propose a per-service-class optimisation as well as a global optimisation usinginteger programming.[10] proposed a genetic algorithm based approach wherethe genome length is determined by the number ofabstract services that require a choice to be made. Con-straints on QoS form a part of the fitness function, as docost and other QoS attributes. A big advantage of GA-based approach is that it is able to handle non-linearconstraints, as opposed to integer programming. Also,it is scalable when the number of concrete services perabstract service increase.[2] propose an interesting mechanism for cutting throughthe search space of candidate web-services, by using sky-line queries. Skyline queries identify non-dominated web-services on at least one QoS criteria. A non-dominatedweb-service means, a web-service that has at least oneQoS dimension in which it is strictly better than anyother web-service and at least equal on all other QoSdimensions. Determining skyline services for a particularabstract service, requires pairwise comparisons amongstthe QoS vectors of all the concrete services. This processcan be expensive if the number of candidate concreteservices is large. Alrifai et al. consider the case wherethe process of selecting skyline services is done offline.This would lead to an inability to adjust to changingconditions of available services and their associated QoSvalues. [56] propose an interesting method to achievea good set of concrete services, using Ant Colony Op-timization (ACO). ACO involves creating virtual antsthat mimic the foraging behaviour of real ants. Thesearch space of optimal concrete services is modelled asa graph, with sets of concrete services as vertices andedges being all the possible connections between differ-ent concrete service sets. The ants attempt to complete atraversal of the graph, dropping pheromones on the edgeof each concrete service visited. The path through thegraph that accumulates the most pheromones representsthe near-optimal path of services to use. Our approachdiffers from the above approaches in two respects:

19

1) Consideration of time as a factor: In practice,the optimal set of concrete services may not beavailable at the time instant that an applicationis searching. The set of service providers changeswith time, as does the set of service consumers.This means that the optimal matching of serviceproviders to consumers changes with time. Theapproaches above do not take this into account.

2) Optimality not considered: Due to the infeasibilityof computing the optimal set (being NP-hard), weconcentrate on finding a good solution, rather thanan optimal one. A good solution is one that doesnot violate any QoS constraints and meets the costconstraint within a certain margin.

4.2 Self-Adaptation

Applications that use dynamic service compositionshould be able to continuously monitor their current QoSlevels and make adjustments when either the demandfor QoS changes or the cost constraint changes. Theapplication should thus be able to respond to bothinternal as well as external stimuli, to trigger a changein its constituent web-services. This change needs tobe both timely, as well as correct, i.e., the new set ofservices should not violate any of the application’s QoSconstraints, and the change should happen as fast aspossible.Self-Adaptation in software systems is the achievementof a stable, desirable configuration, in the presence ofvarying stimuli. These stimuli may be environmental (inthe form of workload, failure of external components,etc.) or internal (failure of internal components, changedtarget states, etc.). Given that the range of stimuli thataffect a software system is wide, Self-Adaptation hascome to mean an umbrella term that covers multipleaspects of how a system reacts [44]:

1) Self-Awareness2) Context-Awareness3) Self-Configuring4) Self-Optimizing5) Self-Healing6) Self-Protecting

However, most approaches to self-adaptation follow acommon pattern: Monitor – Analyze – Plan – Execute,connected by a feedback loop. There are two approachesto self-adaptation: centralized and de-centralized. Ina centralized self-adaptive system, the analysis andplanning part are concentrated in one entity. This formof self-adaptation has the advantage of cohesivenessand low communication overhead as compared to adecentralized mechanism. The analysis and the plan canbe communicated to the effectors, and feedback fromobeying the plan is communicated back through themonitors (or sensors). Rainbow [14] and The AutonomicManager [28] are classic examples of centralized self-adaptation.Decentralized self-adaptation, on the other hand,

distributes the analysis, planning or the feedbackmechanism amongst different parts of the adaptingsystem. This automatically implies a communicationoverhead, since all constituent parts must coordinatetheir actions. However, it also provides for robustnessin the presence of node failure and scalability ofapplication size. Cheng et al [13] have advocatedthat the feedback loop, which is a critical part of theadaptation, be elevated to a first-class entity in termsof modelling, design and implementation. Although,this would allow for reasoning about properties ofthe adaptation, there are no systems that we currentlyknow of, that provide an explicit focus on the feedbackloop. Most decentralized self-adaptation systems aretypically realised as a multi-agent systems whereinthe agents are autonomous in their environments andimplement strategies that collectively move the entiresystem into a desirable state. [15] have advocatedseparating the functional part of the system from theadaptive part, thus allowing for independent evolutionof both. Baresi et al [4] describe such a system, whereadaptation is considered as a cross-cutting concern, andnot a fundamental part of system computation. Baresiet al. use aspect-oriented programming to implementthe Monitor and Execute part of the MAPE loop.They implement distributed analysis and planning bydividing the self-adaptive system into supervised elements,that perform the business logic of the application andsupervisors that oversee how the supervised componentsbehave and plan for adaptation. Aspect-probes form thesensors and actuators that link the supervised elementsto the supervisors.[18] describe another interesting approach todecentralized self-adaptation, through self-organization.DiMarzo et al. take a bio-inspired approach and useprinciples of holons (and holarchy) and stigmergy toget agents in a manufacturing department to performcoordination and control. A holon is defined by [33]to be both a part and a whole. Therefore, an agentis both autonomous as well as a part of a hierarchy,which influences it. The essential idea in their work isthat with such structures, order emerges from disorder,as simple interactions build on each other, to produceprogressively complex behaviour.Weyns et al [50] study a decentralized self-healingsystem and a QoS-driven self-optimized deploymentframework. Their approach is the nearest to ours.They suggest multiple decentralized models whichfeed into decentralized algorithms, which are in turnanalyzed by decentralized analyzers. These analyzersthen individually direct local effectors to make changesto the host system.These approaches, while interesting, have not explicitlyconsidered scale of adaptation. Any approach thatattempts self-adaptation on the cloud, must concernitself with scaling up to hundreds and possibly eventhousands of entities. Another issue that needs to beconsidered, is the effect of other self-adapting systems

20

operating in the same environment.

4.3 QoS Monitoring

Zeng [55], and Michlmayer [37] are good examples ofonline QoS monitoring. Zeng et al. classify QoS met-rics into three categories: (a) Provider-advertised (b)Consumer-rated, and (c) Observable metrics. They pro-vide an event-driven, rule-based model where designerscan define QoS metrics and their computation logic (interms of Event-Condition-Action rules), for observablemetrics. These are then compiled into executable state-charts, which provide execution efficiency in computingQoS metrics based on service-events that are observed.Michlmayer et al. provide their QoS monitoring as aservice runtime environment. This service runtime envi-ronment addresses service metadata, QoS-aware ser-vice selection, mediation of services and complex eventprocessing. The authors propose two mechanisms tomonitor QoS: (a) a client-side approach using statisticalsampling, and (b) a server-side approach using probesthat are present on the same host as the service. Theclient-side approach is non-intrusive, in terms of notneeding access to the service’s host.Both approaches, Zeng and Michlmayer, use an event-based mechanism to detect QoS values, and SLA vio-lations, if any. This fits in neatly with our need for anon-intrusive, third-party based QoS Monitoring Engine.Our mechanism is agnostic to the actual QoS monitoringmechanism, that is used.

5 CONCLUSION AND FUTURE WORK

Cloud-based service-oriented applications have thepotential to self-adapt their QoS, depending ondemand. Using a market-based mechanism maps nicelyto the real-world situation of unpredictable change ofQoS requirements, costs involved in adaptation andadaptation by competing applications. As the numberof possible concrete services increase, the scalability ofthe self-adaptive mechanism becomes important. Wesee that the market-based mechanism consists of simpleagents, is able to adapt well and yet scales linearlyto the number of concrete services. We also see thatit is robust in the presence of differences in demandand supply of QoS. Applications implemented as anASN can thus scale and adapt to the changing businessrequirements of QoS.We have not modelled complex seller-side behaviour.Specifically, actions like deliberate violation of QoS tofree up resources for making Asks with higher pricesor mis-reporting of QoS available. Mechanisms likepenalties and reputation management can be used toprevent seller agents from behaving dishonestly. Also,we have not modelled adaptation on the part of themarket. Sellers that lie about their QoS or, are generallyunattractive for transactions may lower the reputationof the marketplace. Hence, the market could take

steps to ensure that it is populated, only with sellersthat are likely to be sold. In future work, we aim tosystematically add these modifications to observe theireffect on the collective adaptation.

REFERENCES

[1] Do slas really matter? 1-year case study.[2] Mohammad Alrifai, Dimitrios Skoutas, and Thomas Risse. Se-

lecting skyline services for QoS-based web service composition.Proceedings of the 19th international conference on World wide web -WWW ’10, page 11, 2010.

[3] Danilo Ardagna and Barbara Pernici. Global and local qosconstraints guarantee in web service selection. pages 805–806,2005.

[4] Luciano Baresi, Sam Guinea, and Giordano Tamburrelli. Towardsdecentralized self-adaptive component-based systems. Proceedingsof the 2008 international workshop on Software engineering for adaptiveand self-managing systems - SEAMS ’08, page 57, 2008.

[5] B. Benatallah, M. Dumas, Q.Z. Sheng, and a.H.H. Ngu. Declara-tive composition and peer-to-peer provisioning of dynamic Webservices. Proceedings 18th International Conference on Data Engineer-ing, pages 297–308, 2002.

[6] J.P. Brans and Ph. Vincke. A preference ranking organisationmethod: The promethee method for multiple criteria decision-making. Management Science, 31(6):647–656, June 1985.

[7] Ivan Breskovic, Christian Haas, Simon Caton, and Ivona Brandic.Towards self-awareness in cloud markets: A monitoring method-ology. pages 81 –88, dec. 2011.

[8] R Buyya and S Pandey. Cloudbus toolkit for market-orientedcloud computing. In Proceedings First International Conference,CloudCom 2009, pages 22–44, 2009.

[9] Rajkumar Buyya, Chee Shin Yeo, and Srikumar Venugopal.Market-Oriented Cloud Computing: Vision, Hype, and Realityfor Delivering IT Services as Computing Utilities. 2008 10thIEEE International Conference on High Performance Computing andCommunications, pages 5–13, September 2008.

[10] Gerardo Canfora, Massimiliano Di Penta, Raffaele Esposito, andMaria Luisa Villani. An approach for QoS-aware service composi-tion based on genetic algorithms. Proceedings of the 2005 conferenceon Genetic and evolutionary computation - GECCO ’05, page 1069,2005.

[11] Jorge Cardoso, Amit Sheth, and John Miller. Workflow quality ofservice. Technical report, University of Georgia, Athens, Georgia,USA, March 2002.

[12] Jorge Cardoso, Amit Sheth, John Miller, Jonathan Arnold, andKrys Kochut. Quality of service for workflows and web serviceprocesses. Web Semantics: Science, Services and Agents on the WorldWide Web, 1(3):281–308, April 2004.

[13] B Cheng, R De Lemos, Holger Giese, and Paola Inverardi. Soft-ware engineering for self-adaptive systems: A research roadmap.Software Engineering, pages 1–26, 2009.

[14] Shang-Wen Cheng, David Garlan, and Bradley Schmerl.Architecture-based self-adaptation in the presence of multipleobjectives. Proceedings of the 2006 international workshop on Self-adaptation and self-managing systems - SEAMS ’06, page 2, 2006.

[15] SW Cheng and David Garlan. Making self-adaptation an engi-neering reality. Self-star Properties in Complex Information Systems:Conceptual and Practical Foundations, 3460:158–173, 2005.

[16] Scott H. Clearwater, Rick Costanza, Mike Dixon, and BrianSchroeder. Saving energy using market-based control. pages 253–273, 1996.

[17] D Cliff. Simple bargaining agents for decentralized market-basedcontrol. HP Laboratories Technical Report, 1998.

[18] Giovanna Di Marzo Serugendo, Marie-Pierre Gleizes, and An-thony Karageorgos. Self-organization in multi-agent systems. TheKnowledge Engineering Review, 20(02):165–189, June 2005.

[19] Elisabetta DiNitto, Carlo Ghezzi, Andreas Metzger, Mike Papa-zoglou, and Klaus Pohl. A journey to highly dynamic, self-adaptive service-based applications. Automated Software Engineer-ing, 15(3-4):313–341, September 2008.

21

[20] Leticia Duboc, David Rosenblum, and Tony Wicks. A frameworkfor characterization and analysis of software system scalability.Proceedings of the the 6th joint meeting of the European softwareengineering conference and the ACM SIGSOFT symposium on Thefoundations of software engineering - ESEC-FSE ’07, page 375, 2007.

[21] Torsten Eymann, Michael Reinicke, Oscar Ardaiz, Pau Arti-gas, Luis Dı́az de Cerio, Felix Freitag, Roc Messeguer, LeandroNavarro, Dolors Royo, and Kana Sanjeevan. Decentralized vs.centralized economic coordination of resource allocation in grids.In European Across Grids Conference, volume 2970 of Lecture Notesin Computer Science, pages 9–16. Springer, 2003.

[22] Daniel Freidman. The double auction market institution: Asurvey. 1993.

[23] Dhananjay K. Gode and Shyam Sunder. Allocative efficiency ofmarkets with zero-intelligence traders: Market as a partial sub-stitute for individual rationality. The Journal of Political Economy,101(1):119–137, 1993.

[24] Alok Gupta and DO Stahl. The economics of network manage-ment. Communications of the ACM, 42(9):57–63, 1999.

[25] Kieran Harty and David Cheriton. A market approach to operat-ing system memory allocation. pages 126–155, 1996.

[26] Minghua He and Nicholas R. Jennings. Southamptontac: Anadaptive autonomous trading agent. ACM Trans. Internet Technol.,3:218–235, August 2003.

[27] Minghua He, N.R. Jennings, and Ho-Fung Leung. On agent-mediated electronic commerce. Knowledge and Data Engineering,IEEE Transactions on, 15(4):985 – 1003, july-aug. 2003.

[28] IBM. An architectural blueprint for autonomic computing. June2006.

[29] Amazon Inc. Amazon spot-instances. December 2009.http://aws.amazon.com/ec2/spot-instances/.

[30] Nick Jennings. Automated haggling: building artificial negotia-tors. pages 1–1, 2000.

[31] Jeffrey O. Kephart and David M. Chess. The vision of autonomiccomputing. Computer, 36(1):41–50, January 2003.

[32] Paul Klemperer. Auction theory: A guide to the literature.JOURNAL OF ECONOMIC SURVEYS, 13(3), 1999.

[33] Arthur Koestler. The ghost in the machine. 1989. ISBN 0-14-019192-5.

[34] MM Kokar and K Baclawski. Control theory-based foundationsof self-controlling software. Self-Adaptive Software and their Appli-cations, IEEE Intelligent Systems, 1999.

[35] Robert Laddaga. Creating robust software through self-adaptation. IEEE Intelligent Systems, 14:26–29, May 1999.

[36] Makoto Matsumoto and Takuji Nishimura. Mersenne twister: a623-dimensionally equidistributed uniform pseudo-random num-ber generator. ACM Trans. Model. Comput. Simul., 8:3–30, January1998.

[37] Anton Michlmayr, Florian Rosenberg, Philipp Leitner, andSchahram Dustdar. Comprehensive qos monitoring of web ser-vices and event-based sla violation detection. pages 1–6, 2009.

[38] Vivek Nallur and Rami Bahsoon. Design of a Market-BasedMechanism for Quality Attribute Tradeoff of Services in the Cloud. In Proceedings of the 25th Symposium of Applied Computing(ACMSAC). ACM, 2010.

[39] Jinzhong Niu, Kai Cai, Simon Parsons, Enrico Gerding, and PeterMcBurney. Characterizing effective auction mechanisms: insightsfrom the 2007 tac market design competition. pages 1079–1086,2008.

[40] Jinzhong Niu, Kai Cai, Simon Parsons, Peter McBurney, andEnrico Gerding. What the 2007 tac market design game tellsus about effective auction mechanisms. Autonomous Agents andMulti-Agent Systems, 21:172–203, 2010. 10.1007/s10458-009-9110-0.

[41] P. Oreizy, N. Medvidovic, and R.N. Taylor. Architecture-basedruntime software evolution. Proceedings of the 20th InternationalConference on Software Engineering, pages 177–186, 1998.

[42] Sarvapali D Ramchurn, Dong Huynh, and Nicholas R Jennings.Trust in multi-agent systems. The Knowledge Engineering Review,19(01):1–25, 2005.

[43] a Roth and I Erev. Learning in extensive-form games: Experimen-tal data and simple dynamic models in the intermediate term.Games and Economic Behavior, 8(1):164–212, 1995.

[44] Mazeiar Salehie and Ladan Tahvildari. Self-adaptive software.ACM Transactions on Autonomous and Adaptive Systems, 4(2):1–42,May 2009.

[45] Michael Stonebraker, Robert Devine, Marcel Kornacker, WitoldLitwin, Avi Pfeffer, Adam Sah, and Carl Staelin. An economicparadigm for query processing and data migration in mariposa.pages 58–67, 1994.

[46] Perukrishnen Vytelingum. The Structure and Behaviour of theContinuous Double Auction. PhD thesis, 2006.

[47] C.A. Waldspurger, T. Hogg, B.A. Huberman, J.O. Kephart, andW.S. Stornetta. Spawn: a distributed computational economy.Software Engineering, IEEE Transactions on, 18(2):103–117, feb. 1992.

[48] Carl A. Waldspurger and William E. Weihl. Lottery scheduling:flexible proportional-share resource management. page 1, 1994.

[49] Michael P. Wellman. A market-oriented programming environ-ment and its application to distributed multicommodity flowproblems. J. Artif. Int. Res., 1(1):1–23, 1993.

[50] Danny Weyns, Sam Malek, and J. Andersson. On decentralizedself-adaptation: lessons from the trenches and challenges for thefuture. In Proceedings of the 2010 ICSE Workshop on SoftwareEngineering for Adaptive and Self-Managing Systems, pages 84–93.ACM, 2010.

[51] P Wurman. A Parametrization of the Auction Design Space.Games and Economic Behavior, 35(1-2):304–338, April 2001.

[52] L. Servi Y. C. Ho and R. Suri. A class of center-free resourceallocation algorithms. Large Scale Systems, 1:51, 1980.

[53] Liangzhao Zeng, Boualem Benatallah, Marlon Dumas, JayantKalagnanam, and Quan Z. Sheng. Quality driven web servicescomposition. Proceedings of the twelfth international conference onWorld Wide Web - WWW ’03, page 411, 2003.

[54] Liangzhao Zeng, Boualem Benatallah, Phuong Nguyen, and AnneH. H. Ngu. Agflow: Agent-based cross-enterprise workflowmanagement system. pages 697–698, 2001.

[55] Liangzhao Zeng, Hui Lei, and Henry Chang. Monitoring the qosfor web services. pages 132–144, 2007.

[56] Wei Zhang, Carl K. Chang, Taiming Feng, and Hsin-yi Jiang.QoS-Based Dynamic Web Service Composition with Ant ColonyOptimization. 2010 IEEE 34th Annual Computer Software andApplications Conference, pages 493–502, July 2010.

Vivek Nallur Dr. Vivek Nallur is a postdoc at the University of Birming-ham. Prior to doing research, he used to work with VMware Inc. Hisresearch interests are complex systems, decentralized self-adaptation,ultra-large scale systems, and communication and decision-making inmulti-agent systems.

Rami Bahsoon Dr. Rami Bahsoon is a Lecturer in Software Engineeringat the School of Computer Science, the University of Birmingham,United Kingdom. He did his PhD from University College London (UCL),on evaluating software architectures for stability using real optionstheory. His research interests include Cloud Architectures, SecuritySoftware Engineering, Relating software requirements (non-functionalrequirements) to software architectures, testing and regression testing,software maintenance and evolution, software metrics, empirical evalu-ation, and economics-driven software engineering research.

22

APPENDIX

Decomposing Constraints: Decomposing constraints(Figure 24) involves communication between the Buy-erAgents, their respective markets and the Application-Agent. The ApplicationAgent waits for the BuyerAgentsto get data about previous transactions in the market,applies SWR [11] and checks whether the combinationof QoS available in the market meets its end-to-end con-straints. Based on the combinations that meet the end-to-end constraints, the ApplicationAgent creates localconstraints for the individual BuyerAgents. These arethen propagated to the BuyerAgents.Computing Endowments: The budget for the indi-

vidual agents is split in the ratio of the transactionprices that are prevalent in the individual markets (seeFigure 25). Given historical price information in a mar-ket, the prices in the next trading rounds are likely tobe around the same figure. Splitting the application’sbudget evenly across the BuyerAgents could possiblyresult in some agents getting excess endowment, andsome agents too less. The ratio of their transactionprices allows the agents with expensive services to get anaturally higher share of the budget.Trading Phase: In Figure 26, we show the communi-

cation that takes place during the trading phase. Thisphase is essentially a loop. It periodically evaluates thebids and asks in the orderbook, and tries to match them.If it is successful, the transaction moves into the secondstage (see Figure 27). Based on whether a trade occursor not, the application evaluates whether it needs to re-distribute the endowments of its agents. It is possiblethat an agent is unable to find any potential transactions,simply because it does not have the budget to bid highenough.CDA Protocol: The trading proceeds in two stages.

In the first stage, the MarketAgent matches the bidsand asks based on their individual QoS values andshout prices. After matching, a provisional transactionis created. This provisional transaction enters the secondstage. In the second stage, the BuyerAgent compares allthe Asks returned as provisional transactions. The top-ranked Ask is selected and the other Asks are rejected.The BuyerAgent enters into a transaction with the Sell-erAgent of the selected Ask.

23


get_last_k_transaction_data get_last_k_transaction_data

get_last_data

get_last_data get_last_data

last_data last_data

last_k_transaction_data last_k_transaction_data

Loop

Possible_Infeasibility

alt

Decompose_Constraints

[All_Combinations_Checked]

refApply_SWR_to_Combination

refSave_Valid_Combination

[Valid_Combinations_Exist?]

refCreate_local_constraints

[else]

Fig. 24: Application decomposes its constraints into local constraints


get_k_last_transaction_prices

get_k_last_transaction_prices

par

get_last_prices get_last_prices

last_prices last_prices

last_transaction_prices

last_transaction_prices

par

Compute Endowment

refSplit_Budget_In_Corresponding_Ratio

Fig. 25: Application computes endowment for its BuyerAgents

24

Application Buyer Market

Get_Last_Transaction_Price

Last_Transaction_Price

Reg_Bids

Transaction_Details

Accept_Transaction?

Accept_Transaction

Delete_Other_Bids

Transaction_Details

Cancel_Transaction

alt

Failed_to_Transact

Last_Transaction_Price

New_Budget

alt

Revise_Bid

alt

alt

Loop

Trading_Phase

refsub Market: Match_Bid_Ask

[Provisional_Transaction_Possible]

refsub Buyer:Ask_Selection

[Yes]

refsub Application:Redistribute_Budget?

[Surplus_Available?]

refsub Application:Raise_Error

refsub Buyer:Revise_Bid

Fig. 26: The trading phase of buying a service

25

Seller Market Buyer Application

Mkt_OpenMkt_Open

Reg_BidReg_Ask

Provisional_TransactionProvisional_Transaction

Trust_Seller?

Yes

Cancel_Transaction

Delete_Bid

No

Accept_Transaction

New_TransactionNew_Transaction

Delete_Bid

Exit_Mkt

Delete_Ask

alt

timeout! timeout!

alt

Loop

2-Stage CDA

Stage-1

refsub Match_Bid_Ask

[All_Constraints_Met]

Stage-2

[else]

Fig. 27: Two-stage CDA protocol

A decentralized self adaptation mechanism for service based applications in the cloud

Education

Transcript of A decentralized self adaptation mechanism for service based applications in the cloud