scispace - formally typeset
Search or ask a question
Journal ArticleDOI

Agent-Based Cloud Computing

01 Jan 2012-IEEE Transactions on Services Computing (IEEE Computer Society)-Vol. 5, Iss: 4, pp 564-577
TL;DR: This work devised a complex cloud negotiation mechanism that supports parallel negotiation activities in interrelated markets: a cloud service market between consumer agents and broker agents, and multiple cloud resource markets between broker agents and provider agents.
Abstract: Agent-based cloud computing is concerned with the design and development of software agents for bolstering cloud service discovery, service negotiation, and service composition. The significance of this work is introducing an agent-based paradigm for constructing software tools and testbeds for cloud resource management. The novel contributions of this work include: 1) developing Cloudle: an agent-based search engine for cloud service discovery, 2) showing that agent-based negotiation mechanisms can be effectively adopted for bolstering cloud service negotiation and cloud commerce, and 3) showing that agent-based cooperative problem-solving techniques can be effectively adopted for automating cloud service composition. Cloudle consists of 1) a service discovery agent that consults a cloud ontology for determining the similarities between providers' service specifications and consumers' service requirements, and 2) multiple cloud crawlers for building its database of services. Cloudle supports three types of reasoning: similarity reasoning, compatibility reasoning, and numerical reasoning. To support cloud commerce, this work devised a complex cloud negotiation mechanism that supports parallel negotiation activities in interrelated markets: a cloud service market between consumer agents and broker agents, and multiple cloud resource markets between broker agents and provider agents. Empirical results show that using the complex cloud negotiation mechanism, agents achieved high utilities and high success rates in negotiating for cloud resources. To automate cloud service composition, agents in this work adopt a focused selection contract net protocol (FSCNP) for dynamically selecting cloud services and use service capability tables (SCTs) to record the list of cloud agents and their services. Empirical results show that using FSCNP and SCTs, agents can successfully compose cloud services by autonomously selecting services.

Summary (4 min read)

1.1 Cloud Computing

  • A cloud is a large group of interconnected computers that extends beyond a single company or enterprise [1], [2].
  • The applications and data served by the cloud are accessed via the Internet by a broad group of users across multiple enterprises and platforms.
  • A cloud computing system consists of a collection of interconnected and virtualized computers dynamically provisioned as one or more unified computing resource(s) through negotiation of service-level agreements (SLAs) between providers and consumers [3].
  • In cloud computing platforms, resources need to be dynamically (re)configured and aggregated via virtualization [3] and consumers’ requirements can potentially vary over time and amendments need to be accommodated.

1.2 Agent-Based Computing

  • An agent is a computer system that is capable of autonomous actions, that is, deciding for itself and figuring out what needs to be done to satisfy its design objectives [5].
  • A multiagent system consists of a number of agents, which interact with one another [5].
  • To successfully interact, agents require the ability to cooperate, coordinate, and negotiate with each other.
  • Cooperation is the process when several agents work together and draw on the broad collection of their knowledge and capabilities to achieve a common goal.
  • Negotiation is a process by which a group of agents communicate with one another to try to come to a mutually acceptable agreement on some matter.

1.3 Agent-Based Cloud Computing

  • Some of the essential characteristics of cloud computing include resource pooling and resource sharing.
  • In clouds, computing resources are pooled to serve multiple consumers, and applications and data are available to and shared by a broad group of cross-enterprise and cross-platform users.
  • The author is with the School of Computing, The University of Kent, Chatham Maritime, Kent, ME4 4AG, United Kingdom.
  • Agent-based cloud computing is concerned with the design and development of software agents for bolstering cloud service discovery, service negotiation, and service composition [4], [6], [7], [8].
  • In the service consumption phase, the service is delivered to the consumer.

1.4 Agent-Based Cloud Search Engine

  • The challenge in the service discovery phase is to run a query against the cloud services registered in the search engine’s database by matching consumers’ functional, technical, and budgetary requirements.
  • When building a general search engine (e.g., Google), one only needs to consider the issue of searching for webpages that contain concepts in a user’s query.
  • The problem of building a search engine for cloud services is more complex because one needs to search for services that satisfy three types of requirements.
  • The search engine in this work employs a service discovery agent (SDA) that consults a cloud ontology for determining the similarities between providers’ functional and technical specifications of services and consumers’ functional and technical requirements (Section 2).

1.6 Agent-Based Cloud Service Composition

  • The challenge in cloud service composition is to dynamically put together a set of services provided by multiple service providers to form a single unified service to be delivered to a consumer.
  • Various providers need to work together and draw upon each other’s service capabilities.
  • To automate cloud service composition, this work adopts 1) a focused selection contract net protocol for dynamically selecting cloud services and 2) service capability tables (SCTs) to record the list of cloud agents and their services.

2 CLOUD SEARCH ENGINE AND CLOUD CRAWLERS

  • Whereas preliminary ideas of Cloudle were reported in [23], [24], [25], this work presents a new architecture of Cloudle (Fig. 1) consisting of a service discovery agent, a cloud ontology, a database of cloud services, multiple cloud crawlers (Section 2.3), and a web interface.
  • Consumers enter their queries for cloud services using Cloudle’s web interface (Appendices 2 and 3, available in the online supplemental material).
  • The SDA has four submodules: 1. a query processor, 2. a service reasoning module, 3. a price and time slot matching module, and 4. a service rating module.
  • A cloud ontology consists of a set of cloud computing concepts and the interrelationships among cloud concepts to facilitate the reasoning about cloud services.

