Self-Organizing Agents for Service Composition in Cloud Computing

2nd IEEE International Conference on Cloud Computing Technology and Science

Self-Organizing Agents for Service Composition in Cloud Computing J. Octavio Gutierrez-Garcia and Kwang-Mong Sim Department of Information and Communications Gwangju Institute of Science and Technology Gwangju, Republic of Korea [email protected] & [email protected]

proved to be effective for distributed applications where no exact and complete system snapshot can be determined given the inherent dynamicity of the environment. In addition, agents can collaborate to achieve shared objectives, even when selfinterest behaviors to maximize utility are adopted, for example, fixing service fees according to an individual strategy.

Abstract— In Cloud service composition, collaboration between brokers and service providers is essential to promptly satisfy incoming Cloud consumer requirements. These requirements should be mapped to Cloud resources, which are accessed via web services, in an automated manner. However, distributed and constantly changing Cloud-computing environments pose new challenges to automated service composition such as: (i) dynamically contracting service providers, which set service fees on a supply-and-demand basis, and (ii) dealing with incomplete information regarding Cloud resources (e.g., location and providers). To address these issues, in this work, an agent-based Cloud service composition approach is presented. Cloud participants and resources are implemented and instantiated by agents. These agents sustain a three-layered self-organizing multi-agent system that establishes a Cloud service composition framework and an experimental test bed. The self-organizing agents make use of acquaintance networks and the contract net protocol to evolve and adapt Cloud service compositions. The experimental results indicate that service composition is efficiently achieved despite dealing with incomplete information as well as coping with dynamic service fees.

The idea of adopting software agents for managing Cloud services was first introduced in [9, 10]. Whereas [9, 10] are the earliest efforts in designing and constructing negotiation agents for supporting the establishment of service-level agreements among Cloud participants, this present research is the earliest effort, to the best of the authors’ knowledge, that introduces a self-organizing agent-based approach for dealing with Cloud service composition. Self-organizing systems are composed of interacting individuals (e.g., agents) [8]. The interaction among individuals adapts and evolves the system to achieve an objective (e.g., Cloud service composition). The constitution and objective of the system emerge from the interaction of its members [5]. The emergent constitution is determined by the feedback (e.g., service fees) obtained through the free interaction of nearby members. Thus, each member determines the partners to be linked to, by using local rules. Events in the system (e.g., a Cloud consumer submitting requirements) produce changes that are initially managed by directly connected members (e.g., brokers), which replicate the new constitution of the system to indirectly connected members (e.g., service providers).

Keywords- Agent-based Cloud computing; Cloud computing; multi-agent systems; web service composition

I.

INTRODUCTION

Cloud services, which are deployed as self-contained components, are normally partial solutions that must be composed to provide a single virtualized service to Cloud consumers. This composition of services should be carried out in a dynamic and automated manner to promptly satisfy consumer requirements.

In this paper, a self-organizing agent-based service composition framework is presented. Each Cloud participant and Cloud resource is represented and instantiated by an agent. The self-organizing service composition is supported by two well-known agent-based cooperative problem solving techniques: (i) Acquaintance networks [7] (list of known agents and its capabilities) used for dealing with incomplete information about the location of distributed Cloud participants and resources. (ii) The contract net protocol (CNP) [11] used for dynamically selecting services based on service fees.

Cloud participants (e.g., consumers, brokers and service providers) may have incomplete knowledge of all possible Cloud resources and even other participants, due to the constantly changing Cloud environments and their distributed nature, e.g., multi-Cloud schemes. Furthermore, an efficient Cloud service composition method should dynamically select the most appropriate services (e.g., the cheapest services) to create a composite solution. This is because service providers charge a fee for providing a service, and these service fees may change over time, based on supply and demand, e.g., spot instances of Amazon EC2 [1]. Previous Cloud service composition approaches [12, 13] omit these new requirements. In this regard, this present study proposes a Cloud service composition solution based on the agent paradigm, which has 978-0-7695-4302-4/10 $26.00 © 2010 IEEE DOI 10.1109/CloudCom.2010.10

The novel features of this work in Cloud service composition are: 1) Designing a distributed Cloud service composition framework (Section II);

59

Figure 2. Service ontology.

