Mandi: A Market Exchange for Trading UtilityComputing Services

Saurabh Kumar Garg, Christian Vecchiola, Rajkumar Buyya

Cloud Computing and Distributed Systems LaboratoryDepartment of Computer Science and Software Engineering

The University of Melbourne, Australia{sgarg}@csse.unimelb.edu.au

Abstract—The recent development in Cloud computing hasenabled the realization of delivering computing as utility. Anumber of companies have started building Cloud and Gridcomputing environments, and offering access to the resourcesas a “Pay as you go” basis. This has created a need for a marketexchange (ME) that brings providers and consumers togetherand facilitates their trading. Such market environment eases theprocess of finding, comparing and buying, since they aggregategoods and services from a variety of sources and display them in away which is helpful to customers. In this paper we propose a MEframework called “Mandi” that allows consumers and providersto trade computing resources according to their requirements. Wefirst present the ME requirements that motivated our design anddiscuss how these facilitate trading of compute resources usingmultiple market models. Finally, we evaluate the performance ofthe first prototype of “Mandi” in terms of its scalability.

I. INTRODUCTION

Utility computing paradigms such as Clouds and Gridspromise to deliver highly scalable and cost effective infras-tructure for running High Performance Computing (HPC)applications [1]. As a result, the scientific and industrial com-munities [2] have started using cheaper commercially availableinfrastructures to run their applications which can scale upbased on demand, rather than maintaining their own expensiveHPC infrastructure. For such communities, it would be usefulto have access to a ME where the resource availability isaggregated from various commercial providers. The presenceof a Market Exchange (ME) infrastructure can easily fulfilltheir demand for compute resources, that can also resolve otherproblems such as high cost of ownership and the infrequentuse of HPC infrastructures.

ME represents a significant advancement in the state-of-the-art of utility computing, where just one large provider ofresources is dominant (e.g. Amazon [3]) [4]. It can bridgedisparate Clouds and Grids allowing consumers to chooseproviders that suit their requirements. Due to the competitionbetween different providers in the exchange, the price will alsobe lowered down for compute resources, making it even moreaffordable to enterprises with a low budget.

To realize this vision, ME needs to support diverse ser-vices [4] including an infrastructure that allows (a) registration,buying and selling; (b) advertisement of free resources; (c)

coexistence of multiple market models or negotiation protocolssuch as auction; and (d) Grid resource brokers to discoverresources/services and their attributes (e.g., access price andusage constraints) that meet user QoS requirements. On theconsumer side, projects such as Gridbus broker [5] and Grid-Way [6] provide the capability of negotiation with providers,and job submission and monitoring on the heterogeneousresources. On the provider side, technologies such as virtual-ization and market based resource management systems suchas Tycoon [7] and Mirage [8], has enabled trading of computeresources. Thus, the necessary middleware for enabling utilitymarkets from the resource provider and consumer sides arealready present to make ME a viable step.

Current efforts in this direction by projects such as Bella-gio [9], CatNet [10] and Ocean [11] are designed for specificmarket models and specific application models. But Grid iswell known to have heterogeneous resources and applications.Moreover, each participant has its own objectives and require-ments. Since each market model or negotiation protocol has itsown advantages and disadvantages, one market model fits forall problems can be impractical [12]. In other words, in orderto really achieve different objectives, the ME should supportmultiple and concurrent market models to provide flexibilityfor consumers and resource providers to choose market modelsor negotiation protocols according to their requirements.

In this paper, we propose the design and evaluation forsuch a ME called Mandi1 that is the first step towardsproviding a generic marketplace to isolated resource providersand consumers, fulfilling their trading requirements. We aimto develop a light weight and platform independent serviceoriented market architecture which can be accessed easily bycurrent Grid systems. Mandi supports automated buying andselling of compute services such as CPU time and storage.Mandi has been implemented using Web Service technologiesas part of the Cloudbus Project, which is developing solutionsfor service-oriented utility computing that scale from central-ized systems to Clouds.

In the next section, we will discuss in detail the needof marketplaces for advancement of market-based grid and

1Mandi is a colloquial term for marketplace in Indian languages

cloud computing. Then, in Section 3, we discuss related workand compare them with Mandi. In Section 4, we discussrequirements of a market exchange. Then in the subsequentsections, we describe the design and implementation of Mandiwith evaluation results and conclusions.

II. RELATED WORK

Many projects focussed on building a marketplace for Gridand Cloud infrastructures. Among them, the most promi-nent, which are related to our work, are GridEcon [13],SORMA [14], Ocean Exchange [11], Tycoon [7], Bellagio [9],and CatNet [10].