2.1 Service Reasoning

  • Given that Cloudle needs to satisfy three types of requirements: 1) functional, 2) technical, and 3) budgetary, sometimes, it may be difficult to find services that will exactly match these three types of requirements.
  • There are several ways to define a function for determining the degree of similarity between x and y [27].
  • Available in the online supplemental material.
  • When jcx cyj is large (respectively, small), x and y are less (respectively, more) compatible.

2.2 Price and Time Slot Matching

  • In matching price and time slot, the SDA attempts to search for providers with cloud services that have available time slots that match the specified time slots of consumers and with small price difference between the acceptable prices of the provider and consumer.
  • A utility function U is used to evaluate the level of matching for each potential match.
  • Mk between the respective prices and schedules of a consumer and a provider.
  • P cons max since there will be little or no room for negotiation of price.
  • It is assumed that T consS is greater than the actual time slot (end time start time) that a consumer will utilize a service.

3 CLOUD COMMERCE AND NEGOTIATION AGENTS

  • In a cloud business model, consumers pay service providers for consumption of computing capabilities.
  • It was noted in [3] that a market-oriented approach for managing cloud resources is necessary for regulating the supply and demand through flexible and dynamic pricing.
  • Broker agents accept service requests from consumer agents, purchase resources from provider agents, dynamically compose a collection of resources to satisfy consumer agents’ requirements, then sublease the service to consumer agents.
  • In a cloud service market, broker agents negotiate with consumer agents for mutually acceptable terms to establish SLAs for satisfying service requirements from consumers.
  • Since each broker agent can accept requests from many consumer agents and each consumer agent can also submit its requirements and requests to many broker agents, it is envisioned that a many-to-many negotiationmodel be adopted for negotiation between consumer agents and broker agents.

3.1 Multilateral Service Negotiation

  • For the many-to-many negotiation between consumer agents and broker agents, a market-driven negotiation strategy [16], [17], [18], [19], [20] and a bargaining-position-estimation strategy [13] are used to determine the amounts of concessions.
  • Based on its time-dependent concession making function, the consumer agent’s price proposal at negotiation round t is given as follows: PCAðtÞ ¼ IPCA þ t CA CA ðRPCA IPCAÞ; where CA is the consumer agent’s deadline for acquiring a service, 0 < CA < 1 is the concession making strategy.
  • In a cloud service market, whereas a consumer may have information about the number of brokers or providers providing the services it requires, it may not have knowledge of the number of consumers competing for the same type of service because consumers generally do not broadcast their requests to other consumers.
  • Since each consumer agent has m 1 competitors, let m0 denotes m 1. 0, there will be fewer consumer agents competing for services and more broker agents providing services, which means that consumer agents will be in an increasingly more favorable market and broker agents will be in an increasingly more unfavorable market.
  • 0, a consumer agent adopting MDA and a consumer agent adopting BPEwill make little or no concession.

3.2 Concurrent Cloud Resource Negotiation

  • For concurrent negotiation of multiple SLAs, a concurrent negotiation protocol adapted from [10] is adopted.
  • Fig. 8 shows a concurrent negotiation mechanism of a broker agent for establishing multiple SLAs for a collection of cloud resources.
  • If the broker agent receives one or more confirmation of contracts then the broker agent accepts the contract that generates the highest expected utility else the broker agent revises its proposal by making concession.
  • Decide whether to terminate or proceed with the concurrent negotiation based on the prediction of the change in utility in tþ 1 for each one-to-many negotiation.

4 AGENT-BASED CLOUD SERVICE COMPOSITION

  • Service composition in cloud computing generally requires 1. coordination and interaction among cloud participants (consumers, brokers, and providers), 2. automation of service selection, 3. dynamic (re)configuration of distributed and paral- lel services, and 4. dealing with incomplete information about the existence and location of cloud providers and their services.
  • Analyzing the number of messages exchanged among agents in FSCNP in the worst case and showing that FSCNP enhances the efficiency of classical contract net protocol (CNP) [21].
  • In FSCNP, agents focus on selecting relevant cloud services by consulting SCTs, thereby reducing the number of messages exchanged among cloud agents.

4.1 Agent-Based Testbed

  • An agent-based testbed for bolstering cloud service composition was implemented using Java and JADE framework.
  • An SPA delegates some of the service requests it receives to RAs.
  • Available in the online supplemental material.
  • A computing service provider may need additional storage space for an unusually large amount of results derived from processing some tasks.
  • A BA composes a set of resources from multiple SPAs, and provides a single virtualized service to CAs.

4.2 Acquaintance Network and Service Capability Table

  • In [34], an agent’s acquaintance network (AN) is a matrix in which the columns record the list of acquaintances (i.e., the list of agents that an agent knows), and the rows represent the service capabilities of the acquaintances.
  • A cloud agent can be in one of the following states: {“available,” “unreachable,” “failed,” “busy”}.
  • Hence, a BA needs to maintain SCTs of both BAs and SPAs.
  • Both SCTs record the locations of agents, their service capabilities, and their states.
  • When delegating service requests to its RAs, an SPA consults its SCT of RAs.