B. Resource Agents A resource agent (RA) manages a web service, i.e., a RA is a service wrapper that handles the orchestration of a web service. A RA accepts requests from service providers or other RAs to fulfill a requirement and transmits its corresponding output to the requester, either a service provider or a RA. RAs accept requests from RAs to promote the choreography of their services (see Section II.C for further details). C. Service Provider Agents A service provider agent (SPA) administers a set of RAs. In this regard, a SPA can be seen as the owner of a virtual organization, wherein some RAs are registered as members. SPAs are described by the union of all the requirements that their RAs fulfill. The main function of SPAs is to delegate requirements to RAs. Moreover, SPAs play the role of Cloud vendors, providing and encapsulating Cloud resources as well as setting fees for their consumption.

Figure 1. Multi-agent system architecture.

2) Applying agent-based approaches to Cloud computing: acquaintance networks (Section III) to cope with partial information of Cloud-computing environments, and the contract net protocol to dynamically select services (Section IV); 3) Designing and implementing self-organizing agent protocols into an agent-based test bed (Section V), in addition to conducting experiments (Section VI) to evaluate the efficiency and self-organizing capabilities of the agent-based solution to Cloud service composition.

SPAs provide common and collaborative contexts to RAs, i.e., RAs managed by the same service provider are teammates that share a common set of objectives. This allows RAs to delegate tasks among each other, promoting the choreography of the web services contained in the SPA. For example, a computing service provider may contain RAs in charge of dividing big tasks into smaller ones that are delegated to RAs in charge of processing tasks.

Section VII compares this work with related work, and Section VIII presents the conclusion and future work. II.

A DISTRIBUTED CLOUD SERVICE COMPOSITION FRAMEWORK

A SPA may interact with other SPAs when necessary. In the process of fulfilling a requirement, a RA may need an additional requirement, which cannot be satisfied by the current siblings (RAs contained in the same SPA). Then, the RA delegates the requirement to its SPA. In turn, the SPA contacts another SPA to satisfy such requirement. This can be seen as an external interface to collaborate with other SPAs. In doing this, the specialization of SPAs is supported, and whenever some uncommon, but contemplated situations occur, SPAs may collaborate among each other. For instance, a computing service provider may need additional space to store an uncommon large amount of results derived from processing tasks. In this case, a RA may ask for additional storage space, delegating the requirement to its computing SPA that should search for and collaborate with a storage SPA to fulfill it.

The agent-based architecture for supporting Cloud service composition (Fig. 1) consists of web services, resource agents, service provider agents, broker agents and consumer agents. A. Web Services A web service (WS) is an interface to a software application or to a resource (e.g., database, storage space, etc.) that are remotely accessible. The description of a web service is based on the service ontology depicted in Fig. 2. The functionality of a web service is described by a requirement that the service fulfills, e.g., reserving CPU time. The parameters of the requirement become the input of the web service, e.g., type of CPU, initial time, duration, etc. The output consists of a set of parameters of which the values are obtained as a result of fulfilling the requirement, e.g., initial time, final time, and CPU identifier. Finally, the location of the service is expressed as an URI address.

D. Broker Agents A broker agent (BA) is the mediator between Cloud consumers and SPAs, its functions are: providing estimated

60

II.C; and (ii) to overcome major failures within its RAs’ network.

quotations to Cloud consumers for a given set of requirements, and then, if the quotation is accepted, contracting service providers to fulfill the requirements.

The acquaintance network of RAs is used to delegate requirements to the appropriate RAs.

E. Consumer Agents A consumer agent (CA) represents a Cloud consumer, and its functions are: (i) formalizing consumer requirements by making use of the service ontology, (ii) decomposing consumer requirements into atomic requirements, (iii) contacting and contracting one or more BAs to carry out the service composition, and (iv) combining BAs’ outputs into a single virtualized service. III.

D. Resource Agents’ Acquaintance Network A RA has an acquaintance network of sibling RAs, i.e., RAs managed by the same service provider; each record of the acquaintance network contains the location of the RA and the requirement that fulfills. Whenever RAs are unable to fulfill a previously delegated requirement, given a failure, these can delegate the task to a sibling agent. However, in this case, no service fee is necessary, given that RAs are assumed to be part of the same service provider, and therefore they share the same objectives.

