An MASFramework for rk for Speculative Trading ading Research in Stock Index Ind

Junneng N ie and Haopeng Chen(School of Software，Shanghai Jiao Tong University，Shanghai 200240，China)

An MASFramework for rk for Speculative Trading ading Research in Stock Index Index FuturesMarket arket

Junneng N ie and Haopeng Chen
(School of Software，Shanghai Jiao Tong University，Shanghai 200240，China)

In this paper，we develop a futures trading simulation system to determine how speculative behavior affects the futuresmar⁃ket.A configurable client is designed to simulate traders，and users can define trade strategies using different programming languages.A lightweight server is designed to handle large⁃scale and highly concurrent access requests from clients. HBase is chosen as the database to grantee scalability of the system.As HBase only supports single⁃row transaction，a transaction support mechanism is developed to improve data consistency for HBase.The HBase transaction supportmecha⁃nism supports multi⁃row and multi⁃table by using two phase commit protocol.The experiments indicate that our system shows high efficiency in the face of the large scale and high concurrency access request，and the read/write performance loss of HBase introduced by the transaction support mecha⁃nisms is also acceptable.

NOSQL;transaction management;isolation level;multi⁃agent system

1 Introduction

The index futuresmarket is a complex adaptive sys⁃tem that allows the traders to submitorders to sup⁃ply liquidity and to consume liquidity.The behav⁃iorof index futuresmarket isan importantconsider⁃ation for both traders and market regulators for the reason that the ordersneeds to be placed and execute fluently and themar⁃kethas tobe functioned smoothly.

One way to estimating and researching themarket could be focused on analyzing and fitting statisticalmodelson pastdata. However，the futuremarket conditions and scenariosmay nev⁃ er have occurred before.So this approach is very restrictive. Anmore effective approach is themulti⁃agentsystem(MAS)as emphasized by Dawid and Fagiolo[1].This is a specialization to economics of the basic complex adaptive systems paradigm [2].

Hence，inspired by previous studies like the Santa Fe Artifi⁃cial Stock Market[1]，we propose a distributed MAS for specu⁃lative trading strategy research and policy design in the CSI300 index futuresmarket.

Our system is realistic.We build the configurable client on a distributed architecture.The whole system scaleswellwhen the number of clients increases.We also let the client’s trad⁃ing strategy be updated with another typewritten in severaldif⁃ferent programming languages without shutting down the sys⁃tem.The agents gossip with each otherwhich results the pessi⁃mistic or optimistic mood among themselves affecting their trading strategy.Furthermore，the realmarket data is incorpo⁃rated as the fundamental parameterwhich contributes tomake the traders’behaviorsmore reliableand credible.

Everymodule in the server is lightweight，especially for FIX server，it only concerns the transmitting of the trade request. The business logic modules are implemented as simplified as possible.The state oforders and traders is transmitted bymes⁃sages，which enhances the scalability of the system.

Besides，the system is required to process huge volume of trades concurrently，and the historicalmarket information，in⁃cluding the intermediate tradingmessages and the action log of each agent，summing up results in the generation of significant data.Meeting up themassive concurrentaccessaswellas pro⁃viding efficientaccess to the various data are themajor bottle⁃necks of the database.Furthermore，the various data include both structured data，like account ID，initialmoney，contracts held，and unstructured data like the action log which regis⁃tered everymove the agentmade all the time.

In conclusion，there are twomajor obstacles，large scale and high concurrentaccess requests aswellas the large scale data storage and processing，concerning the futures trading simula⁃tion system.The difficulties of the whole system are listed as follows.High efficiency has to bemetwhile dealing with large and high concurrentaccess requests，aswellas the strong con⁃sistency should also be satisfied while handling large scale da⁃tastorageand processing.

2 Related W ork

The basic economic structure of themarketdraws heavily on existing market setups such as Bray[3].However，in recent years，agent⁃based simulationsofmarkethave been developing rapidly and aremore widely accepted.The Santa Fe Institute Artificial Stock MarketModelwas one of the firstagent⁃based models of a financialmarket，and was developed by Brian Ar⁃thur et al.Themodel is inhabited by a population ofmyopic，imperfectly rational，heterogeneous agents who make invest⁃ment decisions by forecasting the future status of the market and who also learn from their experience over time.Themodel illustrates how simple interactions between such agents may lead to theappearanceof the realistic structure itself.