4.3 SCTs and Focused Selection Contract Net Protocol

  • All agents in the testbed (Fig. 10) adopt FSCNP which considerably augments and extends the classical CNP [21] for selecting and subcontracting cloud resources to satisfy consumers’ service requirements.
  • In CNP, agents have two roles: manager or contractor .
  • By only sending messages to selected agents with relevant service capabilities, the interactions among cloud agents in FSCNP are more efficient because 1) the number of messages exchanged among cloud agents are considerably reduced, and 2) cloud agents only focus on interacting with a subset of agents in the cloud system that provides the relevant cloud services.
  • Figs. 11a and 11b show the number of successful compositions and the number of messages exchanged for agents adopting 1) weakly connected SCTs, 2) moderately connected SCTs, and 3) strongly connected SCTs under different failure probabilities of SCTs.
  • When a CA submits a service request to the BA, the BA needs to subcontract the service requests to p SPAs, and p depends on the number of requirements submitted by the CA.

Did you find this useful? Give us your feedback

Content maybe subject to copyright    Report

Kent Academic Repository
Full text document (pdf)
Copyright & reuse
Content in the Kent Academic Repository is made available for research purposes. Unless otherwise stated all
content is protected by copyright and in the absence of an open licence (eg Creative Commons), permissions
for further reuse of content should be sought from the publisher, author or other copyright holder.
Versions of research
The version in the Kent Academic Repository may differ from the final published version.
Users are advised to check http://kar.kent.ac.uk for the status of the paper. Users should always cite the
published version of record.
Enquiries
For any further enquiries regarding the licence status of this document, please contact:
researchsupport@kent.ac.uk
If you believe this document infringes copyright then please contact the KAR admin team with the take-down
information provided at http://kar.kent.ac.uk/contact.html
Citation for published version
Sim, Kwang Mong (2012) Agent-Based Cloud Computing. IEEE Transactions On Services
Computing, 5 (4). pp. 564-577. ISSN 1939-1374.
DOI
https://doi.org/10.1109/TSC.2011.52
Link to record in KAR
https://kar.kent.ac.uk/32039/
Document Version
UNSPECIFIED

Agent-Based Cloud Computing
Kwang Mong Sim, Senior Member, IEEE
Abstract—Agent-based cloud computing is concerned with the design and development of software agents for bolstering cloud service
discovery, service negotiation, and service composition. The significance of this work is introducing an agent-based paradigm for
constructing software tools and testbeds for cloud resource management. The novel contributions of this work include: 1) developing
Cloudle: an agent-based search engine for cloud service discovery, 2) showing that agent-based negotiation mechanisms can be
effectively adopted for bolstering cloud service negotiation and cloud commerce, and 3) showing that agent-based cooperative problem-
solving techniques can be effectively adopted for automating cloud service composition. Cloudle consists of 1) a service discovery agent
that consults a cloud ontology for determining the similarities between providers’ service specifications and consumers’ service
requirements, and 2) multiple cloud crawlers for building its database of services. Cloudle supports three types of reasoning: similarity
reasoning, compatibility reasoning, and numerical reasoning. To support cloud commerce, this work devised a complex cloud
negotiation mechanism that supports parallel negotiation activities in interrelated markets: a cloud service market between consumer
agents and broker agents, and multiple cloud resource markets between broker agents and provider agents. Empirical results show that
using the complex cloud negotiation mechanism, agents achieved high utilities and high success rates in negotiating for cloud resources.
To automate cloud service composition, agents in this work adopt a focused selection contract net protocol (FSCNP) for dynamically
selecting cloud services and use service capability tables (SCTs) to record the list of cloud agents and their services. Empirical results
show that using FSCNP and SCTs, agents can successfully compose cloud services by autonomously selecting services.
Index Terms—Cloud computing, multiagent systems, software agent, service discovery, service composition, negotiation, resource
management
Ç
1INTRODUCTION
W
HEREAS many existing works in cloud computing focus
on the development of infrastructures and tools for
pooling together computational resources, this work com-
plements and supplements existing works in cloud comput-
ing by introducing “agent-based cloud computing”—
applying agent-based approaches to m anaging cloud
computing infrastructures.
1.1 Cloud Computing
A cloud is a large group of interconnected computers that
extends beyond a single company or enterprise [1], [2]. The
applications and data served by the cloud are accessed via
the Internet by a broad group of users across multiple
enterprises and platforms. A cloud computing sy stem
consists of a collection of interconnected and virtualized
computers dynamically provisioned as one or more unified
computing resource(s) through negotiation of service-level
agreements (SLAs) between providers and consumers [3]. In
cloud computing platforms, resources need to be dynami-
cally (re)configured and aggregated via virtualization [3]
and consumers’ requirements can potentially vary over
time and amendments need to be accommodated.
1.2 Agent-Based Computing
An agent is a computer system that is capable of
autonomous (independent) actions, that is, deciding for
itself and figuring out what needs to be done to satisfy its
design objectives [5]. A multiagent system consists of a
number of agents, which interact with one another [5]. To
successfully interact, agents require the ability to cooperate,
coordinate, and negotiate with each other. Cooperation is
the process when several agents work together and draw
on the broad collection of their knowledge and capabilities
to achieve a common goal. Coordination is the process of
achieving the state in which actions of agents fit in well with
each other. Negotiation is a process by which a group of
agents communicate with one another to try to come to a
mutually acceptable agreement on some matter.
1.3 Agent-Based Cloud Computing
Some of the essential characteristics of cloud computing
include resource pooling and resource sharing. In clouds,
computing resources are pooled to serve multiple consu-
mers, and applications and data are available to and shared
by a broad group of cross-enterprise and cross-platform
users. Resource pooling and sharing involve 1) combining
resources through cooperation among cloud providers,
2) mapping, scheduling, and coordination of sha red
resources, and 3 ) establishment of contracts between
providers and consumers. In agent-based cloud computing,
cooperation, negotiation , and coordination protocols of
agents are adopted to automate the activities of resource
pooling and sharing in clouds.
Supporting autonomous resource mapping and dealing
with changing requests accentuate the need for cloud
resource management systems that are capable of continu-
ously managing the resource reservation process by
monitoring current service requests, amending future
service requests, and autonomously adjusting schedules
and prices to accommodate dynamically changing resource
demands [3]. Sim [4] proposed that software agents are
564 IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 5, NO. 4, OCTOBER-DECEMBER 2012
. The author is with the School of Computing, The University of Kent,
Chatham Maritime, Kent, ME4 4AG, United Kingdom.
E-mail: prof_sim_2002@yahoo.com.
Manuscript received 1 Dec. 2010; revised 4 July 2011; accepted 25 Aug. 2011;
published online 10 Oct. 2011.
For information on obtaining reprints of this article, please send e-mail to:
tsc@computer.org and reference IEEECS Log Number TSCSI-2010-12-0154.
Digital Object Identifier no. 10.1109/TSC.2011.52.
1939-1374/12/$31.00 ß 2012 IEEE Published by the IEEE Computer Society