Many existing systems (such as Bellagio [9] and Tycoon [7])have restrictive pricing and negotiation policies. Auctions areheld at fixed intervals, and only one type of auction is allowed(e.g. First Price, Second Price [15]). More generic marketarchitectures such as CatNet, Ocean Exchange, GridEcon andSORMA also currently support only one or two market modelssuch as bilateral negotiation and combinatorial auctions. InSORMA, automated bidding is provided to participate in anauction or to bargain with a resource provider that may leadto increased delays for consumers who urgently need theresources. GridEcon project started with a vision to researchinto a viable business model for trading services in an openmarket. The current implementation of GridEchon only sup-port commodity market model. Ocean Exchange currentlysupports commodity market model, while CatNet supports theonly bargaining and contract/net models. SORMA project’sOpen Grid Market has similar architecture as proposed byCatNet [16]. Thus, in the most of the previous work, thechoice of market model is decided by market itself. On theother hand, in Mandi, we leave the choice of negotiationand pricing protocols to the consumers and providers in thesystem. This is crucial as the choice of the market model(such as the auction and commodity model) and pricing (fixed,variable) can vary from participant to participant dependingon their utility gained. Thus Mandi acts as neutral entityor middleman giving the flexibility to participant to use anymarket model or negotiation protocol for trading their serviceand allowing concurrent and multiple negotiations betweenmarket participants.

Moreover, these systems also handles the management ofjob execution after matching it to appropriate resource. While,in Mandi, unlike the other systems, the responsibility of actualjob submissions to resources and monitoring lies with userbrokers and provider’s resource management system.

Thus, our main contribution in this paper is to propose anovel market-exchange architecture and design which reflectsthe real-world markets where different participants interactwith each other using the mechanisms of their choice.

III. MOTIVATION AND MARKET SCENARIO

In past, the need for marketplace and market based mecha-nisms is argued and counter argued by many researchers suchas Nakai and Van Der Wijngaart [17] argued about the insta-bility of markets using the General Equilibrium (GE) theory.

In spite of these arguments, the need for markets in Grid likeinfrastructures where any user can get resources on demand isa reality. Many commercial providers and consumers from var-ious industries including logistics and automobiles companiesexist today [18]. Moreover, it is pointed out by Shneidmanet al. [19] that many computer systems have reached to apoint where the goal is not always to maximise utilisation;instead, when demand exceeds supply and not all needs canbe met, a policy for making resource allocation decisions isrequired. Hence, market based systems and exchanges are thenext step. The benefits are following: a) Coordination betweenconcurrent user demands, and answers a critical question ofresource allocations i.e., who gets which resources and when?,b) Ease the resource discovery by aggregation of differentresource providers and services, c) Increase the efficiencyof system usage by reducing resource wastage and avoidproblems like tragedy of commons, d) Competition amongvarious resource providers leads to reduction in money andtime, e) Automatically balance supply and demand, and f)the market exchange acts as a neutral third party whichcan support resolution of conflicts between consumers andproviders.

The key participant in any market are resource consumers,providers and ME which act as an auctioneer or clearinghouse. The consumers need to execute their applications thatrequire compute resources, while the providers have freecompute resources which can be leased for executing theapplication. The ME on the behalf of consumers or providersdo the matching according their objectives using a negotiationprotocol such as Vickrey auction or double auction [4]. Thereare three trading scenarios exist in market exchange:

• Consumer contacts providers to initiate the trading. TheME in this context can be used to allow consumer todiscover various compute services on sale by differentresource providers. It allows consumers to join an auctionrunning for compute resources conducted by a provider,or directly contact a provider for reserving computeresources as in the commodity market model. It can alsohold auction for consumers if their need is not satisfiedby current advertised services.

• Provider contacts consumers to initiate the trading. Inthe ME, the providers can also find clients for sellingtheir compute resources. Thus, ME allows providers tojoin an auction initiated by consumers. It also facilitatesthe providers to start their own trading protocol such asauction, or advertise their compute resources.

• Consumers and Providers use ME services to coordi-nate the trading and finding the most appropriate match.In this scenario, the ME act as a clearing house runningmarket model such as double auction.

The market scenario where ME acts as a clearing houseis explained in Figure 1. Several users can submit theirapplication requirements to the ME. These requirements canbe in the form of number of compute resources, time atwhich users need these resources, minimum memory require-

ments, and the power of each computing resource. Users canaccess all services of ME through a user interface whichalso manages the authentication and authorization. Similarlyresource providers can advertise their compute services (timeslot: number of compute resources and time for which theyare available) in the ME which will be maintained in resourcecatalogue and in a database for backup.

The Meta-Broker is the main component of ME that coor-dinates the trading between various consumers and providers.The meta-broker periodically holds a double auction. At eachscheduling event, the Meta-Broker collects the time-slots andthe broker (consumer) requests from the Resource Discov-ery and Queuing Service. According to the objective of theconsumers and the providers whether it is cost minimizationor time minimization, matching is performed. After matchingeach broker resource-request to a time-slot, the reservation ofmatched time-slot will be initiated by the Reservation Service.The information about reservations can be collected by userbrokers from the ME.

IV. MARKET REQUIREMENTS

