Task Sharing Among Agents Using Reactive Rules - Semantic Scholar

Task Sharing

Among

Agents

Using

Reactive

Rules

Mikael Berndtsson Department of Computer Science University of Sk&de, Box 408, 541 28 Sk&de, Sweden [email protected] Sharma Chakravarthy Database Systems Research and Development Center Computer and Information Science and Engineering Department University of Florida, Gainesville FL 32611 [email protected] Brian Lings Department of Computer Science University of Exeter, Exeter EX4 4PT, U.K. [email protected]

Abstract

chine) for obtaining their solutions. Briefly, cooperative problem solving (CPS) is a complex activity requiring harmonious and dynamic interaction between human agents (providing sequencing, decision making, and collaboration components) and computing agents (providing inferencing, algorithmic computation, coordination, and data/knowledge storage). It is viewed in this paper as a generic problem whose instances include workflow problems, problems in office automation, concurrent engineering, multi-agent problem solving etc. By definition, a problem in this category cannot be solved without cooperation among the problem solving agents (PSAs) although each agent is autonomous and capable of sophisticated problem solving. In [30] a distinction is made between two types of cooperation: task shared and result shared. Briefly, task-shared cooperation means that a problem is decomposed and assigned to an agent for solving based upon the agent’s capability (it is assumed that each node has domain specific knowledge). This is in con-

Coordination and collaboration are naturally used by groups for carrying out activities and solving problems that require cooperation. However, getting a set of computer agents to do the same has been a problem - primarily addressed by the AI community and recently by the database community as worlcfow and process management problems. Not surprisingly, the problem has been addressed at different levels of abstraction by the two communities. It is evident that there is a need for bringing the two approaches together to develop cooperative information systems. This paper: - argues for the use of active databases as an enabling technology for cooperative information systems, - details a novel approach for supporting taslc sharing, a hey cooperation strategy within cooperative information systems, using active capability, - elaborates on a methodology for mapping task shared protocols expressed in high level speech acts to eventcondition-action rules.

trast to result-shared cooperation where nodes assist each other in solving a problem by sharing partial results. The objective of cooperative problem solving is

to minimize the use of human agents and maximize the use of computer agents to solve a problem belonging to one of these categories. This problem is currently being addressed by both the AI and database research community at different levels of abstraction. The former has concentrated on