Researchers at Santa Fe Institute later constructed awidely used multi⁃agent software platform called Swarm that simu⁃lates financial trading systems.Swarm[4]is an opensource toolkitwith both Objective⁃C and Java bindings.Itwas origi⁃nally developed as a software toolkit for the creation of simula⁃tionmodels in the field of Artificial Life.It providesmodelers with a flexible，nested approach to modeling interactions. Minar[4]states that agent⁃basedmodeling toolkits or libraries are important in that they save scientists from wasting time on repetitive and error⁃prone programming.Object orientation is alsousefulbecauseof its closeassociationwith agents.

Other agent⁃based simulation platformsare listed as follows. Repast[5]is a family of three free opensource agent⁃based modeling libraries.The three libraries are Java⁃based Repast J，C#⁃based Repast.NET，and NQP(Not Quite Python)⁃based Repastby StarLogo[5].NetLogo[6]isa free opensourceagent⁃based simulation environment that uses amodified version of the Logo programming language.

All these agent⁃based simulation platformsare bound direct⁃ly to specific programming languages.It is common for people from business and financial communities are lack of coding proficiency.Therefore，it is of vital importance to keep high scalable ability of the Futures trading platform which means that the platform has to supportseveral different languages im⁃plementing the tradingalgorithm.

Based on platforms discussed above，researchers have built many simulation systems for financial trading.Multi⁃agent au⁃tomated intelligent shopping system(MAISS)[7]is a distribut⁃ed system where human users(buyers and sellers)delegate their tasks to agents，which then shop on their behalfand pres⁃ent the results.Buyers(customers)and sellers(suppliers)may be organizations，companiesor individuals.S.Mundle[8]intro⁃duces amulti⁃agent architecture that is designed and simulat⁃ed using opensource Java Agent Development Framework (JADE).In this JADE⁃based multi⁃agent system formobile computing in cellular networks，agents interactwith each other to find the optimal threshold for calladmission using distribut⁃ed service architectures.It evaluates connection⁃level perfor⁃mance characteristics of dynamic and mobility based call ad⁃mission control schemes using agents.A.Shemshandi[9]pro⁃poses implementing amulti⁃agent system for real⁃time coordi⁃nation of a typical supply chain based on JADE technology. This paperaddresses the preliminary approach towards process⁃oriented collaborative inventory management in supply chains，taking advantage ofmulti⁃agent technology in terms of modelingand simulation.

Almostall the simulation software previouslymentioned use relationaldatabases.However，a futures trading simulation sys⁃tem faces the challengeof requestson large scaleand high con⁃ current access.This means that a NoSQL database[10]is a better choice.However，NoSQL databases can hardly provide fullsupport for complicated transactions[11].This leads to fail⁃ure in keeping the strong consistency of the data.And that is an indispensable key technology in oursystem.

An open source project called Omid[12]provides transac⁃tional support for HBase.Omid uses a central server called Transaction Oracle to manage transactions.The API can be used in transaction clients.Transaction clients are in charge of connecting to the transaction oracle and perform the required operations in data⁃stores.The transaction oracle replicates transactional information to the transaction clients which just contact the transaction oraclewhen theywant to starta transac⁃tion or commit it.HBASE⁃5229，one of HBase’s updating is⁃sues，mentioned that it provides basic building blocks for“multi⁃row”local transactions，however，afterward italso says this feature is by design and is not available to the client via the HTable API[13].

Goolge proposed a technique called Percolator for BigTable [14].Percolator chooses to use a column of itself to provide lock service and implements a two phase commit protocol to guarantee the synchronism ofmulti⁃row and multi⁃table.We implemented themulti⁃row andmulti⁃table transactionalmech⁃anism based on HBase referencing percolator.Furthermore，we extended the multi⁃row and multi⁃table transaction mecha⁃nism，such asprovidingmulti⁃level isolation level.

3 Framework and Flow