The market framework requirement can be divided into twocategories: infrastructure requirements and the marketplacerequirements.

A. Infrastructural Requirements

1) Scalability: Since, increase in the number of resourcerequests can affect the performance of the ME, thusthe scalability of the exchange can become an issue.The exchange architecture should be designed such thataccess to market services be least effected by the numberof service requests. In addition, it should guarantee thebest efficiency in matching the consumers demand andprovider’s supply.

2) Interface Requirements and Grid Heterogeneity: Theuser interface plays an important role in making theusage of any system easy for a wide variety of users.Depending on how user wants to access the market,different types of interfaces should be provided. InGrids, many market based brokers [6] [5] ease theprocess of accessing the Grid middleware. Similarly,on the resource provider side, heterogeneous resourcebrokers [7] with market based capabilities are available.Thus, these brokers should seamlessly access ME’sservices whenever required by invoking simple platformindependent exchange APIs.

3) Fault Tolerance: As failure is the reality of any system,the ME should be able to resume its services from theclosest point before the failure.

4) Security: To avoid spamming, there should be a securitysystem for user registration. All the services of theexchange must be accessed by authorized users.

B. Marketplace Requirements

1) Variety of Application Models and Compute Ser-vices: The user resource requirement can vary ac-cording to their application model. For example, to

run an MPI application, users may want to lease allthe compute resources from same resource provider,which gives high bandwidth between communicatingprocesses. Thus, users can have different types of com-pute resource demands depending on their applications.Similarly, resource providers can advertise different typeof resources such as storage and virtual machines. Thus,the ME should be generic enough to allow submissionof different types of compute resource requests andservices.

2) Multiple User Objectives: Users may wish to satisfydifferent objectives at the same time. Some possibleobjectives include receiving the results in the minimumpossible time or within a set deadline, reducing theamount of data transfer and duplication, or ensuringminimum expense for an execution or minimum usageof allocated quota of resources. Different tasks within anapplication may be associated with different objectivesand different QoS (Quality of Service) requirements.The exchange should, therefore, ensure that differentmatching strategies meeting different objectives can beemployed whenever required.

3) Resource Discovery: As discussed earlier, users mayhave different resource requirements depending on theirapplication model and Quality of Service needs. Thus,the exchange should be able to aggregate differentcompute resources and should allow users to access anddiscover them on demand.

4) Support for Different Market Models: In Grids, manymarket based mechanisms have been proposed on dif-ferent trading or market models such as auctions andcommodity market [20]. Each mechanism, such as En-glish auction and Vickery auction, has different matchingand pricing strategies and has their own advantages anddisadvantages. Thus, the exchange should be genericenough to support as many market models as possible.

5) Coexistence/Isolation of Market Models: Similar toreal world markets, the ME should support concurrenttrading of compute services by different negotiationprotocols such as auction. For example, double auctionand Vickery auction can coexist simultaneously andusers can participate in each of them.

6) Support for Holding, Joining and Discovery of Auc-tions: Users can have requirements that may not befulfilled by currently available compute resources, andthus, may want to hold their own auctions and invitebids. Moreover, any user can discover these auctionsand join them if necessary.

The following sections present the architecture, design andimplementation of Mandi market exchange that takes intoaccount the challenges mentioned so far, and abstracts theheterogeneity of the environment at all levels from the end-user.

Resource

Discovery Queuing

Service

Ma

rke

t E

xch

an

ge

Global

Information

Service

Grid Exchange User Interface

Gridbus

Broker (B2)Gridbus

Broker (B1)

Pe

rsisten

t da

ta

Send

resource

request

2. Insert request

in database

Sch

ed

ulin

g E

ve

nt M

an

ag

er

3. Check next

Event

Inform Time

For Next

Scheduling Event

Get Current

Available

Resource Get Status of

Resources

Get time slots

with prices

Get request

to matchGet resource

requests

Start

Matching

Reservation

of time slots

1

2

4

3

55 6

6

7

8

Get

Matched

Resource

11

6 Meta-BrokerResourcID

and Job

12

Ma

rke

t E

xch

an

ge

Resource

Provider (R1)Resource

Provider (R2)

Resource

Catalogue

Reservation Service Accounting

Service

da

tab

ase

Advertise

available slots

Insert available slots

by R1..RN

Sch

ed

ulin

g E

ve

nt M

an

ag

er

of time slots

Reservation

of time slots

1

2

910

Update available

Requests and time

slots.

Fig. 1. Grid Exchange Protocol

V. MANDI ARCHITECTURE AND DESIGN

A. Design Considerations and Solutions

The primary aim of Mandi is to provide a marketplacewhere the consumer’s resource requests and the provider’scompute resources can be aggregated, and matched usingdifferent market models. The main challenges and the waythey are approached in Mandi design are as follows:

