(HS-IDA-MD-02-309)
Anette Brodin (anette.brodin@ida.his.se) Department of Computer Science
Högskolan i Skövde, Box 408 S-54128 Skövde, SWEDEN
Final year project on the study programme in computer science 2002.
Supervisor: Mikael Berndtsson
Submitted by Anette Brodin to Högskolan Skövde as a dissertation for the degree of M.Sc., in the Department of Computer Science.
2003-01-07
I certify that all material in this dissertation which is not my own work has been identified and that no material is included for which a degree has previously been conferred on me.
Signed: _______________________________________________
Anette Brodin (anette.brodin@ida.his.se)
Abstract
Both artificial intelligence (AI) and database (DB) communities have advantages in incorporating features from each other’s areas. From a DB view, handling of complexity in today’s information systems can be aided by incorporating AI features, and database environments could gain in flexibility by entrusting some of their functionality to agent systems. Contemplated from the AI view, agent systems could gain in robustness by being based on DB-systems.
By applying the semantics of database-transaction to interactions between agents in a multiagent-system, and analysing the consequences, this project endeavours to cross borders of the two research areas. In the project, states where drop-out of some agent is severe to the task fulfilment, of the system, have been identified, and examined after applying transaction semantics to the agent interactions. An existing system for multiagent applications, JADE, has been examined in order to investigate how problem situations are handled in practice. The result from this work shows the feasibility to contemplate both type of systems as very similar, but modelled and viewed in different ways.
Keywords: Multi-agent system, database-transaction, task, interaction, drop-out agent.
Table of contents
1 Introduction ... 1
1.1 Dissertation overview ...2
2 Background ... 3
2.1 Agent related concepts ...3
2.1.1 Agents...3
2.1.2 Multiagent systems...5
2.1.2.1 Robustness ... 6
2.1.2.2 A reference model ... 8
2.2 Distributed systems...9
2.3 Database concepts...10
2.3.1 Persistence ...10
2.3.2 Transaction ...11
2.3.3 Nested transaction ...12
2.3.4 Recovery...13
2.3.5 The ECA-model ...15
2.3.6 Two-phase commit protocol ...16
3 Problem description... 18
3.1 The problem...18
3.2 Aim ...19
3.3 Objectives...20
3.4 Method and approach...20
4 Investigating an example ... 22
4.1 Task sharing...22
4.2 Contract net ...23
4.3 Task and agents in the example ...26
4.3.1 Failure model considered...27
4.3.2 Task decomposition and allocation ...27
4.3.3 Result synthesis...30
4.3.4 Problem situations in the example ...31
5 Applying transaction semantics to the example ... 32
5.1 The chosen transaction model ...32
5.3 Results from the transfer ...34
5.4 Seamless integration or modifications needed?...35
5.5 Affected problem situations ...35
6 Analysis of results from objective 1-3 ... 37
6.1 Consequences of the work on the example ...37
7 Handling the problem(s) in practice ... 40
7.1 Investigating JADE...40
7.1.1 Architecture and implementation of the agent platform ...40
7.1.2 Handling failure ...43
8 Related work ... 45
9 Conclusions and further work... 47
References ... 50
Table of figures
Figure 1. Agent Management Reference Model (after FIPA, 2001c)... 9
Figure 2. Transaction state diagram (after Elmasri &Navathe (2000), and Gray and Reuter (1993)...13
Figure 3. Rule execution (after Paton & Diaz, 1998)...16
Figure 4. The basic two-phase commit protocol (after Chrysanthis et al. 1998)...17
Figure 5. Contract Net Interaction Protocol (after FIPA, 2001a). ...25
Figure 6. State diagram over an agent using CNP. ...26
Figure 7. First decomposition and allocation...28
Figure 8. Complete decomposition of the task, and allocation of subtasks to agents..29
Figure 9. Result synthesise of the task. ...30
Figure 10. The transaction tree. ...34
Figure 11. Software Architecture of one JADE Platform (after Bellifeme et al. 1999). ...41
1 Introduction
In the late 1980: s, the lack of integration and coordination of efforts between database (DB) and artificial intelligence (AI) communities was criticized by Michael Brodie. He emphasized the need to exceed borders between DB and AI research. Brodie (1989) also presented a view of how DB and AI technologies ought to work together in the future to ensure the creation of a good foundation for building future intelligent information systems. In this view he included five proposals for achieving future progresses in AI/DB integration-work. The following quotation is a part of his first proposal:
“AI[DB] researchers will inevitably encounter DB[AI] problems as they improve their systems. There are 30 years of DB[AI] results and technology to address these problems. Do not ignore that work. Identify relevant results and adapt or extend them to address the problems faced in the new context” (Brodie, 1989, p.624).
Berndtsson (1998) confirms this view of sparse exchange of ideas between the communities and states the reason to be that there are very different types of problem to be solved in the two communities. Berndtsson (1998) also states that the emerging Cooperative Information System (CIS) research domain represent an area for interactions between the two communities. Since 1996 the Conference on Cooperative Information Systems (CoopIS) has been held and serves as a meeting of disciplines that, among others, includes database-, distributed-, and multiagent-systems. Referring to those types of discussions a claim is that both AI and DB communities can benefit from incorporating features from each other’s areas.
From a DB view, the handling of complexity in today’s information systems are aided by incorporating AI features, and database environments could gain in flexibility by entrusting some of their functionality to agent systems. Contemplated from the AI view, agent systems could gain in robustness by being based on DB-systems.
The agent concept and agents working together in order to solve some problem, or achieve a common goal is traditionally handled in the area of AI research. A multi-agent system can also be seen as a way to analyse, design and implement complex software systems that consists of a number of software agents working toward a single global goal, or toward separate individual goals that interacts. Independent of which of those views a multiagent system is considered from, these systems as well as database systems manages a lot of
information. The information can for example concern agent’s knowledge, goals, skills, and plans, and also their interactions as well as the work to be carried out. In order to perform in a desirable manner an important characteristic, as well as an issue of research interest, is robustness for this type of system. A common approach, in order to increase robustness in multi-agent system, is to supply redundancy. The redundancy-approach is mostly handled in distributed systems-theory. The problem is addressed in DB-theory as well since robustness appears to have clear affinity with the DB-concept recoverability, which aims at aiding the dependability attributes, availability and reliability. This is a well-explored area in DB-theory based on the concept transaction as the unit of recovery. A transaction can be seen as an abstraction of the manipulation of data that takes place in order to transfer the database from one consistent state to another consistent state.
In this project an attempt is made to cross the boarder between AI/DB communities by supplying a concrete example. This example is exploring the possibility of applying the semantics of DB-transaction, the unit of recovery, to agent interactions. If this work shows feasible, it is hopefully contributing to the possibility of taking advantage of DB-techniques for reinforcement of robustness in multiagent systems.
1.1 Dissertation overview
In chapter 2 the concepts relevant for this work is described in order to give background information for the problem description presented in chapter 3. Chapter 3 also presents method and approach for the work. In chapter 5-7 the work is presented followed by a presentation of related work in chapter 8. Chapter 9, finally, bring together the findings and present the conclusions.
2 Background
In this chapter an overview of the concepts related to the work in this dissertation is presented. The first part of the chapter, describes the concepts related to agents. In the second part the distributed system-concept is described. Finally, part three concerns DB-concepts of interest for this project.
2.1 Agent related concepts
There are difficulties in defining different agent concepts. The reason for those difficulties is that some of the key concepts in the field lack universally accepted definitions. There is no real agreement even on the core question of exactly what an agent is. But this does not need to be a serious obstacle to progress in research. AI community has made progress without having a universally accepted definition for intelligence (Jennings, Sycara and Wooldridge, 1998).
Given by Franklin and Graesser (1997) is a discussion about what an agent is and the discussion gives a picture of how complex the issue of definitions can be. This section aims at describing agents and multiagent-systems in order to create an intuitive view of these concepts that is serving as foundation for the work in this project.
2.1.1 Agents
Two general usages of the term “agent” can be distinguished according to Wooldridge and Jennings (1995). The first is weak, and relatively uncontentious, the second is stronger and potentially more contentious. Wooldridge and Jennings (1995) describe a weak notion of agency as follows.
“A hardware or (more usually) software-based computer system that enjoys the following, four properties:
• Autonomy, agents operate without the direct intervention of humans and others, and have some kind of control over their actions and internal state.
• Social ability, agents interact with other agents (and possibly humans) via some kind of agent-communication language.
• Reactivity, agents perceive their environment and respond in a timely fashion to changes that occur in it.
• Pro-activeness, agents do not simply act in response to their environment, they are able to exhibit goal-directed behaviour by taking the initiative.” (Jennings &
Wooldridge, 1995, p. 118).
Wooldridge and Jennings (1995) point out that this weak notion of agency has found currency with a surprisingly wide range of researchers. They give the example that in mainstream computer science, the notion of an agent as being a self-contained, concurrently executing software process, that encapsulates some state and is able to communicate with other agents via message passing, and are seen as a natural development of the object-based concurrent programming paradigm.
Also a stronger notion of agency is described by Wooldridge and Jennings (1995). For some researchers, particularly those working in AI, the term “agent” has a stronger and more specific meaning than that sketched out above. In addition to the properties above those researchers generally mean an agent to be a computer system is either conceptualised or implemented using concepts that are more usually applied to humans. It is common in AI to characterize an agent using mentalistic notions, such as knowledge, belief, intention, and obligation. Some researchers have gone further and considered emotional agents. Wooldridge and Jennings (1995) suppose that this is just pointless anthropomorphism but that it should be noted that there are good arguments in favour of designing and building agents in terms of human-like mental states.
Wooldridge and Jennings (1995) also give example of other attributes sometimes discussed in the context of agency. For example: mobility is the ability of an agent to move around an electronic network, veracity is the assumption that an agent will not knowingly communicate false information, benevolence is the assumption that agents do not have conflicting goals,
and that every agent will therefore always try to do what is asked of it, and rationality is (crudely) the assumption that an agent will act in order to achieve goals, and will not act in such a way as to prevent its goals being achieved.
2.1.2 Multiagent systems
Weiss (1999) states that since its inception in the mid to late 1970s, distributed artificial intelligence (DAI) has evolved and diversified rapidly. Weiss (1999) also describes DAI today as an established research and application field which brings together and draws on results, concepts, and ideas from many disciplines, including AI, computer science, sociology, economics, organization and management science, and philosophy.
Even if Weiss (1999) emphasizes that it is difficult to precisely characterize DAI in a few words he provides us with the following definition:
“DAI is the study, construction, and application of multiagent systems, that is, systems in which several interacting, intelligent agents pursue some set of goals or perform some set of tasks” (Weiss, 1999, p.1).
Bond and Gasser (1988, p. 3) define DAI as a subfield of AI concerned with concurrency in AI computations and divide the world of DAI into two primary arenas, Distributed Problem Solving (DPS) and Multiagent systems (MAS). They describe research in DPS as considering how the work of solving a particular problem can be divided among a number of modules, or nodes that cooperate at the level of dividing and sharing knowledge about the problem and about the developing solution. Bond and Gasser (1988, p. 3) describe research in MAS as concerning coordinating intelligent behaviour among a collection of autonomous intelligent agents and how they can coordinate their knowledge, goals, skills, and plans jointly to take action or to solve problems. The agents in a multiagent system may be working toward a single global goal, or toward separate individual goals that interacts. Like modules in a DPS system, agents in MAS must share knowledge about problems and solutions. But they must also reason about the processes of coordination among the agents (Bond & Gasser, 1988, p.3).
Moulin and Chaib-draa (1996) share the above view of two arenas for DAI and elucidate that in a pure DPS system, all interaction (cooperation and coordination if any) strategies are incorporated as an integral part of the system. They also commit themselves to the definition
of MAS as a loosely coupled network of problem solvers working together to solve problems beyond their individual capabilities.
Jennings et al. (1998) provide the following characteristics of MAS:
• Each agent has incomplete information, or capabilities for solving the problem, thus each agent has a limited viewpoint.
• There is no global system control.
• Data is decentralized.
• Computation is asynchronous.
According to Jennings et al. (1998), research into systems composed of multiple agents, traditionally was carried out under the banner of DAI, and has historically been divided into DPS and MAS. They also points out that more recently, the term “multi-agent systems” has come to have a more general meaning, and is now used to refer to all types of system composed of (semi-) autonomous components.
Weiss (1999) describes two forms of interactions between agents playing an important role in DAI. The first form is cooperation i.e. coordination among non-antagonistic agents where participating agents fail or success together. The second form is competition in which the success of one participant implies failure of others. The interactions are defined by protocols that prescribe how the communication for interaction takes place.
Two forms of cooperation defined by Smith and Davis (1988) are task sharing and result sharing. Task sharing is used to organize problem decomposition through formation of explicit task-subtask connections between agents, while result sharing is used to facilitate sub problem solution when kernel sub problems are such that individual agents working independently without significant communication with others cannot solve them. One approach to set up the scene for how subtasks are to be distributed among agents, coordinated by task sharing, is negotiation.
2.1.2.1 Robustness
In literature about MAS the word robustness is often used, in a very general manner, but not well defined. Robustness is mostly treated as an inherent feature of MAS, and the view given is that to deal with the issue of robustness, redundancy is mostly used. One exception is found
in Schillo, Burchett, Fisher, and Klusch (2000a) where an attempt to make a definition is reported. In their opinion, a broader conception of robustness than introducing redundancy in the system is required. Schillo et al. (2000a) claim that robustness only can be defined in relation to some definition of performance measure. The expected drop of the performance measure in four perturbation scenarios defines robustness quantitatively:
• Increase of population size.
• Change of task profile over time.
• Malicious agent intrusion.
• Drop-outs of agents
Using the above scenarios, robustness can be defined and measured by how much decrease of the performance measure will be the result of doubling the population size, or if five percent of the agents randomly drops out etc. If the limit for calling a system robust is defined to five percent, then there is a clear-cut qualitative definition of whether the system is robust (Schillo et al. 2000a). By providing the following four properties Schillo et al. (2000a) state that there is a correspondence to mastering the above perturbation scenarios:
• Scalability: how the system reacts in terms of performance if the size of the agent society is increased by a certain percentage. Scalability requires that patterns of interactions can react to the increased size of the community. Possible strategies are choosing different protocols, employing matchmakers, or organization of participating parties to bigger entities
• Flexibility: how the system is able to recover if any change in the environment occurs and the safety responsibilities cannot be maintained at the moment. With other words, how fast can the system recover from such disturbances and how fast can agents adopt their models of others. This requires some sort of modelling of the system.
• Resistance: regarding the effect of malicious behaviour of agents in the community. In Scillo, Rovatsos, and Funk (2000b), work can be found on trust and betrayal. This work shows that by using trust as a mechanism for evaluating agents and excluding malicious agents from interaction, it is possible to increase robustness of system from malicious agents.
• Drop-out safety: when some agent halting execution. One approach in this context is the use of shadow agents, which monitor other agents and replace them or adapt their plans (Schillo et al. 2000a).
2.1.2.2 A reference model
In order to describe how a MAS can be implemented in practice, an overview of a reference model is given. The Foundation for Intelligent Physical Agents (FIPA) is a non-profit association that develop specifications supporting interoperability among agents and agent- based applications. The FIPA Agent Management Reference Model (Figure 1) provides a normative framework within which FIPA agents exist and operate. The model consists of a number of components, each representing a capability set.
• An Agent is the fundamental actor on an Agent Platform (AP).
• A Directory Facilitator (DF) is a mandatory component of the AP. Agents may register their services with the DF or query the DF to find out what services are offered by other agents.
• An Agent Management System (AMS) is also a mandatory component of the AP. The AMS exerts supervisory control over access to and use of the AP.
• A Message Transport Service (MTS) is the default communication method between agents on different APs.
• An Agent Platform (AP) provides the physical infrastructure in which agents can be deployed. The AP consists of the machine(s), operating system, agent support software, FIPA agent management components (DF, AMS and MTS) and agents.
The internal design of an AP is an issue for agent system developers and is not a subject of standardization within FIPA. A FIPA agent platform is defined as software that implements the set of FIPA specifications.
“To be considered FIPA-compliant, an agent platform implementation must at least implement the Agent Management and Agent Communication Language specifications”
(FIPA, 2002).
Figure 1. Agent Management Reference Model (after FIPA, 2001c).
2.2 Distributed systems
Fault tolerance is an area of interest in Distributed Systems (DS) theory as well, mostly solved by redundancy in the form of replication of system parts. This section aims at giving an overview of some concepts of interest in this area.
Burns and Wellings (1997, p.441-442) define a Distributed Systems (DS) as “….a system of multiple autonomous processing elements, cooperating in a common purpose or to achieve a common goal.” According to Schroeder (1993), there are three primary characteristics of a DS. Those three characteristics are multiple computers, interconnections and shared state. As stated by Stelling, Foster, Kesselman, Lee and Laszewski (1998), a major difference between distributed and sequential computing is that in distributed computing individual components may fail without the entire computation being terminated. Stelling et al. (1998) point out that components may fail without the rest of the computation being aware that failure has occurred and that a challenge is that techniques are required for detecting and responding to component failures.
In Schneider (1993) a discussion on fault tolerance and distributed systems is given. It is stated that as the size of a DS increases, so does the number of components, and thereby the probability that some component will fail. Schneider (1993) states that protocols and system architectures that are not fault tolerant simply are not very useful in these settings. The author also points at the link between fault tolerance and DS in the opposite direction as well;
expressing that implementing a DS is the only way to achieve fault tolerance. According to Schneider (1993), all methods for achieving fault tolerance employ replication of function using components that fail independently. Schneider (1993) also states that failures can be detected only by replication actions in failure independent ways. The replication actions to detect failures, is divided in two categories, replication in space, and replication in time.
Replication in space is when components that are physically isolated and replication in time is the approach when a single device repeatedly performs an action. To determine that a failure has occurred, the condition is that the results of performing a set of replication actions, disagree. Although, the assumption can not be made that a failure has not occurred, if the replication actions agree, since some component may be corrupted, all according to Schneider (1993).
A concluding remark is that to handle and recover from fault in a DS, the fault has to be detected and the DS research area is concerned with this problem. Many years of research have yielded a considerable body of theoretical and practical knowledge of fault detection, handling and recovery techniques according to Stelling et al. (1998). In Andrews (2000) examples are given on algorithms for detection of terminated distributed computation.
2.3 Database concepts
In this section an overview of database concepts, related to this project is given. The main focus is the transaction concept.
2.3.1 Persistence
From the view of Database Management Systems (DBMS), Connolly & Begg (1999) state that a DBMS must provide support for the storage of persistent objects: that is, objects that survive after the user session or application program that created them has terminated. The same authors contrast persistent objects to transient objects that only last for the invocation of the program. Transient objects is described are retained until they are no longer requires, at
which point they are deleted. Persistence can also be applied to (object) code and to the program execution state. Connolly & Begg (1999) also state that including code in a persistent store potentially provides a more complete and elegant solution. However, according to Connolly & Begg (1999), without a fully integrated development environment, making code persist leads to duplication, as the code will still exist in the file system.
Connolly & Begg (1999) points out that having program state and thread state persist is also attractive but unlike code for which there is a standard definition of its format, program execution state is not easily generalized.
Connolly & Begg (1999) also give the following definition of data persistence:
“The ability for data to outlive the execution of a program and possibly the lifetime of the program itself” (Connolly & Begg 1999, p. 760).
2.3.2 Transaction
A transaction is to be seen as an action or a series of actions, carried out by a single user or application program, which accesses or changes the contents of the database. A transaction is the logical unit of work on the database. The main operations in a transaction are read and write data. There are two possible outcomes of a transaction. If the transaction completes successfully it is said to have committed and the database reaches a new consistent state. On the other hand, if the transaction does not execute successfully, the transaction is aborted (Connolly & Begg, 1999).
There are, as described by Haerder and Reuter (1983), four basic properties, called the ACID- properties, that all transactions should posses.
• Atomicity, a transaction is an indivisible unit that is either performed in its entirety or it is not performed at all, the “all-or-nothing” property.
• Consistency, a transaction must transform the database from one consistent state to another consistent state.
• Isolation, events within a transaction must be hidden from other transactions running concurrently. In other words, transactions execute independently of one other.
• Durability, once a transaction has been successfully completed and has committed its result to the database, these results must not be lost because of subsequent failure.
2.3.3 Nested transaction
As transactions represent the basic unit of recovery in a database system, according to the above definitions, Haerder and Reuter (1983) state that problems can be foreseen. This is an ideal condition that will be violated if transactions are not flat but nested, that is, composed of smaller sub transactions. These sub transactions also are atomic, consistent, and isolated. But, they are not durable. Haerder and Reuter (1983) states that since the result of sub transactions are removed whenever the enclosing transaction is undone, durability can only be guaranteed for the highest transaction in the composition hierarchy, therefore, these long transactions are consistent, isolated, and durable, but they are not atomic.
To achieve durability, the updates of committed sub transactions on intermediate levels must be visible only within the scope of their immediate parents. Additionally, a commit of a sub transaction is conditionally subject to the commit or abort of its superiors. Using this approach, top-level transactions conform to the traditional ACID properties, including durability. The main advantages of the nested transaction model are its support for modularity, which means that a transaction can be decomposed into a number of sub transaction for the purposes of concurrency and recovery, and its support for a finer level of granularity for concurrency control and recovery. Further main advantages are support for intra-transaction parallelism, which means that sub transactions can execute concurrently, and finally, intra-transaction recovery control entailing that uncommitted sub transaction can be aborted and rolled back without any side effects to other sub transactions. One way to emulate nested transactions is to use save points that the transaction can roll back to. The shortcoming of this approach is that save points does not support any form of intra-transaction parallelism (Connolly & Begg, 1999).
Transactions have different states during their lifetime. In Figure 2, a state diagram of a flat transaction is presented. There are two possible states where a transaction can terminate.
Either the transaction failed in some state, or the transaction succeeded and reaches the state committed before termination. If the transaction is nested, sub transactions are invoked during the state active. Each sub transaction has the same possible states as the top-level transaction, and the model can be viewed as valid for the nested transaction model as well.
Nested transactions can be closed-nested and open-nested. In the closed-nested model a transaction is only allowed to see results of their own sub transactions. In the open-nested
transaction model, each sub transaction makes its results available for all other sub transaction, immediately after its commitment.
Figure 2. Transaction state diagram (after Elmasri &Navathe (2000), and Gray and Reuter (1993).
2.3.4 Recovery
Database recovery is the process of restoring the database to a correct state in the event of a failure according to Connolly and Begg (1999). Failure can be caused by a lot of different events, and three types have been chosen for consideration, which are described in the following way by Haerder and Reuter (1983).
First there is transaction failure, which means that a transaction program does not reach its normal commit and has to reset back to its beginning. The second type is system failure, which can be caused by a bug in the code, an operating system fault, or a hardware failure. In each of these cases, processing is terminated in an uncontrolled manner and it is assumed that the contents of main memory, in the database, are lost. Finally, there is media failure. This type of failure leads to loss of secondary memory, and there are several causes for such a problem. The most common causes are:
• Bugs in operating system routines for writing the disk.
• Hardware errors in the channel or disk controller.
• Head crash.
• Loss of information due to magnetic decay.
These situations can be handled by full redundancy, that is, by a copy of the database and an audit trail (log file) covering what has happened since then (Haerder & Reuter, 1983).
Other causes can be sabotage, carelessness and natural physical disasters (Connolly & Begg, 1999). Haerder and Reuter (1983) point out that the list of anticipated failures will never be complete because of different reasons. Two examples of these reasons are that for each set of failures that one can think of, there are at least one that was forgotten, and the fact that some failures are extremely rare. However, the recovery actions will look different depending on the type of failure.
Transaction UNDO: Transaction failure means that a transaction program does not reach its normal commit and has to reset back to its beginning. If a transaction aborts itself or must be aborted by the system during normal execution, the recovery action will be transaction UNDO. By definition, UNDO removes all effects of this transaction from the database and does not influence any other transaction (Haerder & Reuter, 1983).
Global UNDO: When recovering from a system failure, the effects of all incomplete transactions have to be rolled back (Haerder & Reuter, 1983).
Partial REDO: When recovering from a system failure, since execution has been terminated in an uncontrolled manner, results of complete transactions may not yet be reflected in the database. Hence, they must be repeated, if necessary, by the recovery component (Haerder &
Reuter, 1983).
Global REDO: This recovery action can also be called “archive recovery”. The assumption is that the database is physically destroyed. Therefore a restart from a copy that reflects the state of the database some days, weeks or months ago, must be done. Since transactions are typically short, there is no need to consider incomplete transactions over such a long time.
Rather the copy has to be supplemented with the effects of all transactions that have committed since the copy was created (Haerder & Reuter, 1983).
According to Connolly and Begg (1999) there are four, main facilities to use as assistance for recovery;
• A backup mechanism, which makes periodic backup copies of the database.
• Logging facilities, which keep track of the current state of transactions and database changes.
• A checkpoint facility, which enables updates that are in progress to be made permanent.
• A recovery manager, which allows the system to restore the database to a consistent state following a failure.
2.3.5 The ECA-model
A traditional DBMS that executes commands (e.g. query, update, delete) as and when requested by the user or application program, is to be considered passive. As described by Paton and Diaz (1998) active databases move reactive behaviour into the DBMS and are thus able to monitor and react to specific circumstances of relevance to an application by supporting mechanisms that enables the system to respond automatically to events taking place either within, or outside the database system itself. The model that has been used for specifying active database rules is referred to as the Event-Condition-Action, or ECA model, according to Elmasri and Navathe (2000, p. 735). A rule consisting of all three components is called an ECA-rule. The event part of a rule describes a happening to which the rule may be able to respond. The condition part examines the context in which the event has taken place.
The action describes the task to be carried out by the rule if the relevant event has taken place and the condition has evaluated to true. A rule consisting of only Event-Action is called a production rule and is not to be seen as active. According to Dayal, Hanson and Widom (1995) this production rule paradigm originated in the field of AI. Paton and Diaz (1998) state that an active database system must provide a knowledge model (i.e. a description mechanism), and an execution model (i.e. runtime strategy) in order to support this active behaviour. Paton and Diaz (1998) state that the knowledge model indicates what can be said about the active rules in a system, the active functionality, while the execution model determines how a set of rules behaves at runtime. The phases in rule evaluation (Figure 3), as described by Paton and Diaz (1998) are;
• The signalling phase that refers to the appearance of an event occurrence caused by an event source.
• The triggering phase that takes the event produced so far, and triggers the corresponding rules. The association of a rule with its event occurrence forms a rule instantiation.
• The evaluation phase that evaluates the condition of the triggered rules. The rule conflict set is formed from all rule instantiations whose conditions are satisfied.
• The scheduling phase that indicates how the rule conflict set is processed.
• The execution carries out the actions of the chosen rule instantiations. During action execution, other events can in turn be signalled and may produce cascade rule firing.
Figure 3. Rule execution (after Paton & Diaz, 1998)
2.3.6 Two-phase commit protocol
A common protocol for commitment of distributed transactions is the two-phase commit protocol (2PC). In Chrysanthis, Samaras, and Al-Houmaily (1998) the 2PC is described in detail. As implied by the name the protocol consists of two phases, a voting phase and a decision phase (see Figure 4). During the voting phase, the coordinator of the transaction requests that participators in the execution of the transaction prepare-to-commit. When a participant receives a prepare request, it validates the transaction with respect to data consistency. If the transaction is validated, the participant sends a yes vote. Otherwise it sends a no vote and aborts the transaction. In the decision phase, the coordinator either decides to commit the transaction if all participants are prepared to commit (voted yes) or to abort if any participant has decided to abort (voted no). On commit decision, the coordinator sends a commit message to all participants whereas on abort decision, an abort message is sent only to
those participants, which voted yes. If a participant voted yes, it can neither commit nor abort the transaction until it receives the final decision from the coordinator. When a final decision is received, the participator complies with the decision and sends an acknowledge message.
When the coordinator receives acknowledgements from all participants that voted yes, it completes the protocol and forgets the transaction by discarding all information pertaining to the transaction from its protocol table.
Figure 4. The basic two-phase commit protocol (after Chrysanthis et al. 1998).
3 Problem description
This chapter presents the problem and the stated aim and objectives for this project. The chapter also includes the method and approach for the work.
3.1 The problem
In accordance with the proposal made by Brodie (see chapter 1) a claim is stated that both AI and DB communities can benefit from incorporating features from each other’s areas. From a DB view, the handling of complexity in today’s information systems are aided by incorporating AI features, and database environments could gain in flexibility by entrusting some of their functionality to agent systems. Contemplated from the AI view, agent systems could gain in robustness by being based on DB-systems. The sparse exchange of ideas between the AI/DB communities (se chapter 1) imply that there is not much work done on giving concrete examples of how concepts and solutions can be applied from AI to DB and vice versa. In this project an attempt is made to cross the boarder between AI/DB communities by supplying a concrete example of how some concept from DB-theory can be adopted to address a related problem in MAS-theory.
In a MAS, as well as in a DB system, failures occur and need to be handled. This need stems from the requirement of ensuring a correct behaviour of the system, which in turn is a necessity for solving the problems or achieving the goal of interest in an appropriate way.
Both agent interactions (section 2.1.2) and DB-transactions (section 2.3.2) can fail. There is also a clear connection between agents cooperating, for solving a problem or achieving a goal in a MAS, and the way to perform interaction in DB-theory, carrying out transactions. In both cases there exists a need to ensure that information, about what the interaction are supposed to bring about, reach its destination. It is also important that actions are performed in a correct manner; if not some alternative action must be resorted to ensure that no malicious effects are caused in the system. The area of recovery from failure is well investigated in DB research, but in MAS research, the area does not have the same coverage. There is a lot of research reported on work for finding solutions for achieving robust systems, e.g., Nagi (2001), Chen and Dayal (2000), Kaminka and Tambe (1998), and Hägg (1996). Although, no reports on successful solutions, dealing with the robustness concept and recovery from failure, actually implemented and working in MAS is found. This fact indicates that the solution to the
problem is yet to be found. If this work shows feasible, it is hopefully contributing to the possibility of taking advantage of DB-techniques for reinforcement of robustness in multiagent systems.
Focus of the work in this project is on the interactions between agents. Attention is also paid to the situations where some interaction is unsuccessful, i.e. interaction failure while the approach in this project is to provide the semantics from DB-transactions to all agent interactions in a generic MAS. An assumption is that agents in the system work under a task sharing protocol and uses contract net protocol for cooperation The reason and motivation, for making this assumption and use this protocol, is the following; task sharing formulating tree structures of sub tasks to be performed by different agents are very similar to how transaction trees are consisting of sub transactions, and contract net protocols give a clear view of how the tasks are assigned to the cooperating agents by negotiation. Additionally, the protocol is classical, well functioning and documented.
3.2 Aim
The aim of this project is to investigate what the consequences are of applying the semantics of database transactions to interactions between agents in MAS, working under the classical task sharing cooperation strategy and using contract net as interaction protocol. How failures of these interactions are handled is also investigated.
3.3 Objectives
In this section the objectives identified, as means to fulfil the aim of the project is stated. The first three objectives employ a database view, and concern the semantics of the concepts of interests, while the fourth objective has a stronger focus on implementation. The next section provides a more detailed presentation of the objectives.
1. The first objective is to apply the semantics of DB transactions to the interactions between agents.
2. The second objective is to investigate the possibility of a seamless integration, between DB-transaction concept and agent interactions, or if there is indications that modification is needed.
3. The third objective is to investigate if applying DB-transaction semantics affects any, possibly found, problem situations in case of interaction failure.
4. The fourth objective is to investigate how interaction failure is handled in practice in some existing system.
3.4 Method and approach
The approach for fulfilling the aim is to model and investigate a generic example of a MAS under task sharing strategy for cooperation and using a contract net interaction protocol. An alternative approach could be to actually perform an implementation of contract net protocol as DB-transaction. The reason for choosing the first approach is that there are no further gains, with respect to the aim of this project, in performing an implementation. The following steps will be taken in order to fulfil the first objective.
• Model an agent and its interactions with other agents under contract net protocol, as state diagram in order to derive a view over the dynamic changing of roles during the problem solving. The reason for choosing this type of modelling is that the technique gives a good picture over both agent states and the reasons that cause the changes of state. State diagrams are also widely used and there are modelling examples that can be used as input for this work.
• Specify and model an example of a task to be solved by a number of agents using contract net protocol.
• Re-model the example with DB transaction semantics on the interactions.
To fulfil the second objective a comparison and analysis of the models resulting from the previous objective will be done in order to find out if there is situations where modifications are needed in order to successfully carry out the applying of DB-transaction semantic. An attempt to propose what these possible modifications may consist of will be done.
The third objective will be fulfilled by identifying the critical situations, for successful solving of a task, in case of some agent halting its execution, i.e. drops out. If these problems remains or is solved by applying transaction semantics will be investigated. An alternative approach would be to investigate problem situations in case of failing interaction in general. To investigate failing interactions in general, efforts need to be placed on low-level implementation details concerning data communication. The reason for choosing to investigate the situation of agent drop-out is that reaching the aim of this work has no additional benefits from the second approach.
To fulfil the fourth objective, investigating how interaction failure is handled in practice, an existing system will be studied. To fulfil the objective two alternative methods are feasible.
The first method is to study documentation of the system and the second method is to study the system under work. Since there is documentation of systems accessible and system tests are not necessary to fulfil the objective the first method is chosen. Focus will be placed on the semantic level of the system since low-level implementation details fall outside the scope of this project.
4 Investigating an example
In order to apply the semantics of DB transactions to interactions between agents (objective one) an example is set up. This chapter starts with a detailed revisit of the task-sharing strategy and the contract net protocol since both is used for the example. An example of a task to be solved by a number of agents using contract net protocol is described as well as problematic situations in case of drop out of some agent.
4.1 Task sharing
Smith and Davis (1988) describe task sharing as a form of cooperation in which individual nodes assist each other by sharing the computational load for the execution of subtasks of the overall problem. Control in systems using task sharing is, according to Smith and Davis (1988), typically goal directed, i.e. the processing done by individual nodes is directed to achieve sub goals whose results can be integrated to solve the overall problem. According to Weiss (1999) there are four main steps in the task-sharing strategy.
• Task decomposition
• Task allocation
• Task accomplishment
• Result synthesis
In the first step, task decomposition, the set of tasks to potentially be passed to other agents are generated. Generally, this involves decomposing large tasks into subtasks that can be 0tackled by different agents. Task allocation is the step when subtasks are assigned to appropriate agents. Next step, task accomplishment, concerns that appropriate agents each accomplish their subtasks. This accomplishment could include further decomposition and task assignment recursively to the point that an agent can accomplish the task it is handed alone.
The last step, result synthesis, takes place when an agent accomplishes its subtask and passes the result to the appropriate agent. The appropriate agent is usually the original agent, since it knows the decomposition decisions and thus is most likely to know how to compose the results into an overall solution. Weiss (1999) notes that depending on the circumstances the difficultness of the different steps may differ. For example, the allocation step may be trivial;
sometimes the agent can pass tasks off to any of a number of identical agents. Another
example is if accomplishing the task does not yield any results that need to be synthesized in any complex way.
4.2 Contract net
Even though task sharing seems to be a quite straightforward strategy for problem solving there is a key issue to resolve. The issue is how tasks are to be distributed among the agents.
There must be a means whereby agents with tasks to be executed can find the most appropriate idle nodes to execute those tasks. Smith and Davis (1988) call this issue the connection problem. Smith and Davis (1988) considered negotiation as a mechanism to solve the connection problem and developed the contract net protocol (CNP), where contracts are established by a process of local mutual selection based on a two-way transfer of information.
There are two roles that an agent can take using contract net protocol for negotiation. An agent that wants a task solved is called the manager, agents that might be able to solve the task is called potential contractors. The process from a manager’s perspective is, according to Weiss (1999):
• Announce a task that needs to be performed.
• Receive and evaluate bids from potential contractors.
• Award a contract to be a suitable contractor.
• Receive and synthesize results.
The process from a contractor’s perspective is described by Weiss (1999) as:
• Receive task announcements.
• Evaluate capability to respond.
• Respond, either decline or bid.
• Perform the task if the bid is awarded.
• Report results.
FIPA (2001a) presents a specification of Contract Net Interaction Protocol based on the protocol originally developed by Smith and Davis (1988). A representation of this protocol is given in figure 5. FIPA Communicative Act Library Specification (FIPA, 2001b) provides full descriptions, formal models, and examples of the acts of communication (speech acts) between agents in CNP. One reason for choosing the protocol as defined by FIPA is that
FIPA provides full documentation of the protocol. Another reason is that the FIPA specifications are well known and used. For more information about the FIPA organisation, please se FIPA (2002). An overview of the speech acts is now to be presented.
The interaction starts with call for proposal (cfp), which is a message that specifies information about the task and possible conditions, sent by the initiating agent. The participating agents receiving the call send back an answer-message, which may be a proposal, to the initiating agent. The proposal-message contains a description of the action the sender is proposing to perform and also a representation of the preconditions on the performance of the action. There are two more types of messages that can be sent as answers from agents receiving a cfp. Those two are not understood and refuse which, in both cases, contains explanation of the reason for the message. Once a deadline is passed the initiator evaluates any received proposals and select contractor(s) to perform the task. Participators in the biding gets accept or reject proposal message. Proposals received after expiring of deadline is automatically rejected. Once an accepted contractor has completed the task, it sends an inform-done message to the initiator. The two alternatives are failure message, containing information about reason for failure to perform the task, and inform-ref message containing some object description as a referential expression.
Figure 5. Contract Net Interaction Protocol (after FIPA, 2001a).
The interaction protocol presented in figure 5 is a pattern for a simple interaction type. Real world issues e.g. cancelling actions, abnormal or unexpected termination of the interaction protocol are not explicitly addressed in FIPA (2001a).
In figure 6 a state diagram is presented that visualizes this dynamic behaviour of an agent taking different roles under the problem solving process. This state diagram is coherent with the FIPA definition of CNP (FIPA, 2001a.) with one exception. The exception is that the interaction inform-ref is neglected since the assumption, for this project, is that inform-ref interaction can be assimilated to the inform-done interaction.
Figure 6. State diagram over an agent using CNP.
4.3 Task and agents in the example
The task and agents presented in this section is serving as a basis for the work aiming at applying transaction semantics to the agent-interactions in a MAS. The assumption made is that the task is decomposable to kernel subtasks, possible to solve by individual agents, in other words appropriate for task sharing. The CNP can also be nested which will be the case in the given example. Since the focal point in this project is the interactions between the agents in the system, no attention is paid to what the task consists of (i.e. what the problem to solve is). In the example no attention will be paid to interactions that do not lead to a contract.
Those interactions would not give any increased value in order to fulfil the aim of this project, by ignoring these interactions a more legible overview, of the example, is reached. Another assumption, concerning the example, is that all agents are in possession of skills to solve any subtask and that no respect is paid to different costs for different agents to execute some task.
As a corollary from these assumptions and the aim of this project, there is no need for an
example with lot of agents and subtasks. A small example will serve its purpose for this work and is built and investigated in this section.
4.3.1 Failure model considered
There can be different causes for interactions to fail. In order to sort these causes out, and elucidate a failure model for the work in this project, help is taken from the research area of Distributed Systems (see section 2.2). An overview of failure models is given in Schneider (1993). Hadzilacos and Toueg (1993) provide a discussion of failures in DS as well. To give a brief overview of failure concepts in DS it can be stated that different types of failure have different gravity on the situation in the system and there are two extremes on the scale. The most severe type of failure is the so-called Byzantine failure that causes arbitrary behaviour of the faulty component and can be malicious. In the opposite end of the severity scale for failures, least severe, crash and fail stop is found. If this type of failure occurs the component just stops working. This type of failure does not result in any malicious behaviour. This is the type of failure that is considered in this project since it also corresponds to the view of agents presented in section 2.1.1. Hence, as delimitation for this project, it is assumed that agents may drop out from the system without causing any further harm. It is also assumed that corrupted messages are not to be considered. If a message reaches its destination, the message is correct and received as the sender intended it. The reason for those delimitations is that in order to fulfil the aim of this project there is no gains to be made by explore details of those areas since they concern low-level implementation, well investigated in DS-theory. Examples of literature related to this area are Mullender (1993), and Burns and Wellings (1997).
As a corollary from this section, for the rest of this project, an agent is regarded as dropped out when it has halted its execution without reaching a final state, according to figure 6.
4.3.2 Task decomposition and allocation
An arbitrary Task1 is the overall problem to be solved, and AgentA is the manager of the same and have made decomposition into subtasks Task1.1 and Task1.2. AgentA has decided to delegate both Task1.1 and Task1.2 to other agents and as a result from negotiation (CNP), AgentB is now contracted for Task1.1 and AgentC for Task1.2. AgentB and AgentC are executing the allocated subtasks in parallel. The situation described is illustrated in Figure 7.
Figure 7. First decomposition and allocation
From the view of the FIPA standard for CNP, a closer look at the described situation reveals that some problems, in case of drop-out of some agent, can be foreseen. According to the protocol, a number of interactions between the manager, AgentA, and the participators, AgentB and AgentC, have to take place in order to establish the contracts of Task1.1 and Task1.2. If these interactions don’t take place in a correct manner, performance of the task of interest is jeopardized.
AgentA has sent a message of type cfp that initiates the negotiation. Following the FIPA Communicative Act Library Specification (FIPA 2001b), cfp-message includes identifiers for receiving agents of the message. For this example it is not interesting to pay attention to if there were other agents than AgentB and AgentC receiving the cfp. Confirmation of cfp- messages followed when AgentB and AgentC sent propose-messages to AgentA. If there had been a drop-out situation on AgentB or AgentC, the risk of infinite waiting for AgentA was guarded by a deadline. Next step in the interaction was more vulnerable. AgentA has sent accept-proposal to AgentB and AgentC. If AgentB or AgentC had dropped out after sending the proposal message, AgentA would not have knowledge about it. In that situation AgentA may be left in infinite waiting. The situation in Figure 7 supposes that AgentB and AgentC did not drop-out, but received the accept-proposal message.
As a summarization, from this first step of decomposition, it can be noted that a weak point, during negotiation, is found if the situation occurs that agent drops out after making a proposal.
In the next phase of the decomposition AgentB and AgentC act as managers for, respectively, Task1.1 and Task1.2. As in previous decomposition of Task1, Task1.1 and Task1.2 is now decomposed in two subtasks each. Task1.1.1 and Task1.1.2 are now decomposed to kernel subtasks and are represented as leaf nodes in the tree hierarchy. The same is the situation for Task1.2.2. Task1.2.3 is decomposed once more and leaf nodes are reached in decomposition into Task1.2.3.1 and Task1.2.3.2. The decomposition is complete and illustrated in Figure 8. The figure also gives a view of the allocation of tasks to the different agents. As can be seen in Figure 8, it is not necessary for agents to negotiate for contractors for subtasks. The agents may as well stay responsible for performing some subtask.
Returning to the four steps in task sharing (section 4.1) the situation described in Figure 8 is that the first two steps, task decomposition and allocation, are achieved. The third step, task accomplishment is now to be performed by the agents responsible to each leaf node in the hierarchy.
Figure 8. Complete decomposition of the task, and allocation of subtasks to agents.
4.3.3 Result synthesis
The fourth step in task sharing (see section 4.1) is result synthesis. The complete synthesis is illustrated in Figure 9 were dotted arrows symbolize this step. Synthesis of the task is initiated at the leaf nodes of the tree hierarchy, and by the agents allocated at the specific nodes. In this example it is assumed that Task1 is successfully synthesised. According to the CNP the initiation takes place in form of a message where result from the task is reported to the allocating agent. This step is a vulnerable part of the result synthesis. As an example the node where AgentD is responsible for Task1.2.3 (see Figure 8), is considered. If AgentB has dropped out at some point before sending a message about result, failure or success of Task1.2.3.1, AgentD has no opportunity to synthesise this branch of the tree hierarchy, which leads to inability to send a message, upward in the hierarchy, to AgentC about results from Task1.2.3. This drop out of AgentB leads to, in its prolongation, that it is not possible for AgentA to synthesise Task1. In the case where no agents drop out, before sending the message concerning results, AgentA are, finally, able to synthesise Task1.1 and Task1.2 and evaluate whether Task1 is a success or failure.
Figure 9. Result synthesise of the task.
In the example (see Figure 9) only the messages that lead to successful performance of the task and its subtasks were considered. The messages refuse, not-understood, reject-proposal and failure also need to be taken care of by the receiving agents. Depending on what information the different messages contain, the receiving agent has to make decisions and take actions. Those decisions and actions are governed by the agent’s behaviour. In section 2.1.1 the agent property reactivity is described. This property is of importance for taking care of and making decisions on the basis of the content of the messages. The actions taken, triggered by messages, depend on the design of the agent’s behaviour.
4.3.4 Problem situations in the example
Relating the example to the agent state diagram in figure 6, occurrence of drop-out of a participating agent from the state wait for answer, in the case were the initiating agent decides to send accept-proposal message, until the participating agent reach some of the final states are devastating for execution of the task. The reason is that the initiating agent, according to the protocol, is not informed about the drop-out and remains in the state wait for results. This problem is not addressed by the protocol, rather the problem of drop-out agents is up to the designer of the system to solve.
5 Applying transaction semantics to the example
In this chapter the work on applying DB transaction semantics to agent interactions, following contract net interaction protocol is presented. The results from this work are used as input to the work on the second and third objective.
5.1 The chosen transaction model
In section 2.3.4 different types of failures were described in a database-context. The type of failure considered in this example, drop-out of an agent, is to be regarded as a partial system failure. This type of failure causes an uncontrolled termination of the transaction processing.
To handle this type of failure in DB-systems the concern is to, first of all, detect the failure and secondly to perform recovery. The approach when applying transaction semantics is to regard a task as a transaction.
To apply the semantics of transaction to agent interactions in the example, presented in chapter 4, the first step is to identify an appropriate transaction model. The type of task used as example in this work, result in a recursive structure itself where leaf nodes in the tree structure are the kernel problems to be solved. This fact indicates that the nested transaction model is an appropriate choice.
The most restrictive variation of nested transactions is the closed-nested transaction model.
Under this model, sub transactions are allowed to execute in parallel within their parent transaction. Sub transactions are only allowed to see results of their own sub transactions. In this model the internal nodes serve as save points for the execution of the transaction tree.
This means that the whole transaction tree does not need to be undone in case of a sub transaction failure, but causes that sub transactions lack the ACID-property durability. In the open-nested transaction model, each sub transaction makes its results available for all other sub transaction, immediately after its commitment. This model results in relaxation of all the ACID-properties (see section 2.3.2), and causes a need for compensating actions. Since there are no needs for making results available to all sub transactions, in the example in this work, there is no benefit in adapting the open-nested transaction model. Therefore the more strict closed-nested transaction model is assumed to be used and in order to achieve commitment of a transaction, or sub transaction, it is assumed that a handshake protocol with acknowledgement is used.
5.2 The transaction tree
When executing a task, the agents perform operations besides interaction with other agents, e.g. the actual execution of the task and evaluation of proposals. In constructing the transaction tree these operations is neglected since this is beyond the scope of this project.
Attention is paid to the interactions.
Task1 is to be considered as top-level transaction, as illustrated in Figure 10, and AgentA has the responsible as transaction manager for this transaction. As the sub transactions are delegated to different agents, so is the transaction manager function for the delegated sub transaction. The cfp and proposal are considered to be atomic sub transactions. The cfp sub transactions are invoked when the responsible agent decides to delegate some task. Since the agent acting as transaction manager does not initiate the proposal interaction, the invocation of this sub transaction is to be seen as triggered by an external event, i.e. another agent sending a proposal. In the example it is assumed that the number of cfp sub transactions can be at most 2x3 since Task1 is decomposed into two subtasks and there are three agents in the community, since the exception of the agent sending the cfp. In the example there are two more interactions, accept-proposal and inform-done. These are considered as one sub transaction where accept-proposal invokes, and inform-done commits the sub transaction.
During this type of sub transaction the transaction-tree branch further in the cases when the subtask is decomposed even more.
The joint ordering of all sub transactions, related to a specific subtask, has to obey the ordering in CNP. Ordering of sub transactions related to different subtasks is allowed to interleave. A condition, for the joint ordering, that must hold is that serializability is achieved.
According to Weihl (1993), serializability means that the effect of executing a group of transactions concurrently is the same as executing them sequentially in some order.
Figure 10. The transaction tree.
5.3 Results from the transfer
In order to apply the DB transaction semantics a generic example of task sharing agents under contract net interaction protocol was modelled and studied. The example shows that successfully solving of a task is severely threatened if a participating agent drops out during specific states. Those states are from the point where a managing agent has sent accept- proposal until the participating agent reaches some of its final states (see figure 6). The reason for the severity in case of drop-out is that the participating agent, during these states, has full responsibility for the delegated task. The managing agent has no possibility to control progress in solving the task until the participator sets up a new interaction to inform about results. This problem originates from the fact that the protocol has no function for controlling successful deliverance of messages and this problem is left to the designer of the system to solve.
In the work on applying the DB transaction semantics to the example, a task, before decomposition, is modelled as a top-level transaction and the subtasks as sub transactions in a transaction tree. By using DB transaction semantics for modelling, focus moves from the agents to the tasks, and the view of responsibility for a task changes. The managing agent takes the role of transaction manager, which results in that the responsible for a task, or subtask, is moved from the participating agent, and allocated the task of interest, to the managing agent.
5.4 Seamless integration or modifications needed?
As described in previous section a managing agent takes the role of transaction manager. A modification is needed to handle the proposal interactions from participating agents. The reason for this modification is that the interaction proposal does not have a natural fit in the transaction model since the agent, acting as transaction manager, is not the initiator of this interaction. A solution to this situation is to use the ECA-concept (see section 2.3.5) where the Event proposal triggers invocation of some Action, i.e. reject or accept proposal, if some Conditions are satisfied, i.e. proposals evaluated and decision made about what proposals is to be accepted or rejected. In this way the agent acting as transaction manager, is responsible for the sub transaction proposal as well. According to Weiss (1999, p.49) the reactivity behaviour (section 2.1.1) of agents often are implemented as rules of the form;
Situation action,
e.g. behaviour activity in ARCON system (Jennings, 1994), and conversation rules in COOL (Barbuceanu and Fox, 1995). Therefore no critical novelty is introduced by suggesting this modification even if those concepts not necessary are fully compatible. Except this modification the integration has shown possible to accomplish seamlessly as far as this project scopes.
5.5 Affected problem situations
By using a handshake-protocol with acknowledgment in order to commit sub transactions, the risk for the managing agent to be left in infinite wait is reduced. Returning to the state diagram (figure 6) over an agent under CNP, the problem occurred if the participating agent drops out at the state wait for answer after sending a proposal. By using the suggested
protocol the manager of the task has a possibility to detect if the participant has dropped out since sending the proposal, hence the risk for infinite wait does not occur if the participant has dropped out before the manager sends accept-proposal. The manager has the possibility to accept proposal from some other participant. In this way the problem of infinite wait may be reduced, but remains with unchanged gravity in the case where the participant drops out in some later state.