1. Introduction A number of problems in electronic commerce, office environments, medical diagnosis, and planning require cooperation among agents (either human or ma-

O-8186-7946-8/97

$10.00 0 1997 IEEE

56

Proceedings of the 2nd IFCIS International Conference on Cooperative Information Systems (CoopIS '97) 0-8186-7946-8/97 $10.00 © 1997 IEEE

our work with respect to these.

cooperation issues and has not addressed the need for databases and manipulation of data. On the other hand, the latter approach has very limited or no support for advanced types of cooperation and coordination. We believe that cooperative information systems will have to deal with both databases and CPS features in applications such as business processes, electronic commerce, logistics, and medical care. A bidirectional approach, encompassing as it does different perspectives, will be beneficial in the long-term. It is likely that integration of the results obtained from these communities will enable the delivery of resilient systems which are geared towards real-life problems. We consider active databases (ADBMS) as an important core technology for problems addressed within cooperative information systems that need both database support and mechanisms for CPS. ADBMS has been proposed as an approach to support ECA (event-condition-action) rules in database systems. The semantics of ECA rules are: when an event E occurs, evaluate condition C, and if the condition is satisfied, then execute action A. The applicability of the ECA rules paradigm has been extensively explored in the context of database systems and has recently triggered ECA related activities in other research communities such as real-time [9], workflow [ll], and cooperative problem solving [12, 61. In this paper, we argue for the use of ADBMS as an enabling technology for cooperative problem solving and cooperative information systems. Based on the architecture provided in [12], we describe the details of realizing that architecture using the reactive paradigm proposed by the active database community [l, 25, 28, 31, 21. We present details of a novel approach for supporting task sharing, a key aspect of CPS, using active capability. In particular, we elaborate on a methodology for mapping task shared protocols expressed in high level speech acts to ECA rules. The authors work on use of active databases for supporting result shared cooperation has been reported elsewhere [7].

2. The

Chosen

2.1

Three phases of CPS

Three different phases of the cooperative problem solving process can be identified: negotiation, execution and the reporting of results. Negotiation takes place as an initial phase to allocate tasks to problem solving agents. This is usually specified by a high-level communication language such as the Contract Net Protocol [29]. This phase can be quite complex if one assumes tasks whose decomposition first needs to be negotiated among agents whose capabilities are unknown to each other. Not knowing whether a solution exists adds another level of complexity. There must follow a distribution/allocation of tasks based on the negotiation (task shared cooperation). Execution refers to the actual problem solving process, in which problem solving agents may share partial results (result shared cooperation). Result reporting is a feedback phase where the success or failure of a problem solving process is managed. This may also include selection of results/partial solutions by consensus or other means if more than one agent is solving the same problem/subproblem (task and result shared cooperation).

2.2. Static and Dynamic Allocation of Tasks Based on the ability to decompose a task by an agent, the dynamics of task shared cooperation can be broadly classified into: 1. Static allocation, which assumes that a problem is posed to a specific agent, which acts as the manager. The manager generates a complete hierarchy of tasks. Thus it is assumed that the manager knows how to decompose a task into a hierarchy of subtasks. During the execution of tasks/subtasks the manager coordinates events from the PSAs which are executing the allocated tasks.

Problem

In the literature, the problem of coordination is conventionally exemplified by task sharing and most of the proposed protocols are driven by task sharing. Hence, we have chosen task sharing to demonstrate that our approach provides a common framework for supporting coordination. Below, we summarize three facets of CPS proposals elaborated in the research literature and then position

allocation (predetermined), which relies on a cooperation protocol such as the Contract Net Protocol (CNP). CNP itself implies that the allocation of tasks becomes dynamic. Each structure (manager/contractor) is dynamically composed. Hence, a contractor can in turn act as a manager and allocate subtasks to other

2. Dynamic

57


result reporting phases above. Support is required for predetermined, dynamic allocation of tasks, using the protocol-oriented approach. Finally, support is to be provided by the active layer of an object-oriented database system.

PSAs. This will form a dynamically derived hierarchy of task allocations. However, a top level problem is still posed to one agent, which becomes the manager for the top level problem. Thus, the responsibility for solving the posed problem is predetermined.

3. Methodology

allocation (general DAI), which 3. Dynamic provides the most general form of collaboration as compared to the previous approaches. In this approach a problem is posed to all PSAs. Each PSA then tries to come up with its own solution to the problem. It further implies that the PSAs need to cooperate in order to find the best solution, and in particular to agree which of them should be responsible for the top level problem.

We wish to support task shared cooperation with protocols expressed in high level speech acts. We therefore need to be able to map these speech acts to ECA rules. We use a three step method for the mapping procedure: model high-level speech acts by state diagrams. Using state diagrams as the modeling technique has several advantages: i) most speech act based protocols are already modeled in high level state diagrams. Thus, they can be used as input to our method. ii) state diagrams are supported by the common software engineering methodologies for modeling dynamic behaviour.

2.3. CPS Protocols A protocol defines the structure logue among agents [24].

of the dia-

There is a broad spectrum of proposals for supporting cooperative problem solving, ranging from cooperation in workflow-oriented systems to cooperation in DA1 applications. One interesting aspect is that as one moves towards DAI, suggestions for CPS performatives begin to appear in the proposals. At one point there is a switch to pure CPS protocols for task sharing, as exemplified by COOL [4] and Contract net [29]. There are different approaches for implementing cooperative features: l

l

extract object model, algorithms and event hierarchies. For the object model, we rely upon the OMT modeling and design technique [26]. Algorithms and event hierarchies are then inferred from the object model and state diagrams. generate ECA rules. We provide a set of active database functionalities that are of importance when a protocol for task sharing is realized in an active database management system.

This approach implies that each application is augmented with cooperative features. Thus, all communication and coordination mechanisms for supporting cooperative work have to be built from scratch. Although the object-oriented paradigm offers the designer concepts such as reuse, (almost) all systems built according to this approach are built in an ad hoc manner and cannot be reused in other applications. application

oriented.

3.1. STEP 1: Model Speech Acts 3.1.1

The

Chosen

Benchmark

Protocol

There are several proposals for negotiation language primitives in the literature. Negotiation primitive have been suggested for a range of applications such as supply chain for manufacturing enterprises [3], and distributed medical care [18]. Given the range of applications a number of application specific negotiation primitives have emerged. According to a classification made in [23] all primitives can be broadly divided into the following three categories:

protocol oriented. This approach assumes that the cooperative features are modeled in a protocol which is independent of the application. Thus, once the type of cooperation has been modeled by a protocol it can be reused in other applications. Typically, these protocols are based on the theory of speech acts [27].

l

2.4. Research Goals Our earlier goal can now be refined to that of supporting task sharing aspects of the negotiation and

l

58


Initiators; primitives that initiate a negotiation, e.g., Propose, Arrange, and Request. Reactors; primitives that react on a given statement, e.g., Answer, Refine, Bid, and Reply.

l

Figure 1 presents a high level finite state machine In this high (FSM) of our coordination protocol. level FSM, we adopt the notation from [3] to denote < received - speech - act > / < sent - speech - act >. Typically, the negotiation starts when an agent receives the speech act propose from a Manager. In response to received speech act, an agent can then either accept, reject, or issue a counter-propose. In case of a counter-propose the Manager can either accept, reject, or issue another counter-propose. Based on the received bids, a Manager can either award an agent the task or notify the agent that it was not awarded the task cancel. An agent can report the outcome of the problem solving phase (or execution of the task) by sending either a fail or satisfy to the Manager. W e next provide the details of the FSM for our coordination protocol and how the dynamic behaviour is mapped into ECA rules.

Completers; primitives that complete a negotiation, e.g., Confirm, Accept, and Reject.

In addition to the above categories, there is a fourth category that is concerned with notification of the outcome of the execution of the task, e.g., fail, and satisfy. For the current work we take a benchmark protocol based on the Contract Net [29], and the approach taken in COOL [5, 31. The benchmark protocol can be viewed as a generic negotiation protocol as it encompasses primitives from all of the above four categories, and the most common phases of negotiation. The semantics of the speech acts in our benchmark protocol are: l

l

Propose. Initiates the negotiation by proposing a task to be solved by an agent(s). Counter-propose. The initial proposal can be refined by issuing a counter-proposal.

3.1.2 l

l

l

l

l

l

Details

of FSM

Signals acceptance to a previously distributed proposal or counter-proposal. Accept.

Agent(Mansger) do: set up Con1w1

Signals rejection to a previously distributed proposal or counter-proposal. Reject.

Award. Used to send a confirmation to an agent that it has been awarded a previously distributed proposal (which may have been refined by several counter proposals).

Agent(Manager)

Figure 2. Distributing

Used to send a cancellation to agents that were not awarded a previously distributed proposal. Cancel.

Fail.

[potentialcontractors] /propose

do: find potentialcontmctors

-0 0

a proposal

Assume that a task T is posed to an agent (see Figure 2). First, the agent will try to execute task T locally. This implies that the agent determines whether it has capacity/capability to execute task T. If it does not, then it needs to allocate the task to another agent(s). This situation will trigger a negotiation process among the agents. The agent that needs help will hereafter be referred to as the Manager. The Manager collects and prepares relevant information about the task that it cannot solve. During this phase an overall task is further decomposed into n subtasks. The outcome of this initial process will be a specification of the subtasks. Each subtask will be modeled by a Contract. A Contract describes the various states of the negotiation process for a given subtask, and is created once there exists a specification of the subtask. Once the task has been decomposed and specified, the Manager needs to find potential Contractors. A potential Contractor is an agent that is likely to have the capability and capacity to solve a subtask. When potential Contractors have been found for all subtasks,

Signals a failure of a task.

Satisfy. Used to announce that a task has been satisfactory executed.

Figure 1. Overview of the task sharing protocol

59


the Manager will propose the contracts to the potential Contractors. mcept propo.w

t

Agent --l---o

a

Figure 5. Collect results Figure 3. Evaluate proposal

Contractor can report the outcome of a subtask execution by submitting a status report: satisfy or fail (see Figure 5). A satisfy message will indicate that the allocated contract has been satisfied by the Contractor. Similarly, a fail message will indicate that the allocated contract has not been solved by the Contractor, i.e. it is reported as a failure. The Manager needs to collect the incoming reports in order to determine whether the overall problem has been solved.

In response to the received speech act propose (or counter-propose), a potential Contractor will evaluate the received proposal, and can then either accept, reject, or issue a counter-propose, (see Figure 3). In the case of a counter-propose, the Manager will need to evaluate the refined proposal, and then respond either with accept or reject, or by issuing a new counter-propose. This can lead to a sequence of counter-proposals being issued. However, in the end, the cycle of counter-proposals will end with the speech acts accept or reject.

3.2. STEP 2: Extract Intermediate Representation Given the semantics outlined in the previous section we now focus on the second step in our method, the intermediate representations of: i) object model, and ii) algorithms and event hierarchies. 3.2.1

Object

Model

Human involvement is required in order to design the object model of the coordination protocol. In our work we have mainly used two classes: an Agent class, and a Contract class. Briefly, an Agent class represents a PSA, and can be viewed as a simple form of agent modeling. In order to capture the different stages of the negotiation we introduce a Contract class. A similar approach can be found in [3] where a Conversation class is introduced. Due to space limitations we do not provide details of the object model. The interested reader is referred to the following sources for details of the object model used in this work [8], and [17].

Figure 4. Collect bids The Manager collects the submitted bids from the potential Contractors (see Figure 4). The evaluation of received bids can start using different criteria, e.g. dead-line, a certain percentage of bids received, or all bids received. In our example we will assume that all bids must be received before the evaluation of the bids can start. The bids can be submitted in any order. When the evaluation of bids is over, we will assume that the Manager has decided upon at least one Contractor for each subtask (Contract). A Contractor is an agent that has been awarded a Contract, i.e. has been contracted to solve a subtask. Further, the Manager can decide whether there are any dependencies among the contracts. Thus, the Manager will award one (or more) of the potential Contractors. The other potential Contractors will get a cancel message from the Manager. Subtasks are then executed by their Contractors. A

3.2.2

Algorithms

and

Event

Hierarchies

We used the following for mapping state diagrams to event hierarchies, see Table 1: Briefly, each event in the state diagram is associated with a method event, which is raised after the execution of the method. Each condition that guards a transition in the state diagram corresponds to a composite event. This composite event can be defined on previously mapped method events or composite events,

60


State Diagram event [condition (guard)] action activity automatic transitions

ECA Paradigm method events composite events rule actions rule actions -

Table 1. Mapping

Remark raised after the method execution

no events or rules are generated

state diagrams

to event hierarchies.

or internal composite events that cannot be directly inferred from the state diagram. Actions and activities are both mapped to rule actions, which can be triggered by either a method event or a composite event. Automatic transitions do not generate any corresponding events and rules. The transition between state S to state S’ occurs as soon as all the activities in S have been executed. Due to space limitations, we cannot demonstrate the mapping algorithm on all of the previously shown state diagrams. The interested reader can find the entire mapping of the state diagrams into ECA rules in the long version of this paper [S]. We next demonstrate the mapping algorithm on the state diagram as shown in Figure 4. 3.2.3

Mapping

State

Diagram

in Figure

4

Figure 6. Composite bids received

The following event and rules were inferred from the state diagram shown in Figure 4, see Table 2. Composite event Eall~ids~eceived corresponds to the semantics expressed by the condition that guards the all bids received link in Figure 4, and it is expressed by the following event hierarchy, (figure 6). Composite event EbidReceivedis defined as a disjunction of E receiveAccept and Ereceive~eject, and it will detect the situation that a bid has been received. Information regarding each incoming bid, i.e. Contract id, Problem id, and sender id (i.e. Potential Contractor id), will be stored by the aid of rule Rsave~id. This information is also passed along in the event hierarchy as event parameters, since the composite events need to combine the correct bids with the appropriate Contracts and Problem. Composite event Eall~idscontract is defined as a conjunction (or sequence) of EbidReceived. This event will detect the situation when all bids have been received for a Contract. Composite event Eall~ids~eceived is then defined as a conjunction (or sequence) of Eall~idscontract, and will detect the situation when all bids have been received for all contracts. The completion of Eall~idsneceived

event Eall~ids~eceived: all

will trigger two rules; RprepareAssignContractors and R evaluate~ids. Rule Rprepare~ssign~ontractors will set up the infrastructure in advance in order to be able to monitor the outcome of the evaluation process. Rule RevaluateBids will trigger the evaluation of the received bids. Composite event Econtractors~ssigned corresponds to semantics expressed by the condition that guards the contractors assigned link in figure 4, and it is expressed by the following event hierarchy, (Figure 7). Composite event Econtrac-orsAssigned is defined as a conjunction (or sequence) of method events E set~‘ontractor. The composite event will be completed once all Contracts have been assigned a Contractor. Three rules are defined on the composite event E contractorsAssigned 7 namely RprepareIncommingReszLlts, RdistributeAwards

1 and

Rdistributecancels.

Rule RpreparelncolnrningReszlltswill create the infrastructure for collecting incoming results in advance, in readiness for receiving those results (Figure 5). Further, there is no need to create an infrastructure for

61


1 EGA Paradigm

State Diagram

Table 2. Mapping

Remark

1

state diagram

in Figure 4.

built on top of ONTOS) [lo, 141, we postulate that the following features are of crucial importance if a task sharing protocol is to be supported by an active database: l

Es&,n,nrracrnr (Contract 1. Problem A, Contractor 5)

%tContrurtor

composite events are of importance as they are used to express the semantics of guarding conditions in the state diagrams, i.e. when to take the next step in the negotiation.

(Contract n, Problem A, Contractor 7) l

Figure 7. Composite event EcontractorsAssigned: contractors assigned l

composite event restriction is crucial in order to match messages from agents to the appropriate task and contract. dynamic event and rule creation is of importance since the decomposition into subtasks takes place at run time.

collecting incoming results unless we know that all subtasks (Contracts) have been assigned a Contractor. will send a notification to Rule RdistribvteAwards those agents that were assigned to be Contractors. Rule Rdistributecance~s will send a cancel notification to those potential Contractors that were not assigned to be Contractors.

We had to propose preliminary solutions to the above in order to implement task sharing using ACOOD using the approach proposed in this paper. Below, we summarize the approach taken for our implementation effort.

3.3. STEP 3: Generate ECA Rules

3.3.1

The final step is to generate ECA rules for a specific active database system. For a given event hierarchy the specification of the rules using an available language is fairly straightforward. However, the mapping of the state diagrams to ECA rules, highlighted the need for some extensions to the ECA framework as proposed in the active DBMS literature. Based on the above mapping procedure and lessons learned from an implementation of the benchmark protocol [17] in ACOOD (an active object-oriented DBMS

The use of composite events for monitoring incoming bids causes a major problem for a Manager, since incoming CPS events are to be matched each with its appropriate problem/subproblem. This is problematic since there is no (or little) support for matching parameters within a composite event. We illustrate this by an example shown in Figure 8. Assume that a Manager has decomposed a task into two subtasks. Each subtask is represented by a Contract and has two potential contractors, (Contract 1:

62


Composite

Event

Restrictions

volved only bids for contract 1. If the condition is satisfied, then EallBi&Received is notified. Although this approach seems promising it was discovered that none of the four consumption modes (recent,, chronicle, continuous, cumulative) could provide the correct, behaviour [17]. l

l

Figure event

8. Invalid

completion

of composite

EallBidsReceived

A and B, Contract 2: C and D). As part of the ECA based protocol for task sharing, each contract has a composite event which monitors incoming bids from its potential contractors. When potential contractor A submits its bid for Contract 1, an event EreceiveAccept will be generThis event occurrence will be injected at ated. the bottom of the event hierarchy, completes event EbidReceived y and initiates the detection of composite event ~~~~&d~CO~~~~~~.Since the composite events at this stage have no mechanisms to match supplied event parameters, it will also be injected at the bottom of the event hierarchy representing incoming bids for Contract 6) i;. potential conWhen tractor D submits its bid for Contract 2, a new event occurrence of EreyiveAccept is generated. This event occurrence will complete both Contracts’ event hierarchies,

i.e.

it ~111

complete EallBidsReceived

EbidReceived 7 and

EallBidsContract

.

logical events; for each predefined event, a logical event, can be created that will filter out irrelevant event, occurrences. This mechanism is appealing since it provides a very clear semantics for which event occurrences and event, parameters are used in the detection of a composite event. There are two drawbacks: there will be an overhead due to the additional set of events that need to be created; few active databases support logical events together with ECA rules.

A further problem with respect, to the choice of event operator was revealed by the implementation [17]. For the second potential solution, it was identified that the conjunction operator is not, appropriate for use in composite events when the constituent events are of the same type. Thus, previous modeled conjunctions had to be replaced by sequence operators in order to get correct behaviour. The third potential solution could still use the conjunction operator, since the logical events filtered out uninteresting event occurrences. Given the above, we have chosen to write conjunction (or sequence) in our diagrams, since the specific alternative supported by the system needs to be used at the time of creation of events once the event hierarchy is generated.

Finally

and trigger the rules

R PrepareAssignContractoTs and RevaluateBids. Obviously, this is not the desired semantics, since we are still waiting for bids from two potential contractors, i.e., B and c. In [17] three potential solutions were investigated in order to avoid the invalid completion of E allBidsReceived: l

same parameters; a unique conversation identifier for each subtask and manager was used to identify which negotiation the message refers to. This conversation identifier is passed along as an event parameter. Hence, the above problem can be solved if it can be specified that all constituent events of a composite event need to have the same conversation identifier. However, this solution requires a modification to the proposed same::parameter operator as proposed in SAMOS [15].

4

Related

Work

The approach taken in [ll] focuses on using ECA rules for implementing agent coordination in workflow management systems. It is one of the first examples of agent coordination using an ADBMS, and as such the experiences reported are valuable. Agent coordination is divided into agent notification and agent synchronization. In contrast to our approach, there is no

rule condition; the condition part of a new rule defined on Eall&dsContract would check that the completion of EallBidsContract for contract 1 in-

63


Secondly, the work offers an architecture which addresses a key question in implementing advanced protocols: where is it best to locate support for protocols based on speech acts? We suggest that, for efficiency and reliability, the protocols should be implemented in the active DBMS layer rather than a separate layer (or within CPS applications). Recent DA1 based approaches for CIS [13, 221 have recognized the importance of having some type of optimizer (e.g., event indicators, rule pre-selection) in order to improve the efficiency of condition-action rules. We believe that these approaches will benefit in efficiency from using the ECA rule formalism. With regard to reliability, the event history will be stored in the database along with all information required to rebuild composite event graphs. Recovery techniques can therefore be extended to offer automatic recovery for CPS protocols based on standard transaction semantics. This means that system crashes would not need to result in a restart of all protocols, and in particular is not the concern of agents. It is acknowledged that there will be CPS applications requiring no database facilities, for which the overhead of using a fully functional ADBMS may be inappropriate. However, even in such situations we would maintain that an active capability (in the form of ECA rules as defined here, but decoupled from a database) would be appropriate, and so should be considered for consistency and generality. Where an agent does require database facilities (for example associative look-up, transaction semantics, persistence, recovery) we would maintain that the ADBMS approach offers significant advantages. In conclusion, advanced types of cooperative work can, with the techniques here, span the domains of advanced DBMSs and DA1 architectures. The use of databases also makes it straightforward to model an agent using existing approaches and automatically generate and store domain knowledge. A proof-of-principle system has been implemented using ACOOD for demonstrating task sharing as detailed in this paper.

support for negotiation among agents and composite events are not supported. The latter implies increased complexity of rule conditions. The approach taken in [16] focuses on supporting agents in cooperative process-oriented environments. Cooperation among agents is supported through a broker/services model using an ADBMS. Interaction among CPE agents is achieved by using the predefined operations request and reply. The limitations are that negotiation among CPE agents cannot be easily supported, since simple send / receive operations are too weak for supporting negotiations among agents [23]. The ARCHON (ARchitecture for Cooperative Heterogeneous ON-line systems) project [20] was Europe’s largest project on Distributed Artificial Intelligence (DAI) during the early 1990’s. Generic cooperation knowledge in ARCHON is captured by conditionaction (CA) rules. This is in contrast to our approach which is based on event-condition-action rules. The event is an important optimization issue, as it specifies when to evaluate a condition, not always as in the case of CA rules. Hence, earlier versions of ARCHON had slow response to important events, and important events could not be easily recognized [19, 211.

5

Conclusions

In this paper we have considered the domain of task sharing as formulated in DAI. This has allowed us to posit how active databases might be used as an enabling technology for supporting interactions in cooperative information systems. We have synthesized an approach based upon research results in DA1 and ADBMS. We have presented details of a novel approach for supporting task sharing, a key cooperation strategy within CIS, using active capability. In particular, we have elaborated on a methodology for mapping task shared protocols expressed in high level speech acts to ECA rules. We have shown that in supporting task sharing protocols with ECA rules, support for composite events and composite event restrictions is of crucial importance. We believe the significance of our approach and the results reported in this paper concern two broad issues. Firstly, we show how ADBMS can support advanced forms of cooperation strategies (e.g., task sharing). In contrast to previous ADBMS approaches, where the ADBMS was considered as a stand alone, isolated system, we show how ADBMS can be used as agents in cooperative information systems.

Acknowledgements The authors would like to thank the anonymous reviewers for their valuable comments on an earlier draft of this paper.

References [l] Special Issue on Active Databases, volume 15. IEEE Quarterly Bulletin on Data Engineering, December

64


[16] A. Geppert, M. Kradolfer, and D. Tombros. Realization of Cooperative Agents Using an Active ObjectOriented Database Management System. In Sellis [28], pages 327-341. [17] I. Hagen. Active Rules in Cooperative Problem Solving. Master’s thesis, University of Sk&de, September 1996. [18] J. Huang, N. R. Jennings, and J. Fox. Cooperation in Distributed Medical Care. In Proceedings of the 2nd International Conference on Cooperative Information Systems CoopIS-94, pages 255-263, 1994. [19] N. R. Jennings. Using GRATE to Build Cooperating Agents for Industrial Control. In Proceedings IFAC/IFIP/IMACS International Symposium on Artificial Intelligence in Real Time Control, pages 691696, 1992. [20] N. R. Jennings. The ARCHON System and its Applications. In Proceedings of the CKBS-SIG Workshop on Cooperating Knowledge Based Systems, pages 1330, 1994. [21] N. R. Jennings and J. A. Pople. Design and Implementation of ARCHON’s Coordination Module. In Proceedings of the CKBS-SIG Workshop on Cooperating Knowledge Based Systems, pages 61-82, 1993. [22] C. Meghini. A reactive logical agent. In Proceedings of the First International Workshop on Cooperative Information Agents (CIA-97), pages 148-158, 1997. [23] H. Muller. Negotiation Principles. In G. O’Hare and N. Jennings, editors, Foundations of Distributed Artificial Intelligence, chapter 7, pages 211-229. WileyInterscience, 1996. [24] H. Parunak. Applications of Distributed Artificial Intelligence in Industry. In G. O’Hare and N. Jennings, editors, Foundations of Distributed Artijicial Intelligence, chapter 4, pages 139-164. Wiley-Interscience, 1996. [25] N. Paton and M. Williams, editors. Proceedings of the 1st Workshop of Rules in Database Systems, Workshops in Computing. Springer-Verlag, 1993. [26] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-Oriented Modelling and Design. Prentice Hall, 1991. [27] J. Searle. Speech Acts. Cambridge University Press, Cambridge, UK, 1969. [28] T. Sellis, editor. Proceedings of the 2nd Workshop of Rules in Database Systems, number 985 in Lecture Notes in Computer Science. Springer-Verlag, 1995. [29] R. Smith. The Contract Net Protocol: High Level Communication and Control in a Distributed Problem Solver. IEEE Transactions on Systems, Man, and Cybernetics, SMC-10(12), December 1980. [30] R. G. Smith and R. Davis. Frameworks for Cooperation in Distributed Problem Solving. IEEE nansactions on Systems, Man, and Cybernetics, 1981. [31] J. Widom and S. Ceri, editors. Active Database Systems: Riggers and Rules for Advanced Database Processing. Morgan Kufmann Publisher, 1995.

1992. [2] ACT-NET Consortium. The Active Database Management System Manifesto: A Rulebase of ADBMS ACM Sigmod Record, 25(3), September Features. 1996. [3] M. Barbuceanu and M. Fox. COOL: A Language for Descriping Coordination in Multi Agent Systems. In First International Conference on Multi-Agent Systems, pages 17-24. AAAI Press / MIT Press, 1995. [4] M. Barbuceanu and M. Fox. Capturing and Modelling Coordination Knowledge for Multi-Agent Systems. International Journal of Cooperative Information Systems, 5(2-3):275-314, 1996. [5] M. Barbuceanu and M. S. Fox. COOL - A Language for Describing Coordination Models in Multi-Agent Technical report, University of Toronto, Systems. 1994. [6] M. Berndtsson, S. Chakravarthy, and B. Lings. Cooperative Problem Solving: A New Direction for Active Databases. In Proceedings of the International Symposium on Cooperative Database Systems for Advanced Applications CODAS’96, December 1996. [7] M. Berndtsson, S. Chakravarthy, and B. Lings. Result Sharing Among Agents Using Reactive Rules. In Proceedings of the First International Workshop on Cooperative Information Agents (CIA-97), number 1202 in Lecture Notes in Artificial Intelligence, pages 126-137. Springer-Verlag, February 1997. [8] M. Berndtsson, S. Chakravarthy, and B. Lings. Task Sharing Among Agents Using Reactive Rules. Technical report, Department of Computer Science, University of Sk&de, 1997. [9] M. Berndtsson and J. Hansson. Workshop Report: The First International Workshop on Active and RealTime Database Systems (ARTDB-95). ACM SIGMOD Record, 25(1):64-66, 1996. [lo] M. Berndtsson and B. Lings. On Developing Reactive Object-Oriented Databases. IEEE Quarterly Bulletin on Data Engineering, Special Issue on Active Databases, 15(1-4):31-34, December 1992. [ll] C. Bussler and S. Jablonski. Implementing Agent Coordination for Workflow Management Systems Using Active Database Systems. In Proceedings of the RIDEADS’94 Workshop, pages 53-59, 1994. [12] S. Chakravarthy, K. Karlapalem, S. B. Navathe, and A. Tanaka. Database supported cooperative problem solving. International Journal of Intelligent and Cooperative Information Systems, 2(3):249-287, 1993. [13] S. M. Deen. A Database Perspective to a Cooperation Environmnet. In Proceedings of the First International Workshop on Cooperative Information Agents (CIA97), pages 19-41, 1997. [14] H. EngstrGm, M. Berndtsson, and B. Lings. ACOOD Essentials. Technical report, University of Sk&de, 1997. [15] S. Gatziu and K. Dittrich. Events in an Active Object Oriented Database system. In Proceedings of the 1st Workshop of Rules in Database Systems, pages 23-29, 1993.

65