1) Flexibility in choosing market model and user ob-jectives: As already discussed various market modelsor negotiation protocol can be used by users to tradecompute resources. Each market model has differentrequirements [20]. For example, in the commodity mar-ket model, consumers search the current state of themarket and immediately buy some compute service.This requires synchronous access to that instance ofcompute resource. In the case of auction, there is aclearing time when the winner selection is done. Inaddition, any user can request to hold their own auc-tions, thus a separation of each auction is required.Thus, the components within the Mandi are designedto be modular and cleanly separated on the basis offunctionality. Each of them talks through the persistencedatabase which reduces the synchronization problems. Itis also possible to introduce new auction protocols byextending the one-sided auction and the double sided

auction components. Each auction type is separated by”objective” and the winner selection mechanism. Thereservation of matched services is handled independentof the trading mechanisms that allows flexibility andcoexistence of different market models.

2) Support heterogeneous compute resources and appli-cations: Mandi is designed to be as generic as possibleindependently of user application model and resourceprovider’s middleware. Mandi has a service oriented ar-chitecture which allows platform independent interactionwith Grid middleware.

3) Fault tolerance: Mandi can handle failure at two stages:during trading, and during reservation. The failure dur-ing reservation can occur due to network problems, andover subscription of resources. In the case of networkproblem, the failed resource requests will be consideredin the next scheduling cycle. The reservation failure dueto resource oversubscription is handled by consumersand providers. For the failures during trading, a parallelor bag of task application is not scheduled until alljobs/tasks are matched with a resource. In addition, Thepersistence database protects the Grid Exchange againstfailure during trading. The state of Mandi is periodicallysaved in the database. Thus, Mandi can resume its workfrom where it left.

4) Scalability: Most of the Mandi’s component work in-

dependently and interact through the database. Thisfacilitates the scalable implementation of Mandi as eachcomponent can be distributed across different serversaccessing a shared database. In addition to that, most ofthe threads of Mandi are light weight and short lived.

B. Architecture Details

WRegistration

Advertisement

Service

Service

Discovery

Service

Reservation

Hold

Auction

Join

Auction

Web Service Interface

Authentication

Authorization

Advance

Reservation

Meta Broker

Double

Auction Accounting

One-Sided

Auction Exch

an

ge

Us

er

Inte

rfa

ce

La

ye

rC

ore

La

ye

r

Persistence Database

Service

Catalogue

Lease Request

Catalogue

Auction

Catalogue

Users

Catalogue

Authorization Auction AccountingAuction

Ma

rke

t E

xch

an

ge

Co

re L

aye

rS

tora

ge

La

ye

r

Fig. 2. Mandi Architecture

The architecture proposed in this work is inspired by theconcepts of the ‘Open Market’ where any user can join , selland buy their compute services. Mandi is made of three layersi.e. the user interface, the core layer consisting of the meta-broker service and the reservation service, and the storagelayer. The main functions of these layers is described asfollows:

User Interface layer: Consumers and compute resourceproviders can access the services of the market exchangethrough a Web Service interface. This layer provides thefollowing features:

1) Registration: The users are needed to be registeredbefore they can access the exchange’s services. Theirdetails are stored in the storage layer, and are used forauthentication and authorization.

2) Hold Auction and Join Auction: This allows users tojoin any auction and bid for the items. Hold Auctionallows participants to specify the type and the objectiveof auctions they want to hold. The objective of theauction help Mandi to decide the winner. Users haveto provide details of the auction item (e.g. CPU timeslot).

3) Service Discovery and Service Reservation : allowconsumers to find services of their requirements andreserve them.

4) Advertisement Service: allows resource providers toadvertise their CPU time slots.

Core layer: This layer performs main function of gridexchange. It provides functionalities like user authentications

and authorization when users submit their login details. Itscore components are the meta-broker, the accounting and theadvance reservation system.

1) Meta-broker: It finds out the current one-sided auctionand double auction from the auction catalogue andinitiates the match process. After matching it invokes theadvance reservation service to inform providers aboutthe matching and the reservation of the resources.

2) Advance reservation: It informs the resource providerabout the match, reserves the advertised (matched) ser-vice, and gets the reservation id that is used by consumerto submit his application.

3) Accounting Service: keeps the trading information ofeach user. It also keeps the information about transac-tions failed and successful.

Storage Layer: This layer is the interface between thedatabase and other agents such as the web interface, theadvance reservation and the meta-broker. Its main objectiveis to maintain the state of Mandi. It enables the recovery ofMandi in the case of unexpected failure, and is also useful insynchronizing exchange’s various components.

To understand the interrelationships between the Mandi’scomponents, it is necessary to see how they interact in differentscenarios. The objects in the Mandi can be broadly classifiedinto two categories- entity and workers. This terminology isderived from standard business modelling processes[21]. Enti-ties exist as information containers representing the properties,functions and instantaneous states of the various architecturalelements. The entities are stored in the database and areupdated periodically. Workers represent the functionality of thebroker, that is, they implement the actual logic and manipulatethe entities in order to achieve the application objectives.Therefore, workers can be considered as active objects andthe entities as passive objects. The next section (Section V-C)takes a closer look at the entities and workers within the brokeraccompanied by UML diagrams that illustrate the relationshipsbetween the components.