ACQUAINTANCE NETWORKS

An acquaintance network of an agent is a list of contacts (other agents) that (i) have been previously contracted by the agent or (ii) the agent is aware of their existence. A node of an acquaintance network contains the address of a known agent and a list of its capabilities.

IV.

THE CONTRACT NET PROTOCOL

All the agents adopt the well-known contract net protocol [11] for selecting and (sub) contracting resource needs to resolve consumer requirements.

Due to the distributed nature of multi-Cloud environments, acquaintance networks are assumed to be incomplete, i.e., only a set of “visible” agents are listed, e.g., agents that may be in the same Cloud.

Agents in the contract net protocol have two roles: initiator and participant. The initiator sends a call-for-proposals to resolve a probably set of requirements to n participants. In turn, these may reply with a proposal that include the price for fulfilling the requirements. The initiator evaluates the received proposals and selects the best proposal, e.g., the cheapest proposal. Afterwards, the initiator sends a reject-proposal message to the agents that are not selected, and an acceptproposal message to the selected agent to delegate the task.

A. Consumer Agents’ Acquaintance Network Consumer agents have an acquaintance network of BAs. However, in this case, the capabilities of BAs are omitted, given that BAs may accept proposals for achieving any set of requirements. In doing this, CAs focus on submitting requirements and selecting the better (cheaper) proposal to resolve them. Whereas BAs focus on resolving consumer requirements by (sub) contracting SPAs or other BAs, which may not be visible to the CA.

In the case of RAs, when they adopt the contract net protocol for delegating tasks among its sibling RAs, the proposals have two possible values {busy, available}. From the available repliers, one of them is randomly selected and an imposed delegation of the task is carried out (see Section V.D for further details).

B. Broker Agents’ Acquaintance Networks A BA has two acquaintance networks: (i) a network of other BAs with their location; and (ii) a network of SPAs with their location and corresponding capabilities.

V.

AGENT BEHAVIORS

An agent behavior comprises the rules that define the reaction of agents to events, e.g., reception of a call-forproposals message. For each type of agent that represents a Cloud participant, a set of behaviors is defined. These behaviors are designed to run in parallel and concurrently.

A BA may accept a job without being certain whether it can contact or hire adequate service providers to satisfy the set of requirements. Therefore, a BA may subcontract another BA for delegating previously acquired requirements. This is carried out when the SPAs contained in its acquaintance network cannot fulfill the requirements.

A. Consumer Agent Behaviors The main behavior of a CA is derived from the contractnet-protocol initiator behavior that submits consumer requirements to BAs. This behavior includes the decomposition of consumer requirements and the integration of BAs’ outputs. Consumer requirements are decomposed (line 1 of CNP_consumer_initiator behavior) by means of mapping consumer needs to a set of atomic requirements that represent instances of Cloud resources, such as spot instances [1]. For instance, in the context of infrastructure-as-a-service scenarios, a high performance computing application may require n cluster instances that are mapped to n requirements.

C. Service Provider Agents’ Acquaintance Networks A SPA has two acquaintance networks: (i) a network of other SPAs; and (ii) a network of RAs linked to it. Both acquaintance networks contain the location of agents and their corresponding capabilities. The capabilities of service providers are expressed as the sum of all the capabilities of the RAs that are linked to them. A SPA may use the network of SPAs: (i) to provide support to interleaving choreographies among SPAs, motivated by RAs delegating requirements to SPAs, as it was explained in Section

61

CNP_consumer_initiator behavior

Request_evaluator behavior

Input: (i) Consumer requirements Output: (i) A single virtualized service

Input: (i) Requirement Reqi Output: (i) Instantiation of a CNP_broker_initiator(BAs) behavior or (ii) instantiation of a CNP_broker_initiator(SPAs) behavior or (iii) failure propagation

1: Decompose consumer requirements 2: for (i ← 1; i 0) then 6: Send reject_proposal to (nProposals-1) BAs 7: Send accept_proposal to 1 BA 8: BlockReceive(Reqi.Output) 9: else 10: Throw exception 11: Integrate outputs into a single virtualized service

