NORMALIZED INTERACTIONS BETWEEN AUTONOMOUS AGENTS: A CASE STUDY IN INTER-ORGANIZATIONAL PROJECT MANAGEMENT Jeremy Pitt1
Matthew Anderton2
Jim Cunningham
Department of Computing, Imperial College of Science, Technology, and Medicine, 180, Queen’s Gate, London, SW7 2BZ, UK. Email: fjvp,mta,
[email protected] Phone: +44-171-594-8185. Fax: +44-171-581-8024. http://medlar.doc.ic.ac.uk/ Abstract The CEC Project GOAL (Esprit 6283) aims to develop generic software tools to support a new project management paradigm, in which projects are collaborative, decentralised and inter-organizational. To support inter-organizational interaction, communication and cooperation, we are developing a design framework for formalizing the flow of information between organizations, specifying access to and provision of project services, and defining project-wide standards and procedures. This framework is based on normalizing interactions between autonomous software agents by specifying messages and protocols for inter-agent communication and cooperation. This paper reviews the framework, and then focusses on the specification and implementation of a case study, the automation of a distributed document review procedure. This is both a successful proof of concept and a demonstration of how Artificial Intelligence technologies can support inter-organizational project management. It also points the way to ‘agent brokering’, an enhancement of object brokering in distributed open systems, where satisfying service requests can be subject to negotiation. R´esum´e Le projet GOAL (Esprit 6283) de la CEE vise a´ d´evelopper des outils logiciels g´en´eriques sur la base d’un nouveau paradigme pour la gestion de projets. Dans ce paradigme, les projets sont collaboratifs, d´ecentralis´es et inter-organisationnels. Pour assurer l’aspect interorganisationnel des communications et de la coop´eration, nous avons d´evelopp´e un cadre de conception en vue de formaliser le flux d’informations entre des organisations, de sp´ecifier l’acc´es et la fourniture de services entrant dans le cadre d’un projet, et de d´efinir des normes et des proc´edures pour de tels projets. Il repose sur la normalisation des interactions entre des logiciels autonomes (des agents) par la sp´ecification des messages et des protocoles pour la communication et la coop´eration entre agents. Ce papier pr´esente le cadre de conception, puis se consacre sur les sp´ecifications et l’implantation d’une e´ tude de cas, ainsi que sur l’automatisation d’une proc´edure de surveillance de documents distribu´es. Ce travail prouve l’int´erˆet du concept et d´emontre les possibilit´es des techniques de l’Intelligence Artificielle pour la gestion de projets inter-organisationnels. Il d´emontre aussi l’int´erˆet d’un gestionnaire d’agents, une am´elioration des gestionnaires d’objets dans les syst`emes distribu´es ouverts, o`u la satisfaction de requˆetes de services peut eˆ tre le sujet de n´egociations. Keywords: Intelligent Agents, Cooperative Systems, Project Management. 1 2
Supported by CEC Esprit Project GOAL (Esprit 6283) and CEC Esprit BRA Medlar II (Esprit 6471). Supported by CEC Esprit Project GOAL (Esprit 6283).
1
1
Introduction
The CEC GOAL Project (Esprit 6283) aims to develop generic software tools to support a new project management paradigm: “the extended enterprise”. Some distinguishing characteristics of projects in the new paradigm are that they are collaborative, decentralised and interorganizational. This means that general issues in project management (such as risk and uncertainty) take on an extra dimension, and there are many new problems to be addressed, such as information access, dissemination, and security, the coordination of independent partners, and communication between partners at remote sites. We are particularly concerned with the inter-organizational aspects of communication and interaction which enable participating organizations to complete shared tasks and to achieve shared goals – i.e. computer-supported cooperative work (CSCW) for inter-organizational projects. The GOAL Cooperation Services Framework (henceforth CSF) is proposed to enable the specification of project-wide standards for normalized interactions between autonomous software agents acting in a federated information system, so providing mechanisms to: i normalize inter-organizational terminology and the flow of messages and information between organizations; ii structure inter-organizational interactions with respect to contractual relationships and local working practices; iii enable each organization to provide/use project services required/offered by other organizations. The CSF could therefore be used to enhance the object brokering capabilities of open distributed systems, by providing a framework for agent (rather than object) interaction, i.e. agent brokering, where requests can be negotiated, delegated, distributed etc. Sections 2 and 3 of this paper review the background and the technical elements of the CSF, while sections 4 and 5 focus respectively on the specification and implementation of a case study, in which the framework is used to automate a distributed document review procedure. This, we believe, is both a successful proof of concept and a demonstration of how Artificial Intelligence technologies – like distributed AI, automated reasoning and multi-agent programming – can be used to support management procedures in inter-organizational projects.
2
Background
2.1 The GOAL Project Each organization in an extended enterprise supported by the GOAL method operates a GOAL system which facilitates its participation in the project. This system incorporates a data repository, common interface and CSCW services. The data repository, called the Information Model, contains a description of the people in the organization participating in the project and the jobs they do, the project tasks, activities and their timescale, and the relationships which bind these things together in the real project. The common interface enables users to access other software 2
tools (e.g. word processors, spreadsheets, etc.) and to transfer information between such tools and the data repository. The service provider offers computer-supported cooperative work via the GOAL Workflow tool, and communication with other GOAL systems via X400 email. The Advanced Research stream of the GOAL project is investigating (inter alia) the application of Artificial Intelligence technologies to extend the service provider via the Cooperation Services Framework. The aim of the CSF is to support advanced CSCW services, i.e. agreed working practices for performing shared project tasks and accessing distributed project information, whilst respecting the local working practices and various security policies of individual organizations. Autonomous software agents operating in this framework enable project management procedures for inter-organizational projects to be normalized and executed.
2.2 Cooperation Protocols The mechanisms by which project management procedures are executed in the CSF is by autonomous agents following cooperation protocols [Burmeister et al., 1993]. The following ‘glossary’ defines our terms of reference in the Cooperation Services Framework: Agent: An agent is a GOAL system application which enables two or more users and/or other GOAL applications to participate in inter- and intra-organizational tasks and activities. Users and applications communicate their intentions and requirements to other users and applications via agents which act as their intermediaries. Agents can understand both etiquette and savoir faire, where etiquette is the specification of the communicative behaviour expected between two agents, and savoir faire includes decision-making and interaction with a user (should it be necessary); Message: Agents communicate by message passing. A message is therefore the basic unit of interaction between two co-operation servers. Message specifications determine for each type of message the space of possible responses. Message passing is specified as an action (i.e. a “speech act”), which we refer to as a message action to distinguish between message passing and other actions that an agent can perform; Protocol: A protocol is the formal definition of a structured exchange of messages which constitute an agreed procedure for performing some inter- organizational task or activity. Literally, a protocol is the formal etiquette and code of behaviour for conducting some procedure. Therefore message specifications provide the ‘etiquette’, and protocol specifications provide the ‘code of behaviour’. Protocols are application and domain independent: they need to be reified for particular applications and domains to give a specification of an agent’s savoir faire; Conversation: A conversation is a protocol in execution, and consists of a sequence of messages which comply with the protocol definition. The current state and history of a conversation is maintained independently by all participating cooperation servers. Cooperation Services: The Cooperation Services exported by a GOAL agent are the set of protocols that it ‘understands’. For the current application, inter-organizational project management, the value of our agents is the services they provide for users, for example, in making local working practices transpar3
ent, in helping to cope with information overload, and in smoothing the execution of distributed management procedures. We describe these agents as autonomous, although we anticipate that while they execute independently, their decision-making is configured by users and user interaction may be required. ‘Fully’ autonomous agents is a subject for further research.
3
The Cooperation Services Framework
We propose a two-tiered approach to the design and specification of cooperation services: a ‘higher’ level for specifying agent interactions via protocols and message passing, and a ‘lower’ level for specifying internal processes which determine how an agent behaves in a protocol. The specification of a protocol at the higher level is agent, application and domain independent, and protocols are then configured at the lower level for particular applications and domains, by specifying the agents’ decision-making processes and message parameters. These two levels of specification are reviewed in the next two sub-sections. Our motivation for this approach is the view that (agent) programming can be regarded as successive transformations from global specifications to more refined and detailed specifications, which are then transformed into programs for the individual agents in an appropriate programming language, as demonstrated in the case study. The programming language we have used for the prototype implementation is IC-Prolog II [Chu and Clark, 1993], and our reasons for this choice are outlined in section 3.3.
3.1 High Level Specification: Deontic Logic At this level of specification, we are exploring the possibilities offered by Deontic Logic [Meyer and Wieringa, 1993]. Deontic Logic is the branch of modal logic which has been developed to reason about behaviour by means of such modal operators as ought, permitted, and forbidden. Deontic Logic has been applied in computer science for specification of fault-tolerant and safetycritical systems, organizational behaviour, and secure databases. A Deontic Action Logic [Maibaum, 1993] has a standard logical syntax and can be given a semantics by a reduction to dynamic logic. It has two sorts of modal operators: • deontic modalities O (ought to) and P (permitted to), and • parameterized agent-action modalities, where if A is an agent and a is an action, then [A, a] is a modality. The agent action modalities can be used for system specification by stating axioms of the general form: PreCondition → [A, a]PostCondition whose intuitive meaning is that if the PreCondition holds in the current state, then after agent A performs action a the PostCondition should hold in the resultant state. Deontic operators are used in the pre- and post-conditions to specify the conditions under which an action is permitted to occur and any resultant obligations on other agents; e.g. the axiom: 4
P (a,boss(b)) → [a, demand(b,tea)] O(b, make(tea)) states that if a is permitted to boss b about, then after a demands tea from b, b ought to make some. In the CSF, Deontic Action logic is used for specifying messages and protocols (examples are given in section 4.2). Message passing between agents in our framework is, like in many others, based on speech act theory, and, since a speech act is formalised as an action modality in the logic, much akin to the language/action perspective of [Winograd, 1988]. Using a set of message specifications as the basic building blocks, we then specify protocols in the logic. This is done by defining action schemas, which give an initiating action and extra constraints that the participants in the protocol should observe. The course of a conversation following the protocol is determined by the range of message actions defined as a response to the initiating and subsequent messages. The formal semantics underlying the logical specifications can be used for: • automatically generating a standard ‘network-style’ specification from the message and protocol specifications, which can be extended and emended by interactive editors (cf. [Kaplan et al., 1991]); • animating specifications for validation purposes, e.g. evaluation of the dynamic behaviour specified by the protocols (see [Costa et al., 1990]); • expressing and reasoning with aspects of time and causality, authority and security, and non-normative behaviour (i.e. what happens when something goes wrong, and what to do about it). These issues are being actively researched, but are not in the scope of the present work.
3.2 Low Level Specification: de Greef Specification To reify protocols for particular applications and domains, we are experimenting with the language proposed by [de Greef et al., 1993] (here referred to as “de Greef specifications”). Although we call this a “low” level specification, this is only “lower” relative to deontic logic specifications: de Greef specifications are still “high” level. The language proposed by de Greef at al. can be used to specify protocols which include conversations between two or more agents, to blur the distinction between ‘client’ and ‘server’ agents, and to be more specific about what data is being passed between agents, and when. The language inherits (most) features of a logic programming language, and also provides for the notion of an agent, communication mechanisms, and sets. The exchange of a message is written: sender_agent: message(arg1 , …, argn ) → receiver_agent Similarly, messages are sent to a set of agents thus: sender_agent: message(arg1 , …, argn ) → Receivers and received from a set of agents by writing: 5
Msgs = f(r, arg1 , …, argn ) | r: message(arg1 , …, argn ) → sender within timeoutg The value of timeout is measured on sender_agent’s clock, and ensures the instruction will terminate because there is no guarantee that all receiving agents will respond. Message passing can be included in “plan schemas” which assign sub-tasks to agents or agent variables. For example, a plan schema to calculate a percentage might be: agent: percentage_of( part, whole, percentage ) = agent_database( divide, Agent1 ), agent: request( divide, part, whole ) → Agent1, Agent1: inform( divide, fraction ) → agent, agent_database( multiply, Agent2 ), agent: request( multiply, fraction, 100 ) → Agent2, Agent2: inform( multiply, percentage ) → agent. Assuming agent has no mathematical skills, it looks in an agent database for an agent offering the appropriate service, and sends a request to that agent asking it to perform the operation on the accompanying data. Having done so, that agent returns the result. This is done for both the divide and multiply to calculate the percentage of the original input. The main drawback of this specification language is that it does not have a semantics, although de Greef et al. believe “a formal semantics can be defined”. We have persisted with this language because we have found it useful in writing ‘formal’, precise specifications whose intended meaning, at least, is intuitively clear.
3.3 Agent Programming in IC-Prolog II IC-Prolog II [Chu and Clark, 1993] is an implementation of Prolog that was designed to address distributed applications, such as automated support for inter-organizational project management. IC-Prolog II is well-suited to multi-agent programming [Chu, 1992] and was chosen as a demonstrator platform for the CSF because of the following features: • multiple threads: each thread is a distinct Prolog process and each currently runnable thread is allocated a timeslice during which it executes. Independent programs and goals can be explicitly forked and run concurrently in pseudo-parallel; • high-level communication primitives: IC-Prolog II provides a form of connection-oriented communication by mailbox primitives, which allow threads to communicate by sending and receiving messages sent to/removed from mailboxes. • an object oriented extension: IC-Prolog II supports objects, plus the usual notions such as inheritance, self/super and message passing, which is a convenient way to structure agents [Chu, 1992]. The execution of an IC-Prolog II program will typically give rise to a set of explicitly forked sequential processes, which run concurrently. If a mailbox server is running, then a set of programs can communicate (asynchronously) by registering with the server. This allows programs (and their forked processes) which are executing concurrently and on separate workstations to 6
cooperate over a network. This describes the behaviour of our agents and the environment in which they are expected to operate.
4
Distributed Document Review: Specification
4.1 Informal Specification The situation we will consider is quality control in a stereotypical Esprit Basic Research Action, where the deliverables are largely technical papers. Suppose the project office aims to ensure quality by having each deliverable reviewed by (say) three referees, some of whom may be internal and some may have been nominated by the Commission. Partners in the project submit their deliverables to the project office, complete with document identifiers (authors(s), title, etc.), an abstract and a set of keywords. The project office then broadcasts to the network of referees that it has a review job to do with a proposed resource allocation of (say) five days, and invites bids to undertake the work. If enough reviewers respond favourably, then three of them are chosen and are appointed. If insufficient reviewers accept the initial terms, then the project office selects what it considers to be a set of appropriate referees (based on the referee’s areas of expertise and the deliverable’s keywords), and engages in one-on-one negotiation with each in an attempt to get a commitment to review the deliverable. This continues until either enough reviewers have been found or the set of potential reviewers has been exhausted. In the latter case an alert is raised. Our intention is for a GOAL system to handle the selection, communication and (if the referees chose) the commitments automatically. To do this, the project office, hereafter referred to as the Chair, and each referee, hereafter referred to as Reviewers, run a software agent which enables them to participate in this distributed document review procedure. The core of the agent can be supplied by the project office, but in addition each referee can extend his/her agent by also specifying the conditions under which he/she will agree to review a deliverable. This is illustrated in more detail in section 5. First, though, we specify the interactions and the protocols.
4.2 Deontic Specifications Message Specifications The three most basic message specifications (implicitly universally quantified) are inform, query, and command, as illustrated in figure 1. Note the modality specifying the speech act is parameterized with an agent (i.e. the “utterer” of the “speech act”) and an action (the “speech act” itself). The action also has parameters: these include the recipient of the message, an action for the recipient to perform, and some additional resources ∆, which need not be specified further at this level of specification. In some cases, receipt of a message will require (oblige, as indicated by the modality O) a response from the receiving agent, which is itself another message action, i.e. to send another message. Some further points to note about these three message specifications are:
7
[s, inform(r, I)] Kr (I)
[s, query(r, Q)] O(r, inform(s, no) + inform(s, yes))
[s, command(r, A, ∆)] O(r,A) ∧ [r,A]O(r, inform(s, done(A))) Figure 1: Agent-Action Modalities for Basic Message Specifications • the result of an inform message is that the recipient r now “knows” the information content (I) of the message. This is represented by the parameterized modality Kr (I); • a query has been represented here as a so-called yes-no question, i.e. one demanding either a ‘yes’ or ‘no’ answer. Queries can, of course, be far more complex than this, and the answers much more so (cf. [Pitt et al., 1994]); • the reading of the command message is that after s commands r to do A with resources ∆, then r ought to do A (here ought to is represented by the modality O), and after r does A it ought to inform s of the fact; • + is the choice action combinator (cf. [Maibaum, 1993]) which defines the range of possible responses to a message action; the responding agent must choose to do one; Figure 2 defines further message specifications required for the case study. These messages particularly relate to performing tasks or getting other agents to perform tasks. Notice that here we have specified a request to do A as being non-negotiable: a negotiable request is a propose, which allows the receiving agent to make a counter-offer using the offer message. Once a contractual relationship has been established (when the receiver accepts what is proposed), the sending agent is then permitted, here represented by the modality P , to command the receiving agent to perform the action. This permission is revoked either by the sender informing the receiver that is has finished the job, or explicitly by the sender itself sending a cancellation. [s, propose(r, A, ∆)] O(r, inform(s, reject) + accept(s, A, ∆) + offer(s, A′, ∆′))
[s, offer(r, A, ∆)] O(r, inform(s, reject) + propose(s, A′, ∆′)) [s, request(r, A, ∆)] O(r, inform(s, reject) + accept(s, A, ∆))
[s, propose(r, A, ∆)] [r, accept(s, A, ∆)] P (s, command(r, A, ∆)) [s, inform(r, done(A))] ¬P (r, command(s, A, ∆))
[s, cancel(r, A)] ¬P (s, command(r, A, ∆))
Figure 2: Agent-Action Modalities for Contracting Work Restricting the use of the command message with the P modality is adequate for the case study, but is not sufficient for a general characterization of inter-agent authority. We hope to 8
address this issue by exploiting the research of [Jones and Sergot, 1994]. Protocol Specifications We are now in a position to specify the protocols required for the distributed document review. These are the initial invitation to tender, which is a one-to-many interaction (i.e. a version of the well-known contract-net protocol), and an iterated one-to-one negotiation for undertaking a fixed task. These are described by the following two logical action schema announce and negotiate: announce:
4
(s, announce(R, A, ∆)) =
^ (s, request(r, A, ∆))
r∈R
negotiate:
4
(s, negotiate(r, A, ∆)) = (s, propose(r, A, ∆)) ∧ [s, propose(r, A, ∆)][r, offer(r, A′, ∆′)]A = A′ Note that the objective of the negotiate protocol is to agree on performing a fixed task with negotiable resources, hence after an iteration of propose and offer, the task A must be unchanged, but the resources ∆ may be varied.
4.3 Network Specification The space of possible messages and responses according to these protocols can be automatically generated from the logical specification, and are shown in the finite state diagrams illustrated in figure 3. In these diagrams, the ‘legend’ is: grey/white circles are states of the conversation, with, respectively, the client or server to perform the next action; solid black circles are (unsuccessful) end states, empty white circles are (successful) end states; solid arrows are or-obliged actions in that state, dotted arrows are or-permitted actions; solid arrows joined by a labelled arc are N-way and-obliged actions. The ‘message space’ of the actual protocol is delimited by the dotted box. The designer of a protocol for a particular application can specify the necessary additional behaviour as required. In the case of the distributed document review procedure, what is required is that having successfully secured an agreement to review a paper, the chair tells the reviewer to proceed (command) or not to bother (cancel). These extensions are shown here.
4.4 de Greef Specification The deontic specification of the protocols specifies the possible agent behaviour through the message passing between agents i.e. the etiquette. There is content to the messages but at this level of abstraction we need not be precise about what it is. Thus the message specifications provide application- and domain-independent aspects of multi-agent communication. In order to specify an agent’s requisite savior faire for a particular application or domain, we need to 9
inform(done) 4.1 command 3.1 accept
cancel inform(done)
2.1 request 1
4.N
reject
command 3.N
N accept
cancel
request 2.N
reject
reject
reject
offer propose 1
3
2
inform(done)
propose command
5
accept 4
cancel
Figure 3: Finite State Diagram for Announce and Negotiate Protocols reify the protocol specifications by specifying how agents make their choices of the next actions to perform (i.e. which message to send), and what is the precise content of the message. In our case study, the project office can achieve its goals by the following ‘algorithm’: when a new deliverable is submitted, announce to all reviewers to see which will accept the task; if the number of acceptors is greater than 2, then select 3, tell them to review the deliverable and reject the others; if it less than 3, select some appropriate reviewers and negotiate with each; if as a result of successful negotiations 3 reviewers can be appointed, select enough to go with the original positive responders and proceed as before, otherwise alert the (human) project manager. Using the specification language of de Greef et al [de Greef et al., 1993], this ‘algorithm’ is specified in figure 4. Note how the two cooperation protocols are used inside the overall specification. This specification only states what the agents should do, not how it should be done. This is coded by the programs for the individual agents, as described in the next section. 10
Distributed Review chair, Reviewers : distributed_review( paper, time, timeout, Appointees ) (1) chair, Reviewers : announce( review( paper ), time, timeout, Acceptors ) (2) ( | Acceptors | ≥ 3, (3) select_3( Acceptors, Appointees, Rejectees ), (4) chair : command( review( paper ), time ) → Appointees, (5) chair : cancel( review( paper ), time ) → Rejectees (6) | | Acceptors | ≤ 2, (7) select_appropriate( Reviewers, Acceptors, PossRevs ), (8) MoreAccept = f (r,atime) | r ∈ PossRevs, chair, r : negotiate( paper, time, atime), atime ≠⊥ g, (9) ( | MoreAccept | + | Acceptors | ≥ 3, (10) select_enough( MoreAccept, | Acceptors |, Accepted, Rejectees ), (11) Appointees = Acceptors ∪ Accepted, (12) chair : command( review( paper ), time ) → Appointees, (13) chair : cancel( review( paper ), time ) → Rejectees (14) | | MoreAccept | + | Acceptors | ≤ 2, (15) alert ) ). Announce chair, Reviewers : announce( review( paper ), time, timeout, Acceptors ) = (1) chair : request( review( paper ), time ) → Reviewers, (2) Acceptors = f(r,time) | r : accept( review( paper ), time ) → chair within timeout, r ∈ Reviewers g. Negotiate chair, reviewer : negotiate( paper, time, agreetime ) = (1) chair : propose( review( paper ), time ) → reviewer, (2) chair, reviewer : do_negotiate( review, paper, time, agreetime ). chair, reviewer : do_negotiate( review, paper, time, agreetime ) = (1) ( reviewer : accept( review( paper ), time ) → chair, agreetime = time, (2) | reviewer : inform( reject ) → chair, agreetime = ⊥, (3) | reviewer : offer( review( paper ), rtime ) → chair, (4) ( chair : accept( review( paper ), rtime ), agreetime = rtime, (5) | chair : inform( reject ) → reviewer, agreetime = ⊥, (6) | chair : propose( review( paper ), ctime ) → reviewer, (7) chair, reviewer : do_negotiate( review, paper, ctime, agreetime ) ) ).
Figure 4: Agent Specification for Distributed Review Procedure
5
Distributed Document Review: Implementation
In our case study we implemented a distributed review procedure as a multi-agent system based on the message specifications and protocols defined in section 4. The system comprised a single client agent, the Chair, and multiple server agents, the Reviewers. The agents were built from
11
program modules which corresponded to elements in the CSF (announcement, negotiation, conversation, message specification) and the application domain (review task, agent knowledge and organization knowledge). We first present the requirements for our study and then discuss the implementation. The role of the CSF is to facilitate negotiation between client and server agents over the terms under which a service will be provided to a client. As such it can be seen as an extension to existing frameworks for inter-object communication to provide the additional support required for inter-agent negotiation.
5.1 Agent Requirements To demonstrate the Framework we require clients (service consumers), servers (service producers), a message passing infrastructure, a method of structuring negotiation and managing conversations, and a shared understanding between clients and servers of specific tasks within an application domain. We can identify further requirements for each element and so elucidate the implementation. Client Agents require the ability to: (1) locate appropriate servers to perform a given task. For our case study the Chair organization is given the names of potential reviewers. Typical open systems make use of a common service repository maintained by an object broker: servers register their interfaces with the broker and clients forward requests to the broker to be matched against known service providers. (2) send messages and wait for corresponding replies. The negotiation process is driven by the client. When a client expects a response it creates a mailbox (using the facilities of IC Prolog II) and the unique mailbox Id is forwarded to the server with the initial message. (3) check the validity of incoming messages with respect to the message specification. The client needs to know both the message specification and the history of messages in the conversation. Valid messages must be recorded in the conversation history. (4) generate service proposals based on external triggers. Agents monitor and respond to changes in their environment. For our study it is enough that client agents react to external triggers by generating service requests, and that servers respond to incoming messages. The agent architecture may be extended to allow for persistent goals, planning and scheduling, (see [Steiner et al., 1993]). (5) formulate an initial service request or proposal. Domain knowledge is required to identify the service name and parameters needed to instantiate the call; the circumstances of the individual agent and its organization will influence the initial terms. (6) evaluate incoming service proposals by applying domain knowledge in the context of organizational knowledge, the current state of the client and the history of the negotiation to date. In addition the client must formulate appropriate responses. The decision-making intelligence of the agent is embodied in these evaluation rules. The rules are not themselves a part of the cooperation service framework which does not attempt to standardize decision making, only to structure the negotiation process within which decisions must be made. Server Agents require a smaller set of similar basic capabilities; namely to: 1. communicate responses to clients (cf. client (2) above); 12
2. validate and record messages (cf. client (3) above); 3. evaluate service proposals (cf. client (6) above). 4. perform services in response to authorised commands. If a server provides tasks by service decomposition and delegation to other agents (cf. [Chu, 1992]) then it combines the functionality of both client and server in a single agent. This case is a simple extension of the agents used in our study. Structuring Negotiation. An agreed message specification such as that proposed in section 4.1 is required. Certain message types are generated by clients, some by servers and some by both types of agents: clients propose, request and command, servers offer and accept, all can inform. For simplicity, our implementation combines the implementation of the whole specification into a generic module which is shared by all agents in the application. Managing Conversations. Each agent manages an independent record of its conversations, hence each requires certain conversation management facilities: new conversations need to be created and closed as necessary; incoming and outgoing messages need to be allocated to conversations. Maintaining conversation histories enables an agent to validate incoming messages with respect to the message specification, make an informed analysis of service proposals, requests and offers, and provide organizations with a record of agent activities. Service Description. A shared understanding of services requires a standard service representation which includes: the service name, a list of input parameters required to instantiate the call and an additional list of terms of execution which may be the subject of negotiation. For the case study we chose: servicename( [ parameter1, ..., parameterN ], [ term1, ..., termN ] ) Such service descriptions form the content of cooperation service messages ( requests, offers, proposals, acceptances, rejections ). For our example we have a single review task with two parameters and a single term over which negotiation is possible: review( [ DocumentId, KeyWordList ], [ TimeAllotted ] ) Open systems typically use a standard interface definition language.
5.2 Agent Implementation Agents are built from a number of reusable components. All agents share the following basic modules: Communicator, Message Specification, Conversation, Negotiation, Domain Knowledge. A Chair (client) agent has in addition: Distributed Review, Announcement, Sequential Negotiation, Specific Chair Knowledge, and Specific Organization Knowledge. A Reviewer (server) agent has in addition to the basic components: Specific Reviewer Knowledge, and Specific Organization Knowledge. Figure 5 shows the architecture of the Chair and Reviewer agents in the distributed review example. Distributed Review implements the top level procedure by which the Chair secures the peer review of a document as described in section 4.4. The submission of a new paper triggers the forking a new process by which the requisite number of reviewers are commissioned to perform 13
Distributed Review
Client Agent: Chair One Review Domain Knowledge Sequential Negotiation Organisation Alpha Knowledge
Announcement
Negotiation Chair One Knowledge
Chair One Conversation History
Conversation
Message Specification Communicator
Legend Message Specification
Generic Module
Communicator Reviewer One Conversation History
Reviewer One Knowledge
Client or Server Specific Module
Conversation
Application Specific Module
Agent Specific Module
Organisation Beta Knowledge Negotiation
Organisation Specific Module
Review Domain Knowledge
Server Agent: Reviewer One
Figure 5: Agent Architecture for the Distributed Review Case Study 14
the review task. The Chair announces an initial service request If insufficient reviewers accept the task request, the Chair proceeds to negotiate with individual Reviewers. Announcement multicasts an initial review request from a client to a list of servers and collates and sorts the responses received within the time-out limit of the announcement. In our example the Chair retrieves the list of potential servers (reviewers) and the initial terms of the review task from its knowledge base. This implementation of the announcement protocol opens a new conversation with each member of the list. There are many possible variations, for example announcement may be used to issue a final service request to multiple servers at the end of a parallel negotiation process, in which case new conversations would not need to be created. Sequential Negotiation manages a sequence of negotiations between the client and possible servers; ending when either sufficient servers have been found, or there are no further potential servers with which to negotiate. Again there are many possible variations on the management of multiple negotiations and these correspond closely to standard search strategies, breadth first, iterative deepening, etc. Complex negotiation strategies may involve interaction between parallel streams of negotiation, though it is questionable to what extent it is useful to attempt software agents that mimic human ingenuity. Negotiation supplies the negotiation protocol as specified in section 4.3 and 4.4; i.e. it directs a cycle of proposal and offer messages between a client and a server until a negotiation reaches its conclusion. There are two sides to the negotiation procedure, one for the client and one for the server. The client proposes, requests or rejects; the server offers, rejects or accepts. Each agent evaluates messages from the other and acts on its evaluation. This is the core mechanism which enables the negotiation process. Evaluation routines are defined in the knowledge modules of the agent. The conversation module is called to open new conversations and produce new messages. Message Specification implements the message specification of section 4.1. The module contains message validation rules defined in accordance with the message specification. Conversation maintains the history of conversations in which the agent participates. The message specification module is called to validate incoming and outgoing messages, while the conversation module provides services for creating and closing conversations, producing new messages and retrieving conversation data. Communicator provides the basic message passing functions of the demonstrator application. Building on the communication primitives of IC Prolog II, this module implements the the ‘send message and wait’ facility for the client side and the ‘send reply’ facility for the server. Agent Knowledge Modules. The division of the the knowledge base reflects the source of this knowledge, be it with the the individual agent (e.g. agent name), the task domain (e.g. request evaluation rules) or the organization within which the agent is functioning (e.g. priority in which client requests are processed). For a demonstrator these divisions are largely arbitrary. Reviewer Knowledge. Many Reviewer agents were used in the study, each has a composite knowledge base drawn from: Individual Reviewer Knowledge, which records the name of the Reviewer agent and the expertise of the reviewer; Organization Knowledge, which implements the decision making procedures according to which review requests are evaluated; and Domain Knowledge which provides the top level request and proposal evaluation procedures. Chair Knowledge. The study makes use of a single Chair agent with knowledge combined from the review task domain (top level offer evaluation routines), the organization (the list of 15
known servers, the low level evaluation rules), and the agent itself (name).
5.3 Results: the Cooperation Services Framework in Use Figure 6 is a screen shot of the distributed review case study during execution. Each window displays the messages sent and received by an individual agent. The chair1 agent window provides a transcript of the messages exchanged between the agents during the distributed review procedure. The three stages of initial announcement, subsequent negotiation and final appointment are clearly shown. In this example the document under review is identified as p1 and covers the subject areas a, b and c. For the initial task request reviewers are allotted 5 days to complete the review. Only reviewer1 accepts these terms. Two more reviewers still need to be found and so the client begins negotiation with those who rejected the terms offered in the first round. A task proposal is issued with the revised assignment of 6 days. Reviewer2 now accepts the task while reviewer3 offers to perform the task in 7 days. The chair approves reviewer3’s offer and sends an echo proposal back to the server which follows with a formal acceptance. Sufficient reviewers have been found and the reviewers are automatically appointed. Chair1 issues the commands and awaits notification that the tasks have been completed. The demonstrator is launched via a simple tcl interface. Further interface dialogues may be constructed to configure the knowledge bases of the individual agents, e.g. to modify the parameters of the proposal and offer evaluation rules and to set the initial terms for task announcements.
6
Conclusions and Further Work
6.1 Summary We have reviewed the Cooperation Services Framework (CSF), an approach to the design of cooperative systems to support advanced CSCW functions in inter-organizational project management. We then focussed on a case study, which implemented agents and protocols to automate a distributed document review procedure. The case study showed how the CSF could be used to normalize interaction, communication and cooperation between organizations. This was achieved by specifying a range of possible messages and space of possible responses, which were consolidated in the form of (generic) cooperation protocols and then ‘instantiated’ in the implementation for the particular application. The case study has shown how standardized project services can be provided based on an agreed message specification and a standard representation of domain knowledge. The study also illustrates how inter-organizational contractual relationships can respect local working practices, in that each reviewer’s agent can be configured so that, for example, the way a negotiated agreement is reached can be different, the way a review is conducted locally can be different, domain, agent and organizational knowledge can be different, etc. The modular design of the system allows for new message specifications and complementary protocols to be added as necessary. In practice the the existing message specification 16
Figure 6: The Distributed Review Case Study in Execution
17
is sufficiently generic to support many applications; the given protocols too are applicationindependent, but there are many potential variations in negotiation strategy, especially when multiple agents are involved. With the CSF in place it is possible to develop and test a library of alternative high level communication protocols. The case study has also shown the value of a framework of agent support services which allows agent developers to concentrate on the functionality of their agents rather than the mechanics of agent interaction. We believe that the use of generic message-specifications and co-operation protocols is sufficiently flexible to encompass a wide range of application domains, particularly in the context of multi-organization systems. In this environment the ability to negotiate over the terms of service provision offers increased the flexibility over traditional client/server systems. At this stage in the development of the CSF, we should separate the principles behind the framework, which we believe are validated by the case study, from the technologies used to specify and implement it, for which there are several caveats. Deontic Action Logic is not with out subtle logical problems, but we expect well-found multi-modal logics (and reasoning systems for them) to emerge from our work on the Medlar II (Esprit 6471) project [Cunningham et al., 1991]. de Greef et al.’s specification language does not have a semantics, so while it is adequate for present purposes and we know of nothing like it, design tools for verification and program transformation are distinctly problematic. Finally, IC Prolog II is a nearly-finalized product of the IMAGINE (Esprit 5362) project, so we stress that the implementation is a demonstrator only. However, IC Prolog II was useful for prototyping and points the way for future agent implementations, for which we intend to use the April programming language [McCabe, 1994].
6.2 Relation to Other Work The CSF is highly eclectic, and so owes its inspiration to a number of different sources. The language/action perspective of [Winograd, 1988] suggested to us that our earlier work on deontic and action logics could be relevant to formalizing speech acts and protocols. Our cooperation protocols themselves are similar to [Burmeister et al., 1993], although we aim for a graphical (network) representation which can be generated from the formal (logical) specification. The two-tiered approach to specification, i.e. successively refining a specification from a global ‘abstraction’ to a well-refined description, can be related to the process of tailoring conversations in the ConversationBuilder system of [Kaplan et al., 1991], although our approach is more in keeping with a traditional model of software development. If we extend the CSF by adding protocol design and verification tools, agent interface and configuration tools, etc., then ConversationBuilder’s open architecture and user-interface suite serve as useful development guides. The SHADE [Kuokka et al., 1993] project is setting standards in a shared agent ontology, a common agent communication language, and facilitator agents to ease communication between application agents, and all to support collaborative engineering. These are all issues pertinent to the CSF, and recent developments in KIF, KQML, KAPI and facilitation applications3 have all had an impact on, and illuminated our thinking on the underlying knowledge representation for 3
References to KIF (Knowledge Interchange Format), KQML (Knowledge Query and Manipulation Language) and KAPI (KQML Application Programming Interface) can be found in [Kuokka et al., 1993].
18
agents, the language of cooperation protocols, CSF user interfaces, and ‘agent brokering’.
6.3 Further Work The challenges ahead range from commercially-oriented development to a long-term research programme. In the first case, we are developing, in conjunction with our GOAL project partner FHG/IML (Dortmund), an implementation of the Cooperation Service Framework based on the DEC ObjectBroker 2.5 implementation of the OMG’s CORBA 1.1 specification [OMG, 1992]. This implementation defines three enhancements to CORBA’s object brokering capabilities, namely standard interface operations for clients and servers through which inter-agent negotiation and service invocation is conducted; expected behaviour for clients and servers, i.e. protocols for inter-agent cooperation; and common services which enable agents to manage conversations and verify the compliance of other agents with the agreed cooperation protocols. For the research programme, we need to demonstrate genericity and configurability of the protocols by re-use in other management procedures (e.g. change management, meeting scheduling, etc.), to examine issues of inter-agent authority and autonomous decision-making, and to investigate autonomous agents which are secure, self-configurable, and pro-active (cf. the July issue (vol. 37, no. 7) of the Communications of the ACM on “Intelligent Agents”). As indicated above, important elements in realizing this programme are developing technologies like April as the agent prototyping language, and multi-modal logics, not only for the design of protocols but also of rational agents, i.e. agents whose autonomy (in terms of their ability to select protocols according to their current plans, beliefs and environment) is founded in the logics of practical reasoning, the subject of research in Medlar II. We have some way to go in achieving these goals, but the present work, construed as a feasibility study, is both a successful proof of concept and a demonstration of how Artificial Intelligence technologies, such as distributed AI and automated reasoning, can be used to design and implement generic agents which can be configured to support particular applications, in this case management procedures in inter-organizational projects. However, the CSF should be applicable to any open computing environment which spans organizational boundaries. We therefore intend to develop the CSF as an enhancement to the object brokering capabilities of CORBA-compliant open distributed systems, to provide a framework for agent brokering, i.e. agent interaction where the terms and quality of service delivery are open to negotiation.
Acknowledgements This work has been partially undertaken in the context of, and partially supported by, the CEC R&D project GOAL (Esprit 6283). The GOAL consortium is Alcatel ISR (F, lead partner), GSE (G), CETE (F), IML (G), MELT (F), SEL (G), City University (UK) and ICSTM (UK). For general information, contact Stephen McConnell, ARTTIC, 72 rue de Chateau des Rentires, 75013, Paris, France. We thank the anonymous reviewers for their comments, and Patrick Brezillon of the COOP’95 Program Committee for all his help. Particular thanks to both Jennifer Pitt and Patrick Brezillon for their work on the translation of the R´esum´e. Any errors are the fault of the authors. 19
References [Burmeister et al., 1993] B. Burmeister, A. Haddadi, and K. Sundermeyer. Generic configurable cooperation protocols for multi-agent systems. In MAAMAW’93, Neuchatel, 1993. [Chu and Clark, 1993] D. Chu and K. Clark. IC Prolog II: A Multi-Threaded Prolog System. m/s, Department of Computing, Imperial College, 1993. [Chu, 1992] D. Chu. IC Prolog II: A Language for Implementing Multi-Agent Systems. In Proceedings SIG on Cooperating Knowledge Based Systems, Keele, 1992. [Costa et al., 1990] M. C. Costa, R. J. Cunningham, and J. Booth. Logical Animation. In Proc. of 12th ICSE, pages 144–149, Nice, 1990. IEEE Computer Society Press. [Cunningham et al., 1991] J. Cunningham, D. Gabbay, and H.-J. Ohlbach. Towards the MEDLAR framework. In Esprit ’91, pages 822–841. Kluwer/CEC DGXIII, 1991. [de Greef et al., 1993] P. de Greef, K. Clark, and F. McCabe. Toward a specification language for cooperation methods. In GWAI’92 16th German AI Conference, volume 671, pages 313– 320. Springer Verlag, 1993. [Jones and Sergot, 1994] A. Jones and M. Sergot. Institutionalized power (preliminary report). To appear in the Bulletin of the IGPL. [Kaplan et al., 1991] S. Kaplan, A. Carroll, and K. MacGregor. Supporting Collaborative Processes with ConversationBuilder. ACM, 1991. [Kuokka et al., 1993] D. Kuokka, J. McGuire, J. Weber, J. Tenenbaum, T. Gruber, and G. Olsen. SHADE: Knowledge-Based Technology for the Re-Engineering Problem. http://hitchhiker.space.lockheed.com/aic/shade/papers/shade-overview.html, 1993. [Maibaum, 1993] T. Maibaum. Temporal Reasoning over Deontic Specifications. In [Meyer and Wieringa, 1993], pp141–202, 1993. [McCabe, 1994] F. McCabe. April: Agent PRocess Interaction Language. Department of Computing, Imperial College of Science, Technology and Medicine, 1994. [Meyer and Wieringa, 1993] J. Ch. Meyer and J. Wieringa. Deontic logic: A concise overview. In J. Ch. Meyer and J. Wieringa, editors, Deontic Logic in Computer Science, pages 3–16. Wiley, 1993. [OMG, 1992] OMG. The Common Object Request Broker: Architecture and Specification. OMG Document Number 91.12.1 (Revision 1.1), Wiley & Sons, 1992. [Pitt et al., 1994] J. Pitt, J. Cunningham, and J. H. Kim. Cooperative answering to natural language email queries. In F. Anger, R. Rodriguez, and M. Ali, editors, Proceedings 7th IEA/AIE-94, pages 273–281. Gordon and Breach Science Publishers, 1994. [Steiner et al., 1993] D. Steiner, A. Burt, M. Kolb, and C. Lerin. The conceptual framework of MAI2 L. In MAAMAW’93, Neuchatel, 1993. [Winograd, 1988] T. Winograd. A language action perspective on the design of cooperative work. In I. Grief, editor, CSCW: A Book of Readings. Morgan Kaufman, 1988. 20