appropriate tools for autonomously managing cloud re-
sources. Whereas consumers need to make decisions to
select suitable providers and negotiate with providers to
achieve “ideal” service contracts, providers need to make
decisions for selecting appropriate requests to accept and
execute depending on the availability of resources, both
current and future demands for services, and existing
service obligations. Since agents are capable of making
decisions when carrying out tasks on behalf of their users,
and interacting with other agents through negotiation,
cooperation, and coordination, all the above-mentioned
challenges provide the motivations for adopting autono-
mous agents to allocate resources amid dynamically
changing resource demands.
Agent-based cloud computing is concerned with the
design and development of software agents for bolstering
cloud service discovery, service negotiation, and service
composition [4], [6], [7], [8]. Appendix 1, which can be
found on the Computer Society Digital Library at http://
doi.ieeecomputersociety.org/10.1109/TSC.2011.52, shows
an overview of applying agent-based approaches to build-
ing software tools and testbeds for some of the phases of a
cloud service life cycle. A cloud service life cycle [9] consists
of: service requirements, service discovery, service negotia-
tion, service composition, and service consumption. In the
service requirements phase, consumers detail the functional
requirements (functions and tasks that a service should
provide), technical requirements (e.g., hardware and oper-
ating systems), and budgetary requirements (acceptable
service cost). The service discovery phase consists of
searching for cloud services that match consumers’ func-
tional, technical, and budgetary requirements. The service
negotiation phase consists of message exchanges between
consumers and brokers, and between brokers and providers
for establishments of service-level a greements. In the
service composition phase, a broker combines a set of
services from multiple providers, and delivers the com-
bined service as a single virtualized service to a consumer.
In the service consumption phase, the service is delivered to
the consumer.
The contributions of this work are:
1. introducing an agent-based paradigm for designing
software tools and testbeds for managing cloud
resources,
2. designing and developing Cloudle—an agent-
based search engine for supporting cloud service
discovery,
3. showing that negotiation protocols in multiagent
systems can be effectively adopted for bolstering
cloud service negotiation and cloud commerce, and
4. showing that cooperative problem-solving para-
digms in multiagent systems can be effectively
adopted for automating cloud service composition.
1.4 Agent-Based Cloud Search Engine
The challenge in the service discovery phase is to run a
query against the cloud services registered in the search
engine’s database by matching consumers’ functional,
technical, and budgetary requirements. When building a
general search engine (e.g., Google), one only needs to
consider the issue of searching for webpages that contain
concepts in a user’s query. The problem of building a search
engine for cloud services is more complex because one needs
to search for services that satisfy three types of require-
ments. The search engine in this work employs a service
discovery agent (SDA) that consults a cloud ontology for
determining the similarities between providers’ functional
and technical specifications of services and consumers’
functional and technical requirements (Section 2).
1.5 Negotiation Agents and Agent-Based Cloud
Commerce
The challenge in cloud service negotiation is to establish
SLAs between consumers and brokers, and between brokers
and service providers. Whereas e-commerce negotiation
mechanisms involve two types of participants (buyers and
sellers) in only one market and participants are not allowed
to breach contracts, the problem of devising a complex
negotiation mechanism for cloud commerce is much more
complex because a complex cloud negotiation mechanism
specifies parallel negotiation activities among three types of
participants (consumers, brokers, and providers) in multiple
interrelated markets and participants are allowed to breach
contracts by paying penalty fees. This work devises a
complex cloud negotiation mechanism by using negotiation
strategies and protocols in multiagent systems [10], [11],
[12], [13], [14], [15], [16], [17], [18], [19], [20] as the basic
building blocks (Section 3).
1.6 Agent-Based Cloud Service Composition
The challenge in cloud service composition is to dynami-
cally put together a set of services provided by multiple
service providers to form a single unified service to be
delivered to a consumer. Various providers need to work
together and draw upon each other’s service capabilities. To
automate cloud service composition, this work adopts 1) a
focused selection contract net protocol (FSCNP) for dynamically
selecting cloud services and 2) service capability tables (SCTs)
to record the list of cloud agents and their services.
2CLOUD SEARCH ENGINE AND CLOUD CRAWLERS
Whereas preliminary ideas of Cloudle were reported in [23],
[24], [25], this work presents a new architecture of Cloudle
(Fig. 1) consisting of a service discovery agent,acloud
ontology,adatabase of cloud services , multiple cloud crawlers
(Section 2.3), and a web interface.
In the previous design [23], [24], [25], Cloudle relied solely
on cloud service providers to register their services in the
database of cloud services. In the new Cloudle architecture,
in addition to allowing service providers to register their
services in Cloudle’s database, cloud crawlers are also used
to build and maintain Cloudle’s database (Section 2.3)—this
is a novel feature that enhances the previous architecture of
Cloudle reported in [23], [24], [25].
Consumers enter their queries for cloud services using
Cloudle’s web interface (Appendices 2 and 3, available in the
online supplemental material). The inputs to Cloudle consist
of a consumer’s functional, technical, and budgetary require-
ments for a cloud service. The SDA has four submodules:
1. a query processor,
2. a service reasoning module,
3. a price and time slot matching module, and
4. a service rating module.
SIM: AGENT-BASED CLOUD COMPUTING 565