Fig.1 shows the architecture of the futures trading simula⁃tion system.Trading strategies ofall kinds of traders are stored in the client backend.Each client front⁃end stimulates a cer⁃tain number of traders and communicateswith the clientback⁃end.Trading requests generated according to corresponding strategies are sent to the server side using Financial Informa⁃tion Exchange(FIX)protocol.FIX is a communication and messaging protocol widely used to conduct securities transac⁃tions.After trading requests are received，they are processedby the business logic adopting distributed computation meth⁃ods.HBase，which is used as the database in our system，only supports single⁃row transactions.Therefore，we add a transac⁃tion support layer formulti⁃row and multi⁃table transactions. The detailed architecture of clientand serverwillbe discussed in the nextsection.

▲Figure1.Architectureof the futures trading simulation system.

Fig.2 shows a simulated trading process that involves the interaction between the threemodules such as client frontend，client backend(CSPI)and server.Client frontend is in charge of generating and transmitting trading requests;clientbackend stores all trading strategies used by traders;server is responsi⁃ble formanaging and matching the trading requests.First，one of the traders that client front end simulates communicates with the corresponding trading strategies stored in client back end to decidewhatkind ofdata itneeds.Thisdatamay be real⁃time and historicaldata of stock index futures.Then，the client frontend collects the required information from the server and sends it back to the client backend.After client back end re⁃ceives the data，trading orders are generated by running rele⁃vantstrategy and then ordersare sent to the server.Finally，the server processes the orders and sends feedback，that the order issuccessfullymatched or failed，to client frontend.

Fig.3 shows the transaction supporting mechanism of HBase.The HBase transaction supportingmechanism is the in⁃terlayer between the user software and HBase，and the HBase transaction supporting mechanism invokes the API of HBase to supportmulti⁃table transaction.The HBase transaction sup⁃ portingmechanism can be divided into five sections:

▲Figure2.A specific simulated trading process.

▲Figure3.Architectureof transaction supportmechanism for HBase.

1)User program，which uses HBase transaction supporting mechanism to execute the transaction，The user program is theentrance to the HBase transactions.

2)HBase transaction supporting API，which is themain body of the transaction supportingmechanism.This APIalso of⁃fersmany of the transaction functions，and transactionalop⁃erationssuch ascreate，update，and delete.

3)Timestamp Server，which provides unified the timestamp of the service for the HBase transaction supporting mecha⁃nism.The timestampmustbemonotonically increasing.The transaction gets a time stamp from the Timestamp Server each timeat thebeginningand submitting.

4)ZooKeeper，which monitors and keeps track of the state of every node in the cluster.

5)Exception server，which is thehandlerof theabnormal trans⁃action in HBase transaction supporting mechanism.Each initiator has to communicate with the Exception Server and the transaction information stored is used by Exception Server to process the abnormal transaction after a abnormal node in the clusterbeing detected.

4 Key Techniques

4.1 Configurable Client

In order to simulate real，complex futures trading，simulated traders depend on well⁃defined trading strategies and apply the data they get from the simulated market to make predic⁃tions and generate trading orders.There are three different kinds of traders:hedger，speculator and arbitrager.Each kind of trader has different trading strategies.The client is split into client front end module and client back end module.Client frontend communicatesmutually with a server，and the client back end provides the trading strategy for client frontend.De⁃tailed realization of the trading strategy is not our top priority. This is realized by financial professionals.The strategies in the clientback end can be implemented using advanced program⁃ming language such as Java，C++，C#，and even Matlab.Also the uniform interface is provided to support different strate⁃gies，adopting the design pattern ofadapter.

The scalability and usability of the system are improved by using the configuration settings to initialize the client frontend and back end.The configuration settings for client front end contain the portnumber，the FIX protocol version，the server’s IP address and port number，the client backend’s IP address and portnumber，the interaction protocolwith clientback end，the number of simulated traders，the percentage of each kind of simulated trader，and the interface of the trading strategy. The configuration settings for the client back end contain the portnumber，the interaction protocolwith client frontend，the implementation of the adapter，and the interface of trading strategy.All configuration settings existas cfg files that can beedited by text and graphic.The system also provides several differentdefaultconfiguration settings.

