Previous: Agent Communication Protocols Up: KQML and Intelligent Information Integration Next: The role of KQML

Facilitators and Mediators

One of the design criteria for KQML was to produce a language that could support a wide variety of interesting agent architectures. Our approach to this is to introduce a small number of KQML performatives which are used by agents to describe the meta-data specifying the information requirements and capabilities and then to introduce a special class of agents called communication facilitators [16]. A facilitator is an agent that performs various useful communication services, e.g. maintaining a registry of service names, forwarding messages to named services, routing messages based on content, providing ``matchmaking'' between information providers and clients, and providing mediation and translation services.

As an example, consider a case where an agent A would like to know the truth of a sentence X, and agent B may have X in its knowledge-base, and a facilitator agent F is available. If A is aware that it is appropriate to send a query about X to B, then it can use a simple point to point protocol and send the query directly to B, as in Figure .

If, however, A is not aware of what agents are available, or which may have X in their knowledge-bases, or how to contact those of whom it is aware, then a variety of approaches can be used. Figure shows an example in which A uses the subscribe performative to request that facilitator F monitor for the truth of X. If B subsequently informs F that it believes X to be true, then F can in turn inform A.

Figure shows a slightly different situation. A asks F to find an agent that can process an ask(X) performative. B independently informs F that it is willing to accept performatives matching ask(X). Once F has both of these messages, it sends B the query, gets a response and forwards it to A.

In Figure , A uses a slightly different performative to inform F of its interest in knowing the truth of X. The recruit performative asks the recipient to find an agent that is willing to receive and process an embedded performative. That agent's response is then to be directly sent to the initiating agent. Although the difference between the examples used in Figures and are small for a simple ask query, consider what would happen if the embedded performative was subscribe(ask-all(X)).

As a final example, consider the exchange in Figure in which A asks F to ``recommend'' an agent to whom it would be appropriate to send the performative ask(X)). Once F learns that B is willing to accept ask(X) performatives, it replies to A with the name of agent B. A is then free to initiate a dialog with B to answer this and similar queries.

From these examples, we can see that one of the main functions of facilitator agents is to help other agents find appropriate clients and servers. The problem of how agents find facilitators in the first place is not strictly an issue for KQML and has a variety of possible solutions.

Current KQML-based applications have used one of two simple techniques. In the PACT project [7], for example, all agents used a central, common facilitator whose location was a parameter initialized when the agents were launched. In the ARPI applications [5], finding and establishing contact with a local facilitator is one of the functions of the KQML API. When each agent starts up, its KQML router module announces itself to the local facilitator so that it is registered in the local database. When the application exits, the router sends another KQML message to the facilitator, removing the application from the facilitator's database. By convention, a facilitator agent should be running on a host machine with the symbolic address facilitator.domain and listening to the standard KQML port.

Scaling up to a national-scale information enterprise will require the incorporation of new techniques. The current Internet Domain Name Servers (DNS) use a very simple, yet robust technique for mapping symbolic names into internet IP addresses. Similar techniques can be used to map symbolic agent ``names'' into specific agent references that can be used to contact the agent. What will be involved is the development of a hierarchical ``ontology'' for organizing information that is orthogonal to the hierarchical scheme used to organize the Internet. Figure shows such an agent which could function as such facilitator-agent-server.