Using the query processor, the SDA extracts essential
keywords such as cloud concepts and the price and
schedule specifications from consumers’ queries.
The SDA consults a cloud ontology (Appendix 4,
available in the online supplemental material) to reason
about the similarity between a consumer’s functional and
technical requirements and providers’ functional and tech-
nical specifications of services. A cloud ontology consists of a
set of cloud computing concepts and the interrelationships
among cloud concepts to facilitate the reasoning about
cloud services. In this work, the cloud ontology consists of
over 400 concepts. At the top level of the cloud ontology
[26], cloud services are generally classified into
1. Infrastructure as a service (IaaS) which provides
computational resources (e.g., Amazon’s EC2 pro-
vides VMs),
2. Data as a service (DaaS) which allows users to store
data at remote disks (e.g., Amazon’s S3),
3. Software as a service (SaaS) which delivers special-
purpose software, remotely accessed via the Internet
(e.g., Salesforce’s CRM),
4. Platform as a service (PaaS) that supplies cloud
developers with programming-level environments
(e.g., Google App Engine provides a python runtime
environment and API for applications to interact
with Google’s cloud runtime environment), and
5. Communication as a service (CaaS) that provides
dedicated bandwidth, network security, encryption,
and network monitoring.
Using the cloud ontology, the SDA carries out: 1) similarity
reasoning, 2) compatibility reasoning, and 3) numerical
reasoning (Section 2.1). Additionally, using the price and
time slot module, the SDA determines the level of matching
between the price and sched ule constraints of both
consumers and providers (Section 2.2). Using the service
rating module, the service provided by each provider is
rated according to the similarity between the functional and
techni cal specifications of both the consumer and the
provider. The output consists of a list of cloud services
ordered in terms of the matching similarities between the
functional, technical, and budgetary constraints specified by
the consumer and service providers (Appendix 5, available
in the online supplemental material).
2.1 Service Reasoning
Given that Cloudle needs to satisfy three types of require-
ments: 1) functional, 2) technical, and 3) budgetary, some-
times, it may be difficult to find services that will exactly
match these three types of requirements.
Similarity reasoning is designed to increase the chance of
finding relevant alternatives of a service. For instance, if an
exact matching service is beyond a consumer’s price range,
other simi lar services within the price range may be
suggested. An intuitive way to determine the degree of
similarity between two concepts x and y is to determine
how much x and y share in common. In similarity
reasoning, the SDA determines the similarity between x
and y by counting their common reachable nodes. Let ðxÞ
(respectively, ðyÞ) be the set of nodes upwards reachable
from x (respectively, y) including x (respectively, y) itself.
For example, in the graph of general ontology (Fig. 2),
ðxÞ¼4 and ðyÞ¼3. Let ðxÞ\ðyÞ be the number of
reachable nodes shared by x and y. ðxÞ\ðyÞ is a measure
of the common featur es between x and y. In Fig. 2,
ðxÞ\ðyÞ¼2. There are several ways to define a function
for determining the degree of similarity between x and y
[27]. One way to measure the degree of similarity between x
and y is to measure the number of common features
between x and
y from the perspective of x as follows:
simðx; yÞ¼
ðxÞ\ðyÞ
ðxÞ
:
Another way is to measure the number of common features
between x and y from the perspective of y as follows:
simðy; xÞ¼
ðxÞ\ðyÞ
ðyÞ
:
In Fig. 2, simðx; yÞ¼2=4 and simðy; xÞ¼2=3, which are
different because simðy; xÞ > simðx; yÞ. To take both mea-
sure methods into consideration, a generalized similarity
function for x and y can be defined by taking the weighted
average of both measure methods as follows:
simðx; yÞ¼
ðxÞ\ðyÞ
ðxÞ
þð1 Þ
ðxÞ\ðyÞ
ðyÞ
; ð1Þ
566 IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 5, NO. 4, OCTOBER-DECEMBER 2012
Fig. 1. The Cloudle architecture.
Fig. 2. A simple general ontology.

