Through the Agent Building Shell Project, an agent language has been construed and implemented at EIL. The COOrdination Language, COOL, is a language that allows the user to define agents, and manage communication and structured interactions amongst these. Agents use coordination protocols, called conversation classes, for the structured interactions. The conversation classes can be visualized as state diagrams, where the transitions from state to state are defined by conversation rules. A rule is executed under given conditions, and the actions defined in the rule are performed. COOL belongs to the family of deliberate architectures, and is thereby based on the symbolic artificial intelligence paradigm (see section 
).
This chapter describes the important features of COOL:
,,,,,,.
The chapter is based on an internal paper at the Enterprise Integration Laboratory (EIL), Teigen and Barbuceanu[27], which, among others, gives an overview of COOL. Teigen and Barbuceanu [27] was based on one published and two internal papers at EIL, Barbuceanu and Fox [2], Barbuceanu and Fox [3], and Barbuceanu [4].
(For the COOL syntax of the definition constructs, please refer to Appendix .)
Looking back to the section , where the notion of agents is presented, we see that an agent has the characteristics of autonomy, social ability, reactivity, and pro-activeness, and that it can also be said to have knowledge, beliefs, intentions, and obligations. The following is a short discussion of how some of these attributes are recognized in COOL agents.
The COOL agents are autonomous entities that communicate through message passing. Their reactivity to changes in the environment is assured by the use of coordination plans. The existence of these plans, and the common conventions they may give, makes it possible for agents to coordinate in complex ways, e.g. by carrying out negotiations [26, 29] about their goals and actions. The coordination plans are called conversation classes, and are treated in the next section.
The term knowledge will often be used for both knowledge and beliefs. When in this paper these notions are distinguished it is by the degree of which information is subject to change. Information that is continuously subject to change, e.g. a demand forecast or inventory levels, is referred to as a belief. Information that is more stable, e.g. the architecture of a plant, is referred to as knowledge. In COOL, knowledge and beliefs are explicitly represented in variables. COOL provides agent variables, associated to a particular agent object, and conversation variables, associated to a specific conversation object. Knowledge can also be implicitly represented in an agent's conversation classes.
Agents communicate by passing messages. Below we see an example of a message. The is a supplier agent sending a message to a materials agent with the intention of notifying that products are arriving. The message gives sender name, receiver name, content (here: arriving orders), intent, and conversation name.
(TELL
:SENDER YOSHI-DISK-INC
:RECEIVER CBOX-MATERIALS
:CONTENT (:ORDERS-ARRIVING
(8 (#:ORDER109 1 CBOX-MATERIALS DISK 279)
(#:ORDER583 4 CBOX-MATERIALS DISK 52)))
:INTENT PRODUCTS-ARRIVING
:CONVERSATION #:ARRIVE74)
The first word in the message, tell, specifies the intentions
of the sending agents. The same information content can be communicated with different intentions. For example:
KQML [9] has been designed as a universal language for expressing such intentions so that all agents would interpret them identically. KQML supports communication through explicit linguistic actions, called performatives.
COOL provides a construct for defining coordination protocols, the conversation class, and a corresponding instance construct, the actual conversation. Conversation classes are rule based descriptions of what an agent does in certain situations (for example when receiving messages with a given structure). COOL provides ways to associate conversation classes to agents, thus defining what sorts of interactions each agent can handle. A conversation class specifies the available conversation rules (described below), their control mechanism and the local data-base that maintains the state of the conversation. The latter consists of a set of variables (the conversation variables) whose values are manipulated by conversation rules. Since rules are indexed on the finite set of values of a special variable (the current-state), conversations admit a finite state machine representation (transition diagrams) which is often used for visualization and animation purposes.
Figure: Transition diagram showing the Arrange-Ship-Conversation. This conversation class is used by dispatching agents in the PMC Model.
Figure shows an example of a state diagram representation of a conversation class. This conversation class is from the PMC Model (Chapter ). It is used by dispatching agents when dispatching products at the end of production (see table , page ). The nodes gives the states of the conversation, and the arrows the transitions. The arrows are labeled with the number of the conversation rule it represents.
In each state of a conversation a certain number of conversation rules apply. The rules are the arrows in the transition diagram (Fig. ), representing the transition from one state to the next. Conversation rules describe the actions that can be performed when the conversation is in a given state. Which of the rules defined for a state actually gets executed, and how, depends on the matching and application strategy of the conversation's control mechanism. Typically, and for all use here, we execute the first matching rule in the definition order. A condition for a rule to match may for instance be that a certain operation must have been performed successfully, or that a certain message is received. These conditions are defined in the rule definition construct.
A rule may be complete or incomplete. When in a conversation a complete rule is encountered the rule will be executed automatically without consulting the human user. An incomplete rule, however, does not contain complete specifications of conditions and actions. The system can therefore not know if it should apply the rule, or in that case what action to take, and will therefore pop up a graphical interface (see section ), allowing the user to inspect, edit, and apply rules.
Another element of the framework is the ability of agents to specify their policies of selecting the next conversation to work on. Since an agent can have many ongoing conversations (some may be waiting for input, some may be waiting for other conversations to terminate, others may be ready for execution), the way it selects conversations reflects its priorities in coordination and problem-solving. The mechanism we use to specify these policies is continuation rules. Unlike conversation rules and error recovery rules, which are attached on conversation classes, continuation rules select from among the conversations of an agent and hence are attached on agents.
Continuation rules perform two functions. First, they test the agent's input queue of messages and apply the conversation class recognition mechanism to initiate new conversations. Second, they test the data base of ongoing conversations and select one existing conversation to execute. Which of these two actions has priority (serving new requests versus continuing existing conversations) and which request or conversation is actually selected, is represented in the set of continuation rules associated to the agent. Our agent definition mechanism allows the specification, for each agent, of both the set of continuation rules and the continuation rule applier.
The purpose of the conversation manager is to specify which agents are controlled by a manager. It is possible in COOL to define several conversation managers, each with its own set of agents. The need for the conversation manager occurs as agents in a COOL environment are not separate processes, hence have to be run individually by some controlling program.
For an agent to use a conversation class, the class must be associated to the agent. Agents can thus use the same conversation classes by associating these to different agents. The order of which classes are associated the agents is of no importance.
Conversation rules are associated to conversation classes. Conversation classes may thus share rules. The order of which the rules are associated to the classes decides which rule an actual conversation will try to execute first. This can be of great importance for the execution of the conversation.
Continuation rules are associated to the agents. Also here, the order of the associations matters. First associated continuation rule will be tried first.
As mentioned above associations can be done in the appropriate slots of the different definition constructs (see Appendix ), or, to avoid forward referencing, in a separate def-associations construct. All objects (agents, conversation classes and rules, and continuation rules) must have been declared before being associated to another object.
Coordination protocols for applications like supply chain integration are generally very complex, hard to specify completely at any time and very likely to change even dramatically during the lifespan of the application. Moreover, due to the social nature of the knowledge they contain, such protocols are better acquired and improved during and as part of the interaction process itself rather than by off-line interviewing of experts. This is especially true in our application context where many agents are supervised by users. Because of this, the coordination tool must support:
COOL satisfies these requirements by providing a subsystem that supports in context acquisition and debugging of coordination knowledge. Using this system execution takes place in a mixed-initiative mode in which the human user can decide to make choices, execute actions and edit rules and conversation objects. The effect of any user action is immediate, hence the future course of the interaction can be controlled in this manner.
Essentially, we allow both conversation and continuation rules to be incomplete. An incomplete rule is one that does not contain complete specifications of conditions and actions. Since the condition part may be incomplete we don't really know whether the rule matches or not, hence the system does not try to match the rule itself. Since the action part may be incomplete, the system can not apply the rule either. All that can be done is to let the user handle the situation. A graphical user interface is popped up.
The follow describes the different windows of the COOL graphical user interface. Figures of the windows are included in appendix .
) This section shows the COOL definition for the current conversation, and it allows the user to browse the conversation variables. The section also displays a state diagram representation of the conversation class, with the current state highlighted. Finally the conversation rules in the current state are listed.
) As its name indicates the section is used to browse, edit, and apply conversation rules. COOL definition of the rules can be seen directly. The rules can be deleted or their position altered (remember that the order of the rules in a conversation class matters). The user can also check for applicable rules, i.e. which rules that match the current conditions. The Conversation Rule Editor, Conversation Class Editor, and Conversation Class & Rule Browser windows (described below) can be accessed.
) When the action part of an existing rule is not complete, this section allows the interactive modification of the action part before executing it. A set of forms is available for presenting and edit the various slots of the action part.
) This section allows the user to look at the history of the execution of the conversation, i.e. the previous states, and received and transmitted messages. The user may also browse the current message queue, and search the queue using pattern matching.
) Specific to a conversation manager. Shows all agents handled by the manager, and the conversation classes used by these. The Conversation Manager window allows the user to initiate (start) actual conversations. It also gives access to the Agent Browser window.
) In the Agent Browser window the user can browse, edit, create, and delete agents. One may also inspect the actual conversations of the agents, and the agent and conversation variables.
) The Conversation Class and Rule Browser allows the user to browse conversation classes and rules. It gives access to the Conversation Rule Editor, and Conversation Class Editor windows, for editing and creation, and allows the user to delete classes and rules.
) This window gives the user the ability to edit slots in the COOL definition of conversation classes. It gives access to the Conversation Rule Editor for creating new rules.
) The editor is used to edit slots in the COOL definition of existing rules, and to create new conversation rules.
This chapter has presented the COOrdination Language (COOL), an agent language developed at EIL. The language allows to user to define agents and conversation plans for agent interactions. An instance of a conversation class, or plan, is called an actual conversation. The conversation plans can be visualized as transition diagrams where the transitions are implemented as conversation rules. A rule is applicable in a certain state, and will bring the conversation to a defined next state. The condition which must apply for the rule to be executed are also given in the rule definition, as are the actions to perform when executing it. Conditions may for example be that a message matching a certain pattern is received (in which case the conversation rule defines the agent's response to the received message), or that a variable is given a certain value. An action may for example be to send a message, start a new actual conversation, or run an application.
Conversation rules are associated to conversation classes, which are associated to agents, which are associated to conversation managers running the program. Continuation rules, which determine the priority of applying conversation rules, are associated to agents. For the association of conversation and continuation rules the order matters.
COOL gives the user the opportunity to incrementally develop conversation rules and classes, by defining rules as incomplete. When, during execution, the program meets an incomplete conversation rule, a graphical user interface will pop up, allowing the user to apply, edit, add, and delete conversation rules, and modify, add, and delete conversation classes and agents.