Fig.4 shows the structureof the client.Thereare several cli⁃ent frontendmodules deployed in a cluster of nodes，and each of these modules runs a certain number of simulated traders. The clientback end isdeployed in a single nodeand communi⁃cateswith all client frontends.There aremultiple types of in⁃teraction between the client front end and backend.These in⁃clude RMIand Web Service.The interaction between the cli⁃ent front end and server relies on FIX protocol.Message for⁃mats and mechanisms for sending and receiving message are defined in FIX protocol，and FIX protocol also includes the contentofsession layermanagement，application layermessag⁃es，and data dictionary.All FIX protocol versions and most part of the functions are implemented in FIX server module and FIX clientmodule.

4.2 Lightweight Server

Fig.5 shows the structure of the server.As soon as the FIX server receives the trade requests from clients，it transmits them to the nodes deployed in the cluster.Each node in the cluster runs two processes:data and transaction support.The data processing module handles the trade requests according to the business logic，and transaction supportmodule provides multi⁃row and multi⁃table transaction support for HBase.As with the client，the server also uses the configuration settings，which can configure the port number of the FIX server，the FIX protocol version and the port number and IP address of the node in the cluster.

In order to improve system performance，we designed a light⁃weight server.First，everymodule in the server is lightweight，especially for FIX server，it only concerns the transmitting of the trade request.Also，we implement thebusiness logic ofoth⁃ermodules in the cluster to be as simple as possible.Second， according to the actual operation condition，we implement dif⁃ferent transaction isolation levels and use the levelwill be as low as possible to decrease the responding time of the data⁃base.Forexample，for theoperation in the tableof the trade re⁃quest，we set the isolation level to be read⁃committed to guar⁃antee consistency.For the operation in table of the real⁃time data of themarket，we set the isolation level to be read⁃uncom⁃mitted in order to improve read performance.For the operation in table of the historical data of themarket，we setno isolation levelbecause it isa read⁃only table.Finally，the server isstate⁃less.The state oforders and traders is transmitted bymessages and thisenhances the scalability ofour system.

▲Figure4.Structureof client.

▲Figure5.Structureofserver.

4.3 Non-relationalDatabase Supporting Strong Consistency

HBase is deployed as the database in our system.Similar to BigTable，HBase supports only single⁃row transaction.Consid⁃er a situation where trader A transmits a purchase order to a server，and trader B sends an order selling the same futures at the same time.Afterwards，the requests are consideredmatch⁃ing successfully，and two trade records are generated by the server.Then，the two records have to bewritten into the data⁃base.We need to ensure atomicity because they would both succeed or fail.However，this operation involves two different rows，and the above requirementcannotbe satisfied by HBase. Therefore，in our system，a technique similar to Percolator is used to supportmulti⁃row andmulti⁃table transaction.Beyond Percolator，we also implement three different transaction isola⁃tion levels for Hbase:read⁃uncommitted，read⁃committed，and repeatable⁃read.

4.3.1 The Design of TheDistributed Transaction Locks

Our system uses a single row in HBase to represent lock for the following reasons:

•If a single row in HBase is used to represent lock，lock sim⁃plymeanswriting the log data to a unitof the single⁃row rep⁃resenting the lock，while unlocking bymeans of deleting thedata.The atomicity of lock and unlock operation is ensured as the HBase providesa single row transaction.

•HBase is a distributed database，data stored in networks of nodes，and the throughput is related to the bandwidth of the system.Thathigh throughputof HBase isensured by storing data in distributed clusters result in the throughput of the distributed transaction locks implemented in the HBase.

•Region server in HBase automatically sends the complex load information to HMater，and HMaster assigns the region to the Region serveraccording to the load of this server.Low latency is ensured by a load⁃balancing function provided by Hbase.This also lead to the low latency of the distributed transaction locks.

•HBase is built on top of the HDFS file system，and HDFS provides the backup function.Each file block in HDFShas three backups by default，whichmeans that if a node in the clustermalfunctioned，there are still two othermodes avail⁃able.And the persistence of HBase results from the Backup function supported by HDFS.The distributed transaction locks implemented in HBase thereby possess the character⁃istic ofpersistence.

•Using sing⁃row of HBase as the distributed transaction lock benefits in away that the read and write performance of the lock is the same of the read and write of HBase，so the per⁃formance of the distributed transaction lock won’t be the bottleneck of the system.