1: Check_for_feasible_acquaintances(SPAs, Reqi) 2: if (nFeasibleSPAs > 0) then 3: Instantiate a CNP_broker_initiator(SPAs, Reqi) behavior 4: else 5: Check_for_feasible_acquaintances(BAs) 6: if (nFeasibleBAs > 0) then 7: Instantiate a CNP_broker_initiator(BAs, Reqi) behavior 8: Else 9: Send failure message to requester

B. Broker Agent Behaviors The set of behaviors of BAs supports the first layer of selforganization. A BA has four behaviors:

The Check_for_feasible_acquaintances() function (line 1 and 5 of Request_evaluator behavior) returns feasible contractors for a given requirement. A contractor is feasible if (i) it has the required capabilities to fulfill the requirement, and (ii) the contractor has no record of being failed in the fulfillment of the requirement.

1) The CNP_broker_participant behavior handles call for proposals to fulfill requirements coming from CAs or other BAs when subcontracting is required. For simulation purposes (see Section VI), participants’ proposals contain service fees, which are computed randomly. More complex proposals can be considered, e.g., a service fee plus time to complete the job. In addition, service fees may be computed based on utility functions. However, these aspects are out of the scope of this paper.

3) The CNP_broker_initiator behavior submits requirements to possible contractors, either BAs or SPAs. CNP_broker_initiator behavior Input: (i) Contractors (BAs or SPAs) and (ii) Requirement Reqi Output: (i) Instantiation of a Result_handler behavior or (ii) failure propagation

CNP_broker_participant behavior

1: Check_for_feasible_acquaintances(Contractors) 2: if (nContractors > 0) then 3: The agent marks itself as visited for Reqi 4: Send call_for_proposals(Reqi) to m acquaintances(Contractors) 5: nProposals ← BlockReceive(Proposals, timeout) 6: if (nProposals > 0) then 7: Send reject_proposal to (nProposals-1) Contractors 8: Send accept_proposal to 1 Contractor 9: Instantiate a Result_handler(Reqi) behavior 10: else 11: if (Contractors = SPAs) then 12: Instantiate a CNP_broker_initiator(BAs, Reqi) behavior 13: else-if (Contractors = BAs) then 14: Send failure message to the original requester (CA or BA) 15: else 16: if (Contractors = SPAs) then 17: Instantiate a CNP_broker_initiator(BAs, Reqi) behavior 18: else-if (Contractors = BAs) then 19: Send failure message to the original requester (CA or BA)

Input: (i) call_for_proposals from CAs or other BAs Output: (i) Instantiation of a Request_evaluator behavior 1: BlockReceive(call_for_proposals(Reqi)) 2: if (not visitedFor(Reqi)) then 3: Prepare and Send Proposal 4: BlockReceive(reply, timeout) 5: if (reply = accept_proposal) then 6: Instantiate a Request_evaluator(Reqi) behavior 7: Else 8: Start over 9: else 10: Send refuse message 11: Start over

The visitedFor() function (line 2 of CNP_broker_participant behavior) verifies whether the agent has been previously subcontracted to resolve the requirement in the context of the same service composition. This avoids cyclic subcontracts, for instance, agent a subcontracts agent b, afterwards, agent b subcontracts agent c, in turn, agent c must not be able to subcontract agent a, even if there is an acquaintance relation between them. Therefore, an agent marks itself as visited for the requirement in question, whenever the agent delegates a requirement to other agent, further details are included in the BA’s CNP_broker_initiator behavior.

Line 3 of CNP_broker_initiator behavior marks the agent as visited for the requirement in question to avoid cyclic subcontracts. 4) The Result_handler behavior receives outputs from SPAs or other BAs regarding previously delegated requirements, and propagates the outputs to the original requesters either CAs or BAs. In case of receiving a failure message, the requirement is delegated to the remaining feasible SPAs.

2) The Request_evaluator behavior verifies whether the proposal can be resolved by contracting SPAs’ acquaintances or whether another BA must be subcontracted.

62

Result_handler behavior

CNP_resource_participant behavior

Input: (i) Outputs of requirements Output: (i) Result propagation or (ii) failure propagation

Input: (i) call_for_proposals from the SPA or sibling RAs Output: (i) Initiation of the Ad_hoc workflow behavior