where 0; 1. An example is given in Appendix 6,
available in the online supplemental material. In Appen-
dix 6, is set to 0.5 so that both measure methods are given
equal consideration. simðx; yÞ¼0 means that x is totally
not similar to y, and simðx; yÞ¼1 means that x is fully
similar to y.
Compatibility reasoning is designed to compare two
sibling nodes in a cloud ontology, e.g., determining the
compatibility between two different versions of a software.
The rationale for devising compatibility reasoning is
because using similarity reasoning, the SDA cannot distin-
guish between two different versions of a software concept.
For example, in the partial Windows ontology in Fig. 3,
ðWindows98Þ¼ðWindowsV istaÞ¼ðWindows7Þ¼2;
ðWindows98Þ\ðWindowsV ista Þ
¼ ðW indows98Þ\ðWindows7Þ
¼ ðW indowsV istaÞ\ðW indows7Þ¼1;
and simðW indows98; W indowsV ista Þ
¼ simðW indows98
; Windows7Þ
¼ simðW indowsV ista; W indows7Þ¼1=2:
Hence, using similarity reasoning, the SDA cannot reason
about the differences among sibling concepts.
Since two sibling nodes representing two different
versions of a software will have a high degree of similarity,
but differ only in terms of their chronological ordering, the
function for measuring the compatibility of two concepts x
and y consists of: 1) measuring the degree of similarity
between x and y, and 2) differentiating between x and y in
terms of their chronological ordering as follows:
compatðx; yÞ¼simðx; yÞþ
ð
jc
x
c
y
j
Þ
; ð2Þ
where c
x
and c
y
are the label values of x and y respectively,
and sim(x,y) is defined in (1). c
x
and c
y
represent the
chronological orderings of different versions of a software.
In (2), sim(x,y) is a coarse-grain measurement because x and
y being different versions of a software will have a high
degree of similarity and ð
jc
x
c
y
j
Þ= is a fine-grain measure-
ment because x and y will have a small degree of difference.
It is also intuitive to think that the degree of difference will
depend on the chronological ordering. For instance,
compared to WindowsVista, Windows95 will have less
features compatible with Windows7. In the previous design
of Cloudle [23], [24], [25], the compatibility function was
defined as follows:
compatðx; yÞ¼simðx; yÞþ
ð0:8
jc
x
c
y
j
Þ
10
: ð3Þ
Equation (2) in this work generalizes (3) in [23], [24], [25].
This is because one can set different values for 0 <<1
and 1 <1. The most essential component in ð
jc
x
c
y
j
Þ=
is the term jc
x
c
y
j. When jc
x
c
y
j is large (respectively,
small), x and y are less (respectively, more) compatible. An
example is given in Appendix 7, available in the online
supplemental material. In Appendix 7, and are set to 0.8
and 10, respectively.
In numerical reasoning, the SDA reasons about the
similarity between two numeric concepts (e.g., CPU speed
and memory size) relative to the maximum and minimum
values as follows:
Simða; b; cÞ¼1
a b
Max
c
Min
c
; ð4Þ
where a and b are numeric values and c is a concept. An
example is given in Appendix 8, available in the online
supplemental material.
2.2 Price and Time Slot Matching
In matching price and time slot, the SDA attempts to search
for providers with cloud services that have available time
slots that match the specified time slots of consumers and with
small price difference between the acceptable prices of the
provider and consumer. A utility function UU is used to
evaluate the level of matching for each potential match M
k
between the respective prices and schedules of a consumer
and a provider. The utility of M
k
is given as follows:
UðM
k
Þ¼w
P
U
P
P
prov
min
þ w
T
U
T
T
prov
S
;
where w
P
and w
T
are a consumer’s preference for more
matching service prices and more matching time slots,
respectively, and w
P
þ w
T
¼ 1. U
P
ðP
prov
min
Þ is a consumer’s
price utility defined as follows:
U
P
P
prov
min
¼
P
cons
max
P
prov
min
=P
cons
max
;
where P
cons
max
is the maximum acceptable price for a
consumer, and P
prov
min
is the minimum acceptable price for a
provider. U
P
ðP
prov
min
Þ!0 if P
prov
min
! P
cons
max
since there will be
little or no room for negotiation of price. U
P
ðP
prov
min
Þ!1 if
P
prov
min
! 0 since there will be plenty of room for negotiation.
U
T
ðT
prov
S
Þ is a consumer’s time slot utility defined as follows:
U
T
T
prov
S
¼
T
cons
S
\ T
prov
S
=T
cons
S
;
where T
cons
S
is the range of possible time slots that the
consumer expects to reserve a time slot to utilize a service,
and T
prov
S
is the range of time slots that a service is available.
It is assumed that T
cons
S
is greater than the actual time slot
(end time start time) that a consumer will utilize a service.
U
T
ðT
prov
S
Þ!1 (respectively, U
T
ðT
prov
S
Þ!0)ifthereare
more (respectively, less) overlap between T
cons
S
and T
prov
S
.
2.3 Cloud Crawle rs
Many parallel threads of the cloud crawler are deployed to
gather information about cloud service providers. The
architecture of a cloud crawler is shown in Fig. 4.
It consists of a crawling agent, a URL filter softbot
(a software agent), and a database agent. The crawling agent
traverses the WWW to extract webpages that are relevant to
cloud computing services. Starting from a root URL that is
predefined by a user, the crawler agent traverses websites
by following hyperlinks. As the crawling agent visits a
SIM: AGENT-BASED CLOUD COMPUTING 567
Fig. 3. A partial Windows ontology.

Citations
More filters
01 Jan 2003

3,093 citations

Journal ArticleDOI
TL;DR: This survey provides a comprehensive discussion of all aspects of MAS, starting from definitions, features, applications, challenges, and communications to evaluation, and a classification on MAS applications and challenges is provided.
Abstract: Multi-agent systems (MASs) have received tremendous attention from scholars in different disciplines, including computer science and civil engineering, as a means to solve complex problems by subdividing them into smaller tasks. The individual tasks are allocated to autonomous entities, known as agents. Each agent decides on a proper action to solve the task using multiple inputs, e.g., history of actions, interactions with its neighboring agents, and its goal. The MAS has found multiple applications, including modeling complex systems, smart grids, and computer networks. Despite their wide applicability, there are still a number of challenges faced by MAS, including coordination between agents, security, and task allocation. This survey provides a comprehensive discussion of all aspects of MAS, starting from definitions, features, applications, challenges, and communications to evaluation. A classification on MAS applications and challenges is provided along with references for further studies. We expect this paper to serve as an insightful and comprehensive resource on the MAS for researchers and practitioners in the area.