Consider the requirements for the lock needed by transac⁃tion operation in HBase.The lock itself must be persistent，and the lock service has to provide high throughputand low la⁃tency.HBase runs on top of HDFS，which provides storage backup capability for HBase，so as to be persistent.As a kind of distributed database，HBase naturally has high throughput. Although HBase can do load balancing itself，italsohas low la⁃tency.Therefore，HBase can provide lock service to itself，so an extra column isadded into the table to illustrate the locks.

4.3.2 Synchronization ofDistributed Transaction

The atomicity ofmulti⁃row and multi⁃table transaction in HBase is guaranteed by two phase commit protocolwhich in⁃volves coordinator and participator.The coordinator can be viewed as both the initiator and a participator of the transac⁃tion.Each row contained in the transaction corresponds to a participator.The two⁃phase commit protocol has pre⁃commit and actual⁃commitphases.In the phase ofpre⁃commit，coordi⁃nator informs all participators to be prepared for committing or cancelling the transaction.And then the coordinator is notified of the decision made by the participators.While in the phase of actual⁃commit，coordinator willmake the decision depend⁃ing on the resultof the voting in the previous phase.If and on⁃ly if all participators agree on committing the transaction，all participatorswillbe informed to commit the transaction.Other⁃wise，the transactionwillbe cancelled.

The traditional two⁃phase commit protocol is adjusted to be more pragmatic and practical:

1)Participants are no longer the traditional cluster nodes but rows in HBase.Because the single⁃row transaction is sup⁃ported by HBase，multi⁃row transaction is the emphasis for the realization of transaction supporting mechanism in HBase.Thus，each row can be abstract as participants，vot⁃ing on transaction submission respectively.

2)The result of the vote is submitted to the originator of the transaction instead of the coordinator.The entire transac⁃tion submission is completed by the user program invoking the transaction for the reason that the user program could collect the vote from the participants conveniently and the rows isnotavailable to communicatewith each other.

3)The coordinator is randomly selected，the first the row in⁃volved in the transaction is normally selected as the coordi⁃nator，and the others the participants.Communicating with participants is no longer the responsibility of the coordina⁃tor，which is in charge of recording the state of transaction submitting.

4.3.3 Exception Handling

If there is problem during a transaction，the node processing the transaction might crash，and the transaction cannot be properly completed.Therefore，a lock is left behind(Fig.6).It is intolerable to the system that the left⁃behind lock is left un⁃handled and the row involved is locked and invisible.

The key to detecting the left⁃behind locks is to check wheth⁃er the corresponding software has crashed or collapsed.Time⁃stamp two，which is obtained from the timestamp server when the transaction started，isattached to the lock held by the trans⁃action and facilitates the process of finding the transaction holding the lock.The Exception Server recodes the information of all running nodes and transactions.The state of the node is quickly checked though ZooKeeper.Furthermore，it is still notefficientautomatically detect the left⁃behind locksbecuase the confliction is rare in the system.Therefore，a shortcut is taken to clean up the left⁃behind locks.

▲Figure6.Exception handling process.

The left⁃behind locks are processed by the system in the manner of rolling back.If the transaction crashed before sub⁃mission，the result of rows，being locked，participating the transaction hasn’t been submitted，the main task of rolling back is to clear up the left⁃behind locks bymeans of deleting the lock locking the rows participating the transaction.If the transaction crashed during the submission，the resultsare part⁃ly submitted，the rollback operation has to clear the left⁃be⁃hind locks of uncommitted rows and recover the state of com⁃mitted rows.

The previouslymentioned coordinator’s role is to record the state of transactions.Whether the transaction crashed before submission or during submission is distinguished according to the state of the coordinator.The transaction of coordinator is fi⁃nally committedmeaning that the lock of coordinator row is fi⁃nally cleared.If the lock of coordinator row doesn’t exist，there is no need to roll back due to complete transaction sub⁃mission.The lock of the coordinator row contains the row key of other transaction，the other rows will be checked in turn whether the data is updated.If the data existed on the time stamp of a row，the row committed the transaction already and crashed during submission，otherwise the row crashed before submission.

4.3.4 Isolation Level

We implement three kindsof isolation level:read uncommit⁃ted，read committed and repeatable reads(Table1).