C. Entities

1) Users: Figure 3 shows the class diagram representationof user details. The Users class is used to store informationabout the participant members (consumers and providers)of Mandi. This information is used for authentication andauthorization. From the point of view of the exchange, anyuser can act as consumer or provider thus there is not specialfield to differentiate this in the Users class.

2) Compute Resource: Figure 3 shows the TimeSlot Classthat is used to represent of compute resources which areavailable as ”commodities”. The ”TimeSlot” indicates the timefor which resource will be available and how many CPUs willbe available. Each ”TimeSlot” is associated with a computeresource that is a representation of a set of CPUs or virtualmachines advertised by the resource provider. The ”TimeSlot”class can be also used for a storage resources where only theattributes related to time will be used. If a resource providerhas conducted an auction for inviting bids for the time-slot,

then the AuctionType and the AuctionID attributes will beused to store information about the auction.

Fig. 3. User, and Timeslot Classes

3) Auction Request: All the information for holding anauction for any commodity advertised by a user is representedusing the AuctionRequest Class. Figure 3 shows the classdiagram of the AuctionRequest. Every auction is identifiedby a unique identifier i.e. auctionID. In economics, generallybids in auctions are considered in the form of monetaryvalue. But in the case of computing service, a bid can bea more generalized form depending on the requirements of anauction holder. For example, a user holds an auction to finda resource provider who can lease the compute resource withminimum delay and within the specified budget. Thus, theuser can invite bids in terms of the start time of the resourcelease. Thus, Mandi provides facilities to define the ”objective”which is used as the criteria for choosing the winner bid.To enable integration of the different auction models withdifferent matching and pricing strategies, the AuctionRequestclass contains the ”auctionType” as an attribute which informsMandi which auction user wants to hold.

4) Application: Application class represents the resourcerequests of the user’s application such as total number of CPUsrequired, QoS requirements, deadline, and budget. The ”dead-line” attribute represents the urgency of the user to get his/herapplication finished. The ”QoS” is an abstract class whichcan be extended to codify special application requirementssuch as bandwidth. Each application can consist of severaljobs that may differ in their resource requirements such asexecution time. To allow users to submit different applicationmodel requirements such as parameter sweep and parallelapplication, in Mandi, each application is associated with the”appType” attribute that will be considered while matching anapplication with a resource. The application object also storesthe information about the auction in which the user (consumer)has opted to participate for leasing resource for its application.

Fig. 4. Application, Job, and Qos Classes

D. Workers

Fig. 5. Main Worker Classes

1) MetaBroker: MetaBroker is the first component inMandi to be started that instantiates other worker componentsof Mandi, and manages the life cycles of other workers suchas Scheduler, and Monitor. The BrokerStorage is the front endto the persistence system and implements interfaces used tointeract with the database. Another function of the MetaBrokeris to periodically get the list of current auction requests fromthe database and start a scheduling thread for clearing eachauction.

2) GridExchange Service: The GridExchange Service is aWeb Service interface which enables users to access variousservices of Mandi. The services that are available to users areregistration, submission of application and time slots, holdingand joining auctions, and discovering services and gettingservice reservations. The GridExchange Service interacts withthe BrokerStorage class to access the persistence database. Theexample sequence of operations for user registration is shownin Figure 6. The UserBroker sends a registration request tothe exchange using the GridExchange web service. It submitsthe preferred login name and password. The GridExchangeservice gets the registered user list from the database andchecks whether the user is registered or not. If the user isnot registered, it sends a reply back to user broker with

Fig. 6. Registration Process

Fig. 7. Scheduling Sequence

”registration success” message.3) Scheduler: For each market model, the Scheduler

matches the user application to the advertised compute re-sources and also decides the price for executing the applica-tion. The Figure 7 shows the basic steps that are performedby the Scheduler. The Scheduler gets the auction object (canbe in the form of a timeslot or an application) from the

persistent database and the list of all the bids submitted for theauction. The Scheduler sets the auction status to ”closed” toprevent any further bid submission to the auction. Dependingon the auction type and objective, the winner bid is chosenand the trading price is calculated. The status of winner bidis changed to “matched” from “unmatched”. The match issaved to database in the form a reservation request which willbe used by the Monitor to inform/reserve resources on thecompute resource. The function of the Monitor is described indetail below.

4) Monitor: The Monitor keeps track of all the reservationrequest in the database, as shown in the Figure 8. TheMonitor periodically requests all the reservation requests fromthe persistent database. It uses Web Services to send SOAPmessages to the resource provider, which informs the providerof the matching of the user application to the advertisedtimeslot (compute service). In the return, the Monitor gets thereservationID from the provider. The reservationID is used bythe consumer to access the compute services offered by theresource provider. It represents the time-slot reserved and isalso the security key for accessing the resource. After gettingthe reservationID, the Monitor will set all the reservationdetails in the user application object stored in the persistentdatabase. The consumers (using brokers) can access the reser-vation information by using the GridExchange service.