290 citations


Cites background from "Agent-Based Cloud Computing"

  • ...A complete survey of MAS applications in the cloud can be found in [56]....

    [...]

Journal ArticleDOI
TL;DR: This paper study the literature on the task scheduling and load-balancing algorithms and present a new classification of such algorithms, for example, Hadoop MapReduce load balancing category, Natural Phenomena-based load balancing categories, Agent-basedLoadBalancing category, General load balancingcategory, application-oriented category, network-aware category, and workflow specific category.

277 citations

Journal ArticleDOI
TL;DR: The cutting-edge research efforts on service migration in MEC are reviewed, a devisal of taxonomy based on various research directions for efficient service migration is presented, and a summary of three technologies for hosting services on edge servers, i.e., virtual machine, container, and agent are provided.
Abstract: Mobile edge computing (MEC) provides a promising approach to significantly reduce network operational cost and improve quality of service (QoS) of mobile users by pushing computation resources to the network edges, and enables a scalable Internet of Things (IoT) architecture for time-sensitive applications (e-healthcare, real-time monitoring, and so on.). However, the mobility of mobile users and the limited coverage of edge servers can result in significant network performance degradation, dramatic drop in QoS, and even interruption of ongoing edge services; therefore, it is difficult to ensure service continuity. Service migration has great potential to address the issues, which decides when or where these services are migrated following user mobility and the changes of demand. In this paper, two conceptions similar to service migration, i.e., live migration for data centers and handover in cellular networks, are first discussed. Next, the cutting-edge research efforts on service migration in MEC are reviewed, and a devisal of taxonomy based on various research directions for efficient service migration is presented. Subsequently, a summary of three technologies for hosting services on edge servers, i.e., virtual machine, container, and agent, is provided. At last, open research challenges in service migration are identified and discussed.

264 citations


Cites background from "Agent-Based Cloud Computing"

  • ...In computer science, an agent is a computer program block that performs tasks in a relationship of agency with other entities [82], [83]....

    [...]

Journal ArticleDOI
TL;DR: To improve the efficiency of big data feature learning, the paper proposes a privacy preserving deep computation model by offloading the expensive operations to the cloud by using the BGV encryption scheme and employing cloud servers to perform the high-order back-propagation algorithm on the encrypted data efficiently forDeep computation model training.
Abstract: To improve the efficiency of big data feature learning, the paper proposes a privacy preserving deep computation model by offloading the expensive operations to the cloud. Privacy concerns become evident because there are a large number of private data by various applications in the smart city, such as sensitive data of governments or proprietary information of enterprises. To protect the private data, the proposed model uses the BGV encryption scheme to encrypt the private data and employs cloud servers to perform the high-order back-propagation algorithm on the encrypted data efficiently for deep computation model training. Furthermore, the proposed scheme approximates the Sigmoid function as a polynomial function to support the secure computation of the activation function with the BGV encryption. In our scheme, only the encryption operations and the decryption operations are performed by the client while all the computation tasks are performed on the cloud. Experimental results show that our scheme is improved by approximately 2.5 times in the training efficiency compared to the conventional deep computation model without disclosing the private data using the cloud computing including ten nodes. More importantly, our scheme is highly scalable by employing more cloud servers, which is particularly suitable for big data.

245 citations


Cites background from "Agent-Based Cloud Computing"

  • ...been successfully applied in industrial products and commercial fields that take advantage of big data [13], [14]....

    [...]

References
More filters
Journal ArticleDOI
TL;DR: This paper defines Cloud computing and provides the architecture for creating Clouds with market-oriented resource allocation by leveraging technologies such as Virtual Machines (VMs), and provides insights on market-based resource management strategies that encompass both customer-driven service management and computational risk management to sustain Service Level Agreement (SLA) oriented resource allocation.

5,850 citations


"Agent-Based Cloud Computing" refers background in this paper

  • ...It was noted in [3] that a market-oriented approach for managing cloud...

    [...]

  • ...In cloud computing platforms, resources need to be dynamically (re)configured and aggregated via virtualization [3] and consumers’ requirements can potentially vary over time and amendments need to be accommodated....

    [...]

  • ...To date, even though service providers have inflexible pricing for cloud resources, it is envisioned that a market infrastructure described in [3] will enable variable cloud service pricing based on market conditions....

    [...]

  • ...Supporting autonomous resource mapping and dealing with changing requests accentuate the need for cloud resource management systems that are capable of continuously managing the resource reservation process by monitoring current service requests, amending future service requests, and autonomously adjusting schedules and prices to accommodate dynamically changing resource demands [3]....

    [...]

  • ...A market model for trading cloud resources described in [3] consists of resource/service providers, consumers, and brokers....

    [...]

Journal ArticleDOI
TL;DR: In this paper, a study which examined perfect equilibrium in a bargaining model was presented, focusing on a strategic approach adopted for the study and details of the bargaining situation used; discussion on perfect equilibrium.
Abstract: Focuses on a study which examined perfect equilibrium in a bargaining model. Overview of the strategic approach adopted for the study; Details of the bargaining situation used; Discussion on perfect equilibrium. (From Ebsco)