Also，we use the snapshot isolation provided by HBase to re⁃duce the happening of conflictand improve concurrency.Each transaction will get two timestamps from a timestamp server: one is at the beginning time of transaction and the other is at the committing time of transaction.The beginning timestamp of a transaction determines the data it can read and the com⁃mitting timestamp determines the data other transactions can read.

5 Experim entsand Results

5.1 Load Test

In this section，we discuss the performance of our system for large and highly concurrent access requests.Because clients and the process part of server are both distributed，the FIX server ismost likely to be the system’s bottleneck.We run a load test tomeasure the performance of FIX server.We simu⁃lated 100 traders，and by modifying the request frequency of each trader，we obtained seven results.Fig.7 shows the re⁃sponse time of FIX server.The horizontalaxis in Figs.7 and 8 represents the number of concurrent requests per second.In Fig.7，when the concurrentnumber is below 500，the response time is short，and when the concurrent number grows to 1000，the response time increases significantly.However this prob⁃lem can be solved by a largerHBase cluster.

▼Table1.Used locksand detected locksin different isolation levels

Fig.8 shows CPU utilization of FIX server.The CPU utiliza⁃tion rate is grows in a similar way.The linearly increasing of concurrency，resulting in computation scaling linearly，led to the CPU utilization increasing accordingly.

5.2 The Influence Caused by Strong Consistency

Asmentioned previously，we providemulti⁃row andmulti⁃ta⁃ble transaction support for Hbas.In this section，we discuss the influence on the read/write performance of HBase caused by this.We designed four experiments:random write 5Mrows in HBase;random read 5Mrows in HBase;random write 5Mtransactions in HBase;random read 5Mtransactions in HBase. In the last two experiments，each transaction only includes one write or read operation，and this represents the worst case ofport，the random read/writeofHBase performance decreases. the transaction.Tables2 to 4 show the results.

▲Figure7.The response timeof FIX server.

▲Figure8.TheCPU utilization of FIX server.

After providingmulti⁃row and multi⁃table transaction sup⁃

▼Table2.Comparison in read uncommitted level

▼Table3.Comparison in read committed level

▼Table4.Comparison in repeatable read level

Under the read uncommitted isolation level，for no addition operations in read operation，the performance difference be⁃tween original HBase APIand HBase supporting API is negli⁃gible.The subtle performance difference results from obtaining unified time stamp from the Timestamp Server after failure.On the contrary，awrite operation involves an additional read and write operation，which createsa big performance gap of0.3 be⁃tween originalHBase APIand HBase supporting API.

While at the read⁃committed level and repeatable⁃read lev⁃el，an extra read and two extra write is required in read opera⁃tion.There is a difference of 0.34 between original HBase API and HBase supporting APIin random read operation.There is also a big performance gap as 0.29 and 0.28 between original HBase APIand HBase supporting API for an additional read and write involved in write operation.

6 Conclusion and FutureW ork

We have designed and implemented a futures trading simu⁃lation system that has been used by financial professionals to study how individual speculation affects the futures market. Our experiments show that the system is very efficient in the face of large⁃scale，high concurrency access requests.It isalso very scalable and consistent in the face of the large scale⁃data storage and processing.Our experiments also show that the read/write performance loss of HBase introduced by the trans⁃action supportmechanisms is acceptable.We plan to deploy our system to amuch bigger cluster and test the system more full⁃scale.Also in reality，the futuresmarketand the spotmar⁃ketare influenced by each other.In order tomake the study of how individual speculative behavior produces an effect on fu⁃turesmarketmore precise，we should concern the spotmarket. So implementing the spotmarketsimulating system willbe our futurework.

[1]H.Dawid and G.Fagiolo，“Agent⁃basedmodels for economic policy design:In⁃troduction to the special issue，”Journal of Economic Behavior&Organization，vol.67，no.2，pp.351-354，2008.doi:10.1016/j.jebo.2007.06.009.

[2]L.Wei，W.Zhang，X.Xiong，and Y.Zhao，“Amulti⁃agentsystem for policy de⁃sign of tick size in stock index futuresmarkets，”SystemsResearch and Behavior⁃alScience，vol.31，no.4，pp.512-526，2014.doi:10.1002/sres.2292.