Fig. 8. Reservation Process

VI. PROTOTYPE AND PERFORMANCE EVALUATION

In order to evaluate the performance of Mandi and providea proof of concept of its architecture, we implemented aprototype and tested it by using Aneka as a service provider.In this section we will give an overview of the componentscomposing the system used for testing and discuss the perfor-mance evaluation.

A. System Details

1) Mandi: Mandi has been implemented in Java which al-lows in order to be portable over different platforms such as the

Windows and Unix operative systems. From an implementa-tion point of view Mandi is composed of a collection of threadsthat interact by means of a persistence layer represented bythe HSQL database. The system is accessible from externalcomponents through a web service that has been deployed byusing Apache Axis2 on a TOMCAT web server (v. 5.5). Thismakes the interaction with Mandi platform independent. Thecurrent prototype support three type of trading mechanisms:i) First Bid Sealed Auction; ii) Double Auction, and iii)Commodity market.

2) Aneka: On the provider side, Aneka [22] has been usedand extended to support the reservation and advertisementof slots on Mandi. Aneka is a service-oriented middlewarefor building Enterprise Clouds. The core component of anAneka Cloud is the Aneka container that represents theruntime environment of distributed applications on Aneka.The container hosts a collection of services through whichall the tasks are performed: scheduling and execution of jobs,security, accounting, and reservation. In order to support therequirements of Mandi a specific and lightweight implemen-tation of the reservation infrastructure has been integratedinto the system. This infrastructure is composed by a centralreservation service that provides global view of the allocationmap of the Cloud and manages the reservation of executionslots, and a collection of allocation services on each nodehosting execution services that are in charge of keeping trackof the local allocation map and ensures exclusive execution forreserved slots. The reservation service is accessible to externalapplications by means of a specific Web Service that exposesthe common operations for obtaining the advertised executionslots and reserving them.

3) Client Components: The client components are consti-tuted by a simple web service client that generates all theresource requests to Mandi.

Reservation Service

Scheduling Services

Slave Node

Allocation Service

Scheduling Services

Slave Node

Allocation Service

Scheduling Services

MandiMarket Exchange

User

Aneka

Master Node

Slave Node

Allocation Service

Scheduling Services

Slave Node

Allocation Service

Scheduling Services

Slave Node

Allocation Service

Scheduling Services

Web Service

Reservation Client

(Dynamically Downloaded)

User

User

Fig. 9. The Topology of Testbed

B. Performance Evaluation

We evaluated the performance of Mandi in terms of over-head caused to the system due to the interaction betweenthe internal components and Mandi’s interaction with usersrequests and provider’s middleware. As discussed previously,Mandi is designed to handle multiple market models con-currently and exposes a service oriented interface to handleusers requests and reservations of resources. Thus, to evaluatethe scalability of Mandi, the first set of experiments examinesthe CPU and memory requirements of our implementation ofMandi. However, the performance of Mandi is also determinedby how quickly and how many simultaneous user requests canbe handled. Hence, the second set of experiments evaluatestime incurred in resource request submission (which is ini-tiated from client machine) and resource reservation (whichinvolve negotiation of Mandi with providers).

The experimental setup for this evaluation is characterizedas follows:

• An instance of Mandi has been deployed on 2.4 GHZIntel Core Duo CPU and 2 GB of main memory runningthe Windows operative system and Java 1.5. The HSQLDatabase was configured to run on the same machine.The performance of Mandi evaluated using JProfiler [23]profiling tool.

• The Aneka setup was characterized by one master nodeand 5 slave nodes. The reservation infrastructure wasconfigured as follows: the master node hosted the reser-vation service while each of the slave nodes contained aninstance of the allocation service. Each container has beendeployed on a DELL OPTIPLEX GX270 Intel Core 2CPU 6600 @2.40GHz, with 2 GB of RAM and MicrosoftWindows XP Professional Version 2002 (Service Pack 3).As a result the reservation infrastructure can features tenconcurrent execution lines (one per core). The topologyof resources is given in Figure 9.

1) Memory Usage and CPU Load: The main threads run-ning in Mandi are: i) MetaBroker, which initiates other threadsand controls the overall execution of Mandi, ii) MonitoringThread, and iii) Scheduler Threads, which dynamically varybased on the number of auctions. Thus, the performanceof Mandi is highly dependent on the number of auctionsconducted concurrently. Thus, to evaluate the performanceof Mandi, we varied the number of auctions from 10 to10,000 that are conducted over period of 5 seconds. Forthis experiment, we generated 50,000 resource requests formatching. Each resource request is mapped to an auctionusing uniform distribution. Figure 10 shows the graphs ofthe memory and CPU usage by the broker over a period of5 Second run. In Figure 10(b), the variation in CPU usageis about 10% with increase in number of auctions. This isbecause scheduler threads conducting auctions are short livedand has comparable CPU need. The little higher value of CPUusage in the case when 10 auctions are conducted is due tothe large number of resource request per auction (50,000/10)needed to be matched.