1: BlockReceive(Result) 2: if (Result = Output) then 3: Send inform_result to its requester 4: else-if (Result = Failure) then 5: Add Result.sender to unfeasible agents 6: if (Result.Sender = BA) then 7: Send failure to the original requester 8: else-if (Result.Sender = SPA) then 9: Instantiate a CNP_broker_initiator(SPAs, Reqi) behavior

1: BlockReceive(call_for_proposals(Reqi)) 2: if (available and capableOf(Reqi)) then 3: Send a propose message to indicate availability 4: BlockReceive(reply, timeout) 5: if (reply = accept_proposal) then 6: Initiate the Ad_hoc workflow behavior 7: Else 8: Start over 9: else 10: Send refuse message 11: Start over

C. Service Provider Agent Behaviors The set of behaviors of SPAs supports the second layer of self-organization, and thus BA behaviors are basically reused. The difference is that SPAs delegate requirements to other SPAs and RAs, instead of BAs and SPAs as BAs do. Nonetheless, as explained in Section II.C, a SPA can receive requests from its RAs, and therefore, an additional behavior is required to listen RAs.

2) The Ad_hoc workflow behavior contains the workflow of the web service. The objective of this behavior is to fulfill a requirement and pass the result to either the SPA or a sibling RA. In addition, in case of error during the workflow, the requirement is delegated to feasible sibling RAs. Ad_hoc workflow behavior

Resource_agent_listener behavior

Input: (i) An ad-hoc workflow specification Output: (i) inform_results(Req.Ouput) or (ii) instantiation of a CNP_resource_initiator(RAs) behavior

Input: (i) Request to resolve Reqi Output: (i) Instantiation of a CNP_provider_initiator(SPAsi) behavior

1: try 2: Ad-hoc workflow specification 3: Send inform_results(Req.Ouput) to the SPA or sibling RAs 4: catch(exception) 5: Instantiate a CNP_resource_initiator(RAs) behavior

1: BlockReceive(Request(Reqi)) 2: Instantiate a CNP_provider_initiator(SPAs, Reqi) behavior 3: Start over

Furthermore, the delegation of requirements to RAs is done via the CNP_provider_initiator(RAs, Reqi) behavior. However, the proposals of RAs contain their availability, e.g., available or busy. Then, the SPA delegates the requirement to any of the feasible and available RAs. In doing this, avoids keeping a record of available resources, and allow RAs to delegate tasks among them, without notifying to the SPA (further details in Section V.D).

3) The CNP_resource_initiator behavior handles the imposed delegation of requirements to sibling RAs. RAs can impose the delegation of requirements to sibling RAs, given that RAs managed by the same SPA have a common objective. CNP_resource_initiator behavior

Although similar in implementation aspects, BAs and SPAs differ in their conceptual function, i.e., SPAs encapsulate sibling RAs and provide a collaborative context to promote the interaction of their RAs. In addition, a SPA keeps a complete record of its existing Cloud resources, whereas a BA keeps an incomplete record of the location of those resources, i.e., the location of SPAs.

Input: (i) Requirement Reqi Output: (i) Requirement delegation or (ii) failure propagation 1: Check_for_feasible_acquaintances(RAs, Reqi) 2: if (nRAs > 0) then 3: The agent marks itself as visited for Reqi 4: Send call_for_proposals(Reqi) to m acquaintances(RAs, Reqi) 5: nProposals ← BlockReceive(Proposals, timeout) 6: if (nProposals > 0) then 7: Send reject_proposal to (nProposals-1) sibling RAs 8: Send accept_proposal to 1 sibling RA 9: else 10: Send failure message to the SPA 11: else 12: Send failure message to the SPA

D. Resource Agent Behaviors The set of behaviors of RAs supports the third layer of selforganization. The behaviors of RAs are pattern behaviors that include self-organizing capabilities, but at the same time allow specifying an ad-hoc web service workflow. The workflow is assumed to be provided by a system designer. Five behaviors are defined for interacting with the SPA and sibling RAs.

4) The Internal_delegator behavior delegates a requirement to a specific sibling RA and waits for its resolution. This behavior should be instantiated in the ad-hoc workflow specification as needed.