[3]M.M.Bray，“Futures trading，rationalexpectations，and theefficientmarketshy⁃pothesis，”Journal of the Econometric Society，vol.49，no.3，pp.575-596，May 1981.

[4]N.Minar，R.Burkhart，C.Langton，and M.Askenazi，“The Swarm simulation system:a toolkit for buildingmulti⁃agent simulations，”Santa Fe Institute，Santa Fe，USA，Paper 96⁃06⁃0421996，Jun.1996.

[5]M.J.North，T.R.Howe，N.T.Collier，and J.R.Vos，“The repastsimphony run⁃time system，”in Proc.Agent 2005 Conf.Generative Social Processes,Models, and Mechanisms，Argonne，USA，2005.

[6]S.Tisue and U.Wilensky，“Netlogo:a simple environment formodeling complex⁃ity，”presented at Int.Conf.Complex Systems，Boston，USA，2004.

[7]L.Yu，E.Masabo，L.Tan，and M.He，“Multi⁃agent automated intelligent shop⁃ping system(MAISS)，”in 9th Int.Conf.Young Computer Scientists，Hunan，Chi⁃na，2008，pp.665-670.doi:10.1109/ICYCS.2008.35.

[8]S.Mundle，N.Giri，A.Ray，and S.Bodhe，“JADE based multiagent system for mobile computing for cellularnetworks，”in Proc.Int.Conf.Advances in Comput⁃ing,Communication and Control，2009，pp.467-473.

[9]A.Shemshadi，J.Soroor，and M.J.Tarokh，“Implementing amultiagent system for the real⁃time coordination ofa typical supply chain based on the JADE tech⁃nology，”System ofSystemsEngineering，vol.2，pp.1-6，2008.

[10]B.G.Tudorica and C.Bucur，“A comparison between several NoSQL databas⁃eswith comments and notes，”in 10th Roedunet Int.Conf.，Iasi，Romania，Jun. 2011，pp.1-5.doi:10.1109/RoEduNet.2011.5993686.

[11]C.Strauch.(2012).NoSQL Databases[Online]Available FTP:http://www. christof⁃strauch.de/nosqldbs.pdf

[12]D.G.Ferro，F.Junqueira，I.Kelly，B.Reed，and M.Yabandeh，.“Omid:lock⁃free transactional support for distributed data stores”，in IEEE 30th Int.Conf. Data Engineering(ICDE)，Chicago，USA，2014，pp.676-687.

[13]L.George，HBase:The Definitive Guide.Sebastopol，USA:O′Reilly Media，2011.

[14]F.Chang，J.Dean，S.Ghemawat，W.C.Hsieh，D.A.Wallach，M.Burrows，T. Chandra，A.Fikes，and R.E.Gruber，“Bigtable:A Distributed Storage System for Structured Data”，ACMTrans.Comput.Syst.，vol.26，no.2，pp.1-26，Jun. 2008.doi:10.1145/1365815.1365816.

t

2014⁃09⁃10

10.3969/j.issn.1673-5188.2014.04.008

http://www.cnki.net/kcm s/detail/34.1294.TN.20141204.1406.002.htm l,pub lished online Decem ber 4,2014

Biographies phies

Junneng Nie(njn@sjtu.edu.cn)received his BSdegree in software engineering from Shanghai Jiao Tong University.He is currently a MsC candidate at the School of Software，Shanghai Jiao Tong University.His research interests includemassive da⁃ta processingand software testing.

Haopeng chen(chen⁃hp@sjtu.edu.cn)is an associate professor of School of Soft⁃ware，Shanghai JiaoTong university.He received his PhD degree from Department of Computer Science and Engineering，Northwestern Polytechinal University in 2001.He hasworked with School of Software，Shanghai Jiao Tong University since 2004 after he finished his two⁃year postdoctoral research job in Departmentof Com⁃puter Science and Engineering，Shanghai Jiao Tong University.In 2010，he studied and researched atGeorgia Institute of Technology asa visiting scholar.His research group focuses on distributed computing and software engineering，and has kept studying Web Services，Web 2.0，Java EE，.NET，and SOA for several years.Re⁃cently，the group is also interested in cloud computing，including cloud federation，resourcemanagement，and dynamic scaling up and down.