60

50

40H

ea

p S

ize

(M

B)

30

He

ap

Siz

e (

MB

)

20He

ap

Siz

e (

MB

)

20He

ap

Siz

e (

MB

)

10

0

10 100 1000 10000

Number of Auctions

(a) Memory Required by Mandi VS Auction Conducted

60%

50%

40%

CP

U L

oa

d

30%

CP

U L

oa

d

20%

CP

U L

oa

d

10%

20%

10%

0%

10 100 1000 10000

Number of AuctionsNumber of Auctions

(b) CPU Usage by Mandi vs Auction Conducted

Fig. 10. Performance of Mandi for 50,000 clearance requests

In figure 10(a), we can see how memory usage of Mandiis increasing with the number of auctions. For instance, thememory usage increases from 32 MB to 56 MB when thenumber of auctions increases from 1000 to 10000. Therefore,there is only a 2 times increase in memory usage for 10times increase in the number of auctions. This is due tothe fact that the auction thread loads resource requests fromdatabase only when a decision for the auction winner needsto be taken. In addition, the memory is freed for all resourcerequests participating in the auction as soon as auction finishedexecuting. This reduces the memory occupied by resourcerequest objects waiting to be matched.

2) Overhead in Interaction with Resource Provider andConsumer: Two experiments were performed; one for mea-suring the resource request submission time and the other forreservation time and free slot advertisement by the providermiddleware. All interactions between different entities i.eMandi, consumer, and provider middleware is using webservice. To measure these parameters, we used JMeter toolthat generate SOAP messages to test the performance of webservices. We generated SOAP messages until no more connec-tion can initiated with the web service located at Mandi andresource provider’s site. In case of interaction with Mandi’sweb service, about 750 concurrent resource submission re-quests were generated, while in case of interaction with Anekareservation web service about 100 concurrent requests weregenerated. Table I shows the time taken to serve a request byweb service in milliseconds. Overhead in terms of time forresource request submission is only 11.75 ms. The time takenby Aneka web service to serve free resource and reservationrequests is much longer because each reservation request cantrigger the interaction between the reservation service on themaster node and the allocation service on the slave nodewhere the reservation is allocated. This interaction implies thecommunication between two different containers and variessensibly according to the network topology.

C. Discussion

The performance results indicate good scalability of currentprototype of Mandi which is able to clear about 50,000resource requests and 10,000 auctions in about 5 seconds. Themajor bottleneck in the scalability of Mandi’s architecture isthe shared database. The database constraints the number ofmultiple and concurrent accesses which is also the reason thatexperiments over 50,000 resource requests are not conducted.In addition to that the database can be cause of single pointfailure of whole system. The distributed databases which usereplication and load balancing techniques can be helpful inincreasing the scalability of the system.

TABLE IOVERHEAD DUE TO INTERACTIONS OF MANDI

Web Service Request Service Time/request (ms)Resource Request Submission 11.75Getting Free Resources 30Resource Reservation 240

VII. CONCLUSION

The presence of IT demand and supply in utility orientedClouds and Grids led to the need of a market exchangethat can ease the trading process by providing the requiredinfrastructure for interaction. In this paper we introducedthe novel market exchange framework named ”Mandi” forfacilitating such trading. We identified the various technicaland market requirements and challenges in designing suchan exchange. We described the architecture and the imple-mentation of Mandi and evaluated it with two experiments:measuring the effect of design choices on the performance ofMandi and measuring overhead time incurred in the interactionbetween the consumer and the provider through Mandi. Theexperiments shows that Mandi can scale well and can handlemany concurrent trading models and resource requests. Wecan thus conclude that the overhead generated for matchinga large number of resource requests in concurrent auctions

is minimal. The only limit to the scalability of the system isthe persistence layer, which also constitutes the single point offailure. In order to address this issue, a more efficient databaseserver and a solid replication infrastructure has to be put inplace.

In the current implementation, the accounting and the bank-ing service are not implemented, thus we aim to implementthem in next version of Mandi. In future, we will like toconsider large scale setups using Mandi. We plan to extend theGridbus Broker [5] and integrate various resource providerssuch as Amazon. In addition, since in reality there will bemultiple exchanges, thus we will research how they willintercommunicate.

REFERENCES

[1] I. Foster, Y. Zhao, I. Raicu, and S. Lu, “Cloud computing and gridcomputing 360-degree compared,” in Grid Computing EnvironmentsWorkshop, 2008. GCE’08, 2008, pp. 1–10.