1) The CNP_resource_participant behavior accepts new requests from the SPA or sibling RAs. A RA accepts a requirement, if it is available and capable of fulfilling the requirement (Line 2 of CNP_resource_participant behavior).

63

Internal_delegator behavior Input: (i) Requirement Reqi to be delegated, and (ii) sibling RA’s id Output: (i) Requirement delegation or (ii) failure propagation 1: 2: 3: 4: 5: 6: 7: 8:

Send call_for_proposals(Reqi) to a sibling RA Proposal ← BlockReceive(Proposal, timeout) if (Proposal = Available) then Send accept_proposal to the sibling RA BlockReceive(Result) Continue with the Ad_hoc workflow behavior else Throw exception

5) The External_delegator behavior delegates a requirement to the SPA and waits for its resolution. If a failure message is received, the Ad_hoc workflow behavior is halted. This is because it is assumed that the SPA tried by every means to satisfy the delegated requirement and failed. This behavior should be instantiated in the workflow specification as needed.

Figure 3. Experimental settings: acquaintance networks’ configurations.

O(m(m + 1)/2) + O(n(n + 1)/2)

The same complexity applies for SPAs, and in a similar way, it can be obtained for CAs and RAs.

External_delegator behavior Input: (i) Requirement Reqi to be delegated Output: (i) Requirement’s output 1: 2: 3: 4: 5: 6:

VI.

Send Request(Reqi) to the SPA BlockReceive(Result) if (Result = Failure) then Halt the Ad_hoc workflow behavior else-if (Result = Output) then Continue with the Ad_hoc workflow behavior

Three sets of experiments with different connectivity degrees of acquaintance networks (weakly, moderately, and fully connected networks) were carried out. a) Objectives. The experiments were designed to explore: (i) the self-organizing characteristics of the agents during Cloud service composition, and (ii) the efficiency relation between exchanged messages and the number of agents’ acquaintances.

In this regard, the complexity of the BA’s CNP_broker_initiator behavior dominates the others. In a worst case scenario, when a CA submits a requirement to a BA. The BA with m feasible SPAs, sends (in the first instance) m call-for-proposals messages. After receiving the proposals, the BA sends an accept-proposal message to only one SPA. If this SPA fails, it propagates the failure message to the BA. Then, the BA sends m - 1 call-for-proposals to the remaining unvisited SPAs, and so on. Thus, in a worst case scenario the BA sends:

b) Experimental settings. As presented in Fig. 3, the agents involved were one CA, four BAs, seven SPAs and twelve RAs. A line connecting two agents establishes acquaintance relations. Resource agents have associated a web service either of type A, B or C. For example, in the context of infrastructure-asa-service scenarios, a web service may provide access to spot instances. Hence, type A could be a memory instance, type B a CPU instance, and type C a cluster instance. The consumer requirements were defined as follows {A, B, C}, which were submitted to BAs one by one. BAs were designed to provide random quotations, and thus any of them has the same probability of being contracted.

(1)

If after contacting all the SPAs, the requirement is not resolved, the BA may subcontract one BA among n BAs by again adopting the CNP_broker_initiator behavior. In a similar case to SPAs, if all the subcontracted BAs fail, the BA sends: n + (n – 1) + (n – 2) + … + 2 + 1 = n(n + 1)/2

EVALUATION

A series of experiments was conducted using the agent test bed defined in Sections II-V. The test bed was implemented using Java and the JADE agent framework [3].

E. Complexity of the Agent Behaviors The algorithm complexities rely on the level of connectivity of agents’ acquaintance networks. This determines the number of messages that agents send among each other.

m + (m – 1) + (m – 2) + … + 2 + 1 = m(m + 1)/2

(3)

The acquaintance networks of all the BAs contain enough service providers to handle the requirements, e.g., BA2 knows SPA2 {A, B} and SPA7 {C}. This ensured the collaboration between the BAs and the SPAs of all branches with the same probability. In addition, SPAs also provided random quotations.

(2)

The RAs were designed to fail with probabilities ranging from 0.0 to 1.0 (in 0.1 increments). Five experiments per failure rate were conducted. Failures were included only in

The CNP_broker_participant, Request_evaluator, and Result_handler behaviors take O(n) time. Thus, the complexity for the broker agent’s behaviors is bounded by:

64

Figure 4. No. of successful compositions vs probability of failure.

Figure 5. Average No. of messages vs probability of failure.

RAs, given that a failure at the end point promotes the biggest stimulus to self-organize the system from the lowest level (RAs) to the higher level (BAs).

exchanged more messages as a consequence of adopting the contract net protocol for obtaining cheaper service fees. Moreover, the three series showed a linear (efficient) behavior from 0.0 to 0.6 probabilities of failure (see Fig. 5), with an overall of 97 out of 105 successful compositions (see Fig. 4). Furthermore, only moderately and fully connected series presented a considerable increment of exchanged messages with 0.9 and 1.0 probabilities of failure, which are extreme cases, and thus improbable scenarios. Finally, the more connected agents are, the more self-organization can be expressed. This results in a minor increment of the number of messages in exchange for a major efficacy.

c) Performance measures. (i) Number of successful service compositions and (ii) number of messages, were used as the baseline for evaluating the self-organizing capabilities of agents and the efficiency of the service composition method. d) Results. From the results shown in Fig. 4 and 5, two observations are drawn: Observation 1. The number of successful compositions increased as the degree of agents’ connectivity increased. Analysis: In Fig. 4, it can be observed that the weakly, moderately, and fully connected series of experiments obtained only successful compositions with probabilities of failure from 0.0 to 0.2, 0.6, and 0.8, respectively. From those points, the efficiency decreases for each series, however, in the weakly connected series, 2 compositions were achieved even with a 0.6 probability of failure; in the moderately connected series, 4 compositions were achieved even with 0.8 probability of failure, whereas the fully connected series achieved 4 compositions with 0.9 probability of failure. The 1.0 probability of failure indicates that all the RAs were unable to fulfill a requirement, and thus, all the nodes of the acquaintance networks were visited with any success. More connected agents’ acquaintance networks allow accessing more Cloud resources, and thus, having a higher probability of success.

VII. RELATED WORK In [13], a multi-Cloud service composition method is presented. The service composition problem is translated into a combinatorial optimization problem. Then, using artificial intelligence planning techniques, a service composition solution is provided. Another Cloud service composition approach is presented in [12]. Web services are described by interfaces that contain semantic input and output parameters. Afterwards, a semantic matching algorithm links semantically similar outputs to corresponding inputs, obtaining a chain of web services that results in the service composition. Both [12] and [13] are centralized methods and need complete knowledge of all existing web services. In addition, the contracts among consumers and providers, necessary in Cloud service compositions are omitted.

Observation 2. The number of exchanged messages increased as the probability of failure increased and the degree of agents’ connectivity increased.

In [6], a hierarchical agent architecture with three types of agents: basic, broker, and super broker agents, is proposed. Basic agents represent services, which are interconnected via broker and super broker agents. In addition, a set of protocols to implement self-organization is included. However, the selforganization is propagated only to upper layers, i.e., no selforganization is designed into agents of a same layer. This causes dependence in higher agents, and thus, the control of the system is partially centralized.

Analysis: As it can be observed in Fig. 5, the three series of experiments presented a growing tendency caused by both failures and degree of connectivity. This was due to the additional agent interaction derived from the self-organization promoted by the failures. In addition, more connected agents

65

In [4], the service composition is partitioned, and for each partition, a monitoring agent is assigned. These agents monitor and capture the progress of the composition. When an error occurs, this is transmitted to an upper-level central monitor. The central monitor stops the composition and interacts with monitor agents to undo the progress of each partition to the last known correct state. The adopted centralized perspective to handle errors causes that a single fault impedes the development of the entire composition, in addition to considering an initial phase to partition the orchestration specification. This requires having the specification of all the involved services for determining proper partitions.

REFERENCES [1] [2] [3]

[4]

[5]

In contrast to [6], this work includes self-organization in the vertical and horizontal layers. Moreover, changes like the promoted by errors are handled in a distributed and local manner in difference to [4, 6]. VIII.

[6]

[7]

CONCLUSION AND FUTURE WORK

