Recent research foresees the advent of a new discipline of agent-based cloud computing systems on the Future Internet, which would provide processing and memory resources for agents and intelligent cloud services at unprecedented scale. In this paper we discuss the role of argumentation on the next generation of agreement technologies in cloud computing environments and provide an example application.
Recent developments on argumentation-based agreement models have provided
the necessary technology to allow agents to engage in argumentation dialogues
and harmonize beliefs, negotiate, collaboratively solve problems, etc [
Once we have client-server systems where agents are able to argue and reach
agreements, now is time to put the new developments of the Future Internet into
the picture. Recent research foresees the advent of a new discipline of agent-based
cloud computing systems on the Future Internet, which would provide processing
and memory resources for agents and intelligent cloud services at unprecedented
scale [
On the other side, an environment based on cloud computing must readjust
its resources taking into account the demand of its services. At the technological
level, the di culties have been overcome thanks to the use of virtualization of
hardware resources [
Mutual contributions in agreement technologies and cloud computing can advance research in both areas to the nal establishment of the Future Internet. In this paper we introduce the potential role of argumentation on the next generation of agreement technologies in cloud computing environments. Among the potential applications of argumentation in this area, we focus here on the concrete domain of resources re-distribution in cloud computing systems. Section 2 develops our proposal. Then, Section 3 introduces related work and future challenges and summarises the results of this work. 2
A current open issue in a cloud computing system is how to e ciently redistribute resources among a variable set of virtual machines, considering the demand for the services o ered by the system. In this section we propose an argumentation-based approach to deal with the problem of resource re-distribution during a peak service demand in a cloud computing platform. To illustrate our proposal, we provide an example where a set of agents in charge of managing virtual machines and physical resources in the platform engage in an argumentation dialogue to reach an agreement about the best solution to make when a service is failing due to an overload in the virtual machines that provide this service. First, the platform and the argumentation framework used are presented. Then, an example argumentation dialogue in this domain is provided. 2.1
bCloud Architecture bCloud is a platform based on the cloud computing paradigm. This platform allows to o er services at the PaaS (Platform as a Service) and SaaS (Software as a Service) levels. On the one hand, the SaaS services are o ered to the nal users in terms of web applications. On the other hand, PaaS services are o ered as web services. The IaaS (Infrastructure as a Service) layer is composed by an physical environment which allows the abstraction of resources shaped as virtual machines. The virtual and physical resources are managed dynamically. To this end, a virtual organization of intelligent agents that monitor and manage the platform resources is used. This organization implements an argumentationbased agreement technology in order to achieve the distribution of resources depending on the needs of the whole system.
The system has a layered structure that covers the main parts of cloud computing. Both PaaS and SaaS layers are deployed using an IaaS layer, which provides a virtual hosting service with automatic scaling and functions for balancing workload. The SaaS layer is composed of the management applications for the environment (control of users, installed applications, etc.), and other more general third party applications that use the services from the PaaS layer. At this level, each user has a personalized virtual desktop from which he has access to his applications in the cloud environment, and to a personally con gurable area as well. The PaaS layer provides services through REST web services in an API format. One of the more notable services among the APIs is the identi cation of users and applications, a simple non-relational database service and a le storage area that controls versions and simulates a directory structure.
SaaS Layer. This layer hosts a wide set of cloud applications. All of them make use of the services provides by the PaaS lower layer. bCloud as environment o ers a set of native applications to manage the complete cloud environment: virtual desktop, user control panel, and administration panel.
PaaS Layer. The PaaS layer is oriented to o er services to the upper layer, and it is supported by the lower IaaS layer. The components of this layer are: the IdentityManager, which is the module of bCloud in charge of o ering authentication services to clients and applications; the File Storage Service (FSS), which provides an interface for a container of les, emulating a directory structure in which the les are stored with a set of metadata, thus facilitating retrieval, indexing, search, etc; and the Object Storage Service (OSS), which provides a simple and exible schemaless data base service oriented towards documents.
IaaS Layer. The objective of this layer is not to o er infrastructure service as usual cloud platforms do. However, it has to o er this infrastructure service to upper layers of bCloud (SaaS and PaaS). The key characteristic on a cloud environment is that the hardware layer includes the physical infrastructure layer and the virtual one (in terms of virtual machines). The virtual resources (number and performance of the processors, memory, disk space, etc.) are shown as Demand Monitor
VM unlimited, but they are supported by a limited number of physical resources, although the nal user has the view of unlimited resources.
bCloud MAS. In bCloud, the elastic management of the available resources has been done by a MAS based on Virtual Organizations (VO). In the bCloud VO there is a set of agents that are especially involved in the adaptation of the system resources in view of the changing demand of the o ered services. Figure 1 presents the di erent roles that bCloud agents can play. These are the following: { Demand Monitor: in charge of monitoring each demand service which is o ered by bCloud (FSS, OSS, Applications of the SaaS layer, etc.). There is one agent of this type per each kind of service. This agents will be able to o er information about not only the instant demand, but also the historical of the demand. { Resource Monitor: in charge of knowing the usage level of the virtual resources of each virtual machine. There is one in each physical server. { Local Manager: in charge of allocating the resources of a single physical machine among its virtual machines. There is one in each physical server. { Migration Manager: in charge of negotiating with their peers the sharing of global resources in terms of 1) Migration of virtual machines between physical servers; and 2) Creation/Destruction of physical resources (switch on and o physical servers), as well as virtual resources (instantiating/stopping virtual machines). There is one in each physical server.
In this system, a peak in the demand of a speci c service can give rise to an overload of one or more of the virtual machines that provide this service. Therefore, the system has to re-distribute its virtual and physical resources to cope with this problem. In this situation, several potential agreement processes can be identi ed, let us call them intra-machine or inter-machine. On the one hand, at the intra-machine level, the local manager could start an agreement process with the migration manager to decide the best option among re-distributing physical resources between existing virtual machines, instantiating new virtual machines or switching on new physical resources (extra physical machines). On the other hand, at the inter-machine level, if the outcome of the former process entails the migration of a virtual machine or the switching on of a new physical server, several migration managers could start an agreement process to decide which machine(s) (already running or not) should host the migrated virtual machine and with which distribution of resources. Summarizing, we can identify several types of solutions as potential outcomes of the agreement processes established: { Basic Solution: consists of redistributing the physical resources of the machine among its virtual machines { Halfway Solution: consist of instantiating a new virtual machine in the same physical machine. { Complex Solution: consist of migrating a virtual machine to a new physical machine that can host it (already running or not).
Any of these solutions entails an underlaying negotiation process to allocate virtual and physical resources among services to solve the overload problem. However, it is not our aim in this work to discuss the best negotiation mechanism to implement the solution itself, but to provide the agents of the system with the ability of engaging in an argumentation dialogue to collaboratively decide which would be the best solution to make before starting the negotiation. Our hypothesis is that agents may make the most of their experience and help each other to avoid complex negotiation processes that have a lower probability of ending in a successful allocation of resources in view of similar previous experiences. In this sense, our approach can be viewed as a model to guide the negotiation process and maximise its success. 2.2
In [1, Chapter 3] we presented a computational case-based argumentation
framework that agents can use to manage argumentation processes. In this work, we
apply this framework to model the argumentation dialogue among agents in the
bCloud platform. Concretely, let us propose a running example where several
migration managers try to reach an agreement about the best solution to apply
for the resource re-distribution problem during a service peak of demand. The
solution that an agent proposes de nes its position. We assume that a problem
can be characterised by a set of features that describe it. Also, in our example
domain, we assume that all agents are collaborative and all follow the common
objective of providing the best solution by making the most of their individual
experiences. An agent that proposes a position, let us say a proponent agent,
tries to persuade any potential opponent that has proposed a di erent position
to change its mind. Thus, the proponent engages in a two-party argumentation
process with the opponent, trying to justify its reasons to believe that its
solution is most suitable. This section summarises the main components of the
framework and illustrates them in this example. The full explanation about the
reasoning process that agents use to manage their positions and arguments is
out of the scope of this paper and can be found at [
A case-base with argument-cases: that store previous argumentation experiences and their nal outcome. Argument-cases have three main objectives: they can be used by agents 1) to generate new arguments; 2) to select the best position to put forward in view of past argumentation experiences; and 3) to store the new argumentation knowledge gained in each agreement process, improving the agents' argumentation skills. In our example, each migration manager has an individual argument-cases case-base that can query to select the most suitable argument in each step of the process.
Arguments. In our proposal, arguments that agents interchange are tuples
of the form Arg = f ; v; < S >g, where is the conclusion of the argument,
v is the value that the agent wants to promote and < S > is a set of elements
that justify the argument (the support set). Therefore, we follow the approach
of value-based argumentation frameworks [
The support set S can consist of di erent elements, depending on the
argument purpose. On one hand, if the argument justi es a potential solution for a
problem, the support set is the set of features (premises ) that match the
problem to solve and other extra premises that do not appear in the description of
this problem but that have been also considered to draw the conclusion of the
argument and optionally, any knowledge resource used by the proponent to
generate the argument (domain-cases and argument-cases ). This type of argument
is called a support argument. On the other hand, if the argument attacks the
argument of an opponent, the support set can also include any of the allowed
attack elements of our framework. These are distinguishing premises or
counterexamples, as proposed in [
PROBLEM Service Demand
VMs
Resources Resources Usage
FSS
SR VM1, VM2 VM1R, VM2R VM1RU, VM2RU
POSM1
Domain Cases
M1 Domain-Case - DC1
PROBLEM Service Demand
FSS
SR1
VMs VM1, VM2, VM3 Resources VM1, VM2, VM3 Resources VM1RVUM,3VRMU2RU, Usage
SOLUTION Description Migrate to ServerN
SoTlyuptieon ComplexSolution (i.e. a domain-case or an argument-case), where the problem description of the counter-example matches the current problem to solve and also subsumes the problem description of the case, but proposing a di erent solution. This other type of argument is called an attack argument.
Domain-cases. The structure of domain-cases that an argumentation system that implements our framework has depends on the application domain. As example, Figure 2 presents a potential domain-case that the migration manager M1 could retrieve to generate its recommended solution "Migrate to ServerN" (since it has deemed it as similar enough to the current problem), which proposes to migrate the most overloaded virtual machine to another server with more available resources and promotes "ComplexSolution" type of solution. Note that in this example we assume that domain-cases also store the type of solution that they represent. The premise "VM3" would be a distinguishing premise between the domain-case shown in Figure 2 and another domain-case, say DC2, that has exactly the same problem description than DC1, but that stores di erent data for this premise (a di erent set of virtual machines that provide the service). Also, let us assume that the domain-case DC2, which has the same problem description than DC1, proposes an alternative solution (e.g "Instantiate a new VM") that promotes the type of solution "HalfWaySolution". Therefore, DC2 could be used to generate a counter-example attack to DC1 and vice-versa.
Argument-cases. Argument-cases store the information about a previous argument that an agent posed in certain step of a dialogue with other agents. Their structure is generic and domain-independent. To illustrate the components of an argument-case, let us show the following example. The migration manager M1 has generated a support argument SA1 to persuade another migration manager M2 to accept his position. The position of M1 (P OSM1) was generated by using the domain-case DC1 and consist of a migration of the most overloaded virtual machine to another physical sever, which promotes the same type of solution than DC promotes, say "ComplexSolution". If p1 = f"Service" = F SSg, p2 = f"Demand" = SR1g, p3 = f"V M s" = fV M 1; V M 2; V M 3gg, p4 = Domain Context Premises = fp1, ...., p5g
Proponent IRDol=e=MM1igration Manager
ValPref = B<HW<C PROBLEM Social Context Opponent IRVDaollP=er=eMf M2=igCr<atBio<nHMWanager
Group IRVDaollP=er=eGf D=P-C
Dependency Relation = Charity Conclusion = "Migrate to ServerN"
Value = C SOLUTION Acceptability Status = Accepted
Received Attacks CDoisutnintegruiEshxianmgpPlersem=isDesC=2 ; JUSTIFICATION CDaGs1es = DC1 f"Resources" = fV M 1R; V M 2R; V M 3Rgg, and p5 = f"ResourcesU sage" = fV M 1RU; V M 2RU; V M 3RU gg then SA1 = f"M igratetoServerN ", C, < fp1, p2, p3, p4, p5g, fDC1g, -, -, -, -, - >g.
Table 1 presents an example of an argument-case that stores the information of the support argument SA1 in tour running example. In the table, "B" stands for "BasicSolution", "HW" for "HalfWaySolution" and "C" for "ComplexSolution". Argument-cases have the three possible types of components that usual cases of CBR systems have: the description of the state of the world when the case was stored (Problem); the solution of the case (Conclusion); and the explanation of the process that gave rise to this conclusion (Justi cation).
The problem description has a domain context that consists of the premises that characterise the argument. In addition, if we want to store an argument and use it to generate a persuasive argument in the future, the features that characterise its social context must also be kept. The social context of the argumentcase includes information about the proponent and the opponent of the argument and about their group. Although we have this distinction between proponent and opponent of an argument (and of its underlying defended or attacked position), in our running example all agents are willing to collaborate and share the common objective to propose the best solution for the overloaded service problem.
Moreover, we also store the preferences (ValPref ) of each agent or group
over the set of values pre-de ned in the system. Finally, the dependency relation
between the proponent's and the opponent's roles is also stored. In this work, we
consider two types of dependency relations (inherited from [
In the solution part, the conclusion of the case, the value promoted, and the acceptability status of the argument at the end of the dialogue are stored. The last feature shows if the argument was deemed acceptable, unacceptable or undecided in view of the other arguments that were put forward in the agreement process. Thus, the conclusion of the argument-case in Table 1 presents the solution proposed by M1 to solve the service overload problem. In addition, the conclusion part includes information about the possible attacks that the argument received during the process. These attacks could represent the justi cation for an argument to be deemed unacceptable or else reinforce the persuasive power of an argument that, despite being attacked, was nally accepted.
In the example shown in Table 1 we can see that the opponent, say migration
manager M2, attacked the argument represented by this argument-case with the
counter-example DC2. Therefore, M2 generated an attack argument AA2 with
this counter-example in the support set: AA2 = f"Instantiate a new VM", HW ,
< fp1, p2, p3, p4, p5g, -, -, -, -, -, fDC2g >g. However, as shown in Table 1,
M1 's support argument remained acceptable at the end of the dialogue (when
the argument-case that represents it was retained in the argument-cases
casebase). Attacked arguments remain acceptable if the proponent of the argument is
able to rebut the attack received, or if the opponent that put forward the attack
withdraws it. This feature is used in the argument management process of our
argumentation framework to represent the potentially high persuasive power of
current arguments that are similar to previous arguments that were attacked
and still remained acceptable at the end of the agreement process (see [
The justi cation part of an argument-case stores the information about the knowledge resources that were used to generate the argument represented by the argument-case (the set of domain-cases and argument-cases). In the example of Table 1, the justi cation part of the argument-case includes the domaincase DC1, that the migration manager M1 used to generate its position. In addition, the justi cation of each argument-case has a dialogue-graph (or several) associated, which represents the dialogue where the argument was put forward (DG1 in Table 1). In this way, the sequence of arguments that were put forward in a dialogue is represented, storing the complete conversation as a directed graph that links argument-cases. This graph can be used later to improve the e ciency of an argumentation dialogue, for instance, nishing a current dialogue that is very similar to a previous one that proposed a solution that ended up in an unsuccessful re-distribution of resources. 2.3
The agents of the our framework use an argumentation protocol to manage
positions and arguments and perform the argumentation dialogue. The entire
protocol is de ned in [1, Chapter 4]. Here a simpli ed version of the protocol
proposed in [
In order to show how our argumentation framework can be applied to
manage the service overload problem, the data- ow for the argumentation dialogue
among several migration agents engaged in the agreement process is described
below. The process starts when a demand monitor agent noti es an overload in a
service that it manages. Then, the resource monitor agent in charge of the virtual
machines that o er this service sends the load information about the resources
associated to these virtual machines to the migration manager of the physical
machine that hosts them. For clarity reasons, we assume in this example that all
virtual machines that o er a service are hosted in the same physical machine.
However, in a real implementation, these virtual machines could be distributed
in several physical machines and in that case, several parallel argumentation
dialogues would be started by the migration manager of each physical machine.
Also, migration managers are connected among them and are able to check the
positions proposed by other migration managers.
1. The rst state is the initial state. At the beginning of the agreement
process, migration managers remain in this state waiting for an open dialogue
locution. Also, they will come back to this state when the agent that starts
the argumentation dialogue (say, the initiator agent) communicates that
the dialogue has nished. The open dialogue locution informs the
migration manager agent that receives it about the start of a new dialogue to
solve a re-distribution problem. Then, this agent will retrieve the cases of
its domain-cases case-base which features match the given problem
characterisation (e.g. the FSS overload presented in Figure 2) with a similarity
degree greater than a given threshold. Finally, if the agent has been able to
retrieve similar domain-cases and use their solutions to propose a solution
for the current problem, it will engage in the argumentation dialogue with
the locution enter dialogue and will go to the state 2. A migration manager
only engages in the dialogue if it has solutions to propose. For instance, on
our running example, M1 will engage in the dialogue, since it has been able
to retrieve DC1 as a similar case.
2. When a migration manager is in this state it has retrieved a list of similar
domain-cases to the current problem to propose a solution (position to
defend). If the agent has been able to generate several alternative solutions, it
will select the most suitable for its current context (following the reasoning
process presented in [
The dialogue nishes when no new positions or arguments are proposed after a certain time. Then, the initiator migration manager retrieves the active positions of the participants and the most accepted position (if several remain undefeated) is selected as the nal solution to propose. In case of draw, the nal solution will be the most frequent position generated by the migration managers during the argumentation dialogue. Finally, once a position is selected as the outcome of the agreement process, the migration manager sends it to the local manager of its physical machine and both would start the process to implement it (with further negotiations if necessary). Also, at the end of the argumentation dialogue, all agents update their domain-cases case-bases with the new problem solved and their argument-cases case-bases with the information about the arguments proposed, with the attacks received, the nal acceptability state, etc. 3
Cloud computing is a new model of business and technology services, which
allows the user to access a catalog of standardized services and meet the needs
of his business in a exible and adaptive way, paying only for the consumption
made [
In the last years, the community of argumentation in MAS has advanced
research in many elds on the area of applying argumentation theory to harmonise
agents incoherent beliefs and model the interaction among a set of agents [
Acknowledgements This work is supported by the Spanish government grants [CONSOLIDER-INGENIO 2010 CSD2007-00022, TIN2008-04446, and TIN2009-13839-C03-01] and by the GVA project [PROMETEO 2008/051].