[2] “Ian Foster, What’s faster-a supercomputer or EC2? ,” http://ianfoster.typepad.com/blog/2009/08/whatsfasterasupercomputerorec2.html, Aug.2009.

[3] Amazon, “Amazon Elastic Compute Cloud (EC2),” http://www.amazon.com/ec2/, Aug. 2009.

[4] J. Broberg, S. Venugopal, and R. Buyya, “Market-oriented grids andutility computing: The state-of-the-art and future directions,” Journal ofGrid Computing, vol. 6, no. 3, pp. 255–276, 2008.

[5] S. Venugopal, K. Nadiminti, H. Gibbins, and R. Buyya, “Designing a re-source broker for heterogeneous grids,” SoftwarePractice & Experience,vol. 38, no. 8, pp. 793–825, 2008.

[6] E. Huedo, R. Montero, and I. Llorente, “A framework for adaptiveexecution in grids,” Software Practice and Experience, vol. 34, no. 7,pp. 631–651, 2004.

[7] K. Lai, L. Rasmusson, E. Adar, L. Zhang, and B. Huberman, “Tycoon:An implementation of a distributed, market-based resource allocationsystem,” Multiagent and Grid Systems, vol. 1, no. 3, pp. 169–182, 2005.

[8] B. Chun, P. Buonadonna, A. AuYoung, C. Ng, D. Parkes, J. Shneidman,A. Snoeren, and A. Vahdat, “Mirage: a microeconomic resource allo-cation system for sensornet testbeds,” in Proceedings of the 2nd IEEEworkshop on Embedded Networked Sensors. IEEE Computer Society,2005, pp. 19–28.

[9] A. AuYoung, B. Chun, A. Snoeren, and A. Vahdat, “Resource allocationin federated distributed computing infrastructures,” in Proceedings ofthe 1st Workshop on Operating System and Architectural Support forthe On-demand IT InfraStructure, vol. 9. Citeseer, 2004.

[10] T. Eymann, M. Reinicke, O. Ardaiz, P. Artigas, L. de Cerio, F. Freitag,R. Messeguer, L. Navarro, D. Royo, and K. Sanjeevan, “Decentral-ized vs. Centralized Economic Coordination of Resource Allocation inGrids,” in Grid computing: first European Across Grids Conference,Santiago de Compostela, Spain. Springer-Verlag New York Inc, 2003.

[11] P. Padala, C. Harrison, N. Pelfort, E. Jansen, M. Frank, andC. Chokkareddy, “OCEAN: The Open Computation Exchange andArbitration Network,” in International Symposium on Parallel andDistributed Computing, Ljubljana, Slovenia, October 2003.

[12] D. Neumann, J. Stoßer, and C. Weinhardt, “Bridging the adoption gap -developing a roadmap for trading in grids,” Electronic Markets, vol. 18,no. 1, pp. 65–74, 2008.

[13] J. Altmann, C. Courcoubetis, G. Stamoulis, M. Dramitinos, T. Rayna,M. Risch, and C. Bannink, “GridEcon: A market place for computingresources,” Lecture Notes in Computer Science, vol. 5206, pp. 185–196,2008.

[14] D. Neumann, J. Stoesser, A. Anandasivam, and N. Borissov, “Sorma-building an open grid market for grid resource allocation,” Lecture Notesin Computer Science, vol. 4685, p. 194, 2007.

[15] C. Yeo and R. Buyya, “A taxonomy of market-based resource manage-ment systems for utility-driven cluster computing,” Software Practiceand Experience, vol. 36, no. 13, p. 1381, 2006.

[16] SORMA, “Economic Middleware and Grid Operating SystemExtensions,” http://www.im.uni-karlsruhe.de/sorma/fileadmin/SORMA\Deliverables/D5.1\ final.pdf.

[17] J. Nakai and R. Van Der Wijngaart, “Applicability of markets to globalscheduling in grids,” NAS Report, pp. 03–004.

[18] TOP500 Supercomputers, “Supercomputer’s Application Area Share,”http://www.top500.org/stats/list/33/apparea, 2009.

[19] J. Shneidman, C. Ng, D. Parkes, A. AuYoung, A. Snoeren, A. Vahdat,and B. Chun, “Why markets could (but dont currently) solve resourceallocation problems in systems,” in 10th USENIX Workshop on HotTopics in Operating System, 2005.

[20] J. Altmann, M. Ion, and A. Mohammed, “Taxonomy of grid businessmodels,” Lecture Notes in Computer Science, vol. 4685, p. 29, 2007.

[21] H. Eriksson and M. Penker, “Business Modeling with UML: BusinessPatterns at Work, John Wiley&Sons,” 2001.

[22] C. Vecchiola, S. Pandey, and R. Buyya, “High-performance cloudcomputing: A view of scientific applications,” CoRR, vol. abs/0910.1979,2009.

[23] E. Cho, “JProfiler: Code Coverage Analysis Tool for OMP Project,”2006.