The novelty and significance of this paper is that distributed and cooperative agent-based problem solving techniques such as acquaintance networks and the contract net protocol were used to create a self-organizing service composition method. This method (to the best of the author’s knowledge) is the first work in considering incomplete information about Cloud participants and its combination with dynamic service selection mechanisms. In addition, a test bed that evaluated and demonstrated the advantages of selforganizing agents in Cloud service composition was implemented.

[8] [9]

[10]

[11]

[12]

Furthermore, the distributed Cloud service composition framework provides generic agent behaviors to handle ad-hoc web service workflow specifications. Such behaviors allow RAs to take advantage of the delegation of tasks, e.g., when a RA delegates a task to another RA given a failure. This promotes interleaving choreographies that may involve several SPAs. Finally, self-organizing service composition was supported by (sub) contracts among Cloud participants that can be mapped to service level agreements in Cloudcomputing environments.

[13]

In the future, work will be focus on: (i) Designing mechanisms to create and maintain acquaintance networks of new and current Cloud participants. (ii) Engineering an agent’s decision-making process that considers complex proposals in the service selection mechanism. (iii) Designing mechanisms to adjust existent service compositions to changes in consumer requirements, for example, a Cloud consumer demanding more storage capacity to its currently contracted BAs. (iv) Deploying the agent-based test bed in a semantic web service framework, following the direction of [2]. ACKNOWLEDGMENT This work was supported by the Korea Research Foundation Grant funded by the Korean Government (MEST) (KRF-2009-220-D00092) and the DASAN International Faculty Fund (project code: 140316).

66

Amazon EC2 Spot Instances, http://aws.amazon.com/ec2/spot-instances/, 2010. R. Battle, and E. Benson. “Bridging the semantic Web and Web 2.0 with Representational State Transfer,” Web Semant. 6(1), 2008, pp. 61-69. F. Bellifemine, A. Poggi, and G. Rimassa, “JADE - A FIPA-compliant agent framework,” in 4th International Conference and Exhibition on the Practical Application of Intelligent Agents and Multi-Agents, 1999. G. B. Chafle, S. Chandra, V. Mann, and M. G. Nanda, “Decentralized orchestration of composite web services,” in Proc. of the 13th international World Wide Web Conference on Alternate Track Papers & Posters, ACM, New York, NY, 2004, pp. 134-143. C. Gershenson, and F. Heylighen, “When Can we Call a System Selforganizing?,” in Proc. of the 7th European Conference, W. Banzhaf, T. Christaller, P. Dittrich, J. T. Kim, and J. Ziegler Eds. Advances in Artificial Life, LNAI 2801, Springer, 2003, pp. 606-614. S. Helal, and M. Wang, “Service Centric Brokering in Dynamic Ebusiness Agent Communities,” J. Electron. Commerce Res. 2(1), 2001, pp. 32-47. C. Hewitt, “Viewing control structures as patterns of passing messages,” Artificial Intelligence, 8(3), 1977, pp. 323-364,. F. Heylighen, and C. Gershenson, “The Meaning of Self-organization in Computing,” IEEE Intelligent Systems, 18(4), 2003, pp. 72-75. K. M. Sim, “Agent-based Cloud Commerce,” in Proc. of the IEEE International Conference on Industrial Engineering and Engineering Management, Hong Kong, 2009, pp. 717-721. K. M. Sim, “Towards Complex Negotiation for Cloud Economy,” in Proc. of the 5th International Conference on Grid and Pervasive Computing, LNCS 6104, Taiwan, 2010, pp. 395-406. R. G. Smith, “The Contract Net Protocol: High-Level Communication and Control in a Distributed Problem Solver,” IEEE Trans. Comput. 29(12), 1980, pp. 1104-1113. C. Zeng, X. Guo, W. Ou, and D. Han, “Cloud Computing Service Composition and Search Based on Semantic,” in Proc. of the International Conference on Cloud Computing, M. G. Jaatun, G. Zhao, and C. Rong, Eds. LNCS 5931, Springer-Verlag, Berlin, Heidelberg, 2009, pp. 290-300. G. Zou, Y. Chen, Y. Yang, R. Huang, and Y. Xu, “AI Planning and Combinatorial Optimization for Web Service Composition in Cloud Computing,” in Proc. of the International Conference on Cloud Computing and Virtualization, 2010.