ACTIVE CAPABILITY SUPPORT FOR
COOPERATION STRATEGIES IN
COOPERATIVE INFORMATION SYSTEMS
Mikael Berndtsson
Submitted by Mikael Berndtsson to the University of Exeter as a dissertation towards the degree of Doctor of
Philosophy in the Faculty of Science.
July 1998
I hereby certify that all material in this dissertation which
is not my own work has been identified and that no work
is included for which a degree has already been conferred
on me.
Mikael Berndtsson
1
Abstract
One important feature for the current and next generation of information systems
is the ability to be able to cooperate. Information systems that are able to cooperate
are referred to as cooperative information systems. The problem of moving the state
of the art from information systems designed as islands of automation to cooperative
information systems has primarly been addressed by the distributed artificial intelligence community and the database community. For example, the distributed artificial
intelligence community has investigated cooperation strategies such as task sharing
and result sharing, whereas the database community has developed techniques for
interoperability over heterogenous databases. One characteristic of cooperative information systems is that no individual solution can satisfactorily support all required
characteristics of cooperative information systems. This thesis takes the position that
a synthesis of results from the distributed artificial intelligence community and the
database community is a promising direction for developing cooperative information
systems.
In this thesis, active capability (as defined within active databases) is considered as
an important core technology for cooperative information systems. Active capability
is supported by event condition action (ECA) rules with the following semantics:
when an event E occurs, evaluate condition C, and if the condition is satisfied, then
execute action A. The applicability of using ECA rules has primarly been explored
within database systems and has recently initiated ECA related research within other
research communities such as real-time and workflow.
This thesis focuses on what is required in an interface between information systems when using an active capability approach to supporting the major cooperation
strategies as formulated in distributed artificial intelligence. The significance of the
2
work reported in this thesis concerns two major issues. First, advanced types of
cooperation strategies such as task sharing and result sharing can now span the domains of database and distributed artificial intelligence architectures. Second, as this
work synthesizes and extends results from two different research communities, it provides a good foundation for using active capability as one of the core technologies for
cooperative information systems.
3
Acknowledgments
Obtaining a PhD degree is like taking a ride on a roller coaster. It starts with a
slow ride up a hill. During this time frame the knowledge of the chosen field of study
is increased by spending non trivial amounts of hours of reading research reports.
Once a satisfactory level of understanding of related work has been achieved, then
the roller coaster wagon has reached the top of the hill. At this point a PhD student
realizes how little he / she knows about the chosen field of study.
The roller coaster wagon starts to move fast down the hill. At the bottom of the
hill, the student is having serious problems with envisioning how the chosen project
is going to contribute to the research field, since everything seems to have already
been done by somebody else. However, by the guidance of experienced supervisors
the roller coaster wagon manages to stay on the tracks. The roller coaster wagon
makes small jumps and quick turns when small steps of progress is made.
Entering and surviving the first loop with the roller coaster wagon has two sides
of the coin. First, tremendous excitement is achieved when the student’s first paper
is accepted for publication to a workshop. The excitement does not last for long
as the roller coaster wagon is suddenly upside down and starts to move down the
loop when the next couple of papers are rejected. Reaching the bottom of the loop
puts further doubts in the students mind whether the project is ever going to be
successfully finished. Trying to stand up in the wagon and get off the roller coaster
at this point is not to be recommended.
The roller coaster wagon continues its bumby journey over some small hills and
does some quick turns when reacting to gained experience and guidance from supervisors. The grand finale of the roller coaster is coming up fast. The roller coaster
wagon has picked up great speed and the wagon produces painful noises as it screams
4
through a series of sharp turns and twisted loops. The student is pleased to see that
a great portion of the results from the thesis is accepted for publication at some of
the major workshops and conferences.
The roller coaster makes a final quick turn as the end station of the roller coaster
is becoming visible. The student’s first journal paper based on the thesis is accepted
for publication. The roller coaster wagon rocks violently as it is approaching the end
station with screaming breaks. At this point the student is struggling with revisions
of the thesis while keeping an eye on the deadline for submission of the thesis. The
roller coaster wagon abruptly stops and the safety bar is released. The roller coaster
ride has successfully ended and the thesis has been completed.
With the above description in mind I would like to thank the following people
that have helped me to stay on track during my roller coaster ride that started in
1993:
• My supervisor Dr. Brian Lings, University of Exeter (UK) for his invaluable
guidance and supervison of this project from the very first day.
• My co-supervisor Professor Sharma Chakravarthy, University of Florida (USA)
for sharing his knowledge and introducing me to the overlap area of active
databases and cooperative problem solving.
• Stig Emanuelsson (Head of computer science department) and Lars-Erik Johansson (Principal) at the University of Skövde for supporting this work. I
would also like to take the oppurtunity to thank everybody at the department
of computer science at the University of Skövde.
5
• The ACT-NET (a European research network on active database systems) consortium for allowing me to present ideas and results from the thesis in a stimulating environment.
• Researchers from all around the world that have taken the time to answer my
questions and/or provided me with useful information. You know who you are.
Finally, I would like to thank my family and Karin Lundberg for all their support
and encouragement during these years.
c
1996
Karin Lundberg
6
Contents
1 Introduction
13
1.1
Current Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
1.2
Two Views on Supporting Cooperative Work . . . . . . . . . . . . . .
17
1.3
Need for Combining DAI and DB Research . . . . . . . . . . . . . . .
20
1.4
Thesis Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
1.4.1
Research Question . . . . . . . . . . . . . . . . . . . . . . . .
24
1.4.2
Research Objectives
. . . . . . . . . . . . . . . . . . . . . . .
25
1.4.3
Research Methodology . . . . . . . . . . . . . . . . . . . . . .
25
1.5
Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
1.6
Outline of Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
2 Background and Related Work
29
2.1
Active Database Management Systems . . . . . . . . . . . . . . . . .
29
2.2
Distributed Artificial Intelligence . . . . . . . . . . . . . . . . . . . .
32
2.3
Cooperative Information Systems . . . . . . . . . . . . . . . . . . . .
34
2.4
ADBMS Applicability to CIS . . . . . . . . . . . . . . . . . . . . . .
37
2.4.1
ADBMS and Cooperative Problem Solving . . . . . . . . . . .
38
2.4.2
ADBMS and Workflow Systems . . . . . . . . . . . . . . . . .
40
7
2.4.3
2.5
2.6
ADBMS and Agent Technology . . . . . . . . . . . . . . . . .
41
DAI Applicability to CIS . . . . . . . . . . . . . . . . . . . . . . . . .
42
2.5.1
ARCHON . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
2.5.2
COOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
The Approach Taken in This Thesis . . . . . . . . . . . . . . . . . . .
48
3 The Chosen Problem
3.1
3.2
3.3
51
Task Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
3.1.1
Static and Dynamic Allocation of Tasks . . . . . . . . . . . .
51
3.1.2
Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
Result Sharing
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
3.2.1
Sharing of Information . . . . . . . . . . . . . . . . . . . . . .
54
3.2.2
Producers and Consumers of Result Notifications . . . . . . .
55
3.2.3
Multiple Responses from Multiple Agents . . . . . . . . . . . .
57
Research Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
3.3.1
Task Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
3.3.2
Result Sharing . . . . . . . . . . . . . . . . . . . . . . . . . .
58
4 Task Shared Cooperation
4.1
4.2
59
Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.1.1
STEP 1: Model Speech Acts . . . . . . . . . . . . . . . . . . .
60
4.1.2
STEP 2: Extract Intermediate Representation . . . . . . . . .
70
4.1.3
STEP 3: Generate ECA Rules . . . . . . . . . . . . . . . . . .
81
Implementation and Testing . . . . . . . . . . . . . . . . . . . . . . .
85
4.2.1
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
4.2.2
Application Scenario . . . . . . . . . . . . . . . . . . . . . . .
87
8
4.2.3
Summary of Findings . . . . . . . . . . . . . . . . . . . . . . .
5 Result Shared Cooperation
5.1
5.2
5.3
93
Result Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
5.1.1
Inadequacy of Subscription Mechanisms for ECA Rules . . . .
93
5.1.2
A Refined Subscription Mechanism for ECA Rules . . . . . . .
96
Multiple Result Notifications . . . . . . . . . . . . . . . . . . . . . . .
97
5.2.1
Characteristics of Concurrent Engineering . . . . . . . . . . .
98
5.2.2
The Power of Composite Events . . . . . . . . . . . . . . . . .
98
Pruning Result Notifications and Subscriptions . . . . . . . . . . . . . 102
5.3.1
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.3.2
Limitations of current ECA approaches . . . . . . . . . . . . . 105
5.3.3
Context Based Subscriptions . . . . . . . . . . . . . . . . . . . 110
5.3.4
Summary of Findings . . . . . . . . . . . . . . . . . . . . . . . 116
6 Conclusions
6.1
91
118
Desirable Active Capability Properties for Supporting Cooperation
Strategies in CIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.2
A Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
6.3
Significance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.4
Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.4.1
Efficiency of Logical Composite Events . . . . . . . . . . . . . 123
6.4.2
Tools and Methodologies . . . . . . . . . . . . . . . . . . . . . 127
6.4.3
Rollbacks of Composite Events and Rule Actions . . . . . . . 128
6.4.4
Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
9
List of Tables
1
Mapping state diagrams to event hierarchies. . . . . . . . . . . . . . .
72
2
Mapping state diagrams in Figure 11. . . . . . . . . . . . . . . . . . .
73
3
Mapping state diagrams in Figure 12 . . . . . . . . . . . . . . . . . .
74
4
Mapping state diagram in Figure 13. . . . . . . . . . . . . . . . . . .
76
5
Mapping state diagrams in Figure 14. . . . . . . . . . . . . . . . . . .
79
6
Mapping state diagrams in Figure 15. . . . . . . . . . . . . . . . . . .
80
7
PSAs currently available. . . . . . . . . . . . . . . . . . . . . . . . . .
87
8
Suppliers of components. . . . . . . . . . . . . . . . . . . . . . . . . .
88
9
Non logical event consumption . . . . . . . . . . . . . . . . . . . . . . 106
10
Logical event consumption . . . . . . . . . . . . . . . . . . . . . . . . 113
11
Active (CIS) capability properties supported by current ADBMSs. . . 121
12
Number of condition evaluations, simple example . . . . . . . . . . . 125
13
Number of condition evaluations, advanced example . . . . . . . . . . 127
10
List of Figures
1
Islands of automation . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
Previously isolated systems connected by a distributed computing in-
14
frastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3
Relation between collaboration and coordination . . . . . . . . . . . .
18
4
Degree of support for cooperation . . . . . . . . . . . . . . . . . . . .
19
5
A generic cooperation interface between ISs . . . . . . . . . . . . . .
23
6
Major influences on CIS . . . . . . . . . . . . . . . . . . . . . . . . .
36
7
Centralized architecture based on an active database system . . . . .
39
8
ARCHON layers
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
9
Overview of an agent . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
10
Interplay between application, agent and agent acting as manager . .
64
11
Evaluate proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
12
Offer potential contracts . . . . . . . . . . . . . . . . . . . . . . . . .
66
13
Collect bids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
14
Distribute awards and cancels to subcontrators . . . . . . . . . . . . .
68
15
Collect results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
16
Agent and Contract classes . . . . . . . . . . . . . . . . . . . . . . . .
71
11
17
Composite event EpotentialContractors : potential contractors have been
identified for each contract . . . . . . . . . . . . . . . . . . . . . . . .
75
18
Composite event EallBidsReceived : all bids received . . . . . . . . . . . .
77
19
Composite event EallResultsReceived : all results received . . . . . . . . .
80
20
Invalid completion of composite event EallBidsReceived . . . . . . . . . .
83
21
Architecture of test application . . . . . . . . . . . . . . . . . . . . .
86
22
Agent 4 receives notifications from other agents . . . . . . . . . . . .
99
23
Event time line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
24
Chronicle consumption mode, event context checked by rule condition 106
25
Context specific information is redundantly duplicated in rule conditions108
26
Chronicle consumption mode, event context checked by logical events
27
Context specific information is captured by a logical event . . . . . . 114
28
Redefining logical expression of E1
29
Introducing a new explicit event E3 . . . . . . . . . . . . . . . . . . . 115
30
Non logical composite event (simple scenario) . . . . . . . . . . . . . 124
31
Logical composite event (simple scenario) . . . . . . . . . . . . . . . . 125
32
Non logical composite event (complex scenario) . . . . . . . . . . . . 126
33
Logical composite event (complex scenario) . . . . . . . . . . . . . . . 126
12
112
. . . . . . . . . . . . . . . . . . . 115
Chapter 1
Introduction
1.1
Current Trends
Over the last twenty years, information systems (IS) have been developed for supporting users with computer services for manipulating information related to applications
such as inventory control, computer integrated manufacturing, stock trading and accounting. The ISs were developed to work as stand-alone units, thereby creating
islands of automation. This lead to problems when ISs needed to access information
maintained by other ISs, since the ISs were not designed to interact with each other.
This has been pointed out in (Brodie and Ceri, 1992):
Most organizations have developed many application-specific but independent ISs only to find out that almost all ISs require access to other
ISs, just as people in organizations need to interact.
As an example, consider an application for computer integrated manufacturing
(Figure 1). In such an application, information about raw material, machines, operators, schedule, bill of materials, inventory and operations such as drilling are likely
13
Chapter 1. Introduction
14
Shop floor control
(monitor)
Release order
manufacturing
users
users
users
Bill of material
(file system)
users
Inventory
(relational database)
Figure 1: Islands of automation
Chapter 1. Introduction
15
to be stored in separate ISs. In order to manufacture a new product, information
from all of these ISs needs to be accessed. If these ISs are built as islands of automation then human involvement is required in order to manually access and retrieve the
information from the ISs. This can quickly become a time consuming and complex
activity. As an alternative approach, ISs could interact and retrieve the required
information with no (or little) human involvement.
More recently, successful attempts have been made to move towards greater integration. Typically, this has been done for a specific type of IS, for example interaction
among a set of (interoperable/federated) databases. Furthermore, a distributed computing infrastructure such as CORBA (Object Management Group, 1995) or email is
assumed to be the backbone for most applications.
Release order
manufacturing
Shop floor control
(monitor)
Distributed computing infrastructure
Bill of material
(file system)
Inventory
users
(relational database)
Figure 2: Previously isolated systems connected by a distributed computing infrastructure
Chapter 1. Introduction
16
However, simply connecting previously isolated systems (Figure 2) will not be
sufficient to support the envisioned requirements (or characteristics) of the next generation of IS. These types of system not only need to establish links between themselves (communication channels), but they also need to support more advanced forms
of interaction. That is, they need to interact beyond the level of sending messages.
Importantly, they need to be able to cooperate, since an individual IS cannot solve
a problem on its own. In general these systems need to encompass (Chakravarthy
et al., 1993; Berndtsson et al., 1996a):
• distributed, heterogeneous environments, since ISs are most likely to be distributed and to be working with heterogeneous environments/tools. For example, inventory and bill of materials in our application scenario may be distributed
(different departments) and supported by a relational database system and file
system, respectively (Figure 2).
• access to current and relevant information, since ISs need to be able to manipulate shared data and monitor evolving states. For example, multiple users may
want to access the inventory application and monitor its evolving state (Figure
2).
• coordinated behaviour, since ISs need to coordinate their activities with other
ISs, and react to other ISs’ activities. For example, an IS that maintains the release of manufacturing orders to the shop floor needs to coordinate its activities
with other ISs such as the IS responsible for the inventory application. That is,
a manufacturing process should not start unless the required components are
available in the inventory (Figure 2).
Chapter 1. Introduction
17
• collaborative behaviour, since each interaction between ISs will have a special
semantic content and intention. For example, an IS that monitors break-downs
in the manufacturing process may have to interact and reason together with
other ISs in order to decide how to re-route an order to avoid a broken machine.
Importantly, an IS need to be aware of the semantic content and the intention
of the access from other ISs (Figure 2).
The first characteristic has primarily been addressed by researchers in database
systems (DB), distributed artificial intelligence (DAI) and distributed computing infrastructures. The second characteristic has been addressed by the database community. The third and fourth characteristics have primarily been addressed by the DAI
community.
This thesis follows the approach taken in (Chakravarthy et al., 1993) where coordinated behaviour and collaborative behaviour are considered as the key aspects that
distinguish traditional (non-cooperative) ISs from ISs that need to be able to cooperate, Cooperative Information Systems (CIS).
1.2
Two Views on Supporting Cooperative Work
Two related views on supporting cooperative work have been taken by the database
community and the DAI community, where the former can be classified as a bottomup approach and the latter as a top-down approach. In general, DAI approaches
focus on solving the most general problems of cooperation, whereas work done within
the database community focuses on very restricted forms of cooperation. In between
these two extremes, there are several approaches which either incrementally add support for collaboration and coordination to a database environment, or focus on less
Chapter 1. Introduction
18
sophisticated functionality in terms of collaboration and coordination.
Collaboration can be seen as the act of working together in order to produce
results and solutions. According to Chakravarthy et. al (Chakravarthy et al., 1993)
collaboration includes a planning phase and encompasses issues such as reasoning
among group members about which problem solving strategy to choose.
A decision by group members on a problem solving strategy to be used will influence the choice of an appropriate coordination process (see Figure 3). This has also
been identified by Malone and Crowston. They note that (Malone and Crowston,
1994):
..alternative ways of making group decisions give rise to alternative
coordination processes
and in this context they define coordination as the act of:
..managing dependencies between activities.
Collaboration
Coordination
Figure 3: Relation between collaboration and coordination
I next elaborate on the approaches taken in the database community and DAI
community for supporting cooperation and the different emphases on collaboration
Chapter 1. Introduction
Centralized
Databases
Low
Distributed
Databases
19
Federated
Databases
Workflow
Distributed AI
Cooperation (collaboration and coordination)
High
Figure 4: Degree of support for cooperation
and coordination in each community, (Chakravarthy et al., 1993; Berndtsson et al.,
1996b). In doing so, I present a figure (Figure 4) which has centralized databases as
the starting point of the scale, since they have no support for cooperation.
Distributed databases add functionality for supporting simpler forms of coordination. There is very little (or no) support for collaboration in distributed databases.
Cooperative functionality is provided in terms of processing queries and executing
transactions in a distributed environment. Given that the functionality is provided
within a database context, special emphasis is placed on guaranteeing properties such
as atomicity and durability. Typically, distributed databases assume a homogeneous
network of ISs where coordination and collaboration details are known a priori.
In contrast to distributed databases, federated databases assume a heterogeneous
network of ISs which are partly autonomous. As a consequence of the heterogeneous
environment, IS modeling needs to be more detailed and flexible. This information
is usually maintained by a global data model (Türker and Conrad, 1996). One of
the key issues within federated databases is to ensure global consistency of federated
data.
Workflow systems offer little support for collaboration, but the support for coordination is substantially different from the previous approaches. In contrast to the
previous database approaches coordination is unforced (not hard coded), cognitive
Chapter 1. Introduction
20
oriented and knowledge intensive.
Approaches in DAI encompass approaches from distributed cooperative problem
solving and multi-agent systems. Both approaches have sophisticated support for
cooperation strategies such as task sharing and result sharing. In addition, there is
an assumption that in multi-agent systems ISs (or agents) are autonomous and need
to reason about the problem solving process.
1.3
Need for Combining DAI and DB Research
Historically, the DAI and DB communities have had little in the way of an exchange
of ideas, since they try to solve very different types of problems. However, the emerging CIS research domain represents one area of common ground where the DAI and
DB communities are likely to interact with each other. For some applications such
as electronic commerce, office environments, and computer integrated manufacturing, a CIS solution may need to combine and integrate DB techniques for accessing
and manipulating shared data with DAI techniques for supporting advanced types
of cooperative processing. With regard to computer integrated manufacturing, approaches have been taken both within DAI (Balasubramanian et al., 1996) and DB
(Schreier, 1993). For example, assume a CIS such as the computer integrated manufacturing application introduced earlier that requires both DB and DAI techniques.
A designer of such a system is faced with several problems. First, neither a DB nor
a DAI approach can support all required characteristics.
For example, a DB solution would have satisfactory support with respect to access and manipulation of shared data, but it would have little (or no) support for
cooperation. The degree of cooperative behaviour in DB approaches is limited to:
Chapter 1. Introduction
21
i) distributed query processing, and ii) forced (or hard coded) cooperation. Furthermore, most of the DB approaches lack an underlying formalism for specifying
cooperation.
A DAI solution would have satisfactory support with respect to cooperation. Typically, DAI based approaches focus on supporting cooperation strategies (e.g. task
sharing) among a set of agents. Currently, this interaction is governed by conditionaction rules. However, a DAI solution will possibly not have satisfactory mechanisms
for manipulating shared (persistent) data, since it lacks mechanisms similar to those
of database transactions.
As neither a DB nor a DAI solution can satisfactory support all required characteristics, a promising direction for research is a synthesis of research results from
both the DB and DAI communities. This may also be more beneficial for the overall
problem (e.g. computer integrated manufacturing application) in the long-term. The
question is then how this combination or synthesis of DB and DAI results should take
place?
One answer to the above question is initiated in section 1.1 and may be found
further elaborated in the papers of Michael L. Brodie (Brodie et al., 1988; Brodie,
1988) from which the following four levels of interaction between ISs (including DAI
and DB components) can be identified:
1. ISs are disjoint, i.e. they do not communicate with each other and will thereby
create islands of automation (Figure 1).
2. ISs are connected by a distributed computing infrastructure which will allow
two or more ISs to exchange messages (Figure 2).
Chapter 1. Introduction
22
3. General interoperability (cooperation) mechanisms are encapsulated in, for example, cooperation protocols and provided by a resource agent (or global planner). This architecture can become a potential bottleneck in that all cooperation
is routed through a central resource agent.
4. Each IS will have its own resource agent. Each IS can then contact its own
resource agent when cooperation is needed with other ISs in order to solve a
problem. The resource agent can be viewed as an interface (consisting of generic
cooperation services) between ISs that need to cooperate (Figure 5).
The idea of encapsulating generic interoperability (cooperation) mechanisms has
also been identified by DAI projects such as ARCHON (Jennings, 1994a) and COOL
(Barbuceanu and Fox, 1996) in which shared conventions make it possible for multiple
agents to coordinate their activities. Typically, these are enforced by cooperation
protocols.
This thesis will expand upon using active capability, in the form of event-conditionaction (ECA) rules as defined within active databases, for a cooperation interface (see
Figure 5) for supporting CIS. The importance of active capability (active databases)
as one of the enabling technologies for CIS has been expressed within the community
(see for example The International Journal of Cooperative Information Systems (IJCIS, 1996) and a Panel session held at the Second IFCIS International Conference on
Cooperative Information Systems (CoopIS-97) (Chakravarthy, 1997)). Thus, there
is evidence that a detailed exploration of an active capability (and active database)
approach to CIS is of significance to the CIS research community.
Chapter 1. Introduction
23
AI application
Active database
111111
000000
000000
111111
manufacturing
11111111
00000000
00000000
11111111
Distributed computing infrastructure
11111
00000
00000
11111
00000
11111
File system
11
00
00
11
111111111
000000000
000000000
111111111
000000000
111111111
users
Relational database
= Generic cooperation interface
Figure 5: A generic cooperation interface between ISs
Chapter 1. Introduction
1.4
Thesis Statement
1.4.1
Research Question
24
In this thesis I take an active capability approach to providing a standardized and
extensible interface between ISs in CIS to support cooperation among ISs and combine
research results from both the DAI and DB communities in a synergistic manner. An
important question is then, what type of interface can we define that will provide a
standardized and extensible coupling between the ISs in CIS and at the same time
assist research in both the DB and DAI communities to proceed in a synergistic
manner?
The advantages of such an interface would be:
• clear separation of concerns for DAI and DB; once the interface has been defined,
then it can assist research in both communities to proceed in a synergistic
manner.
• extensible; for example, new types of cooperation protocols can be introduced
for a cooperative agent. These cooperation protocols can then, by utilizing
the defined interface, be mapped down to a database management system for
efficient implementation.
• cooperative strategies; advanced types of cooperation strategies such as task
sharing and result sharing can span the domains of DB and DAI architectures.
• recovery and persistence properties; recovering from failures and system crashes
during cooperative work can be enforced by techniques from database management systems.
Chapter 1. Introduction
25
• efficient; cooperation based on event-condition-action rules facilitates optimization issues, since the event part of a rule is used as a filter to reduce computation.
1.4.2
Research Objectives
This thesis focuses on what is required in an interface between ISs when using an active capability approach to supporting the major cooperation strategies as formulated
in DAI, i.e. task sharing and result sharing. In particular,
• what are the desirable active capability properties when supporting task sharing and how can task sharing be mapped down to ECA rules in a systematic
manner?
• what are the desirable active capability properties when supporting result sharing?
1.4.3
Research Methodology
Concerning the first objective, before one can identify the desirable active capability properties when supporting task sharing, a method is needed that can map the
semantics of task sharing down to ECA rules in a systematic manner. In order to
address this I have:
• studied the literature on active databases, DAI, and CIS in order to find a
method that can map a task sharing protocol to ECA rules. No such method was
found in the studied literature. This motivated the development of a method
for mapping a task sharing protocol down to ECA rules.
Chapter 1. Introduction
26
• developed a generic task sharing protocol in order to test and validate the
method for mapping a task sharing protocol down to ECA rules. A generic
task sharing protocol was developed, since such a protocol was not found in the
literature. The protocol is based upon a set of representative speech acts from
previous classifications of speech acts and existing task sharing protocols.
• specified and co-supervised a M.Sc. project (Hagen, 1996) that had primarily two objectives. First, to test and validate the mapping method in detail
and practice. Second, to develop a proof-of-principle implementation of an
ECA based task sharing protocol in an active object-oriented database system,
ACOOD.
Concerning the second objective, I have:
• studied the literature on active databases, DAI, and CIS in order to identify
similarities and differences on subscription mechanisms. A refined ECA rule
subscription was developed, in order to support simpler forms of result sharing.
• performed a case study on the applicability of using composite events for specifying when to take responsive action to multiple result notifications.
• performed case studies on supporting context based subscriptions using active
capabilities. The case studies identified limitations of using active capabilities
when supporting context based subscriptions. To address these limitations, the
concept of logical events for ECA rules was developed.
• specified and co-supervised a M.Sc. project (Schwinger, 1995) that elaborated
on introducing logical events for ECA rules in an active object-oriented database
system, ACOOD.
Chapter 1. Introduction
1.5
27
Contributions
This thesis analyzes active capability as defined in active databases and cooperation
strategies as formulated in DAI, and synthesizes an approach to interaction in CIS
that is novel and exhibits several advantages over previously proposed approaches.
In this thesis I have:
• defined the interface between ISs with regard to supporting advanced types of
cooperation strategies for CIS. The interface is based on a synthesis of research
results from both the active database community (active capability) and the
DAI community (speech acts, cooperation strategies), (Berndtsson et al., 1996a;
Berndtsson et al., 1997b; Berndtsson et al., 1997c; Berndtsson et al., 1997a).
• presented details of a novel approach for supporting task sharing, a key cooperation strategy within CIS (and DAI), using active capability. In particular, I
have introduced a method for mapping task shared protocols expressed in high
level speech acts to ECA rules (Berndtsson et al., 1997c; Berndtsson et al.,
1997a).
• shown that if ECA rules are to support task sharing protocols, then support
for composite events and composite event restrictions are of crucial importance
(Berndtsson et al., 1997c; Berndtsson et al., 1997a).
• shown how active capability can be applied to result sharing. In particular
I have proposed a refined ECA subscription mechanism for supporting result
sharing in active databases (Berndtsson et al., 1997b).
• demonstrated the applicability of using composite events as defined within active databases for supporting responses from multiple agents in the context of
Chapter 1. Introduction
28
result sharing (Berndtsson et al., 1997b).
• shown that current active database approaches cannot support context based
subscriptions as described in result shared cooperation. It is shown that current
active database solutions are inappropriate with respect to event consumption,
maintenance, and efficiency for supporting context based subscriptions. To
overcome the aforementioned limitations a solution based on logical events in
combination with ECA rules has been proposed.
• made a clear separation of the DAI notions result sharing and information sharing when considering database systems: i) sharing of committed information
(result sharing), ii) sharing of uncommitted information (information sharing),
and iii) sharing of meta-data (Berndtsson et al., 1997b).
1.6
Outline of Thesis
The remainder of this thesis is organized as follows:
• Chapter 2 addresses related work within the database area and DAI.
• Chapter 3 elaborates on the research literature and positions my work with
respect to related research activities.
• Chapter 4 demonstrates how the core functionality of task sharing can be supported using the ECA rule paradigm.
• Chapter 5 demonstrates how result sharing can be supported using the ECA
rule paradigm.
• Conclusions and directions for future work are presented in chapter 6.
Chapter 2
Background and Related Work
This chapter gives the reader an introduction to related issues in active database management systems (including active capability), and distributed artificial intelligence,
and introduces current thinking on cooperative information systems. It describes
previous approaches to solving problems in cooperative information systems taken by
the active database community and the distributed artificial intelligence community.
The chapter concludes with a brief statement on how this work improves previously
taken approaches.
2.1
Active Database Management Systems
Briefly, active capability is supported through the ECA (event-condition-action) rule
abstraction as suggested in the HiPAC project (Chakravarthy et al., 1989). Occurrence of a specified type of event (e.g., a database transition, a time event, or an
external signal) triggers the evaluation of a condition and if the condition evaluates
to true, the action is carried out. Several other aspects of the ECA rule abstraction,
such as composite events, event consumption modes, coupling modes, and conflict
29
Chapter 2. Background and Related Work
30
resolution have been investigated (ACT-NET Consortium, 1996).
An active database management system (ADBMS) can automatically react to
events (that may cause a change of state) in a timely and efficient manner. This is in
contrast to traditional database systems which are passive in their behaviour, which
means that, in order to detect events applications have to either: i) poll the database,
or ii) incorporate embedded instructions. The first approach implies that database
queries must be run exactly when an event occurs. The frequency of polling can be
increased in order to detect such an event, but if the polling is too frequent, then the
database is overloaded with queries that most of the time will fail. On the other hand
if the frequency is too low, the event will be missed.
The second approach implies that every application that updates the database
needs to be augmented with condition checks in order to detect events. For example,
an application may be extended with code to detect whether the quantity of certain
items has fallen below a given level. From a software engineering point of view this
approach is inappropriate, since a change in a condition specification implies that
every application that uses the modified condition needs to be updated. Neither
of the two previous approaches can satisfactorily support reactive behaviour in a
database context (Chakravarthy et al., 1989).
The use of ECA rules rather than standard production rules (condition-action
rules) is important for the applications under consideration. A clear distinction between events and conditions is presented in (Dayal, 1995):
• Different roles: the event specifies when to check, whereas a condition specifies
what to check.
• External events: it is easier to model reactions to external signals if events are
explicit.
Chapter 2. Background and Related Work
31
• Finer control for database state transitions: asymmetric responses to database
state transitions are not easy to model without explicit events.
• Execution semantics: condition evaluation can, for example, be deferred to later
point in time, end of transaction.
• Optimization: evaluate conditions when a specific event occurs, not always.
Event types can be classified into: i) primitive events and ii) composite events.
Primitive events refer to elementary occurrences which are predefined in the system,
such as transaction events, method events, and database events. A composite event
is a set of primitive events or composite events related by a set of event operators
such as disjunction, conjunction, and sequence. Event occurrences are instances of
an event type.
Composite event restrictions are used to restrict event consumption for composite
events. Typically, composite event restrictions are enforced by using the same identifier restriction as suggested in the SAMOS prototype (Gatziu, 1994). For example,
the component events of a composite event may need to have been raised within the
same transaction or by the same user.
Typically, active database systems are based on event algebras which do not allow
conditions. One exception is the event algebra for the active database system Ode
(Gehani et al., 1992). Ode introduces logical events, where the condition part of
the ECA model is folded into the event part. The condition can be over the event
parameters and the state of any objects in the database system.
Simple forms of active rules (triggers, ECA rules, alerters etc) are currently provided by most commercial relational database systems.
The applicability of active capability has been extensively explored in the context
Chapter 2. Background and Related Work
32
of database systems and its potential and importance for novel applications such as
workflow (Bussler and Jablonski, 1994), cooperative problem solving (Chakravarthy
et al., 1993; Berndtsson et al., 1996a), and real-time (Berndtsson and Hansson, 1996)
is becoming clearer.
The interested reader is referred to the following sources for more information on
active database management systems; the rules in database workshops (RIDS) (Paton
and Williams, 1993; Sellis, 1995; Geppert and Berndtsson, 1997), RIDE-ADS (Widom
and Chakravarthy, 1994), active database manifesto (ACT-NET Consortium, 1996),
special issues of journals (Chakravarthy, 1992; Chakravarthy and Widom, 1996) and
text books (Widom and Ceri, 1995; Paton, 1998).
2.2
Distributed Artificial Intelligence
Distributed Artificial Intelligence (DAI) is a subfield of artificial intelligence which
is concerned with knowledge models for cooperation and reasoning in societies of
entities. These entities are usually referred to as agents in the literature. A general
definition of DAI is presented in (Moulin and Chaib-Draa, 1996):
..., DAI is concerned with situations in which several systems interact
in order to solve a common problem...
At the heart of cooperative behaviour is effective interactions among a set of agents
according to a cooperation strategy. Agents can cooperate according to two types of
cooperation strategies (Smith and Davis, 1981; Hall, 1996): task shared cooperation
and result shared cooperation. Briefly, task-shared cooperation follows the following
procedure: i) decompose a problem into subproblems, ii) solve the subproblems, and
iii) integrate the results obtained for the subproblems. Result-shared cooperation
Chapter 2. Background and Related Work
33
implies that agents assist each other by sharing partial results of the same overall
problem. In contrast to task sharing, an explicit hierarchy of task / subtasks does
not exist within result sharing.
Each agent has a structure and behaviour which needs to be captured. Aspects
that need to be identified for each agent are (Jennings, 1994b):
• State knowledge; the status of the activities carried out by the agent.
• Capability knowledge; descriptions of tasks and actions that can be executed
by an agent.
• Intentional knowledge; high-level description of the long term objectives of an
agent.
• Evaluative knowledge; information about the time required to complete tasks
etc.
• Domain knowledge; facts and relationships about the environment in which the
agent is operating.
DAI is divided into two research areas: distributed cooperative problem solving
and multiagent systems. In distributed cooperative problem solving the emphasis is
on the problem itself and in multiagent systems the emphasis is on the agent (Chaibdraa, 1995) .
Typically, in distributed cooperative problem solving a three step procedure is
used as follows:
1. Negotiation takes place as an initial phase to allocate tasks to agents. This is
usually specified by a high-level communication language such as the Contract
Chapter 2. Background and Related Work
34
Net Protocol (Smith, 1980). 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).
2. Execution refers to the actual problem solving process, in which agents may
share partial results (result shared cooperation).
3. 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).
According Chaib-draa (Chaib-draa, 1995) multi-agent systems are concerned with
coordinating intelligent behaviour (e.g. skill, plans, knowledge) among a heterogeneous network of agents. The agents are assumed to be autonomous. Furthermore,
multi-agent systems need to be able to reason about the coordination process.
The interested reader can find more information on DAI in (Bond and Gasser,
1988b; O’Hare and Jennings, 1996).
2.3
Cooperative Information Systems
Cooperative Information Systems is a recently established research community: the
international foundation for cooperative information systems (IFCIS) was founded in
1996. This thesis follows the definition of cooperative information system as described
by the The International Journal of Cooperative Information Systems (IJCIS, 1996)
in its Aims & Scope:
Chapter 2. Background and Related Work
35
The paradigm for the next generation of information systems (ISs) will
involve large numbers of ISs distributed over large, complex computer /
communication networks. Such ISs will manage or have access to large
amounts of information and computing services and will interoperate as
required. These support individual or collaborative human work. Communication among component systems will be done using protocols that
range from conventional ones to those based on distributed AI. We call
such next generation ISs Cooperative Information Systems (CIS).
A similar and perhaps more concrete definition of what constitutes a cooperative
information system has been given by Brodie and Ceri (Brodie and Ceri, 1992).
We consider two or more ISs that execute joint tasks to form a larger
IS, called a Cooperative IS. We call an individual IS within a cooperative
IS, a component IS.
In this thesis, the terms CIS and component IS will be used as defined in the
above two definitions. From the above definitions we can infer the characteristics of
CIS. These were also described in 1.1:
• distributed and heterogeneous environments
• access to current and relevant information
• coordinated behaviour
• collaborative behaviour
Supporting the above characteristics implies that CIS needs to borrow and synthesize research results from several different research areas such as:
Chapter 2. Background and Related Work
36
• DAI (e.g. multiagent systems and distributed cooperative problem solving).
• database systems (e.g. distributed databases, heterogenoues databases and active databases).
• process modelling (e.g. workflow systems and communication protocols).
The synthesized research results should facilitate the development of an architecture which will then allow a component IS (e.g. a database extended with a
cooperative interface) to access and cooperate with other component ISs.
DAI
CPS / MAS
Cooperation stragetgies
-task sharing
-result sharing
Condition-Action rules
C
I
S
DB
Distributed, federated, multi DB
Transactions
Event-Condition-Action rules
Figure 6: Major influences on CIS
Chapter 2. Background and Related Work
37
As CIS research is still in its early stages, the approaches taken so far are still
heavily influenced by either DAI or DB, as shown in Figure 6. Approaches in the
database community to CIS are currently influenced by research results from federated databases, multi-databases, distributed databases and active databases. For
example, advanced forms of transaction models, query processing, and interoperability of heterogeneous information sources have influenced recent approaches, see for
example (Kandzia and Klusch, 1997).
The interested reader is referred to the following sources for more information
on cooperative information systems; the International Journal of Cooperative Information Systems (IJCIS, 1996) and the conference series on Cooperative Information
Systems (CoopIS) (Brodie et al., 1994; CoopIS-95, 1995; CoopIS-96, 1996; CoopIS-97,
1997).
2.4
ADBMS Applicability to CIS
The forthcoming sections will briefly describe three categories of previous ADBMS
based approaches of relevance to CIS and this thesis:
• ADBMS and cooperative problem solving, e.g., (Chakravarthy et al., 1993; Karlapalem et al., 1995).
• ADBMS and advanced workflow systems, e.g., (Bussler and Jablonski, 1994;
Geppert et al., 1995; Lockemann and Walter, 1995).
• ADBMS and agent technology, e.g., (Bailey et al., 1995; Akker and Siebes,
1997).
Chapter 2. Background and Related Work
2.4.1
38
ADBMS and Cooperative Problem Solving
An active database approach to cooperative problem solving is presented in (Chakravarthy
et al., 1993). Two approaches are presented: i) a centralized approach, and ii) a distributed approach. The suggested centralized approach has been refined and realized
in the CapBasED-AMS project (Karlapalem et al., 1995).
The centralized (near-term) approach is based on a central node in the cooperative
problem solving system, which acts as a centralized persistent blackboard (active
database) for the problem solving agents (PSA). The central node has three major
components: a problem manager, a capability manager and an execution manager,
Figure 7.
The problem manager is responsible for decomposing a posed problem into subproblems. Further, for each subproblem it needs to: identify appropriate problem
solving agents, generate an intermediate representation (state machine, Petri net
etc.), generate a schema for maintaining run time data and generate a set of ECA
rules for coordination and scheduling. The capability manager is responsible for
maintaining in a database the capabilities of the problem solving agents involved.
Thus, the search for appropriate problem solving agents can be achieved by posing a
database query to the capability database. The execution manager is responsible for
coordinating and monitoring the execution of subproblems.
The approach taken requires that each node is capable of communicating with the
centralized persistent blackboard. Thus, nodes post their solutions to subproblems
etc. by sending them to the central node.
The distributed (long-term) approach implies that each problem solving agent is
either enhanced with a capability manager and execution manager (problem manager is considered as optional) or that the agent is tightly coupled with a capability
Chapter 2. Background and Related Work
PSA-1
PSA-2
39
PSA-n
Network
Problem
Manager
Active
Database
Execution
Manager
Capability
Manager
Figure 7: Centralized architecture based on an active database system
Chapter 2. Background and Related Work
40
manager and an execution manager.
Two application scenarios are outlined: a process control system and an office
information system. Although the cooperation strategy in this work is influenced by
task sharing, the interaction among agents is based upon forced cooperation. That
is, most of the interactions in the outlined examples are predetermined.
2.4.2
ADBMS and Workflow Systems
The approach taken in (Bussler and Jablonski, 1994) focuses on using ECA rules for
implementing agent coordination in workflow management systems. Agent coordination is divided into agent notification about work to do, and agent synchronization.
Synchronization policy (in the form of an ECA rule) is introduced in order to
prevent agents from executing tasks they have been notified about but not selected
for. An example of such a synchronization policy rule is given below (Bussler and
Jablonski, 1994):
on start
if eligible-agent()
AND NOT operation-started()
AND NOT operation-finished()
AND NOT operation-reset()
AND NOT operation-aborted()
do add-agent-executing()
forbid-others-to-start()
update-worklists()
This rule can be interpreted as follows. When an agent tries to start the operation
an event start is raised, which will trigger the rule. It has a complex rule condition,
Chapter 2. Background and Related Work
41
which ensures that the operation is not started, finished, reset or aborted. If the
condition is satisfied then the first agent that applied for executing the operation will
be awarded the operation; the other agents that have received the same notification
about work to do need to be informed that they are not allowed to start the operation,
i.e. update worklists.
Recently, other ADBMS based approaches targeting workflow systems have appeared in the literature. A broker/services model for workflow systems using an
ADBMS is suggested in (Geppert et al., 1995). The approach focuses on supporting
processing entities as defined in workflow systems for cooperative process-oriented environments. Cooperation and interaction among the processing entities are achieved
by using the predefined interaction operations request and reply.
A richer set of interaction operations for distributed workflow systems has been
suggested in (Lockemann and Walter, 1995). This work introduces the concept of an
alliance which can be viewed as a cooperation protocol between cooperating objects
(or entities). The suggested cooperation protocol encompasses complexity similar to
previously suggested coordination DAI based protocols, e.g. COOL (Barbuceanu and
Fox, 1996).
2.4.3
ADBMS and Agent Technology
A comparison between the characteristics of ADBMS and agent systems was reported
in (Bailey et al., 1995). It is shown that although they are developed in different
fields of computer science, they have much in common. Hence, researchers in both
communities can benefit from the exchange of ideas and techniques developed. In
particular,
• Language syntax and semantics are not standardized in the two research fields.
Chapter 2. Background and Related Work
42
Thus, concepts such as powerful event languages can be adopted by the agent
community. Similarly, ADBMS can benefit from incorporating more reasoning
about which action(s) should be executed.
• Agent systems will need to adopt database features such as recovery techniques,
rollbacks, and history. This is especially important for real world agent systems
that need to be able to recover from failures etc.
The work reported in (Akker and Siebes, 1997) contrasts ADBMS with respect to
the notions of weak and strong agency. It is demonstrated that ADBMS already support the notion of weak agency (autonomy, social ability, reactivity, pro-activeness),
whereas no aspect of strong agency (knowledge, belief, intention, obligation) is yet
supported. Although ADBMS do not support strong agency, there is speculation on
how the notion of strong agency can improve the adaptability and flexibility of an
ADBMS. According to the authors of (Akker and Siebes, 1997), this can be achieved
by incorporating general purpose reasoning abilities into an ADBMS.
2.5
DAI Applicability to CIS
The forthcoming sections will briefly describe two DAI based approaches that are of
relevance to CIS and this thesis:
• The ARCHON project, Europe’s largest project on DAI during the early 1990’s
(Jennings, 1994a).
• COOL, which is a coordination language for multiagent systems (Barbuceanu
and Fox, 1996).
Chapter 2. Background and Related Work
2.5.1
43
ARCHON
The ARCHON (ARchitecture for Cooperative Heterogeneous ON-line systems) project
(Jennings, 1994a) was Europe’s largest project on Distributed Artificial Intelligence
(DAI) during the early 1990’s. It focused on a general-purpose architecture, software
framework and methodology for supporting real world DAI systems. The results
from the ARCHON project have been applied in several real-world applications such
as electricity distribution and supply, control of a cement kiln complex and control
of a particle accelerator.
Each ARCHON agent (problem solving entity) is divided into two layers, see
Figure 8: an ARCHON layer that encapsulates generic knowledge about cooperative
interaction which is domain independent; and one or more intelligent systems that
are possibly pre-existing systems which perform the problem solving process.
The ARCHON layer is mainly composed out of the following five components:
• the high level communication module is responsible for communication (message
passing) with other ARCHON agents. In provides services such as intelligent
addressing and filtering.
• the planning and coordination module reasons about the individual ARCHON
agent’s role and decides which actions should be taken. It provides generic
cooperation know-how encoded in production rules of the form (Jennings and
Pople, 1993):
Rule-1
if
an agent has generated a piece of information i
and it believes that i is of use to an acquaintance
Chapter 2. Background and Related Work
ARCHON
agent
44
ARCHON
agent
Distributed computing infrastructure
ARCHON layer
-high level communication
-planning and coordination
-acquaintance
-self
-monitor
111111111111
000000000000
000000000000
111111111111
Intelligent system(s)
Figure 8: ARCHON layers
Chapter 2. Background and Related Work
45
then send i to that acquaintance
Rule-2
if
an agent has a skill to perform and is not able to perform it
then locally seek assistance from another agent
• acquaintance models represent the skills, interests and capabilities of other ARCHON agents.
• the self model is an abstraction of an ARCHON agent’s underlying intelligent
information system. Information about current state and actions that can be
executed in the underlying intelligent system are provided.
• the monitor controls the underlying intelligent system.
ARCHON represents a general purpose architecture for real world applications.
It is important in making a separation between generic knowledge about cooperative
interaction, and application knowledge (of an intelligent system). Thus, its approach
enables generic cooperative features to be reused for other applications.
2.5.2
COOL
COOL (COOrdination Language) is a language for describing coordination in multiagent systems (Barbuceanu and Fox, 1994; Barbuceanu and Fox, 1995; Barbuceanu
and Fox, 1996). It is based on speech act communication, which captures the coordination that is required when agents are working together. COOL is being used:
i) for representing the coordination mechanism for a supply chain of manufacturing
Chapter 2. Background and Related Work
46
enterprises; ii) as a framework for designing and validating coordination protocols for
multi-agent systems.
For the purpose of this thesis we will briefly summarize the most important levels
of agent interaction that were identified in (Barbuceanu and Fox, 1994; Barbuceanu
and Fox, 1995):
1. Information content level: This level is concerned with the specification of lowlevel information transmitted among agents. Specification is done by a specific
language such as KIF (Knowledge Interchange Format) language (Genesereth
and Fikes, 1992), e.g. “(produce 100 chairs)”.
2. Intentional level: This level specifies the intention an agent has with respect to
the information content. As described in (Barbuceanu and Fox, 1995) the same
information content can be transmitted with different intentions, e.g. “(ask
(produce 100 chairs))” vs. “(deny (produce 100 chairs))”. Specification of
intentions of agents are addressed in, for example, KQML (Knowledge Query
Manipulation Language) (Finin et al., 1994; Labrou and Finin, 1994), which
provides a set of performatives such as ask and deny.
3. Coordination level: This level is concerned with shared conventions (Jennings,
1993), which makes it possible for agents to coordinate their exchanged messages. A protocol for this type of coordination has been addressed in the COOL
language (Barbuceanu and Fox, 1995).
The COOL language has proposed a number of high-order speech acts, specified
with the aid of a finite state machine. These supplement the basic set of speech acts
provided in KQML. The new speech acts are (Barbuceanu and Fox, 1995):
Chapter 2. Background and Related Work
47
• Propose. This speech act proposes a subgoal to an agent.
• Counter-Propose. This speech act is used to issue a counter-proposal. This
means that a new subgoal is proposed which partially satisfies the initial subgoal.
• Accept and Reject. These two speech acts allow agents to accept or reject a
previously proposed subgoal.
• Cancel. This speech act sends a cancel message with respect to a previously
accepted subgoal.
• Satisfy. This speech act is used to announce that a subgoal has been satisfied.
• Fail. This speech act is used to announce that a subgoal could not be satisfied.
For the purpose of this thesis we also note two other speech acts which were
originally described in (Barbuceanu and Fox, 1994), but were left out in (Barbuceanu
and Fox, 1995):
• Commit. This speech act is used to send a confirmation to an agent that it
has been awarded a previously proposed subgoal.
• De-Commit. This speech act sends a cancellation of a previously committed
subgoal.
COOL provides a clear separation of agent interaction at different levels. It introduces an explicit coordination level for agent interaction using high-order speech
acts.
Chapter 2. Background and Related Work
2.6
48
The Approach Taken in This Thesis
The literature study performed indicates that parts of the DB community and the
DAI community are moving towards each other. One important common ground for
both the DB and DAI communities is the research community of CIS. This thesis
targets the complexity of cooperation as found within CIS and proposes an active
database solution (including active capability) to supporting CIS. Thus, the thesis
has its roots in the DB community (ADBMS). Special emphasis has been placed on
a synthesis of research results from both the DB community and the DAI community
with respect to cooperation.
This thesis expands upon the architecture described in (Chakravarthy et al., 1993).
In contrast to the work presented in (Chakravarthy et al., 1993), which is based on
the use of blackboards, this thesis is based on message passing for interaction. The
centralized approach proposed in (Chakravarthy et al., 1993) can become a potential bottleneck since a single blackboard does not scale up well when the number of
problem solving agents is large. Further, when moving to the distributed (long-term)
approach which relies on multiple blackboards, it has been shown that multiple blackboards have the same semantics as message passing systems (Hewitt and Lieberman,
1984; Jennings, 1994b).
Current ADBMS based suggestions can broadly be divided into the following three
categories with respect to the types of cooperation primitives provided:
1. No cooperation primitive is supported. As a consequence there is no explicit
support for negotiation, e.g. (Chakravarthy et al., 1993).
2. Simple types of cooperation primitives such as send and receive operations are
suggested, e.g. (Bussler and Jablonski, 1994; Geppert et al., 1995). Extending
Chapter 2. Background and Related Work
49
these approaches to support more advanced forms of interaction such as negotiation can be problematic, since simple send / receive operations are too weak
for supporting negotiations (Muller, 1996).
3. Advanced types of cooperation primitives such as assign, vote, eval are suggested including support for negotiation, e.g. (Lockemann and Walter, 1995).
With regard to the above categorization this thesis falls into the third category.
Thus, the work reported in this thesis is similar to the work on cooperation protocols
in (Lockemann and Walter, 1995). In contrast, this thesis reuses well founded work
in DAI, such as speech acts and coordination protocols, for specifying cooperation
in CIS. As a consequence, prior to the work reported in this thesis none of the
relevant ADBMS approaches had tried to tackle the issue of if/how active capability
in the form of ECA rules can capture the fundamental cooperation strategies, i.e. task
sharing and result sharing. Finally, none of the above ADBMS approaches provide a
clear methodology for mapping a high-level cooperation (protocol) specification into
ECA rules.
This thesis acknowledges and reuses well founded work in DAI on cooperation.
For example, the representation of protocols using speech acts is taken up in this
work. In contrast to the relevant DAI based approaches such as ARCHON (Jennings,
1994a) and COOL (Barbuceanu and Fox, 1995), where generic cooperation knowledge
is captured by condition-action rules, this thesis has used ECA rules. The ECA
approach is important as it introduces an explicit event part for cooperation rules. The
event is an important optimization issue, as it specifies when to evaluate a condition,
not always as in the case of condition-action rules. Introducing an explicit event part
also makes it possible to combine primitive events into high level composite events.
Composite events can thereby: i) reduce the complexity of rule conditions, and ii)
Chapter 2. Background and Related Work
50
precisely specify when to take responsive actions to multiple result notifications.
Previous work on ADBMS and agent technology primarily concerns conceptual
issues such as extending ADBMSs to support weak and strong agency (Akker and
Siebes, 1997) and comparing ADBMS and agent characteristics (Bailey et al., 1995).
This thesis explicitly targets the cooperation between multiple agents (ISs). Neither
the work reported in (Akker and Siebes, 1997) nor (Bailey et al., 1995) explicitly
addresses issues of cooperation in a multiagent environment.
In summary, this thesis synthesizes previous ADBMS results and DAI results in
a novel approach for supporting cooperation in CIS.
Chapter 3
The Chosen Problem
In this chapter I elaborate on the research literature related to the major cooperation
strategies of task sharing and result sharing. Both cooperation strategies can be used
stand alone or mixed. In this thesis the stand alone approach of each strategy will
be addressed. I then present the refined research objectives of the thesis.
3.1
Task Sharing
In the forthcoming sections two facets of proposals elaborated in the research literature are presented: static and dynamic allocation of tasks, and protocols.
3.1.1
Static and Dynamic Allocation of Tasks
Based on the ability of an agent to decompose a task, the dynamics of task shared cooperation can be broadly classified into (classification based upon (Bond and Gasser,
1988a)):
1. Static allocation, which assumes that a problem is posed to a specific agent,
51
Chapter 3. The Chosen Problem
52
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 agents which are executing the allocated tasks.
2. Dynamic allocation (predetermined managers), 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 agents. 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. Dynamic allocation (general DAI), which introduces a greater element of
collaboration than the previous approaches. In this approach a problem is posed
to all agents. Each agent then tries to come up with its own solution to the
problem. It further implies that the agents 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.
3.1.2
Protocols
A protocol defines the structure of the dialogue among agents (Parunak,
1996).
There is a broad spectrum of proposals for supporting cooperation, ranging from
cooperation in workflow-oriented systems to cooperation in DAI applications. In most
Chapter 3. The Chosen Problem
53
of these systems, cooperation consists of a set of messages exchanged among agents.
The exchanged messages range from application specific messages to generic (non
application dependent) cooperation performatives. Protocols are used to define the
structure and the allowed sequences of the messages exchanged.
There are different approaches to implementing cooperative features:
• application oriented. 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.
• 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.
In the literature, the terms cooperation protocols and coordination protocols are
used interchangeably. However, in contrast to DB proposals, DAI and CIS proposals
tend to use the notion of coordination protocols rather than cooperation protocols. In
this thesis I will use coordination protocols as I believe it better reflects the semantics
of a protocol. This is also consistent with the separation of the terms collaboration
and coordination introduced in Section 1.1. Thus, the use of coordination protocols
indicates less emphasis on issues such as reasoning, intentions and semantic contents.
Chapter 3. The Chosen Problem
3.2
54
Result Sharing
In this section I elaborate on three aspects of result sharing: i) sharing of information,
ii) producers and consumers of result notifications, and iii) multiple responses from
multiple agents. Research on result sharing has not been as exhaustive as it has been
on task sharing, so is less well reported.
3.2.1
Sharing of Information
In the literature the notions of result sharing and information sharing are used interchangeably. Below, two related definitions are presented. In their work on distributed
problem solving, Smith and Davis define result sharing as (Smith and Davis, 1981):
... a form of cooperation in which individual nodes assist each other
by sharing partial results, based on somewhat different perspectives on
the overall problem.
In his work on multi-agent systems, Jennings categorizes information sharing as
(Jennings, 1994b) an activity in which:1
Agents assist one another by spontaneously volunteering partial results
which are based on different perspectives of the global problem.
Information sharing (or result sharing) is appropriate to use when the results of
one agent influence the work done by another agent and / or when task decomposition
is not possible (or is difficult). For example, the SHADE (SHAred Dependency Engineering) project (Kuokka et al., 1993) provides support for information sharing within
1
In an earlier paper by Jennings (Jennings et al., 1992) the same definition is used for result
sharing.
Chapter 3. The Chosen Problem
55
concurrent engineering. Information sharing services include change notification and
subscription among a set of agents.
Although the DAI community has not dealt with the notion of transactions and
committed data, I feel that a a clear separation of the notions of result sharing and
information sharing is needed when considering database systems. Hence, in this
work I make the following categorizations:
• sharing of committed information (result sharing). The information obtained
will not change subsequently (a cancel cannot be issued).
• sharing of uncommitted information (information sharing). The information
may change subsequently (a cancel may be issued).
• sharing meta-data. This information is associated with the meta-data of an
agent (capabilities).
In this thesis I will use the term result sharing as described in the above categorization.
3.2.2
Producers and Consumers of Result Notifications
Essentially, result shared cooperation is based on distributing notifications of results
between producers and consumers. Thus, these notifications can broadly be categorized into (Kuokka et al., 1993):
• result notifications to known consumers
• result notifications to unknown consumers
Chapter 3. The Chosen Problem
56
The limitation of the first approach is that the consumers have to know exactly
to which producer they should subscribe. It is not always the case that a consumer
knows where to locate the producer of a result in a distributed environment. Similarly,
the producer does not always know where to locate the consumers of a result. For
example, the consumer may have yet to be added to the number of known agents in
the network. Hence, the second approach provides support for situations in which
the consumers and producers do not know about each other’s existence. Thus, result
notifications to unknown consumers will be routed through a broker or a match-maker,
or stored in shared memory for future use.
Both approaches rely on the use of subscription and notification mechanisms.
These range from simple ones such as defined within active databases (Anwar et al.,
1993; Berndtsson, 1994), to more complex techniques such as content-based routing
as defined within multi-agent based approaches for result sharing (Kuokka et al.,
1993; Kuokka and Harada, 1996).
Support for the more advanced techniques require that a number of open issues
and extensions are addressed (Kuokka and Harada, 1996). For the purpose of this
thesis I briefly highlight two of the relevant issues:
• generality of advertisements and requests. For example, one could introduce a
SQL construct such as the where clause to prune the number of result notifications and subscriptions.
• error recovery. One of the issues in this category is concerned with how/if
the transaction model as defined within the database community should be
introduced to support error recovery for agent protocols.
Chapter 3. The Chosen Problem
3.2.3
57
Multiple Responses from Multiple Agents
It is noted in (Hall, 1996) that,
For DAI systems which use result sharing, the user may be confronted with
a number of different agent responses to the same demand. This could
be extremely confusing, unless the DAI system facilitated her interactions
with a mechanism to view and understand the different results obtained
for the same problem.
I postulate that the use of composite events as defined within active databases can
help the user to specify, view and understand multiple results for the same problem.
3.3
Research Goals
3.3.1
Task Sharing
The previous research objective related to task sharing can now be refined as follows:
• task sharing aspects of the negotiation and result reporting phases of distributed
cooperative problem solving should be supported.
• support is required for predetermined and dynamic allocation of tasks, using
the protocol-oriented approach.
• support is to be provided by the active layer of an object-oriented database
system, ACOOD.
• a method for mapping task shared cooperation protocols into ECA rules in a
systematic manner is required.
Chapter 3. The Chosen Problem
3.3.2
58
Result Sharing
The previous research objective related to result sharing can now be refined as follows:
• support is required for result notifications to known consumers with the ability
to prune the number of result notifications and subscriptions.
• support is required for sharing of committed data (result sharing) and a technique for specifying when to take responsive action to multiple result notifications.
Chapter 4
Task Shared Cooperation
4.1
Method
I wish to support task shared cooperation with protocols expressed in high level
speech acts. I therefore need to be able to map these speech acts to ECA rules. For
this, I use a three step method for the mapping procedure:
1. 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. extract object model, algorithms and event hierarchies. For the object model,
we rely upon the OMT modeling and design technique (Rumbaugh et al., 1991).
Algorithms and event hierarchies are then inferred from the object model and
state diagrams.
59
Chapter 4. Task Shared Cooperation
60
3. 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.
One goal is to develop a tool to aid the generation of ECA rules from any state
diagram representing a protocol based on speech acts.
4.1.1
STEP 1: Model Speech Acts
The Chosen Benchmark Protocol
There are several proposals for negotiation language primitives in the literature. Negotiation primitives have been suggested for a range of applications such as supply
chain for manufacturing enterprises (Barbuceanu and Fox, 1995), and distributed
medical care (Huang et al., 1994). Given the range of applications, it is perhaps not
surprising that a number of application specific negotiation primitives have emerged.
According to a classification made in (Muller, 1996) all primitives can be broadly
divided into the following three categories:
• 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.
• 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 a task, e.g. fail, and satisfy.
Chapter 4. Task Shared Cooperation
61
For the current work we adopt a benchmark protocol based on the Contract Net
(Smith, 1980), and follow the approach taken in COOL (Barbuceanu and Fox, 1994;
Barbuceanu and Fox, 1995). The benchmark protocol can be viewed as a generic negotiation protocol as it encompasses primitives from all of the above three categories,
and the most common phases of negotiation. The semantics of the speech acts in our
benchmark protocol are:
• Propose. Used to initiate a negotiation by proposing a task to be solved by
one or more agents.
• Counter-propose. Used to refine an initial proposal by issuing a counterproposal.
• Accept. Used to signal acceptance of a previously distributed proposal.
• Reject. Used to signal rejection of a previously distributed proposal.
• Award. Used to send a confirmation to an agent that it has been awarded
a previously distributed proposal (which may have been refined by a counter
proposal).
• Cancel. Used to send a cancellation to agents that were not awarded a previously distributed proposal (which may have been refined by a counter proposal).
• Fail. Used to signal the failure of a task.
• Satisfy. Used to announce that a task has been satisfactorily executed.
The work in the thesis focuses on the coordination protocol for an agent and with
respect to this a high level finite state machine (FSM) for an agent is presented,
Chapter 4. Task Shared Cooperation
62
figure 91 . The left half of the figure represents an agent responding to the speech act
Propose. The right half of the figure represents an agent acting as a manager.
An application initiates (or handles over) a task to be solved to an agent by using
an application programmer interface (API) in order to send a /Propose speech act.
In response to a Propose/ speech act targeting an agent, the agent can respond with
an /Accept or a /Reject, or can issue a /Counter-propose, figure 9.
An agent can raise the event cannot execute task when it cannot solve the posed
task on its own. In such a situation the agent will seek assistance from other agents,
and will then act in the role of a manager (see figure 9).
In the case of responding with a /Counter-propose or an /Accept, an agent can
receive either Award/ or Cancel/.
In the case of Award/, an agent carries out the execution of the task and can report
the outcome of the problem solving phase by sending either a /Fail or /Satisfy.
Figure 9 also presents a FSM of an agent acting as a manager. A manager seeks
assistance from other agents by initiating a negotiation among potential contractors
using the speech act /Propose.
In response to distributed proposals, a manager will receive bids (Accept/, Reject/,
Counter-propose/) from potential contractors. Having received all bids and evaluated them, the manager can choose to respond in its turn, in its role as agent, with
/Accept, /Reject or /Counter-propose. (Compare with state Aa). Thus, the transitions from Am are sent up to the next manager or in the case of a top level problem
to the application that posed the original top level task.
In the case of deciding to /Reject, the manager needs to distribute /Cancel to
1
In this and in forthcoming FSMs, the thesis adopts the notation from (Barbuceanu and Fox,
1995) to denote < received − speech − act > / < sent − speech − act >. Annotations in italics
represent events being raised and arrows indicate to whether the speech act is being sent up or down
in the task hierarchy.
Figure 9: Overview of an agent
AGENT
/ Satisfy
Ca
Evaluate result
Award /
Ba
Await decision
/ Fail
cannot
execute
task
/ Accept
Aa
Evaluate proposal
/ Counterpropose
Cancel /
/ Reject
Propose /
/ Cancel
Agent as
MANAGER
Fm
Cancel all bids
Dm
Offer potential
contracts
Cancel /
Bm
Await decision
/ Accept
Am
Evaluate bids
all bids
received
Em
Save bids
/ Fail
/ Satisfy
Cm
Evaluate results
/ Counterpropose
/ Reject
/ Propose
all results
received
Award /
Hm
Save results
Gm
Distribute awards
Accept /
Reject /
Counter-propose /
Fail /
Satisfy /
/ Award
/ Cancel
Chapter 4. Task Shared Cooperation
63
Chapter 4. Task Shared Cooperation
64
its potential contractors.
In the case of responding with /Counter-propose or /Accept, the manager will
await a response, which can be either a Cancel/ or an /Award. (Compare with state
Ba). A received Cancel/ speech act implies distributing /Cancel to its potential
contractors.
A received Award/ speech act implies distributing /Award and /Cancel to successful contractors and unsuccessful contractors, respectively.
A manager will receive results from its contractors by collecting the speech acts
Fail/ and Satisfy/. When all results have bee received, the manager decides
whether or not the problem has been successfully solved. Based upon this decision it
will either send a /Fail notification or a /Satisfy. (Compare with state Ca).
A summary of the interplay between the application, agent/manager and agent
roles are provided in figure 10.
APPLICATION
API
AGENT
AGENT /
MANAGER
/ Propose
/ Reject
/ Accept
/ Counterpropose
/ Award
/ Cancel
/ Fail
/ Satisfy
/ Reject
/ Accept
/ Counterpropose
/ Fail
/ Satisfy
/ Propose
/ Award
/ Cancel
Figure 10: Interplay between application, agent and agent acting as manager
Chapter 4. Task Shared Cooperation
65
We next provide the details of the FSM for our coordination protocol (as shown
in figure 9) and show how the dynamic behaviour can be mapped into ECA rules.
Details of FSM
cannot execute task
Propose/
agentAccept
/Accept
agentReject
/Reject
Agent
do: evaluate proposal
agentCounter-propose
/Counter-propose
Figure 11: Evaluate proposal
Assume that a task T is posed to an agent (see figure 11 which corresponds to
state Aa in figure 9) using the speech act Propose/. First, the agent will evaluate the
proposal and 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 can raise
the event cannot execute task as a signal that it needs to allocate the task to one or
more agents. This situation will trigger a negotiation process among the agents. The
agent that needs help will hereafter be referred to as the Manager. This situation is
further explored in figure 12.
Having evaluated the proposal, an agent needs to decide how to respond. In
the case that an agent can execute task T (locally or by the assistance of one or
more agents), it can respond by raising either the event agentAccept or the event
Chapter 4. Task Shared Cooperation
66
agentCounter-propose. The former will trigger the submission of /Accept and the
latter of /Counter-propose.
In the case an agent raises the event agentReject then it will respond with the
speech act /Reject.
cannot execute task
Manager
do: set up Contract
Manager
do: find potential contractors
[potential contractors]
/ Propose
Manager
do: distribute proposals
Figure 12: Offer potential contracts
In figure 12, which corresponds to state Dm in figure 9, 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, the Manager will /Propose the contracts to the potential
contractors.
Chapter 4. Task Shared Cooperation
67
Accept /
Reject /
Counter-propose /
Em
do: save bids
[all bids received]
agentCounter-propose
Am
do: evaluate bids
agentAccept
/Counter-propose
/Accept
agentReject
/Reject
/Cancel
Fm
do: cancel all bids
Figure 13: Collect bids
In figure 13, which corresponds to states Em, Am, and Fm in figure 9, the Manager
collects the submitted bids from the potential contractors. The evaluation of received
bids can start, using appropriate criteria such as dead-line, a certain percentage of
bids received, or all bids received. In our benchmark protocol we will, without loss
of generality, 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, the Manager can decide how to respond to the
Chapter 4. Task Shared Cooperation
68
initial proposal, i.e. the task that was decomposed, in its role as agent. A response
can be made using one of the speech acts /Accept, /Reject, or /Counter-propose.
Thus, this state is similar to state Aa in figure 9.
In the case of /Reject the Manager needs to cancel all received bids from its
subcontrators using the speech act /Cancel.
agentAccept
agentCounter-propose
Bm
do: await decision
Cancel/
Fm
do: cancel all bids
Award/
/Award
/Cancel
/Cancel
Gm
do: distribute awards and
cancels to subcontractors
Figure 14: Distribute awards and cancels to subcontrators
In figure 14, which corresponds to states Bm, Fm, and Gm in figure 9, the Manager
first awaits the response to its submitted bid. The response can be either Cancel/ or
Award/.
In the case of Cancel/ the Manager needs to cancel all received bids from its
subcontractors.
In the case of Award/ the Manager needs to distribute notifications to its subcontractors using the speech acts /Award and /Cancel. We will assume that the
Chapter 4. Task Shared Cooperation
69
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.
Fail/
Satisfy/
Hm
do: save result
[all results received]
Cm
do: evaluate results
agentFail
/Fail
agentSatisfy
/Satisfy
Figure 15: Collect results
Subtasks are then executed by their contractors. A contractor can report the
outcome of a subtask execution by submitting a status report: Satisfy/ or Fail/
(see figure 15). 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.
Having received all results, the Manager needs to determine whether the initial
problem, i.e. task T, has been solved. Finally, the Manager submits its status report,
in its role as agent, using either /Satisfy or /Fail.
Chapter 4. Task Shared Cooperation
4.1.2
70
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.
Object Model
Human involvement is required in order to design the object model of the coordination
protocol. The intention of the object model (a set of classes) presented here is not
to give a complete model of a fully fledged system. Instead, we focus on the core
features that need to be provided in terms of interaction as described in our previous
scenario.
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 (Barbuceanu and Fox, 1995)
where a Conversation class is introduced.
Each Agent can be responsible for several Contracts. In order to initiate a negotiation an agent invokes the operation cannotExecuteTask. During the initiation
phase, operations such as setupContract and distributeProposals are needed.
Agents need to be able to evaluateProposals, and can then reply by invoking
one of the operations sendAccept, sendReject, or sendCounterPropose. Further,
agents need to be able to evaluateBids, and thereafter distributeAwards and
distributeCancels to potential contractors. Finally, Agents can report the outcome of a task by using either operation sendSatisfy or operation sendFail.
Each contract has a responsible Manager. Attributes such as Set of Accepts,
Chapter 4. Task Shared Cooperation
71
Agent
Contract
Set of Contracts
operations
evaluateProposal
cannotExecuteTask
setupContract
evaluateBids
evaluateResults
send operations
sendReject
sendAccept
sendCounter-propose
sendFail
sendSatisfy
distributeProposals
distributeAwards
distributeCancels
Pointer Manager
Set of PotentialContractors
Set of Accepts
Set of Rejects
Set of Contractors
Set of Results
operations
findPotentialContractors
savePotentialContractors
saveBid
setContractors
sendAward
sendCancel
saveResult
.....
receive operations
receiveAccept
receiveReject
receiveCounter-propose
receiveCancel
receiveAward
receiveFail
receiveSatisfy
.....
Figure 16: Agent and Contract classes
(event raised)
Chapter 4. Task Shared Cooperation
72
Set of Rejects, Set of Contractors, and Set of Results are used to keep information about the different phases of the protocol. Similarly, the following operations
are used to initiate and respond to activities of the protocol: findPotentialContractors,
savePotentialContractors, setContractors, sendPropose, saveBid, and saveResult.
Algorithms and Event Hierarchies
We used a straightforward system for mapping state diagrams to event hierarchies,
see Table 1.
State Diagram
event
received speech act (event)
[condition (guard)]
sent speech act (action)
activity
automatic transitions
ECA Paradigm
primitive event
primitive event
composite event
rule action
rule action
no events or rules are generated
Table 1: Mapping state diagrams to event hierarchies.
Briefly, each event and received speech act in the state diagram are associated with
a primitive event, which is raised after the execution of the operation. Each condition
that guards a transition in the state diagram corresponds to a composite event. This
composite event can be defined on previously mapped primitive events or composite
events, or internal composite events that cannot be directly inferred from the state
diagram. Sent speech acts (actions) and activities are both mapped to rule actions,
which can be triggered by either a primitive event or a composite event. Automatic
transitions do not generate any corresponding events and rules. The transition from
state a S to a state S’ occurs as soon as all the activities in S have been executed.
Chapter 4. Task Shared Cooperation
73
We next demonstrate the mapping algorithm on the state diagram as shown in
Figure 11.
Mapping State Diagram in Figure 11
Using the above mapping procedure on the state diagram shown in figure 11 we
get the skeletons for events and rules shown in Table 2.
State Diagram
Propose/
evaluate proposal
ECA Paradigm
primitive event
rule action
cannot execute task
agentAccept
agentReject
agentCounter-propose
/Accept
primitive event
primitive event
primitive event
primitive event
rule action
/Reject
rule action
/Counter-propose
rule action
Remark
EreceiveP roposal
RevaluateP roposal triggered
by EreceiveP roposal
EcannotExecuteT ask
EagentAccept
EagentReject
EagentCounter−propose
RsendAccept is triggered
by EagentAccept
RsendReject is triggered
by EagentReject
RsendCounter−propose is triggered
by EagentCounter−propose
Table 2: Mapping state diagrams in Figure 11.
In the above, the event EreceiveP roposal is the triggering event for the evaluation of
a proposal. Once the evaluation is done, an agent can raise one of the following events:
EcannotExecuteT aks
which initiates the negotiation process among the agents.
EagentAccept
which triggers rule RsendAccept.
EagentReject
which triggers rule RsendReject.
EagentCounter−propose
which triggers rule RsendCounter−propose.
Chapter 4. Task Shared Cooperation
74
Mapping State Diagram in Figure 12
Table 3 depicts the events and rules that were inferred from the state diagrams
shown in figure 12.
State Diagram
cannot execute task
set up Contract
ECA Paradigm
primitive event
rule action
potential contractors
distribute proposals
(and /Propose)
composite event
rule action
Remark
EcannotExecuteT ask
RsetU pContract triggered
by EcannotExecuteT ask
EpotentialContractors
RdistributeP roposals is triggered
by EpotentialContractors
Table 3: Mapping state diagrams in Figure 12
In the above, if an agent cannot execute a posed problem (Figure 12), it will raise
an event cannot execute task in order to start the negotiation process. This event
is the starting point for when an agent is acting as a manager. The mapping to
ECA rules for the starting point is rather straightforward, in that a primitive event
EcannotExecuteT ask will trigger a rule RsetU pContract .
Rule RsetU pContract will decompose the overall problem (task) into n subtasks,
where each subproblem (subtask) is represented by a Contract. The arity of subtasks
is dynamically derived, since we cannot know in advance which problem will cause
an agent to trigger the task shared protocol. In fact, this would imply that we would
have to specify every potential problem and decompose it into subtasks in advance.
Rule RsetU pContract will also create a composite event EpotentialContractors . This composite event corresponds to the semantics expressed by the condition potential contractors link in figure 12, and is expressed by the event hierarchy shown in figure
17.
The automatic transition in figure 12 will not generate any events and rules.
Chapter 4. Task Shared Cooperation
75
Hence, the activity find potential contractors does not appear in the above table.
R prepareCollectBids
R distributeProposals
E potentialContractors
CONJUNCTION
(or SEQUENCE)
E savePotentialContractors
E savePotentialContractors
(Contract 1, Problem A)
(Contract n, Problem A)
Figure 17: Composite event EpotentialContractors : potential contractors have been identified for each contract
The composite event EpotentialContractors is a conjunction (or sequence) of primitive
events EsaveP otentialContractors , where each EsaveP otentialContractors event instance refers
to a set of potential contractors that have been found for a given Contract (i.e.
subtask). Event EsaveP otentialContractors is raised after each invocation of the operation
savePotentialContractors in class Contract. Event EsaveP otentialContractors is inferred
from the object model in figure 16.
Rule RdistributeP roposals is defined on event EpotentialContractors and will distribute the
indicated proposal to potential contractors. A second rule, RprepareCollectBids , needs
to be defined on event EpotentialContractors , the action for which will set up a composite event EallBidsReceived before bids are submitted. Details of EallBidsReceived will be
explained in figure 18. Rule RprepareCollectBids is executed before rule RdistributeP roposals .
Mapping State Diagram in Figure 13
Chapter 4. Task Shared Cooperation
76
Table 4 depicts the events and rules which were inferred from the state diagram
shown in figure 13.
State Diagram
Accept/
Reject/
Counter-propose/
save bids
ECA Paradigm
primitive event
primitive event
primitive event
rule action
all bids received
evaluate bids
composite event
rule action
agentCounter-propose
agentAccept
agentReject
/Counter-propose
primitive event
primitive event
primitive event
rule action
/Accept
rule action
/Reject
rule action
cancel all bids (and /Cancel)
rule action
Remark
EreceiveAccept
EreceiveReject
EreceiveCounter−propose
RsaveBid triggered by either
EreceiveAccept, EreceiveReject or
EreceiveCounter−propose
EallBidsReceived
RevaluateBids triggered
by EallBidsReceived
EagentCounter−propose
EagentAccept
EagentReject
RsendCounter−propose triggered by
EagentCounter−propose
RsendAccept triggered by
EagentAccept
RsendReject triggered by
EagentReject
RdistributeCancels triggered by
EagentReject
Table 4: Mapping state diagram in Figure 13.
Composite event EallBidsReceived corresponds to the semantics expressed by the
condition that guards the all bids received link in figure 13 and is expressed by the
event hierarchy of figure 18.
Chapter 4. Task Shared Cooperation
77
R evaluateBids
E allBidsReceived
E allBidsContract
CONJUNCTION
(or SEQUENCE)
CONJUNCTION
(or SEQUENCE)
CONJUNCTION
(or SEQUENCE)
(Contract n, ..)
E bidReceived
E receiveAccept
DISJUNCTION
E receiveReject
R saveBid
DISJUNCTION
E receiveCounter-propose
(Contract 1, Problem A, Potential Contractor 1)
E ....
E ....
E ....
(Contract 1, Problem A, Potential Contractor n)
Figure 18: Composite event EallBidsReceived : all bids received
EbidReceived
is defined as a disjunction of EreceiveAccept, EreceiveReject and
EreceiveCounter−propose and 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 with the aid of rule
RsaveBid . 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.
EallBidsContract
is defined as a conjunction (or sequence) of EbidReceived .
This event will detect the situation when all bids have been
received for a Contract.
Chapter 4. Task Shared Cooperation
EallBidsReceived
78
is defined as a conjunction (or sequence) of EallBidsContract ,
and will detect the situation when all bids have been received for all contracts. The completion of EallBidsReceived
will trigger the rule RevaluateBids .
Once the evaluation of the received bids is done, a manager can respond in its
role as agent to the initial proposal by raising one of the following events2 :
EagentAccept
which will trigger rule RsendAccept.
EagentCounter−propose
which will trigger rule RsendCounter−propose.
EagentReject
which will trigger two rules: RsendReject and RdistributeCancels .
Rule RdistributeCancels is used to cancel all received bids from
subcontrators.
Mapping State Diagram in Figure 14
The events and rules of Table 5 were inferred from the state diagram shown in
figure 14.
In the case that an agent has chosen to raise either agentCounter-propose or agentAccept it will enter a state in which it awaits the decision on its submitted bid.
Event EreceiveAward is an indication to the agent that it has been chosen to execute
the task. This event will trigger three rules: RprepareIncommingResults, RdistributeAwards
and RdistributeCancels .
Rule RprepareIncommingResults is not part of the FSM shown in figure 14. It will
create the infrastructure for collecting incoming result notifications in advance in
2
These can be compared with p73: responses as non-manager.
Chapter 4. Task Shared Cooperation
State Diagram
agentCounter-propose
agentAccept
await decision
ECA Paradigm
primitive event
primitive event
rule action
Award/
Cancel/
cancel all bids (and /Cancel)
primitive event
primitive event
rule action
distribute awards
(and /Award)
distribute cancels
(and /Cancel)
rule action
rule action
79
Remark
EagentCounter−propose
EagentAccept
Ridle triggered by either
EagentCounter−propose or EagentAccept
EreceiveAward
EreceiveCancel
RdistributeCancels triggered by
EreceiveCancel
RdistributeAwards
triggered by EreceiveAward
RdistributeCancels
triggered by EreceiveAward
Table 5: Mapping state diagrams in Figure 14.
order to be able to collect the incoming results (figure 15). Further, there is no need
to create an infrastructure for collecting incoming results unless the agent has been
chosen to execute the task.
Rule RdistributeAwards will send a notification to agents that were assigned to be
subContractors. Rule RdistributeCancels will send a cancel notification to those potential
subcontractors that were not assigned to be subcontractors. In the case that rule
RdistributeCancels is triggered by EreceiveCancel it will cancel all bids.
Mapping State Diagram in Figure 15
The events and rules of Table 6 were inferred from the state diagram shown in
figure 15.
Composite event EallResultsReceived corresponds to the semantics expressed by the
condition that guards the all results received link in figure 15, and is expressed by the
event hierarchy shown in figure 19.
Composite event EallResultsReceived detects the situation in which the outcome of
Chapter 4. Task Shared Cooperation
State Diagram
Fail/
Satisfy/
save result
ECA Paradigm
primitive event
primitive event
rule action
all results received
evaluate results
composite event
rule action
agentSatisfy
agentFail
/Fail
/Satisfy
primitive event
primitive event
rule action
rule action
80
Remark
EreceiveF ail
EreceiveSatisf y
RsaveResult triggered by either
EreceiveSatisf y or EreceiveF ail
EallResultsReceived
RevaluateResults triggered by
EallResultsReceived
EagentSatisf y
EagentF ail
RsendF ail triggered by EagentF ail
RsendSatisf y triggered by EagentSatisf y
Table 6: Mapping state diagrams in Figure 15.
RevaluateResults
E allResultsReceived
CONJUNCTION
(or SEQUENCE)
RsaveResult
E resultContractReceived
DISJUNCTION
E receiveSatisfy
(Contract_1)
E receiveFail
(Contract_1)
DISJUNCTION
E receiveFail
E receiveFail
(Contract n)
(Contract n)
Figure 19: Composite event EallResultsReceived : all results received
Chapter 4. Task Shared Cooperation
81
each subtask is known. It is defined as a conjunction (or sequence) of EresultContractReceived ,
which indicates that a result has been received for a Contract (subtask).
Composite event EresultContractReceived is defined as a disjunction of EreceiveSatisf y
and EreceiveF ail for a given Contract. It will trigger rule RsaveResult which will save the
received result.
Rule RevaluateResults is defined on EallResultsReceived and will trigger the evaluation
of the received results. A manager can then choose various strategies for deciding
whether the task has been successfully solved (raise EagentSatisf y which will trigger
RsendSatisf y ) or not (raise EagentF ail which will trigger RsendF ail ). For example, it may
be acceptable that one or two tasks have failed if the other tasks are completed.
4.1.3
STEP 3: Generate ECA Rules
The final step in the method 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 in ACOOD (Hagen, 1996), we postulate that the
following features are of crucial importance if a task sharing protocol is to be supported by an active database.
• 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.
Chapter 4. Task Shared Cooperation
82
• 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 if the decomposition into
subtasks takes place at run time.
We had to propose preliminary solutions to the above in order to implement task
sharing using ACOOD and taking the approach proposed in this paper. Below, we
summarize the approach taken for our implementation effort.
Composite Event Restrictions
The use of composite events for monitoring incoming bids causes a major problem for a
Manager, since each incoming speech act event must be matched with its appropriate
problem/subproblem. This is problematic since there is no (or little) support in
prototype active databases for matching parameters within a composite event. We
illustrate this by an example, shown in Figure 20.
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: 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 generated. This event occurrence will be injected at the bottom of the event
hierarchy, completes event EbidReceived , and initiates the detection of composite event
EallBidsContract . If 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 2.
Chapter 4. Task Shared Cooperation
83
initiating event
R prepareAssignContractors
terminating event
R evaluateBids
E allBidsReceived
(E allBidsContract SEQ E allBidsContract )
Contract 2
Contract 1
E allBidsContract :
)
(E bidReceived CON E bidReceived
E bidReceived :
(E receiveAccept OR
E receiveReject)
E allBidsContract :
)
(E bidReceived CON E bidReceived
E bidReceived :
(E receiveAccept
E receiveAccept
(Potential Contractor A)
OR
E receiveReject)
E receiveAccept
(Potential Contractor B)
(Potential Contractor C)
(Potential Contractor D)
Figure 20: Invalid completion of composite event EallBidsReceived
Chapter 4. Task Shared Cooperation
84
When potential contractor D submits its bid for Contract 2, a new event occurrence of EreceiveAccept will be generated. This event occurrence will complete both
Contracts’ event hierarchies, i.e. EbidReceived , and EallBidsContract . Finally, it will complete EallBidsReceived and trigger the rules RprepareAssignContractors and RevaluateBids . Obviously, this is not the desired semantics, since we should still be waiting for bids
from two potential contractors, i.e. B and C.
In (Hagen, 1996) three potential solutions were investigated in order to avoid the
invalid completion of EallBidsReceived :
• rule condition; the condition part of a new rule defined on EallBidsContract would
check that the completion of EallBidsContract for contract 1 involved only bids for
contract 1. If the condition is satisfied, then EallBidsReceived is notified. Although
this approach seems promising it was discovered that none of the the four consumption modes (recent, chronicle, continuous, cumulative) could provide the
correct behaviour (Hagen, 1996).
• 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
(Gatziu and Dittrich, 1993).
• 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
Chapter 4. Task Shared Cooperation
85
provides a very clear semantics for which event occurrences and event parameters are used in the detection of a composite event. The drawbacks are twofold.
Firstly, there will be an overhead due to the additional set of events that need
to be created. Secondly, 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 (Hagen, 1996). For the second potential solution, it was identified
that it is not appropriate to use the conjunction operator for composite events when
the constituent events are of the same type. Thus, situations previously modeled by
conjunctions had to be replaced by sequences in order to obtain correct behaviour.
The third potential solution could still use the conjunction operator, since the logical
events filtered out uninteresting event occurrences.
Given the above, I have chosen to write “ conjunction (or sequence)” in the 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.
4.2
Implementation and Testing
In this section I will present the architecture and proof of principle application which
was implemented in ACOOD on a UnixT M , SunOST M 4.1 platform. Further details
can be found in (Hagen, 1996).
4.2.1
Architecture
For this proof of principle application two ACOOD nodes were set up, where each
ACOOD node had the main modules depicted in Figure 21:
Chapter 4. Task Shared Cooperation
86
ACOOD Node 1
Problem
Solving
Agents
ACOOD Node 2
Capabilities
Database
Email
Daemon
Email
Daemon
Decomposer
Problem
Solving
Agents
Capabilities
Database
Decomposer
Figure 21: Architecture of test application
• Problem solving agent, a persistent object representing an agent, which could be
activated to execute a certain task (or solve a subproblem). A short description
of an agent’s capabilities is maintained in the capabilities database.
• Capabilities database, a persistent object for maintaining information about the
types of task a PSA was capable of executing/solving. Each entry consisted
of a pair < agent, capability > that identified where the agent was located
and contained a short description of the capability it had. Providing a formal
notation and underlying formal semantics for expressing capabilities is beyond
the scope of this research.
• Decomposer, a persistent object which specified the problems that could be
decomposed. A list of subproblems was manually generated and maintained for
each decomposable problem.
• Email daemon. Distribution was achieved by examining the receiver slot of a
COOL message (Barbuceanu and Fox, 1994). If the receiver was not located
at the local ACOOD node, then the COOL message was sent to a local email
Chapter 4. Task Shared Cooperation
87
daemon process which forwarded the message to the correct node. At the receiving node there was another email daemon that processed the message and
raised the appropriate event.
4.2.2
Application Scenario
A supply chain application was considered for testing the ECA rules for task sharing.
It was assumed that a factory could manufacture several different products, where
the products were assembled by different assembly units such as CIM work stations.
Each assembling unit could only assemble one product at a time. In order to assemble
a product, each assembly unit needed component parts, which were ordered from
suppliers. A supplier could either be able or unable to deliver the requested component
part. Both assembly units and suppliers were viewed as PSAs.
For the above application environment two ACOOD nodes were set up. The first
was used to represent the assembly units in a factory. The second represented the
different suppliers. All of the PSAs had capabilities to assemble all products that
a factory manufactures. A table (see Table 7) indicated which PSAs were currently
available for supplying/assembling, for example, a chair. The status of a PSA could
either be busy or idle, where the latter indicated that the PSA (assembly unit) was
currently waiting for a product to assemble.
ACOOD node
ACOOD-1
ACOOD-1
ACOOD-1
ACOOD-1
PSA
PSA-1
PSA-2
PSA-3
PSA-4
Capability
assemble chair
assemble chair
assemble chair
assemble chair
..
..
..
..
Table 7: PSAs currently available.
busy / idle
busy
idle
busy
busy
Chapter 4. Task Shared Cooperation
88
The second ACOOD node modeled the suppliers and which components they
could deliver. The final product could be assembled by the component parts A and
B. All of the suppliers could supply these parts. Table 8 shows which components
each supplier had available for delivery at the start of the test scenario.
ACOOD node
ACOOD-2
ACOOD-2
ACOOD-2
ACOOD-2
ACOOD-2
ACOOD-2
ACOOD-2
PSA
PSA-1
PSA-2
PSA-3
PSA-4
PSA-5
PSA-6
PSA-7
Capability
All components
All components
All components
All components
All components
All components
All components
inventory
A, B
C
B
D, E
B, C, D
E, F
E
Table 8: Suppliers of components.
Below is a high level description based on the log (Hagen, 1996) of the test run:
1. The scenario starts with the detection of an event EcannotExecuteT ask which indicates that help is needed in assembling a chair. This event was raised explicitly by a PSA which, in this scenario, we will refer to as the Manager. An
EcannotExecuteT ask event occurrence triggers rule RsetU pContract which i) invokes
the Decomposer to decompose the task into smaller subtasks, and then ii) sets
up the initial infrastructure for the task sharing protocol (i.e. EpotentialContractors ,
RdistributeP roposal , RprepareCollectBids ).
2. For each subtask a contract is created. The task of assembling a chair is represented by Contract 1. We assume that the arity of the subtasks for each problem
are not in general known in advance. Thus, composite event EpotentialContractors ,
used to monitor whether there exists at least one potential contractor for each
Chapter 4. Task Shared Cooperation
89
subproblem, has to be dynamically created (created at run time).
3. In our scenario there are four PSAs at ACOOD-1 in the Capability database
that have the capability to assemble a chair. These PSAs are considered as
potential contractors. The successful search for potential contractors, signaled
by EsaveP otentialContractors , causes completion of EpotentialContractors and triggers
two rules: RdistributeP roposal , RprepareCollectBids.
4. Rule RprepareCollectBids dynamically creates composite events EallBidsReceived ,
EallBidsContract , and EbidReceived which monitor incoming bids from the potential
contractors. These composite events cannot be created at compile time since it
is not possible to determine the number of potential contractors until run time.
5. Event restriction is of importance for the correct completion of the above composite events. For example, EallBidsReceived must only complete if its constituent
events refer to the same Contract id. This event restriction is ensured by the
use of the same object id operator in ACOOD. Hence, EallBidsReceived consumes
events only with due regard to the same Contract id.
6. Rule RdistributeP roposal distributes a proposal for Contract 1 to each potential
contractor at ACOOD-1: PSA-1, PSA-2, PSA-3, and PSA-4. Each PSA that
receives the proposal then evaluates whether it can undertake the proposal. In
this scenario, PSA-1, PSA-3, and PSA-4 reject the proposal.
7. In order to reduce work-in-progress (Vollmann et al., 1992) PSA-2 does not
have any buffer of assembled chairs or components that are needed to assemble
a chair. Thus, during the evaluation phase PSA-2 raises event EcannotExecuteT ask
since it cannot solve the problem of assembling a new chair on its own. It needs
Chapter 4. Task Shared Cooperation
90
to find suppliers for missing components.
8. Event EcannotExecuteT ask now initiates another negotiation procedure as described
above. The Decomposer breaks down the task into two subtasks: supply component A and supply component B. A contract is created for each of these
subtasks: contract 2 (component A), and contract 3 (component B).
9. Suppliers 1-7 are all considered as potential contractors, i.e. potential suppliers
of parts for the required components. Thus, proposals for supplying component
A are distributed to suppliers 1-7, and proposals for supplying component B
are distributed to suppliers 1-7.
10. According to the scenario, supplier 1 accepts the proposal of contract 2, whereas
the other suppliers reject the proposal. For contract 3, suppliers 1, 3, and 5
accept the proposal, whereas the other suppliers reject the proposal.
11. The received bids (EreceiveAccept or EreceiveReject) from the suppliers complete the
composite events EbidReceived , EallBidsContract and finally EallBidsReceived . The completion of EallBidsReceived indicates that at least one potential contractor exists
for each contract. That is, there is at least one supplier that can deliver component A and one that can deliver component B. PSA-2 then submits its own
bid to the Manager that it accepts the proposal of Contract 1, i.e. assembling
a chair.
12. The Manager receives the bid from PSA-2 and the composite events EbidReceived ,
EallBidsContract , and EallBidsReceived are completed. Since there is only one PSA
that has accepted the proposal, PSA-2 at ACOOD-1 is chosen as the contractor
to assemble a chair. When all contractors have been set (EcontractorsAssigned) two
Chapter 4. Task Shared Cooperation
91
rules are triggered: RprepareIncommingResults and RdistributeAwards .
13. The triggering of rule RprepareIncommingResults causes the infrastructure for collecting incoming results EallResultsReceived to be prepared. Rule RdistributeAwards
causes distribution of a commit message. In this scenario, no cancel message is
sent, since there was only one PSA that accepted the proposal for contract 1.
14. As soon as PSA-2 at ACOOD-1 receives a commit for contract 1, it makes its
own decisions and distributes the following: a commit to supplier 1 for contract
2, a commit to supplier 5 for contract 3, and cancel messages to suppliers 1 and
3 for subcontract 3.
15. The committed suppliers eventually start to report their results, which in our
case is simply that they have satisfied the deliveries for the two components.
This causes completion of EallResultsReceived which monitors the incoming results,
which in turn triggers the evaluation phase of the received results. In our
scenario PSA-2 at ACOOD-1 uses the received components to assemble a new
chair. Thereafter it sends a satisfy of contract 1 to the Manager: a new chair
has been assembled.
4.2.3
Summary of Findings
In this chapter the identified active capabilities are:
1. Composite events for monitoring guarded state transitions in the FSM of the
protocol.
2. Composite event restrictions for matching incoming cooperation messages with
the appropriate task/contract.
Chapter 4. Task Shared Cooperation
92
3. External events, since potential contractors are likely to be found outside the
active database system.
4. Passing of event parameters for passing task related information.
5. Conflict resolution for controlling triggering of multiple rules.
6. Action execution for specific instances such as triggering the evaluation of bids
for a specific contract.
7. Dynamic creation of events and rules for constructing protocol infrastructure
when a task hierarchy can only be created at runtime.
Chapter 5
Result Shared Cooperation
In this chapter I elaborate on how active capability can be used in: i) supporting
result notifications to known consumers, ii) specifying when to take responsive action
to multiple result notifications, and iii) pruning the number of result notifications and
subscriptions.
5.1
5.1.1
Result Notifications
Inadequacy of Subscription Mechanisms for ECA Rules
Supporting result notifications to known consumers implies that one or more consumers have, in advance, made a subscription to a producer. Once a subscription
has been made, a producer can send result notifications to its consumers. Taking
an active capability approach to supporting result notifications to known consumers
implies that appropriate mechanisms for subscription and passing of results (data)
should be provided.
One of the most widely used subscription techniques within active databases (e.g.
93
Chapter 5. Result Shared Cooperation
94
ACOOD (Berndtsson, 1994), SAMOS (Gatziu and Dittrich, 1993)) is to subscribe
ECA rules to a specific event. The semantics of this approach are (Berndtsson,
1994):
When an event has been generated by an object check only those rules
which have subscribed to the generated event.
The above subscription semantics implies that rules which have not made a subscription to the generated event will not be triggered for condition evaluation. This
approach is appealing since it reduces unnecessary triggering of rules compared with
other approaches such as rules indexed by classes (Diaz et al., 1991).
Event parameters in active databases are usually passed on to the condition and/or
action part of a rule and so are available for providing context information. A classification of different types of event parameters is provided in SAMOS (Gatziu and
Dittrich, 1993) which distinguishes between:
• environment parameters. For example, time stamp (when was the event raised),
transaction id (in which transaction did the event occur) and user id (which user
caused the event).
• parameters which depend on the type of an event. For example, method events
have in addition the identification of the object (oid) and the parameters of the
invoked method.
If ECA rules are to be used for supporting result sharing, then the only way
they can transmit information is with the aid of event parameters. According to the
categorization made in SAMOS, I propose that result notifications be sent as event
parameters which depend on the type of the event.
Chapter 5. Result Shared Cooperation
95
Current active capability (including that in active database systems) includes
mechanisms for both subscription and passing of results (data). However, such mechanisms are inadequate for use in supporting result sharing, due to the adopted subscription semantics. In order to demonstrate the inherent problem, a simple example
is provided.
Assume that an agent has subscribed to the results of an operation sum which
is performed by another agent. The outcome (result) of the operation is the sum of
the two parameters x and y, i.e. result = sum(x,y). Thus, if x = 10 and y = 10, the
outcome of the operation 20 will be sent to the subscribing agent.
The above scenario is not a problem for subscription techniques suggested within
DAI. However, the same example supported by active capabilities will be problematic. Although the result 20 can be sent as an event parameter, an active capability
approach will face the following problems:
• an ECA subscription cannot refer to the outcome of an operation, i.e. 20. In
active databases it is possible to send the input parameters of an operation
(e.g. x = 10 and y = 10) as event parameters but not the return value of an
operation.
• an active database solution would need to store the outcome of an operation
in order to be able to first retrieve the results and then send them as event
parameters to subscribers. This is problematic since not all applications may
have mechanisms available for saving results.
In order to address the inadequacy of subscription mechanisms as used within
active databases, a refined ECA subscription mechanism is introduced in the following
section.
Chapter 5. Result Shared Cooperation
5.1.2
96
A Refined Subscription Mechanism for ECA Rules
In my work on supporting result sharing by using ECA rules, I see the need to
constrain the behaviour of the ECA subscription technique. This is a consequence of
the semantics of result sharing. In the current ECA subscription version it is possible
to subscribe to events which are generated either before or after the completion of an
operation. Clearly, the before option is not appropriate for supporting result sharing,
since the result will not be available until the operation has been completed. Thus,
the semantics for a refined subscription mechanism for ECA Rules supporting result
sharing are proposed as follows:
A consumer of a result can subscribe to results generated by a producer,
by subscribing to an event that indicates the completion of the operation
that produces them. In such a case the result is passed along as an event
parameter.
The subscription process can roughly be divided into the following three steps:
1. A consumer locates the set of producers that can provide the requested results.
2. Having identified the producers of the results, a formal subscription will take
place. The subscription includes a consumer-id which is a unique identifier of
the consumer, and an operation-id which is a unique identifier of the operation
that produces the results.
SUBSCRIBE consumer-id TO RESULTS OF operation-id
3. Results will be sent to the consuming agent until it unsubscribes.
Chapter 5. Result Shared Cooperation
97
The semantics of the keywords TO RESULTS OF, implies that a consumer has
subscribed to an event that is raised after the completion of the operation that produces them and that the outcome of the operation is passed along as an event parameter. For example, after the subscription
SUBSCRIBE Agent 4 TO RESULTS OF (Agent 1: sum(x,y))
Agent 4 has subscribed to the results of the operation sum(x,y). A potential
control flow based on ECA rules can be encoded as follows:
1. SUBSCRIBE Agent 4 TO RESULTS OF (Agent 1: sum(x,y))
2. execute sum(10,10):return-value
3. raise event(event-id, return-value, ..) and trigger rules which have subscribed
to event-id
5.2
Multiple Result Notifications
In most situations it is useful to react to result notifications from more than one
source. Typically, this is modelled in condition-action rules in DAI based approaches.
As discussed in section 2.6, when contrasting ECA rules with condition-action rules,
condition-action rules imply increased complexity of rule conditions. Due to the
absence of any equivalence to composite events (Chakravarthy and Mishra, 1994) in
current approaches to result sharing, an agent can only initiate responsive reactions
to the most recent occurrences of incoming result notifications.
In the forthcoming sections, I apply the usage of composite events and event
consumption modes to a concurrent engineering scenario. I will demonstrate the
Chapter 5. Result Shared Cooperation
98
applicability of composite events and event consumption modes, as defined within
active databases, for result sharing.
5.2.1
Characteristics of Concurrent Engineering
Concurrent Engineering (CE) is a departure from the earlier approach that can be
termed islands of automation. The need for a shift to CE is due to the fact that it
allows companies to develop products much more quickly and with higher quality than
with traditional sequential methods. CE relies on forming a full-time multidisciplinary
task group for each new project and on the use of disciplined techniques (Hartley,
1992). A task group typically consists of people and computer based tools from
different areas such as product design, manufacturing, marketing, purchasing, and
finance.
Although each group member is capable of performing sophisticated activities on
its own, it needs to be informed about recent design changes made by other group
members, in a timely and efficient manner. Similarly, each member needs to route its
own design changes to potentially interested group members.
5.2.2
The Power of Composite Events
Composite events are used to model complex situations which cannot be expressed
by a single primitive event. Thus, a composite event can be viewed as an abstraction
of a set of events.
Consider a CE scenario where a designer is developing a new product. The designer needs to be informed about changes in available stock sizes for those parts that
are components of the new product. Similarly, he/she needs to be informed about
any changes in stock-cost options (the sub parts cannot be too expensive). Whenever
Chapter 5. Result Shared Cooperation
99
the designer receives a request from the chief designer concerning a meeting about the
new product, the designer needs to present the current status of the new product and
also be able to present any related and important changes to, for example, stock-cost
options.
The above scenario could be modeled by introducing the following four agents:
Agent 1 (inventory agent), Agent 2 (purchasing agent), Agent 3 (chief designer), and
Agent 4 (the designer).
Agent 4 will subscribe to events that are generated by the other agents. When
subscribing to the events, Agent 4 can specify how the results should be transmitted.
For example, it may want to handle only one result, a set of results, or a stream
of results (see for example the KQML performatives stream-in and stream-all (Finin
et al., 1994)). The events in our scenario indicate the following:
• E1, change in available stock sizes for sub parts involved in the new product.
• E2, change in stock-cost options, i.e. new prices.
• E3, request for group meeting in the chief designer’s office.
Agent 1
e1
e3
Agent 4
Agent 2
Agent 3
e2
Figure 22: Agent 4 receives notifications from other agents
Chapter 5. Result Shared Cooperation
100
Having subscribed to the above events (Figure 22), the designer (Agent 4) can
then take responsive action (preparations for meeting) based upon the results that
are received when at least one result has been obtained from all three agents, with the
result from Agent 3 (E3) being the last one. In our scenario, the events are signaled
to the designer as illustrated in Figure 23 (example borrowed from (Chakravarthy
and Mishra, 1993)).
e11
E1
E2
e13
e12
e22
e21
e31
E3
e32
Time
t1
t2
t3
t4
t5
t6
t7
t8
Figure 23: Event time line
I adopt the notation E (e1 ,e2 , ...en ) to represent an event E, where e1 and e2
denote the first occurrence and second occurrence of E, respectively. Given the above
semantics, in order for Agent 4 to take responsive action, the following issues need to
be addressed:
• when should the triggered action be executed?
• assuming that each event e1, e2, and e3, by means of event parameters, carry
results that will influence the work done by Agent 4, then which set of event
parameters will be involved when the triggered action is executed?
Using composite events, the above scenario would be modeled as a composite
Chapter 5. Result Shared Cooperation
101
event CE-1. This will allow Agent 4 to take responsive action based upon different
combinations of the event occurrences, i.e. according to a chosen event consumption
mode.
CE-1: ((E1(parameters) and E2(parameters)) sequence E3(parameters))
• In the recent context, only the most recent occurrence of the initiator for any
event that has started the detection of a composite event will be used. All
other event occurrences will be deleted once the composite event has been detected. Thus, the first occurrence of CE-1 and the triggered action will be
based upon the following event occurrences along with their event parameters:<
e22 , e13 , e31 >.
• In the chronicle context the oldest occurrence of each component event will
be used. Thus, the first occurrence of CE-1 and the triggered action will be
based upon the following event occurrences along with their event parameters:
< e21 , e11 , e31 >. The second occurrence of CE-1 will include: < e12 , e22 , e32 >.
• In the continuous context each initiating event occurrence is a candidate for
starting the detection of CE-1. Thus, the first four occurrences of CE-1 will
be as follows: < e21 , e11 , e31 >, < e11 , e22 , e31 >, < e12 , e22 , e31 >, and <
e22 , e13 , e31 >.
• In the cumulative context all initiators are combined into one event detection. Thus, the first (only) occurrence of CE-1 will include the following:
< e21 , e11 , e12 , e22 , e13 , e31 >.
In current approaches for result sharing it is not obvious how the above scenario
would be supported. Although most approaches within multi-agent systems (e.g.
Chapter 5. Result Shared Cooperation
102
SHADE (Kuokka et al., 1993)) can support reaction to multiple result notifications,
these approaches would try to encode the semantics by using condition-action rules.
This will imply that control knowledge needs to be incorporated in rule specification. For example, in order to reflect the desired ordering between rule actions, rules
need to be arranged in a strict sequential thread. This also implies that condition
specifications need to be repeated in several rules.
Even though primitive events are introduced, there are complex events that cannot
be provided by using multiple rules based on primitive events (Chakravarthy and
Mishra, 1993). Importantly, event consumption modes can only be supported if
composite events are used. The absence of composite events will imply the semantics
of the recent consumption mode. Thus, it would not be possible to provide a range
of event contexts for condition action rules which most DAI based systems for result
sharing are currently using.
The conclusion is that composite events as defined within active databases are
useful for specifing multiple result notifications.
5.3
Pruning Result Notifications and Subscriptions
In order not to burden a consumer with uninteresting result notifications, it is of
importance that mechanisms are provided that offer subscription to result notifications at various levels of granularity. For example, an agent may wish to subscribe to
results according to one of the following levels of granularity:
1. any result generated by a given operation, or
2. specific results such as p(x).
Chapter 5. Result Shared Cooperation
103
Previous work on result sharing (information sharing) have suggested a SQL construct such as the where clause in order to prune the number of result notifications
and subscriptions (Kuokka and Harada, 1996).
When considering ECA rules for result sharing, it is of importance that similar
mechanisms are supported for pruning the number of result notifications and subscriptions. As for now, ECA rule subscriptions provide support for the first category, i.e.
the most general type of subscription. However, the support for the second category
is supported in an ad hoc manner and has several limitations.
I next demonstrate that current ECA based approaches are not suitable for context
based subscription with regard to:
• event consumption; since a composite event can consume any event occurrence
of its event components, some events will be pruned too early and several “nonevents” will be generated.
• maintenance; as context specific information is redundantly duplicated in associated rule conditions.
• efficiency; in terms of unnecessary triggering of ECA rules in order to check in
which context the event was generated.
Some of these problem were originally revealed in (Berndtsson and Lings, 1995)
and later on also verified by the implementation of the task sharing protocol. In order
to address the limitations the notion of context based subscriptions for ECA rules is
introduced.
Chapter 5. Result Shared Cooperation
5.3.1
104
Example
In this section a simple application scenario will be described. This application scenario will be used as a running example in the forthcoming sections.
Consider a scenario where a CIMstation can be in one of five different status
modes such as break-down, idle, busy, unloading or repair. It can change its current
status by invoking the method changeStatus. The invocation of method changeStatus
is associated with an event E0 , which is generated after the execution of method
changeStatus. One of the event parameters of E0 indicates the current status mode
of the CIMstation. Each of the five different status modes may require a special
response, each captured by a rule. Thus, the following five rules are introduced:
R1
which is specifically interested when event E0 indicates a machine breakdown.
R2
which is specifically interested when event E0 indicates that a machine
is idle.
R3
which is specifically interested when event E0 indicates that a machine
is busy.
R4
which is specifically interested when event E0 indicates that a machine
is unloading.
R5
which is specifically interested when event E0 indicates that a machine
is undergoing repair work.
The above relations between events and rules can be captured by the following
set of parameters (Berndtsson, 1994; Berndtsson and Lings, 1995):
• Let Ei be an event which is generated, e.g. E0 .
• Let REi be the set of rules that are triggered when event Ei is generated, e.g.
Chapter 5. Result Shared Cooperation
105
all rules that have subscribed to event E0 .
• Let Ei(j) be a specialization of event Ei with respect to a specific instantiation of
the event parameters. That is, event Ei is generated in a specific context j. For
example, E0(break−down) implies that E0 was generated in context break − down.
• Let REi(j) be the set of rules that are interested when event Ei is generated in
context j. For example, only rule R1 is interested when event E0 is generated
in context break − down.
5.3.2
Limitations of current ECA approaches
Event Consumption
As mentioned in section 5.1, event parameters can be used for providing context information in ECA rule based systems. Typically, these are evaluated in rule conditions
together with other non event parameter predicates. Within CIS environments, they
can be used to transfer results between producers and consumers of results.
Consider a scenario in which an agent is monitoring the status of two CIMstations
and that it will take responsive action when both CIMstations have signalled that
they are idle. In this example they do not have to be idle at the same point in time.
In order to detect status changes at these two CIMstations, a composite event
defined as a sequence1 of E0 and E0 is used to monitor the incoming status changes,
as shown in Figure 24. Suppose also that a rule has subscribed to the composite
event which will only be executed if the constituents of the composite are matched
with the status argument of idle in each case, i.e. E0(idle) should have occurred at
1
A conjunction is not appropriate since the composite event would be signalled at the first
occurrence of E0 . This is due to the fact that the constituents of the composite are of the same
event type
Chapter 5. Result Shared Cooperation
106
time
1
e0
(idle)
2
e0
(busy)
3
e0
(idle)
e0
e0
Seq
E0
(idle)
4
e0
(busy)
1
3
e0
e0
2
4
R
R
E0
(busy)
Figure 24: Chronicle consumption mode, event context checked by rule condition
both CIMstations. In the scenario of Figure 24, one would expect a rule firing based
on the event occurrences < e01 , e03 > to occur.
Considering the four event consumption modes (recent, chronicle, continuous, cumulative), I conclude that none of them can provide the required semantics. Although
several composite events will be generated, each and every rule condition will not be
satisfied. Hence, no rule firing will occur, see Table 9.
Event Consumption
Composite Event Occurrence
recent
never
1
2
chronicle
< e0 , e0 >, < e03 , e04 >
continuous
< e01 , e02 >, < e02 , e03 >, < e03 , e04 >
cumulative
< e01 , e02 >, < e03 , e04 >
Table 9: Non logical event consumption
Rule Execution
no
no
no
no
Chapter 5. Result Shared Cooperation
107
It is apparent that, in the above scenario, there is a problem with respect to event
consumption for composite events. The characteristics of these composite events
are that the event components are of the same event type, and they are generated in
different event contexts (different instantiations of the event parameters). In addition,
the event components are related to each other beyond matching of common identifiers
such as transaction id and user id. In such a system several non-event occurrences will
be generated, since a composite event will take any event occurrence of the correct
type for detection of its event components.
Maintenance
An important reason for introducing composite events is that they provided a higher
level of abstraction than previous approaches. For example, a single composite event
could now express what otherwise had to be captured by several rule conditions.
Hence, redundant rule condition specifications could be extracted and then defined
once, i.e. by the aid of a composite event.
Although composite events have been successfully introduced, there is still a similar maintenance problem with respect to the definition of event parameter checking.
In current approaches a user has to consider every rule associated with an event,
since the specification of event parameter checking has to be duplicated throughout
the rule base.
Consider a scenario in which a composite event is used to monitor unusual breakdowns in a manufacturing environment, Figure 25. The composite event indicates
a change from status mode idle to status mode break-down. Several rules may have
subscribed to the composite event. As current approaches only support definition
of event parameter checking in rule conditions, this definition has to be redundantly
Chapter 5. Result Shared Cooperation
108
Rule - 1
unusual
C: idle followed by break-down ...
break-down
A: ...
SEQ
Rule - n
C: idle followed by break-down ...
E0( * )
E0( * )
A: ...
Figure 25: Context specific information is redundantly duplicated in rule conditions
duplicated for each rule which is triggered by the composite event.
It is apparent that, in the above situation, there is a maintenance problem with
respect to the event and rule sets if one wishes to refine the definition of what constitutes an unusual break-down event. If the composite event is redefined to a change
in status from either idle or repair to break-down, then one must identify and change
each rule using the event. Hence, from a maintenance perspective, it would have been
better if the definition of what constitutes an unusual break-down event could have
been abstracted and centralized, rather than redundantly duplicated in several rule
conditions.
Efficiency
Reconsider the example in 5.3.2 and assume that event E0 was generated in context
break − down, i.e. E0(break−down) . For each specialization of an event type, a corresponding rule condition needs to be modeled. When an event is raised, all rules whose
condition contains a specialization of the raised event are notified. These rules are
triggered, for condition evaluation, in order to determine whether specialized versions
Chapter 5. Result Shared Cooperation
109
of the raised event have occurred. For the purpose of this chapter we can define rule
R1 in SAMOS (Gatziu and Dittrich, 1993) as follows:
DEFINE EVENT E0
AFTER.CIMstation.changeStatus(char* status)
DEFINE RULE R1
ON EVENT E0
IF status=’break-down’ AND ....
DO NotifyProductionManager(..., char* status)
This means that, when an occurrence of event E0 is generated, all rules that have
subscribed to event definition E0 will be triggered, i.e. RE0 . In our scenario five
rules will be evaluated in order to check whether the context, i.e. value of the status
parameter, satisfies the condition part. If the event parameter is equal to break-down,
then we have a situation in which:
• we have notified one rule (R1 ) that is interested in the generated event E0 and
matches the context (break-down).
• we have notified four rules (R2 , R3 , R4 , R5 ) which are interested in the generated
event E0 , but do not match the context (e.g. idle, busy) in which the event was
generated.
The above can be expressed by, URCEi(j) which is the ratio of unnecessary rule
checks which are performed when event Ei is generated in context j.
URCEi(j) = 1 −
Then, URCE0(break−down) is,
REi(j)
REi
Chapter 5. Result Shared Cooperation
1−
110
RE0(break−down)
1
= 1 − = 0, 8
RE0
5
The above solution does not scale well. In the above example as much as 80
percent of the rule checking performed in the given scenario is unnecessary, since the
contexts (event parameters) are checked in rule conditions. However, using the ECA
model gives the user little choice in reducing rule checking further, since the user
must perform the context check in rule conditions.
5.3.3
Context Based Subscriptions
As I have demonstrated in previous sections, most active database systems are based
on event algebras which do not allow conditions. Thus, every check of event parameters has to be performed by rule conditions. This implies problems with respect to:
event consumption, maintenance of events and rules, and unnecessary triggering of
rules. In order to address these problems I follow the approach in (Pissinou et al.,
1994) which allows:
... simple conditions, such as X > 10 < on attribute X of an event, or
a boolean predicate on attributes of events, to be included in the algebra
for composite events. Note that the boolean predicates in a composite
event do not refer to items stored in the database, and can be evaluated
from the given event, without querying the database.
This approach has a particular advantage in that it gives a better mechanism for
handling event consumption, and so gives finer control of event semantics and better
structure to event and rule bases. As a side effect efficiency will be improved. The
Chapter 5. Result Shared Cooperation
111
efficiency aspect of moving constraints from rule conditions into event detectors has
recently been addressed in (Paton et al., 1998).
Given the above, a refined ECA model can then be described as:
ON EVENT: a primitive or composite event
IF Event condition (event restriction): a simple boolean expression on
the event attributes
IF Condition: either a boolean expression or a SQL query on
the database
DO Action: either a database operation or an arbitrary application
program that is executed.
Concerning the expressiveness of the event condition the following definition is
used in the thesis:
<event condition> ::=
<conjunct expression> AND <logical event clause> |
<disjunct expression> OR <logical event clause> |
<logical event clause>
<conjunct expression> ::= <conjunct expression> AND <logical event clause> |
<logical event clause>
<disjunct expression> ::= <disjunct expression> OR <logical event clause> |
<logical event clause>
<logical event clause> ::= <event parameter> EQUAL <constraint value>
<constraint value> ::=
<event parameter> | <constant>
In the forthcoming sections I demonstrate that introducing logical events is a
promising route to take in order to address the previously introduced problems with
event consumption, maintenance, and efficiency.
Chapter 5. Result Shared Cooperation
112
Event Consumption
In section 5.3.2 it was identified that the current event consumption modes could
not provide the required semantics for event components of the same type that are
logically related to each other. In contrast to traditional ECA approaches, use of
logical events (as shown in Figure 26) for the same scenario will result in a single rule
firing.
time
1
e0
(idle)
1
e1
(idle)
2
e0
(busy)
3
e0
(idle)
e1
1
e1
2
e1
(idle)
2
4
e1
(busy)
R
Seq
E1( idle )
E0( * )
E1( idle )
E0( * )
Figure 26: Chronicle consumption mode, event context checked by logical events
In this scenario an explicit event E1 is created and associated with the method
event E0 . The explicit event will then get event notifications each time E0 occurs.
The semantics of E1 is to filter out uninteresting event occurrences. Hence, it will only
Chapter 5. Result Shared Cooperation
113
be raised if its logical condition over event parameters is satisfied. In this scenario,
E1 will be raised each time the status parameter is equal to idle.
Event Consumption Composite Event Occurrence Rule Execution
recent
never
no
1
2
chronicle
< e1 , e1 >
yes
continuous
< e11 , e12 >
yes
1
2
cumulative
< e1 , e1 >
yes
Table 10: Logical event consumption
When using logical events we get a very clean and precise semantics for when
events are raised. This is also reflected in that only interesting composite event
occurrences are signaled, see Table 10.
Maintenance
With logical events, a user can define a logical expression over the event parameters
centrally, rather than changing several (redundantly duplicated) rule conditions.
Reconsider the scenario where a composite event is used to monitor unusual breakdowns in a manufacturing environment, as shown in Figure 25. If logical events are
used for the same scenario then we can introduce two explicit events E1 and E2 ,
which are associated with method event E0 . Events E1 and E2 are defined to detect
whether the status parameter is equal to idle or break-down, respectively (Figure 27).
When redefining the semantics of what constitutes an unusual break-down to a
change in status from either idle or repair to break-down then:
1. we can redefine the logical expression of E1 to that the status parameter must
satisfy the value of idle or repair, (Figure 28), or
Chapter 5. Result Shared Cooperation
114
Rule - 1
unusual
break-down
C: ...
A: ...
SEQ
Rule - n
E1( idle )
E2( break down )
E0( * )
E0( * )
C: ...
A: ...
Figure 27: Context specific information is captured by a logical event
2. we can introduce a new explicit event E3 which can detect that the status
parameter is equal to repair, (Figure 29).
The first approach implies a single change to the logical condition (event restriction) of E1 , whereas the second approach requires that additional explicit events and
composite events are defined.
In contrast to traditional ECA approaches, event and rule definitions are independent of each other. Hence, there is no need to redefine rule conditions, for example,
when we redefine an event.
Efficiency
Consider that the CIM scenario in 5.3.2 is captured by logical events. The method
event E0 will be specialized into five logical explicit (abstract) events. Each logical
event is defined to detect one of the five status modes of a CIM station, and is
associated with one rule as follows:
Chapter 5. Result Shared Cooperation
115
Rule - 1
unusual
C: ...
break-down
A: ...
SEQ
Rule - n
E1( idle | repair )
E0( * )
C: ...
E2( break down )
A: ...
E0( * )
Figure 28: Redefining logical expression of E1
Rule - 1
unusual
break-down
C: ...
A: ...
SEQ
Rule - n
C: ...
OR
E1( idle )
E3( repair )
E0( * )
E0( * )
A: ...
E2( break down )
E( * )
Figure 29: Introducing a new explicit event E3
Chapter 5. Result Shared Cooperation
E1
116
which detects the situation when event E0 indicates a machine breakdown. Rule R1 has subscribed to E1
E2
which detects the situation when event E0 indicates that a machine is
idle. Rule R2 has subscribed to E2
E3
which detects the situation when event E0 indicates that a machine is
busy. Rule R3 has subscribed to E3
E4
which detects the situation when event E0 indicates that a machine is
unloading. Rule R4 has subscribed to E4
E5
which detects the situation when event E0 indicates that a machine is
undergoing repair work. Rule R5 has subscribed to E5
When the method event E0 is generated in this scenario five logical primitive
events will be evaluated (E1 , E2 , E3 , E4 , E5 ), one will be detected, and will trigger
one rule. Hence, for example, only those rules are triggered which are explicitly
interested when event E0 indicates a break-down.
This can be expressed by URCE0(break−down) as follows,
1−
5.3.4
RE1 (break−down)
1
=1− =0
RE1(break−down)
1
Summary of Findings
In this chapter the identified active capabilities are:
1. Composite events for specifying when to take responsive reactions to multiple
result notifications.
2. Event restrictions (primitive and composite) for supporting context based subscriptions.
Chapter 5. Result Shared Cooperation
117
3. External events for reacting to results provided by remote agents.
4. Passing of event parameters for distributing result notifications.
5. A refined rule subscription technique in order to reflect the semantics of result
sharing.
Chapter 6
Conclusions
6.1
Desirable Active Capability Properties for Supporting Cooperation Strategies in CIS
Based on the findings in this thesis and the implementation of various proof of
principle applications (Schwinger, 1995; Hagen, 1996) in ACOOD (Berndtsson and
Lings, 1992; Engström et al., 1997), a set of desirable active capability properties for
supporting cooperation strategies in CIS can now be identified. Briefly, the identified
properties are:
• Composite events. These are of importance both when supporting task sharing and result sharing. Concerning task sharing they are used to express the
semantics of guarding conditions in the state diagrams, i.e. when to take the
next step in the task sharing protocol. There is evidence that most aspects of a
task sharing protocol can be captured by the event operators conjunction and
disjunction. For some ADBMS it can be more appropriate to use other event
operators such as sequence, but in general conjunction and disjunction seem
118
Chapter 6. Conclusions
119
to be satisfactory. The recent event consumption mode together with event
restrictions (see below) have been observed to be satisfactory with respect to
supporting task sharing, see Chapter 4.
As for result sharing, no further requirements concerning event operator and
event consumption mode have been observed, see Chapter 5.
• Event restrictions (primitive and composite). These are of importance when
supporting task sharing and/or result sharing. A composite event that is used to
monitor a task shared protocol needs to be able to match incoming events with
the correct task, contract etc. Thus, it cannot be completed by consuming event
occurrences arbitrarily. The use of logical events (or modified same parameter)
has been identified as useful here, see Section 4.1.3.
When supporting context based subscriptions in result sharing it is of crucial
importance that mechanisms for event restrictions are available, see Section
5.3.3.
• External events. These are of importance when supporting task sharing and/or
result sharing, since events may be generated by other agents. The ability to
react to external events will allow a user to build composite events that contain
external sub events, see for example Chapter 4 and Section 5.2.
• Passing of event parameters. The results from operations are transported to
subscribers by the means of event parameters. This information needs to be
passed on to condition evaluation and/or action execution of an ECA rule, see
Section 5.1.
• Conflict resolution. This is of importance when multiple rules are triggered
Chapter 6. Conclusions
120
by the same events. With regard to this, rules that are used to create the
infrastructure of a task sharing protocol, e.g. RprepareCollectBids , need to be
executed before those rules that send out announcements, e.g. RdistributeP roposal .
This can be achieved by using rule priorities, see Chapter 4.
• Refined rule subscription. A refined ECA rule subscription has been introduced
in order to reflect the semantics of result sharing. Briefly, the semantics are: a
consumer of results subscribes to an event that is raised after the completion
of an operation that produces them and the outcome of the operation is passed
along as an event parameter to the consumer. See section 5.1 for more details.
• Action execution. Actions are executed in response to events, and they need
to be executed for a specific instance (or object), as identified in the proof of
principle implementation (Hagen, 1996). Thus, in ADBMS terms the action
execution is referred to as instance-oriented binding.
• Dynamic creation of events and rules. Depending upon the dynamics of the
chosen cooperation strategy and the application in mind, dynamic creation of
events and rules may be needed, see Chapter 4. If a task can be decomposed
into subtasks in advance (e.g. when constructing a system), then there is no
need for dynamic creation of events and rules.
6.2
A Comparison
I next compare the above set of desired active capability properties with features
supported by current ADBMS prototypes (ACOOD (Engström et al., 1997), Ode
(Lieuwen et al., 1996), SAMOS (Gatziu, 1994), Sentinel (Chakravarty et al., 1994).
Chapter 6. Conclusions
121
The table (Table 11) is based upon what is currently implemented and documented
in the official versions of each prototype. Hence, although external events were implemented for one of our proof of principle applications, this feature has not yet been
incorporated in the official version of ACOOD.
Feature
Composite events:
conjunction and disjunction
Event restrictions:
logical events or same OID
External events
Passing of event parameters
to condition and/or action
Conflict resolution
Refined rule subscription
Action execution:
instance-oriented binding
Dynamic creation of events and rules
ACOOD Ode Samos
Yes
Yes
Yes
Sentinel
Yes
Yes
Yes
Yes
No
Yes
No
Yes
No
Yes
Yes, instance
level events
Yes
Yes
Yes
No
Yes
No
No
Yes
Yes
No
Yes
Yes
No
Yes
Yes
No
No
Only rules
Table 11: Active (CIS) capability properties supported by current ADBMSs.
ADBMS prototypes have been developed for different types of applications, where
each application type has its requirements concerning supported active features.
Hence, it is not surprising, from the above table, that none of the above implemented ADBMS prototypes support all useful features. However, most of them have
the potential, with a few extensions, to be able to participate in a CIS environment.
6.3
Significance
As I have addressed in the thesis one important feature of current and future information systems is the ability to cooperate. In a special issue of IEEE Expert on
Chapter 6. Conclusions
122
CIS Mylopoulos and Papazoglou state that the advances of CIS technologies will not
come from any single research area such as database systems, artificial intelligence or
distributed systems. It is argued that (Mylopoulos and Papazoglou, 1997):
..although further enhancements are desirable, the greatest leverage
for technology advancement should come from their integration into a
seamless technology for building and managing cooperative information
systems.
The approach taken in this thesis is to view CIS as a synthesis of DB and DAI,
where the thesis can be viewed as a response to how DB and DAI results can be
integrated into a seamless technology for supporting CIS.
The significance of the work reported in the thesis concerns two major issues:
• How databases can participate as agents in CIS using active database technology.
• Architectural issues of relevance to CIS, for problems that require a combination
of DAI and DB solutions.
The achievements in the thesis concern three major issues:
• active capabilities for supporting cooperation strategies.
• a general method for mapping FSMs to ECA rules.
• separation of result sharing and information sharing with respect to a database
framework.
Chapter 6. Conclusions
123
In summary, ECA rules have proven to be useful in non-database areas such
as real-time and workflow. In addition to these two non-database areas, I have in
this thesis demonstrated that ECA rules are also useful for supporting cooperation
strategies. As a consequence, ECA rules can now be considered as an alternative rule
format for supporting, for example, coordination within DAI.
6.4
Future Work
Assuming that ADBMSs are extended to support the desirable properties for supporting cooperation strategies in a CIS environment, then the following issues can be
investigated: efficiency of logical composite events, tools and methodologies, rollbacks
of composite events and rule actions, and recovery.
6.4.1
Efficiency of Logical Composite Events
In section 5.3.3 one could argue that much of the previous context checking has been
moved from rule conditions to logical events. Thus, the same amount of work still
has to be done by logical events, although run-time rule triggering may have been
reduced. I address this argument by considering logical composite events.
Consider a scenario where users can raise two primitive events E0(answer, user)
and E1(colour, user). The event parameters can be instantiated as described in
Figure 30. We then introduce a composite event CE defined as a conjunction of E0
and E1. If we assume that the event occurrences of the primitive events are E0, E1,
E0, .., E1, then the detection of the composite event in both the recent and chronicle
context will be the same.
Typically, ECA rule languages cannot express event parameter matching within
Chapter 6. Conclusions
124
a composite event. Hence, in building a composite any event occurrence of its event
components can be used. Thus, we need to associate four rules with the composite
event in order to capture the various combinations of the event parameters.
R0: (Yes, Blue)
R1: (No, Blue)
R2: (Yes, Red)
R3: (No, Red)
CE: (E0:(*), E1(*))
E0(answer: {Yes, No}, user:{A, B})
E1(colour:{Blue, Red}, user:{A, B})
Figure 30: Non logical composite event (simple scenario)
Using logical events for the above scenario we get the set of events and rules shown
in Figure 31.
Although there is no unnecessary triggering of rules when using logical events, it
leads to even more condition checks than with a traditional non-logical approach. For
example, when 100 events are generated for each primitive event, then in a non logical
approach we would check 400 conditions (0 event conditions + 400 rule conditions),
whereas with a logical approach we would have to check 500 conditions (400 event
conditions + 100 rule conditions), see Table 12.
In the above example a context check is performed with respect to answer and
colour. If the rule execution is dependent upon all the event parameters answer,
colour, and user, then we need to add four new rules for the non logical approach,
Chapter 6. Conclusions
R0:
125
R1:
CE00(Yes, Blue)
E00(Yes)
CE01(No, Blue)
E01(No)
E0(answer: {Yes, No}, user:{A, B})
R3:
CE02(Yes, Red)
E02:(Blue)
R4:
CE(No, Red)
E03(Red)
E1(colour:{Blue, Red}, user:{A, B})
Figure 31: Logical composite event (simple scenario)
Event Cond. CE occurrences Rule Conditions Rule Actions
Non Logical
0
100
100 x 4
100
Logical
100 x 4
100
100
100
Table 12: Number of condition evaluations, simple example
(see Figure 32), and modify the existing event and rule base for the logical approach
as shown in Figure 33.
It is apparent that this will lead to an increased triggering of rules. Under this
scenario we can see that the non logical approach will lead to a total of 800 condition
checks, whereas a logical approach would only need 600, see Table 13.
Although initial work on logical composite events has been reported (Gehani et al.,
1992; Pissinou et al., 1994; Berndtsson and Lings, 1995; Schwinger, 1995), there are
still open research questions to address. In particular, how can logical composite
Chapter 6. Conclusions
126
R0: (Yes, Blue), user=A
R1: (Yes, Blue), user=B
R2: (No, Blue), user=A
R3: (No, Blue), user=B
R4: (Yes, Red), user=A
R5: (Yes, Red), user=B
R6: (No, Red), user=A
R7: (No, Red), user=B
CE: (E0:(*), E1(*))
E0(answer: {Yes, No}, user:{A, B})
E1(colour:{Blue, Red}, user:{A, B})
Figure 32: Non logical composite event (complex scenario)
R1: user=B
R0: user=A
R3: user=B
R2: user=A
R5: user=B
R4: user=A
R7: user=B
R6: user=A
CE00(Yes, Blue)
CE01(No, Blue)
CE02(Yes, Red)
CE(No, Red)
E00(Yes)
E01(No)
E0(answer: {Yes, No}, user:{A, B})
E02:(Blue)
E03(Red)
E1(colour:{Blue, Red}, user:{A, B})
Figure 33: Logical composite event (complex scenario)
Chapter 6. Conclusions
127
Event Cond. CE occurrences Rule Conditions Rule Actions
Non Logical
0
100
100 x 8
100
Logical
100 x 4
100
100 x 2
100
Table 13: Number of condition evaluations, advanced example
events be implemented efficiently? In a recent performance evaluation of four active
object-oriented database systems (Geppert et al., 1998) it is shown that adding additional functionality such as logical events to an event specification may not necessarily
degrade the performance. The active database system Ode (Gehani et al., 1992) is
an example of an efficient implementation of logical composite events. Furthermore,
when should rule conditions be used instead of logical composite events? In this section I have provided a simple and a complex scenario. There is an indication that
logical composite events may be more appropriate for use in complex scenarios than
for simpler examples.
6.4.2
Tools and Methodologies
The method introduced earlier for mapping task shared protocols into ECA rules (see
chapter 4) can benefit from a tool which automates the process of generating ECA
rules. An algorithm that describes the mapping procedure will ease the development
of such a tool.
It is also envisioned that the mapping method introduced can be the starting point
for further research on tools and methodologies for supporting active capability during
the software engineering process. As of now, the need for such tools and methodologies
have been identified in the literature (Dayal, 1995; Berndtsson and Hansson, 1996;
Diaz, 1998), but there are no suggestions available which fully address this problem.
Chapter 6. Conclusions
6.4.3
128
Rollbacks of Composite Events and Rule Actions
Rollbacks of composite events and rule actions due to cancelled information can become a problem when dealing with speech acts such as de-commit and/or information
sharing in an ADBMS context.
With regard to a speech act that de-commits a previously committed agreement,
e.g. a previously awarded task, this causes problems for an ADBMS, as the protocol
would need to back track in order to award the task to another agent, or in the worst
case restart the whole protocol. Concerning the latter, a protocol based on ADBMS
features would have to roll back signaled events and executed rule actions.
Information sharing introduces a higher level of uncertainty, as the received information may be cancelled at a later stage. Thus, in database terms we are then
dealing with uncommitted information. Hence, if composite events are built and rules
are fired based upon the completion of events, then we need to provide a user with
techniques and/or restrictions on how to use uncommitted information together with
active capability. For example, assume that a composite event is completed and triggers several rules. At a later stage, the information that caused the completion of the
composite event is cancelled. In a sense, this means that the composite event should
not have occurred. The question is then, i) should one ignore an attempted rollback
of the composite event and its associated triggering of rules, or ii) try to rollback the
composite event and try to undo the effect of the previously triggered rule actions.
As of now, there are no techniques available which fully address this problem.
6.4.4
Recovery
Most DAI based approaches have not addressed the issue of manipulation of shared
data or incorporate limited and ad hoc database functionality. The lack of database
Chapter 6. Conclusions
129
functionality in DAI systems implies that most approaches do not have a robust way
of supporting failures, recovery, and persistence. This has previously been pointed
out by Michael H. Huhns in (Huhns, 1994), where there is a discussion of how
transaction-processing concepts (consistency and integrity of data), persistence and
logging (recover from failures), and security (protection against corruption of information) should be incorporated into DAI based approaches. The paper concludes
that:
Agents with such capabilities would be more robust and, thus more
useful.
Based on the work reported in this thesis, the question opens of whether DAI
based cooperation protocols can utilize recovery and persistence properties of an
active database system.
Bibliography
ACT-NET Consortium (1996). The Active Database Management System Manifesto:
A Rulebase of ADBMS Features. ACM Sigmod Record, 25(3).
Akker, J. and Siebes, A. (1997). Enriching Active Databases with Agent Technolog.
In Proceedings of the First International Workshop on Cooperative Information
Agents (CIA-97), pages 116–125.
Anwar, E., Maugis, L., and Chakravarthy, S. (1993). A new perspective on rule support for object-oriented databases. In Proceedings of the International Conference
on Management of Data, pages 99–108.
Bailey, J. A., Georgeff, M., Kemp, D. B., Kinny, D., and Ramamohanarao, K. (1995).
Active Databases and Agent Systems - A Comparison. In 2nd International
Workshop on Rules in Database Systems (RIDS95), pages 342–356.
Balasubramanian, S., Maturana, F., and Norrie, D. (1996). Multi-Agent Planning
and Coordination for Distributed Concurrent Engineering. International Journal
of Cooperative Information Systems, 5(2–3):153–180.
Barbuceanu, M. and Fox, M. (1995). 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.
130
BIBLIOGRAPHY
131
Barbuceanu, M. and Fox, M. (1996). Capturing and Modelling Coordination Knowledge for Multi-Agent Systems. International Journal of Cooperative Information
Systems, 5(2–3):275–314.
Barbuceanu, M. and Fox, M. S. (1994). COOL - A Language for Describing Coordination Models in Multi-Agent Systems. Technical report, University of Toronto.
Berndtsson, M. (1994). Reactive Object-Oriented Databases and CIM. In Proceedings
of the 5th International Conference on Database and Expert System Applications,
Lecture Notes in Computer Science, pages 769–778. Springer-Verlag.
Berndtsson, M., Chakravarthy, S., and Lings, B. (1996a). Cooperative Problem Solving: A New Direction for Active Databases. In Proceedings of the International
Symposium on Cooperative Database Systems for Advanced Applications CODAS’96.
Berndtsson, M., Chakravarthy, S., and Lings, B. (1996b). Coordination Among
Agents Using Reactive Rules. Technical Report HS-IDA-TR-96-011, Department
of Computer Science, University of Skövde.
Berndtsson, M., Chakravarthy, S., and Lings, B. (1997a). Extending Database Support for Coordination Among Agents. International Journal of Cooperative Information Systems.
Berndtsson, M., Chakravarthy, S., and Lings, B. (1997b). 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.
BIBLIOGRAPHY
132
Berndtsson, M., Chakravarthy, S., and Lings, B. (1997c). Task Sharing Among Agents
Using Reactive Rules. In Proceedings of the Second IFCIS Conference on Cooperative Information Systems (CoopIS-97), pages 56–65.
Berndtsson, M. and Hansson, J. (1996). Workshop Report: The First International
Workshop on Active and Real-Time Database Systems (ARTDB-95). ACM SIGMOD Record, 25(1):64–66.
Berndtsson, M. and Lings, B. (1992). On Developing Reactive Object-Oriented
Databases. IEEE Quarterly Bulletin on Data Engineering, Special Issue on Active Databases, 15(1-4):31–34.
Berndtsson, M. and Lings, B. (1995). Logical events and eca rules. Technical Report
HS-IDA-TR-95-004, University of Skövde.
Bond, A. and Gasser, L. (1988a). An Analysis of Problems and Research in DAI. In
Readings in Distributed Artficial Intelligence, chapter 1, pages 3–35.
Bond, A. and Gasser, L., editors (1988b). Readings in Distributed Artficial Intelligence. Morgan Kaufmann.
Brodie, M. (1988). Future Intelligent Information Systems: AI and Database Technologies Working Together. In Readings in AI and Databases. Morgan Kaufmann
Publisher Inc.
Brodie, M., Bobrow, D., Lesser, V., Madnick, S., Tsichritzis, D., and Hewitt, C.
(1988).
Future Artificial Intelligence Requirements For Intelligent Database
Systems. In Proceedings from the Second International Conference on Expert
Database Systems, pages 45–62.
BIBLIOGRAPHY
133
Brodie, M., Jarke, M., and Papazoglou, M., editors (1994). Proceedings of the 2nd
International Conference on Cooperative Information Systems CoopIS-94.
Brodie, M. L. and Ceri, S. (1992). On Intelligent and Cooperative Information Systems: A Workshop Summary. International Journal of Intelligent and Cooperative Information Systems, 1(2):249–290.
Bussler, C. and Jablonski, S. (1994). Implementing Agent Coordination for Workflow
Management Systems Using Active Database Systems. In Proceedings of the
RIDE-ADS’94 Workshop, pages 53–59.
Chaib-draa, B. (1995). Industrial Applications of Distributed AI. Communications
of the ACM, 38(11):49–53.
Chakravarthy, S., editor (1992). Special Issue on Active Databases, volume 15. IEEE
Quarterly Bulletin on Data Engineering.
Chakravarthy, S. (1997). Active Databases and Agents in Cooperative Information
Systems. Panel at the Second IFCIS International Conference on Cooperative
Information Systems (CoopIS-97).
Chakravarthy, S., Blaustein, B., Buchmann, A. P., Carey, M., Dayal, U., Goldhirsch,
D., Hsu, M., Jauhari, R., Livny, M., McCarthy, D., McKee, R., and Rosenthal,
A. (1989). HiPAC: A research project in active time-constrained database management - final technical report. Technical report, Xerox Advanced Information
Technology.
Chakravarthy, S., Karlapalem, K., Navathe, S. B., and Tanaka, A. (1993). Database
supported cooperative problem solving. International Journal of Intelligent and
Cooperative Information Systems, 2(3):249–287.
BIBLIOGRAPHY
134
Chakravarthy, S. and Mishra, D. (1993). Snoop: An Expressive Event Specification
Language For Active Databases. Technical Report UF-CIS Technical Report
TR-93-007, University of Florida.
Chakravarthy, S. and Mishra, D. (1994). Snoop: An expressive event specification
language for active database. Knowledge and Data Engineering Journal, 14:1–26.
Chakravarthy, S. and Widom, J., editors (1996). Special Issue on the Active Database
Systems, number 2. Journal of Intelligent Information Systems (JIIS).
Chakravarty, S., Krishnaprasad, V., Anwar, E., and Kim, S. K. (1994). Composite Events for Active Databases: Semantics Contexts and Detection. In 20th
International Conference on Very Large Databases (VLDB94), pages 606–617.
CoopIS-95 (1995). Proceedings of the 3rd International Conference on Cooperative
Information Systems CoopIS-95.
CoopIS-96 (1996). Proceedings of the First IFCIS International Conference on Cooperative Information Systems (CoopIS-96).
CoopIS-97 (1997). Proceedings of the Second IFCIS International Conference on
Cooperative Information Systems (CoopIS-97).
Dayal, U. (1995). Ten Years of Activity in Active Database Systems: What Have
We Accomplished? In Proceedings of the 1st International Workshop on Active
and Real-Time Database Systems (ARTDB-95), Workshops in Computing, pages
3–22. Springer-Verlag.
Diaz, O. (1998). Tool Support. In Paton, N., editor, Active Rules for Databases.
BIBLIOGRAPHY
135
Diaz, O., Paton, N., and Gray, P. (1991). Rule Management in Object Oriented
Databases: A Uniform Approach. In Proceedings of the 17th International Conference on Very Large Data Bases, pages 317–326.
Engström, H., Berndtsson, M., and Lings, B. (1997). ACOOD Essentials. Technical
Report HS-IDA-TR-97-010, University of Skövde.
Finin, T., Fritzson, R., McKay, D., and McEntire, R. (1994). Kqml - an information
and knowledge exchange protocol. In Fuchi, K. and Yokoi, T., editors, Knowledge
Building and Knowledge Sharing. Ohmsha and IOS Press.
Gatziu, S. (1994). Events in an Active Object-Oriented Database System. PhD thesis,
University of Zurich.
Gatziu, S. and Dittrich, K. (1993). Events in an Active Object Oriented Database
system. In Proceedings of the 1st Workshop of Rules in Database Systems, pages
23–29.
Gehani, N., Jagadish, H. V., and Smueli, O. (1992). Event specification in an active
object-oriented database. In Proc. of the ACM SIGMOD International Conference on Management of Data, pages 81–90.
Genesereth, M. and Fikes, R. (1992). Knowledge Interchange Format. Version 3.0,
Reference Manual Technical Report Logic-92-1, Computer Science Department,
Stanford University.
Geppert, A. and Berndtsson, M., editors (1997). Proceedings of the 3rd International Workshop on Rules in Database Systems, number 1312 in Lecture Notes
in Computer Science. Springer-Verlag.
BIBLIOGRAPHY
136
Geppert, A., Berndtsson, M., Lieuwen, D., and Roncancio, C. (1998). Performance
Evaluation of Object-Oriented Active Database Management Systems Using the
BEAST Benchmark. Journal of Theory and Practice of Object Systems. to
appear.
Geppert, A., Kradolfer, M., and Tombros, D. (1995). Realization of Cooperative
Agents Using an Active Object-Oriented Database Management System. In (Sellis, 1995), pages 327–341.
Hagen, I. (1996). Active Rules in Cooperative Problem Solving. Master’s thesis,
University of Skövde.
Hall, L. (1996). User Design Issues for Distributed Artificial Intelligence. In O’Hare,
G. and Jennings, N., editors, Foundations of Distributed Artificial Intelligence,
chapter 21, pages 543–556. Wiley-Interscience.
Hartley, J. R., editor (1992). Concurrent Engineering: Shortening Lead Times, Raising Quality, and Lowering Costs. Productivity Press.
Hewitt, C. E. and Lieberman, H. (1984). Design issues in parallel architectures for
artificial intelligence. In IEEE Computer Society, pages 418–423.
Huang, J., Jennings, N. R., and Fox, J. (1994). Cooperation in Distributed Medical Care. In Proceedings of the 2nd International Conference on Cooperative
Information Systems CoopIS-94, pages 255–263.
Huhns, M. (1994). A DAI Perspective on Cooperating Knowledge-Based Systems. In
Deen, S., editor, Proceedings of the Second International Working Conference on
Cooperating Knowledge Based Systems (CKBS’94), pages 3–12.
BIBLIOGRAPHY
137
IJCIS (1996). Aims and Scope. Number 4. International Journal of Cooperative
Information Systems.
Jennings, N. (1994a). The ARCHON System and its Applications. In Deen, S., editor, Proceedings of the Second International Working Conference on Cooperating
Knowledge Based Systems (CKBS’94), pages 13–30.
Jennings, N., Mamdani, E., Laresgoiti, I., Perez, J., and Corera, J. (1992). Grate: A
general framework for cooperative problem solving. IEE-BCS Journal of Intelligent Systems Engineering, 1(2):102–114.
Jennings, N. R. (1993). Commitments and Conventions: The foundation of coordination in multi-agent systems. The Knowledge Engineering Review, 8(3):223–250.
Jennings, N. R. (1994b). Cooperation in Industrial Multi-Agent Systems. World
Scientific.
Jennings, N. R. and Pople, J. A. (1993). Design and Implementation of ARCHON’s
Coordination Module. In Proceedings of the CKBS-SIG Workshop on Cooperating Knowledge Based Systems, pages 61–82.
Kandzia, P. and Klusch, M., editors (1997). Proceedings of the First International
Workshop on Cooperative Information Agents (CIA-97), number 1202 in Lecture
Notes in Artificial Intelligence. Springer.
Karlapalem, K., Yeung, H., and Hung, P. (1995). CapBasED-AMS - A Framework
for Capability-Based and Event-Driven Activity Management System. In Proceedings of Third International Conference on Cooperative Information Systems
(CoopIS-95).
BIBLIOGRAPHY
138
Kuokka, D. and Harada, L. (1996). Issues and extensions for information matchmaking protocols. International Journal of Cooperative Information Systems,
5(2–3):251–274.
Kuokka, D. R., Weber, J. C., and et al. (1993). Shade: Knowledge-Based Technology
for the Re-Engineering problem. Technical report, Lockhead Palo Alto Research
Laboratories. Annual Report.
Labrou, Y. and Finin, T. (1994). A semantics approach for kqml – a general purpose
communication language for software agents. In Proceedings of the Third International Conference on Information and Knowledge Management (CIKM’94).
Lieuwen, D., Gehani, N., and Arlein, R. (1996). The Ode Active Database: Trigger
Semantics and Implementation. In Twelfth International Conference on Data
Engineering, pages 412–420.
Lockemann, P. and Walter, H. (1995). Object-oriented protocol hierarchies for distributed workflow systems. Journal of Theory and Practice of Object Systems,
1(4):281–300.
Malone, T. W. and Crowston, K. (1994). The Interdisciplinary Study of Coordination.
ACM Computing Surveys, , 26(1):87–119.
Moulin, B. and Chaib-Draa, B. (1996). An Overview of Distributed Artificial Intelligence. In O’Hare, G. and Jennings, N., editors, Foundations of Distributed
Artificial Intelligence, chapter 1, pages 3–55. Wiley-Interscience.
Muller, H. (1996). Negotiation Principles. In O’Hare, G. and Jennings, N., editors, Foundations of Distributed Artificial Intelligence, chapter 7, pages 211–229.
Wiley-Interscience.
BIBLIOGRAPHY
139
Mylopoulos, J. and Papazoglou, M. (1997). Cooperative Information Systems. IEEE
Expert, 12(5):28–31.
Object Management Group (1995). The Common Object Request Broker: Architecture and Specification. Technical Report PTC/96-03-04, OMG.
O’Hare, G. and Jennings, N., editors (1996). Foundations of Distributed Artificial
Intelligence. Wiley-Interscience.
Parunak, H. (1996). Applications of Distributed Artificial Intelligence in Industry.
In O’Hare, G. and Jennings, N., editors, Foundations of Distributed Artificial
Intelligence, chapter 4, pages 139–164. Wiley-Interscience.
Paton, N., editor (1998). Active Rules in Database Systems. Springer. To appear.
Paton, N., Dinn, A., and Williams, M. (1998). Optimization. In Paton, N., editor,
Active Rules for Databases.
Paton, N. and Williams, M., editors (1993). Proceedings of the 1st International
Workshop on Rules in Database Systems, Workshops in Computing. SpringerVerlag.
Pissinou, N., Snodgrass, R., Elmasri, R., Mumick, I., Özsu, M., Pernici, B., Segev, A.,
Theodoulidis, B., and Dayal, U. (1994). Towards an Infrastructure for Temporal
Databases: Report of an Invitational ARPA / NSF Workshop. ACM Sigmod
Record, 23(1):35–51.
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., and Lorensen, W. (1991).
Object-Oriented Modelling and Design. Prentice Hall.
BIBLIOGRAPHY
140
Schreier, U. (1993). Database Requirements of Knowledge-based Production Scheduling and Control: A CIM Perspective. In Proceedings of the 19th VLDB Conference, pages 710–711.
Schwinger, W. (1995). Logical events in eca rules. Master’s thesis, University of
Skövde.
Sellis, T., editor (1995). Proceedings of the 2nd International Workshop on Rules in
Database Systems, number 985 in Lecture Notes in Computer Science. SpringerVerlag.
Smith, R. (1980). The Contract Net Protocol: High Level Communication and Control in a Distributed Problem Solver. IEEE Transactions on Systems, Man, and
Cybernetics, SMC-10(12).
Smith, R. G. and Davis, R. (1981). Frameworks for Cooperation in Distributed
Problem Solving. IEEE Transactions on Systems, Man, and Cybernetics.
Türker, C. and Conrad, S. (1996). Using Active Mechanisms for Global Integrity
Maintenance in Federated Database Systems.
In Conrad, S., Höding, M.,
Janssen, S., and Saake, G., editors, Kurzfassungen des Workshops “Föderierte
Datenbanken”, Magdeburg, 22.04–23.04.96, pages 51–65. Bericht 96–01, Institut
für Technische Informationssysteme, Universität Magdeburg.
Vollmann, T., Berry, W., and Whybark, D. (1992). Manufacturing Planning and
Control Systems. Business One Irwin.
Widom, J. and Ceri, S., editors (1995). Active Database Systems: Triggers and Rules
for Advanced Database Processing. Morgan Kufmann Publisher.
BIBLIOGRAPHY
141
Widom, J. and Chakravarthy, S., editors (1994). Proceedings of the Fourth International Workshop on Research Issues in Data Engineering: Active Database
Systems. IEEE-CS.