5,139 citations


"Agent-Based Cloud Computing" refers background in this paper

  • ...Adopting Rubinstein’s alternating offers protocol [29], a pair of consumer and broker agents negotiates by making proposals in alternate rounds....

    [...]

Journal ArticleDOI
TL;DR: In this article, the contract net protocol has been developed to specify problem-solving communication and control for nodes in a distributed problem solver, where task distribution is affected by a negotiation process, a discussion carried on between nodes with tasks to be executed and nodes that may be able to execute those tasks.
Abstract: The contract net protocol has been developed to specify problem-solving communication and control for nodes in a distributed problem solver. Task distribution is affected by a negotiation process, a discussion carried on between nodes with tasks to be executed and nodes that may be able to execute those tasks.

3,612 citations

Proceedings ArticleDOI
01 Nov 2008
TL;DR: In this article, the authors compare and contrast cloud computing with grid computing from various angles and give insights into the essential characteristics of both the two technologies, and compare the advantages of grid computing and cloud computing.
Abstract: Cloud computing has become another buzzword after Web 2.0. However, there are dozens of different definitions for cloud computing and there seems to be no consensus on what a cloud is. On the other hand, cloud computing is not a completely new concept; it has intricate connection to the relatively new but thirteen-year established grid computing paradigm, and other relevant technologies such as utility computing, cluster computing, and distributed systems in general. This paper strives to compare and contrast cloud computing with grid computing from various angles and give insights into the essential characteristics of both.

3,132 citations

01 Jan 2003

3,093 citations


"Agent-Based Cloud Computing" refers methods in this paper

  • ...Integrating results and dealing with failures....

    [...]

  • ...Software as a service (SaaS) which delivers special- purpose software, remotely accessed via the Internet (e.g., Salesforce’s CRM), 4....

    [...]

  • ...The applications and data served by the cloud are accessed via the Internet by a broad group of users across multiple enterprises and platforms....

    [...]

Frequently Asked Questions (11)
Q1. What have the authors contributed in "Agent-based cloud computing" ?

The significance of this work is introducing an agent-based paradigm for constructing software tools and testbeds for cloud resource management. The novel contributions of this work include: 1 ) developing Cloudle: an agent-based search engine for cloud service discovery, 2 ) showing that agent-based negotiation mechanisms can be effectively adopted for bolstering cloud service negotiation and cloud commerce, and 3 ) showing that agent-based cooperative problemsolving techniques can be effectively adopted for automating cloud service composition. Cloudle consists of 1 ) a service discovery agent that consults a cloud ontology for determining the similarities between providers ’ service specifications and consumers ’ service requirements, and 2 ) multiple cloud crawlers for building its database of services. To support cloud commerce, this work devised a complex cloud negotiation mechanism that supports parallel negotiation activities in interrelated markets: a cloud service market between consumer agents and broker agents, and multiple cloud resource markets between broker agents and provider agents. To automate cloud service composition, agents in this work adopt a focused selection contract net protocol ( FSCNP ) for dynamically selecting cloud services and use service capability tables ( SCTs ) to record the list of cloud agents and their services. 

An analysis on the number of messages exchanged among agents in FSCNP was also carried out to study the worst case. Some of the future work and challenges are given as follows: 1. In its present form, the cloud negotiation mechanism reported in Section 3 only considers negotiation of resource pricing but does not consider negotiation of other issues such as QoS and time slot negotiation. 2. Given that cloud services can be dynamically removed or added, creating and maintaining the SCTs of cloud agents can be a difficult problem. 3. A more sophisticated service selection mechanism may be needed to deal with changing consumers ’ requirements. 

The contributions of this work are:1. introducing an agent-based paradigm for designing software tools and testbeds for managing cloud resources, 2. designing and developing Cloudle—an agentbased search engine for supporting cloud service discovery, 3. showing that negotiation protocols in multiagent systems can be effectively adopted for bolstering cloud service negotiation and cloud commerce, and 4. 

2. Given that cloud services can be dynamically removed or added, creating and maintaining the SCTs of cloud agents can be a difficult problem. 

The reasons for allowing decommitments are as follows: 1) if a broker agent cannot acquire ALL its required resources before its deadline, it can release those resources acquired so that providers can assign them to other broker agents, and 2) it allows a broker agent that has already reached an intermediate contract for a resource to continue to search for better deals before the entire concurrent negotiation terminates. 

The general idea in estimating the reneging probability of PAij is that if a broker agent reaches a tentative agreement with PAij at a price that is much lower (respectively, higher) than the average price of all provideragents, then there is a higher (respectively, lower) chance that PAij will renege on the contract. 

A cloud ontology consists of a set of cloud computing concepts and the interrelationships among cloud concepts to facilitate the reasoning about cloud services. 

If broker agents are making relatively larger (respectively, smaller) concessions, then it is likely that the consumer agent is in a relatively favorable (respectively, unfavorable) Bp. Similarly, the Bp of a broker agent can also be estimated by considering the concession patterns of each consumer agent. 

An example to analyze the number of messages sent by a BA is as follows (due to space limitation, the analyses of other agents, e.g., SPAs and RAs will not be given here). 

These experiments are designed to evaluate the agents’ abilities to interact among themselves for autonomous (re)configuration and reselection of cloud services in response to failure of the resources. 

In a cloud service market whereconsumers compete for computing services and brokerscompete to provide services, a market-oriented approachfor regulating the supply and demand of cloud services isappropriate.