Jackal: a Java-based Tool for Agent Development *

R. Scott Cost, Tim Finin, Yannis Labrou, Xiaocheng Luan, Yun Peng, Ian SoboroffLaboratory for Advanced Information Technology

Department of Computer Science and Electrical EngineeringUniversity of Maryland Baltimore County

Baltimore, Maryland

James MayfieldResearch and Technology Development Center

Johns Hopkins University Applied Physics LaboratoryLaurel, Maryland

Akram BoughannamCIIMPLEX Project Office

Advanced Manufacturing Solutions DevelopmentIBM Corporation

Charlotte, North Carolina

Abstract

Jackal is a Java-based tool for communicating with theKQML agent communication language. Some featureswhich make it extremely valuable to agent develop-ment are its conversation management facilities, flexi-ble, blackboard style interface and ease of integration.Jackal has been developed in support of an investiga-tion of the use of agents in shop floor information flow.This paper describes Jackal at a surface and designlevel, and presents an example of its use in agent con-struction.

IntroductionJackal is a Java package that allows applications writtenin Java to communicate via the KQML (Finin, Labrou,& Mayfield 1997) agent communication language. It isdesigned to be used as a ’tool’ by other applications,in that it does not require that applications be modi-fied or extend some standard shell. Additionally, Jackalis designed so that multiple instances of it, and there-fore multiple agents, may be run within the same JavaVirtual Machine. Jackal:

* Facilitates the sending and receipt of KQML mes-sages.

¯ Implements a conversation-based approach to dia-logue management.

¯ Presents a blackboard interface to the agent.

This work is supported in part by the Advanced Tech-nology Program, administered by the National Instituteof Standards and Technology, under agreement number:70NANB6H2000.

¯ Provides portability through Java.

¯ Supports the use of multiple transport protocols.

¯ Requires no modification to existing code.

¯ Implements a complete scheme for agent naming andaddressing.

Jackal has been developed as part of a larger effortto develop an agent infrastructure for manufacturinginformation flow. It has been used to facilitate commu-nication among diverse agents responsible for collecting,processing and distributing information on a manufac-turing shop floor.

In next section, we introduce the application domainin which Jackal has been developed. This is followed bya discussion of Jackal’s features and their value to theagent development environment. Next, we expand onJackal’s conversation management abilities. Then, thesystem’s design and several key components are pre-sented. Finally, an example agent is used to illustratethe use of Jackal in construct communicating agents.

CIIMPLEXWith matching funds from the National Institute ofStandards and Technology, the Consortium for In-telligent Integrated Manufacturing Planning-Execution(CIIMPLEX), consisting of several private companiesand universities, was formed, with the goal of develop-ing technologies for intelligent enterprise-wide integra-tion of planning and execution for manufacturing (Chuet al. 1996; Peng et al. 1998). CIIMPLEX adoptsas one of its key technologies the approach of intelli-

73

From: AAAI Technical Report WS-98-10. Compilation copyright © 1998, AAAI (www.aaai.org). All rights reserved.

gent software agents, and develops a multi-agent system(MAS) for enterprise integration.

One of the key objectives of CIIMPLEX is to es-tablish a monitoring/notification architecture for enter-prise integration (Dourish & Bellotti 1992). In this ar-chitecture, an application defines events in which it isinterested (e.g. changes in process rates, yield, mate-rial due dates) and requests that agents monitor theseevents. When these events occur, the responsible agentsnotify the appropriate applications. A natural way toimplement the monitoring/notification architecture isto use broker agents to track and identify other agentsthat can provide event monitoring services.

Within the architecture of the MAS for the CIIM-PLEX enterprise, an Agent Name Server and BrokerAgent allow agents to be located by name and adver-tised services, respectively. In addition, several othertypes of agents are required for enterprise integration.For example, data-mining/parameter-estimation agentsare needed to collect, aggregate, interpolate and extrap-olate the raw transaction data of the low level (shopfloor) activities, and to make this aggregated informa-tion available for higher level analyses by other agents.Event monitoring agents monitor, detect, and presentabnormal events that require attention. The CIIM-PLEX Analysis Agents evaluate disturbances to thecurrent planned schedule and recommend appropriateactions to address each disturbance. Scenario Coordi-nation Agents assist human decision making for specificbusiness scenarios by providing the relevant context, in-cluding filtered information, actions, and well as work-flow charts.

All these agents speak KQML, as implemented inJackal, and use a subset of KIF (Genesereth 1992) thatsupports Horn clause deductive inference as the contentlanguage. The shared ontology is an agreement docu-ment established by the application vendors and usersand other partners in the consortium. The agreementadopts the format of the Business Object Documentdefined by the Open Application Group.

Jackal and Agent DevelopmentAgents which will interact with one another requiresome method of communication in order to coordinatetheir activities and distribute and collect information.To this end, several agent communication languages(e.g., KQML (Finin, Labrou, & Mayfield 1997), FIPAACL (FIPA 1997), ARCOL (FIPA 1997), ICL (Mar-tin, Cheyer, & Moran 1998), AgenTalk (Kuwabara,Ishida, & Osato 1995; Kuwabara 1995), KaOS (Brad-shaw 1996; Bradshaw et al. 1997), AOP (Shoham1993) and MAP (Eriksson et al. 1998)), and vari-ous software tools for them (e.g., TKQML (Cost et al.1997), OAA (Martin, Cheyer, & Moran 1998), JAT JATLite (Frost 1998; Petrie 1998), Magenta (Gene-sereth & Katchpel 1994) and AgentBase (Eriksson etal. 1998)), have been developed. Jackal is a tool forthe use of KQML by agents written in the Java pro-gramming language. Java is a useful language for writ-

ing agents because it is platform independent, as aninterpreted language, and has good language supportfor multi-threading. Jackal benefits from these prop-erties, and relies exclusively on the core Sunsoft JDK1.1 classes. This maximizes the likelihood that Jackal-based agents can run without modification on any plat-form that supports Java. Not only can Jackal-basedagents run on diverse or remote environments; manymay coexist within the same Java Virtual Machine.This is exploited by transparent protocol adapters forshared memory message passing.

Adding communication abilities to any Java programrequires no modification of existing code. This is be-cause Jackal’s functionality is accessed through a classinstance, which can be shared among agent componentslike a portable two-way radio. This is in contrast to sys-tems which require that a program subclass an agentshell, or otherwise restructure itself. With this Jackalinstance, the agent gains more than just the ability tosend and receive messages, however. Jackal’s designis based in large part on, and implements, the KQMLNaming Scheme (KNS), an evolving standard for re-solving agent names in a hierarchically structured, dy-namic environment. This means that the agent appli-cation need only deal with symbolic agent names, andmay leave issues such as physical address resolution andalias identification to the Jackal infrastructure.

Two components which work together to provide thegreatest benefit to the agent are the conversation man-agement routines and the Distributor, a blackboard formessage distribution. The conversation system sup-ports the use of easily interchangeable protocols for in-teraction, which guide the behavior of the system. TheDistributor presents a flexible, active interface for in-ternal message retrieval by agent components. Whilethe Distributor optimizes access to the message flow, itis the conversation system which gives it its real value;the next section will discuss in depth the rational be-hind the conversation-based approach.

Conversation-Based ProtocolsThe study of agent communication languages (ACLs)is one of the pillars of current agent research. KQMLand the FIPA ACL are the leading candidates as stan-dards for specifying the encoding and transfer of mes-sages among agents. While KQML is good for message-passing among agents, the message-passing level is notactually a very good one to exploit directly in build-ing a system of cooperating agents. After all, when anagent sends a message, it has expectations about howthe recipient will respond to the message. Those expec-tations are not encoded in the message itself; a higher-level structure must be used to encode them. The needfor such conversation policies is increasingly recognizedby the KQML community, and has been formally rec-ognized in the latest FIPA draft standard (FIPA 1997;Dickenson 1997).

It is common in KQML-based systems to provide amessage handler that examines the message performa-

74

tive to determine what action to take in response to themessage. Such a method for handling incoming mes-sages is adequate for very simple agents, but breaksdown as the range of interactions in which an agentmight participate increases. Missing from the tradi-tional message-level processing is a notion of messagecontext.

We claim that the unit of communication betweenagents should be the conversation. A conversation is apattern of message exchange that two (or more) agentsagree to follow in communicating with one another.In effect, a conversation is a communications protocol,albeit one that may be initiated through negotiation,and may be short-lived relative to the way we are ac-customed to thinking about protocols. A conversationlends context to the sending and receipt of messages,facilitating more meaningful interpretation. The adop-tion of conversation-based communication carries withit numerous advantages to the developer, including:

¯ There is a better fit with intuitive models of howagents will interact than is found in message-basedcommunication.

¯ There is also a closer match to the way that networkresearch approaches protocols, which allows both the-oretical and practical results from that field to beapplied to agent systems.

¯ Conversation structure is separated from the actionsto be taken by an agent engaged in the conversa-tion. This allows the same conversation structure tobe used by more than one agent, in more than onecontext. In particular, two agents can use the sameconversation structure to ensure that they will engagein the same dialogue.

¯ The standard advantages of the underlying ACL ac-crue, including language-independence and ontology-independence.

To date, little work has been devoted to the prob-lem of conversation specification and implementationfor mediated architectures. Strides must be taken inthe following directions:

¯ Potential conversations must be easy to specify.

¯ Conversation specifications must be easy to reuse.

¯ Libraries of standard conversations should be devel-oped.

¯ An ontology of conversations must be developed.

To achieve these goals, we must solve three mainproblems:

1. Conversation specification: How can conversationsbest be described so that they are accessible bothto people and to machines?

2. Conversation sharing: How can an agent use a con-versation specification standard to describe the con-versations in which it is willing to engage, and tolearn what conversations are supported by otheragents?

3. Conversation aggregation: How can sets of conversa-tions be used as agent ’APIs’ to describe classes ofcapabilities that define a particular service or capa-bility?

Conversation specification

A specification of a conversation that could be sharedamong agents must contain several kinds of informationabout the conversation and about the agents that willuse it. First, the sequence of messages must be speci-fied. We advocate the use of deterministic finite-stateautomata (DFAs) for this purpose; DFAs can express wide variety of behaviors while remaining conceptuallysimple. Next, the set of roles that agents engaging ina conversation may play must be enumerated. For ex-ample, a conversation that allows a sensor to report anunusual condition to all interested agents would havetwo roles: sensor and broker (which would in turn bespecializations of sentinel and sentinel-consumer roles).Most conversations will be dialogues, and will specifyjust two roles; conversations with more than two rolesare perfectly acceptable though, and represent the co-ordination of communication among several agents inpursuit of a single common goal.

DFAs and roles dictate the syntax of a conversa-tion, but say nothing about the conversation’s seman-tics. The ability of an agent to read a descriptionof a conversation, then engage in such a conversa-tion, demands that the description specify the con-versation’s semantics. To be useful though, such aspecification must not rely on a full-blown, highly ex-pressive knowledge representation language. We be-lieve that a simple ontology of common goals and ac-tions, together with a way to relate entries in the on-tology to the roles, states, and transitions of the con-versation specification, will be adequate for most pur-poses. This approach sacrifices expressiveness for sim-plicity and ease of implementation. It is nonethelessperfectly compatible with attempts to relate conversa-tion policy to the semantics of underlying performa-tives, as proposed for example by (Bradshaw 1996;Bradshaw et al. 1997).

These capabilities will allow the easy specification ofindividual conversations. To develop systems of conver-sations though, developers must have the ability to ex-tend existing conversations through specialization andcomposition. Specialization is the ability to create newversions of a conversation that are more detailed thanthe original version; it is akin to the idea of subclass-ing in an object-oriented language. Composition is theability to combine two conversations into a new, com-pound conversation. Development of these two capa-bilities will entail the creation of syntax for expressinga new conversation in terms of existing conversations,and for linking the appropriate pieces of the componentconversations. It will also demand solution of a varietyof technical problems, such as naming conflicts, and themerger of semantic descriptions of the conversations.

75

Conversation sharing

A standardized conversation language, as proposedabove, dictates how conversations will be represented;however, it does not say how such representations areshared among agents. While the details of how conver-sation sharing is accomplished are more mundane thanthose of conversation representation, they are never-theless crucial to the viability of dynamic conversation-based systems. Three questions present themselves:

¯ How can an agent map from the name of a conversa-tion to the specification of that conversation?

¯ How can one agent communicate to another the iden-tity of the conversation it is using?

¯ How can an agent determine what conversations arehandled by a service provider that does not yet knowof the agent’s interest?

Conversations Sets as APIs

The set of conversations in which an agent will partici-pate defines an interface to that agent. Thus, standard-ized sets of conversations can serve as abstract agentinterfaces (AAIs), in much the same way that standard-ized sets of function calls or method invocations serveas APIs in the traditional approach to system-building.That is, an interface to a particular class of service canbe specified by identifying a collection of one or moreconversations in which the provider of such a serviceagrees to participate. Any agent that wishes to pro-vide this class of service need only implement the ap-propriate set of conversations. To be practical, a nam-ing scheme will need to be developed for referring tosuch sets of conversations, and one or more agents willbe needed to track the development and dissolution ofparticular AAIs. In addition to a mechanism for es-tablishing and maintaining AAIs, standard roles andontologies, applicable to a wide variety of applications,will need to be created.

There has been little work on communication lan-guages from a practitioner’s point of view. If we setaside work on network transport protocols or protocolsin distributed computing (e.g., CORBA) as being toolow-level for the purposes of intelligent agents, the re-mainder of the relevant research may be divided intotwo categories. The first deals with theoretical con-structs and formalisms that address the issue of agencyin general and communication in particular, as a dimen-sion of agent behavior (e.g., AOP (Shoham 1993)). second addresses agent languages and associated com-munication languages that have evolved to some degreeto applications (e.g., TELESCRIPT (White 1995)). both cases, the bulk of the work on communication lan-guages has been part of a broader project that commitsto specific architectures.

Agent communication languages like KQML pro-vide a much richer set of interaction primitives (e.g.,KQML’s performatives), support a richer set of com-munication protocols (e.g., point-to-point, brokering,

recommending, broadcasting, multicasting, etc.), workwith richer content languages (e.g., KIF), and are morereadily extensible than any of the systems describedabove. However, as discussed above, KQML lacks orga-nization at the conversation level that lends context tothe messages it expresses and transmits. Limited workhas been done on implementing conversations for soft-ware agents, and almost none has been done on express-ing those conversations. As early as 1986, Winogradand Flores (Winograd & Flores 1986) used state tran-sition diagrams to describe conversations. The COOLsystem (Barbuceanu & Fox 1995) has perhaps the mostdetailed current finite state automata model to describeagent conversations. Each arc in a COOL state transi-tion diagram represents a message transmission, a mes-sage receipt, or both. One consequence of this policy isthat two different agents must use different automatato engage in the same conversation. We believe that aconversation standard should clearly separate messagematching from actions to be carried out when a matchoccurs; doing so will allow a single conversation specifi-cation to be used by all participants in a conversation.This, in turn, will allow conversation specifications todescribe standard services, both from the viewpoint ofthe service provider, and from that of the service user.

COOL also uses an :intent slot to allow the recipientto decide which conversation structure to use in under-standing the message. This is a simple way to expressthe semantics of the conversation. We argue below thatmore general descriptions of conversation semantics willbe needed if agents are to acquire and engage in newconversations on the fly. The challenge will be to de-velop a language that is general enough to express themost important facts about a conversation, without be-ing so general that it becomes an intellectual exercise,or is too computationally expensive to implement.

Other conversation models that have been developedinclude those of Parunak (Parunak 1996), Chauhan(Chauhan 1997), who uses COOL as the basis forhis multi-agent development system, Kuwabara et al.(Kuwabara, Ishida, & Osato 1995; Kuwabara 1995),who add inheritance to conversations, Nodine and Un-ruh (Nodine & Unruh 1997), who use conversationspecifications to enforce correct conversational behav-ior by agents, Bradshaw (Bradshaw 1996), who intro-duces the notion of a conversation suite as a collection ofcommonly-used conversations known by many agents,and Labrou (Labrou 1996), who uses definite clausegrammars to specify conversations. While each of thesemakes contributions to our general understanding ofconversations, none show how descriptions of conver-sations might be shared by agents and used directly bythem in implementing conversations.

Defining common agent services viaconversationsA significant impediment to the development of agentsystems is the lack of basic standard agent services thatcan be easily built on top of the conversation architec-

75

ture. Examples of such services are: name and addressresolution; authentication and security services; broker-age services; registration and group formation; messagetracking and logging; communication and interaction;visualization; proxy services; auction services; workflowservices; coordination services; and performance mon-itoring services. Services such as these have typicallybeen implemented as needed in individual agent devel-opment environments. Two such examples are an agentname server and an intelligent broker.Agent Name Server At first blush, the problem ofmapping from an agent name to information about thatagent (such as its address) seems trivial. However, solv-ing this problem in a way that can easily scale as thenumber of users and amount of data to be processedgrows is difficult. We believe that development of a suc-cessful symbolic agent addressing mechanism demandsat least two advances:

1. A simple naming convention to place each role anagent might play in an organization at a unique pointin a namespace for that organization. Currently thereis no widely-accepted mechanism for universal uniqueagent naming (in the way that there now is, e.g., forInternet hosts or web documents).

2. An efficient, scalable name service protocol for map-ping from symbolic role names to information aboutthe agents that fill those roles.

To a large extent, the desired techniques can bemodeled after existing name service techniques suchas DNS (which is widely implemented) and CORBA(whose namespace mechanisms are only narrowly im-plemented). Such techniques are well-studied, highlyreliable, and scalable. Agent name service will differfrom DNS primarily in that agents will tend to appear,disappear, and move around more frequently than doInternet hosts. This will necessitate the developmentof naming conventions that are less rigid than thoseused in DNS, and algorithms for mapping from namesto agent information that do not rely on the static localdatabases found in DNS.Intelligent Broker A system that is to respond tothe demands of multiple users, with needs that varyover time, under an ever-increasing query load mustbe able to do on-the-fly matching of queries to doc-uments and services. In an agent-based architecture,this means that one agent must be able to dynami-cally discover other agents based on the content of theirknowledge. It should exploit the research on conver-sations and the symbolic agent-addressing scheme de-scribed above, while at the same time fitting neatly intoexisting brokered systems. Such systems will continueto see a single broker where there had been a single bro-ker all along; now, however, that broker will have theoption of coordinating many other disparate brokers ofvarying capabilities.

An Overview of Jackal’s Design

Jackal was designed to provide comprehensive function-ality, while presenting a simple interface to the user.Thus, although Jackal consists of roughly seventy dis-tinct classes, all user interactions are channeled throughone class, hiding most details of the implementation.

Figure 1 presents the principal Jackal components,and the basic message path through the system. Wewill first discuss each of the components, and then, toillustrate their interaction, trace the path of a messagethrough the system (that is, as it is received by Jackal,passed on to and replied to by an agent thread, and thereply sent back to the original sender).

Intercom

The Intercom class is the bridge between the agent ap-plication and Jackal. It controls startup and shutdownof Jackal, provides the application with access to in-ternal methods, houses some common data structures,and plays a supervisory role to the communications in-frastructure.

Transport Interface

Jackal runs a Transport Module for each protocol it usesfor communication. Jackal 3.0 comes with a module forTCP/IP, and users can create additional modules forother protocols. A Transport Module is responsible forreceiving messages at some known address, and trans-mitting messages out via a given protocol.

Message Handler

Messages received by the Switchboard must be directedto the appropriate place in the Conversation Space; thisis the role of the Message Handler. Messages are asso-ciated with current (logical) threads based on their (the value of the ’reply-with’ field). This directs theirassignment to ongoing conversations when possible. Ifno such assignment can be made, a new conversationappropriate to the message is started.

Conversations

Based largely on the work of Labrou and Finin (Labrou1996; Labrou & Finin 1997) regarding a semantics forKQML, we have created protocols, which describe thecorrect interactions for various performatives and sub-sequent messages. The protocol for ask-one, for exam-ple, specifies among other things that a reply must bea tell, untell, deny, sorry or error. These protocols are’run’ as independent threads for all current conversa-tions. This allows for easy context management, whileproviding constraints on language use and a frameworkfor low level conversation management. This is in con-trast with earlier approaches (e.g., TKQML (Cost al. 1997)) which require the agent to maintain contexton their own.

The Conversation Space is a virtual entity, consistingof the collection of conversations started by the Message

77

1 Interne.______A2

~Switchboard

Modules

©Jackal 3.0 in a Nutshell

8j

13

[~= Message Queue Q = Java Thread

Intercom

f Distributor

C4,10

~- = Message Path

7

Services

Figure 1: Jackal Architecture and Message Flow

~ (ask-one)

(tell)

~(deny)

Figure 2: DFA for KQML ask-one conversation

Handler. These conversations run individual protocolinterpreters.

As of Jackal 3.0.4, conversation templates (or speci-fications) are completely independent from the Java li-brary. Rather, they are specified by URLs, and loadedat runtime from some remote source. Figure 3 showsthe conversation template for a standard KQML con-versation available from the Jackal host. This templatecorresponds to the finite state machine depicted in Fig-ure 2.

The conversation management component offers anumber of significant benefits to the agent:

¯ Running conversations in individual threads provides

maximum flexibility.

¯ Conversations, in conjunction with the Distributor,route messages automatically to the threads whichneed them.

¯ Each conversation maintains a local store, which canbe accessed by the agent via a message ID, and whichserves as the conversation’s context.

¯ Since conversations are declaratively specified, theycan be loaded (remotely or locally) on demand. Ourcurrent agents download at initialization only theconversations they will need.

¯ The conversation mechanisms and the specificationare almost completely independent of the content ormessage language used, and so could be easily betuned work in a ’multi-lingual’ environment.

¯ Actions can be associated with conversation struc-tures, enhancing their utility. While our systemsupports this, the preliminary specification languagedoes not. Extending it to include actions will requirefirst the development of an ontology enumerating ac-tions implemented by conversation interpreters.

Distributor

The Distributor is a Linda-like (Carriero & GelertnerApril 1989) blackboard, which serves to match messageswith requests for messages. This is the sole interfacebetween the agent and the message traffic. Its conciseAPI allows for comprehensive specification of messagerequests. Requesters are returned message queues, and

78

// Conversation Template// Convention: Initial and accepting states all caps,// other states initial caps,// arc-labels lower case.(conversation

(name kqml-ask-one)(author "R. Scott Cost")(date "3/4/98")(start-state START)(accepting-states TOLD)(transitions

(arc (label ask-one)(arc (label tell)(arc (label deny)(arc (label untell)(arc (label sorry)(arc (label error)

(from START) (to Asked) (match "(ask-one)"))(from Asked) (to TOLD) (match "(tell)"))(from Asked) (to TOLD) (match "(deny)"))(from Asked) (to TOLD) (match "(untell)"))(from Asked) (to TOLD) (match "(sorry)"))(from Asked) (to TOLD) (match "(error)"))))

Figure 3: Conversation Template for KQML ’ask-one’

receive all return traffic through these queues. Requestsfor messages are based on some combination of message,conversation or thread ID, and syntactic form. Theyalso permit actions, such as removing an acquired mes-sage from the blackboard or marking it as read only.A priority setting determines the order or specificity ofmatching. Finally, requests can be set to persist indefi-nitely, or terminate after a certain number of matches.

Services

A service here is any thread; this could be a Jackalservice, or threads within the agent itself. The onlything that distinguishes among threads is the requestpriority they use. System, or Jackal, threads choosefrom a set of higher priorities than agent threads, buteach chooses a level within its own pool. Jackal reservesthe highest and lowest priorities for services directingmessages out of the agent and for those cleaning theblackboard, respectively.

Message RoutingThe Switchboard acts as an interface between theTransport Modules and the rest of Jackal. It must fa-cilitate the intake of new messages, which it gathersfrom the Transport Modules, and carry out send re-quests from the application. The latter is a fairly com-plicated procedure, since it has multiple protocols at itsdisposal. The Switchboard must formulate a plan forthe delivery of a message, with the aid of the AddressCache, and pursue it for an unspecified period of time,without creating a bottleneck to message traffic. In ad-dition, it is equipped to handle the delivery of messageswith multiple recipients or ’cc’ fields.

Naming and Addressing/Address Cache

In any multi-agent system, the problem of agent nam-ing arises: how do agents refer to each other in a simple,

flexible, and extensible way? If the system in questionemploys a standard communication language such asKQML, another requirement is that agents must be ableto refer to KQML-speaking agents in the outside world.Within the development of Jackal, we propose KNS, anaming scheme designed to support collaborating, mo-bile KQML-speaking agents using a variety of transportprotocols. Jackal supports KNS transparently throughan intelligent address cache.

KNS is a hierarchical scheme similar in spirit to DNS.A fully-qualified agent name (FQAN) is a sequence agent names, separated by periods. The sequence de-scribes registrations between agents, so that the agentpreceding a period is registered with the agent followingit. An example of a FQAN is

phil. cs. http ://www. umbc. edu/ans/

In this example, "phil" is an agent registered with agent"cs", which in turn is registered with an agent thatlives at the URL http://www.umbc, edu/ans/. The fi-nal agent in a FQAN is always a URL, providing unique,static location information for the base of an agent reg-istration chain.

When one agent registers with another, a relation-ship is formed between them. The registering agent(or child) submits information to the agent being reg-istered with (or parent) on how the child may be con-tacted: socket ports, email addresses, or web serversare all possible. In return, the parent becomes a repos-itory for that information. An agent who knows how tocontact agent cs, i.e. knows a physical address for cs,can contact phil by first asking cs for phil’s contactinformation. If an agent seeks to register with a newparent using a name already registered with the par-ent, the name is qualified by an instance number, e.g.,phil [2] . cs. http ://www. umbc. edu/ans/.

Agents can register together to form teams, and can

79

maintain multiple identities to represent roles in themulti-agent system. Multiple registrations for an agentbecome a network of aliases for that agent; if one namebecomes inaccessible, another can be identified to fillthe gap. Moreover, since agents can maintain multiplecontact information for each name, agents can changelocations and leave forwarding arrangements for mes-sages while they migrate. In this way, dynamic groupformation is supported.

KNS also provides a set of protocols for maintainingan agent’s identity independently of any one of its regis-tered names. This unburdens the agent and those seek-ing it from the need to manage dynamic sets of iden-tities over time. For example, after a series of nameregistrations and unregistrations, an agent can be lo-cated through KNS via any one of the names it haspreviously used.

The Address Cache holds agent addresses in order todefray lookup costs. It is a multilayered cache support-ing various levels of locking, allowing it to provide highavailability. Unsuccessful address queries trigger under-lying KNS lookup mechanisms, while blocking access toonly one individual listing.

Message PathHaving described the various components of Jackal, wewill trace the path of a received message and the cor-responding reply, using the numbered arcs in Figure 1for reference.

The message is first received by a connection threadwithin a Transport Module [1], perhaps TCP/IP, andis processed and transferred directly to the input queueof either a waiting or new conversation [2]. A uniquethread manages each conversation. Methods for theinitial processing of the message reside in the MessageHandler, but are called by the responsible transportthread. The target conversation, awakened, takes themessage from its input queue [3] and tries to advance itsstate machine accordingly. If accepted, the message isentered into the Distributor [4], an internal blackboardfor message distribution. The Distributor examines themessage [5] in turn, and tries to match it with any pend-ing requests (placed by Jackal or agent code), in orderof a specified priority, Ideally, a match is found, andthe message is placed in the queue belonging to the re-quester [6]. The message may in fact be passed to sev-eral requesting threads. This is the point at which theagent gains access to the message flow; through servicesattending to the blackboard.

Once the requesting service thread picks the messageout of its queue [7], it presumably performs some ac-tion, and may send a reply or new message; we assumeit does. The service has two options at this point. Ifit does not expect a reply to the message it is sending,the message may be sent via Intercom’s send_messagemethod [8]. Otherwise, it should be sent indirectlythrough the Distributor. This is equivalent to send-ing alone and then requesting the reply, hut allows therequest to be posted first, eliminating possible nonde-

terminism. Either way, the message is eventually pro-cessed through send_message, which directs it into theconversation space. The message then traces the samepath as the previous incoming message [9,10] to thedistributor. Note that every message, incoming or out-going, passes through the conversation space and theDistributor. The message is captured by the Switch-board’s outbound message request [11], which has a spe-cial, reserved priority. The Switchboard removes newmessages from its queue and assigns them each indi-vidual send threads [12]; this results in some overhead,but allows sends to proceed concurrently, avoiding bot-tlenecks due to wide variation in delivery times. Thesend thread uses the send method of the appropriatetransport module to transmit the message.

Using Jackal: An ExampleIn this section, we will examine an agent that usesJackal. This agent implements a simplified, workingbroker, and functions within a suite of Jackal demoagents that includes an agent name server, remote sen-sor agents and a client. The code for this agent is quitesparse, illustrating the ease with which agents can beconstructed using Jackal.

Jackal agents typically consist of one main executionthread and a number of service threads. The broker’smain thread is depicted in Figure 4.

package Agents.Weather;import java.lang.*;import java.util.Vector;import J3.*;

class broker extends Thread {Intercom j3;Vector ad = new Vector();

public static voidmain (String[] argv) { new broker();

broker() { start();

public void run() j3 = new Intercom("broker",

"ftp://cs.umbc.edu/common.kqmlrc");j3.stderr("Agent broker started.");BrokerServ brokerServ = new BrokerServ();AdvertServ advertServ = new AdvertServ();

}

// Advertise service goes here.// Broker service goes here.

Figure 4: Broker Agent

This agent has a ’main’ method so that it can bestarted directly via the command ’java J3.broker’. A1-

8O

ternatively, it could be instantiated by another agent;an important option if several agents are running withinthe same virtual machine. As an aid to development,each instance of Jackal spawns an individual console,which it uses for standard output. The console can alsobe used to execute methods in the API directly, includ-ing spawning agents, via a simple command interface.

The first parameter to the Intercom constructor isthe agent’s initial name. As outlined above, this will beaugmented at registration into a fully qualified name.The second parameter specifies the agent’s resource file,which contains information needed for basic operation.Once Intercom is instantiated, Jackal performs basicstartup operations, such as starting listener threadsand registering with this agent’s primary Agent NameServer. Note the use of the console in the next step.

Finally, the broker starts the threads that will per-form its basic services; accepting advertisements (Fig-ure 5), and matching stored advertisements with in-coming requests (Figure 6). For clarity, these threadshave been separated out from the main broker code.

class AdvertServ extends ThreadFIFO queue;

public AdvertServ() { start();

public void run() Message msg, reply;queue = j3.attend(null,"(advertise)",

null,8,false,true,O,true,false);while ((msg = (Message)

queue.dequeue()) != null) ad.addElement(msg);try {

reply = newMessage(" (tell : content true)")

reply, put (" : language", "ascii") reply, put (" : receiver",

msg. get (" : sender") ) reply .put (": in-reply-to",

msg. get (" : reply-with") ) j3.send_message(reply);

} catch (MalformedMessageX e) System.err.println(e);

}}

Figure 5: Broker Agent: Advertise Thread

The advertisement service illustrates the basic Jackalservice construction. Its first step is to place a perma-nent request with the Distributor for all incoming mes-sages with the performative ’advertise’. All matchesshould be left for other threads, but with the write per-mission removed. It is returned a queue from which to

fetch results. The thread then enters a cycle in whichit waits (blocks) for the next message, processes it, andrepeats. Our simple service merely stores the incomingmessage, and replies that it has been noted. Threadshave the option to poll the queues, rather than block.

class BrokerServ extends Thread {FIFO queue;

public BrokerServ() start();

}

public void run() Message msg, reply = null, a, b;int i;queue = j3.attend(null,"(broker-one)",

null,8,false,true,O,true,false);while ((msg = (Message)

queue.dequeue()) != null) try {

for (i = O; i < ad.size(); i++) a = (Message) ad.elementAt(i);b = (Message) a.get("content");if (b.equals(msg)) break;

}if (i == ad.size()) reply =

Message("(sorry :content \"\")");else reply = new

Message(" (tell : content "+a+")") reply .put (":language", "ascii") reply, put (" : re ceiver",

msg. get (" : sender") ) reply, put (":in-reply-to",

msg. get (" : reply-with") ) j3.send_message(reply);

} catch (MalformedMessageX e) System.err.println(e);

}}

Figure 6: Broker Agent: Broker Thread

The broker service is only slightly more complicated,but has the same basic structure. Each message re-ceived is compared to (the contents of) each existingadvertisement, using the comparison method associatedwith the message. Where possible, this will recursivelymake use of the comparison method for the given con-tent language. If a match is found, it is forwarded tothe requesting agent. Otherwise, a ’sorry’ is sent.

Summary

Jackal provides developers with an easy to use facilityfor KQML, supporting the use of conversation basedprotocols. In addition, it provides basic services such

81

as hidden address resolution. These features make it avaluable asset in developing agents for manufacturinginformation flow.

ReferencesBarbuceanu, M., and Fox, M. S. 1995. COOL: Alanguage for describing coordination in multiagent sys-tems. In Lesser, V., ed., Proceedings of the First Inter-national Conference on Multi-Agent Systems, 17-25.San Francisco, CA: MIT Press.Bradshaw, J. M.; Dutfield, S.; Benoit, P.; and Woolley,J. D. 1997. KAoS: Toward an industrial-strength openagent architecture. In Bradshaw, J. M., ed., SoftwareAgents. AAAI/MIT Press.

Bradshaw, J. M. 1996. KAoS: An open agent architec-ture supporting reuse, interoperability, and extensibil-ity. In Tenth Knowledge Acquisition for Knowledge-Based Systems Workshop.

Carriero, N., and Gelertner, D. April, 1989. Linda incontext. CACM 32(4):444-458.Chauhan, D. 1997. JAFMAS: A java-based agentframework for multiagent systems development andimplementation. Master’s thesis, ECECS Department,University of Cincinnati.

Chu, B.; ans R. Wilhelm, W. J. T.; Hegedus, M.;Fesko, J.; Finin, T.; Peng, Y.; Jones, C.; Long, J.;Matthes, M.; Mayfield, J.; Shimp, J.; and Su, S.1996. Integrating manufacturing softwares for intel-ligent planning-execution: A CIIMPLEX perspective.In Plug and Play Software for Agile Manufacturing,SPIE International Symposium of Intelligent Systemsand Advanced Manufacturing.

Cost, R. S.; Soboroff, I.; Lakhani, J.; Finin, T.; andMiller, E. 1997. TKQML: A scripting tool for buildingagents. In Wooldridge, M.; Singh, M.; and Rao, A.,eds., Intelligent Agents Volume IV- Proceedings of the1997 Workshop on Agent Theories, Architectures andLanguages, volume 1365 of LNAI. Berlin: Springer-Verlag. 336-340.

Dickenson, I. 1997. Agent standards. Technical report,Foundation for Intelligent Physical Agents.

Dourish, P., and Bellotti, V. 1992. Awareness and co-ordination in shared workspaces. In Proceedings of theACM 1992 Conference on Computer-Supported Coop-erative Work: Sharing Perspectives (CSCW ’92), 107-114.

Eriksson, J.; Espinoza, F.; Finne, N.; Holmgren, F.;Janson, S.; Kaltea, N.; and Olsson, O. 1998. Aninternet software platform based on SICStus prolog.Position Paper, Swedish Institue of Computer Science.

Finin, T.; Labrou, Y.; and Mayfield, J. 1997. Soft-ware Agents. MIT Press. chapter KQML as an agentcommunication language.

FIPA. 1997. FIPA 97 specification part 2: Agentcommunication language. Technical report, FIPA -Foundation for Intelligent Physical Agents.

Frost, H. R. 1998. Java Agent Template. OnlineDocumentation:http://cdr.stanford.edu/ABE/JavaAgent.html.

Genesereth, M. R., and Katchpel, S. P. 1994. Softwareagents. CACM 37(7):48-53, 147.

Genesereth, M. R. 1992. Knowledge interchange for-mat version 3.0 reference manual. Technical ReportLogic Group Report Logic-92-1, Stanford University.

Kuwabara, K.; Ishida, T.; and Osato, N. 1995.AgenTalk: Describing multiagent coordination proto-cols with inheritance. In Proceedings of the 7th IEEEInternational Conference on Tools with Artificial In-telligence (ICTAI 95), 460-465.Kuwabara, K. 1995. AgenTalk: Coordination protocoldescription for multi-agent systems. In Proceedingsof the First International Conference on Multi- AgentSystems (ICMAS 95). AAAI/MIT Press.

Labrou, Y., and Finin, T. 1997. Semantics and con-versations for an agent communication language. InProceedings of the Fifteenth International Joint Con-ference on Artificial Intelligence (IJCAI-97). MorganKaufman.Labrou, Y. 1996. Semantics for an Agent Commu-nication Language. Ph.D. Dissertation, University ofMaryland Baltimore County.Martin, D. L.; Cheyer, A. J.; and Moran, D. B. 1998.Building distributed software systems with open agentarchitecture. In Proceedings of the Third Interna-tions Conference on Practical Applications of Intelli-gent Agents.

Nodine, M. H., and Unruh, A. 1997. Facilitating opencommunication in agent systems: the InfoSleuth in-frastructure. In Singh, M.; Rao, A.; and Woolridge,M., eds., Proceedings of the l~th Annual Workshop onAgent Theories, Architectures and Languages (ATAL-97).Parunak, H. V. D. 1996. Visualizing agent conversa-tions: Using enhanced dooley graphs for agent designand analysis. In Proceedings of the Second Interna-tional Conference on Multi- Agent Systems (ICMAS96).Peng, Y.; Finin, T.; Labrou, Y.; Chu, B.; Long, J.;Tolone, W. J.; and Boughannam, A. 1998. A multi-agent system for enterprise integration. InternationalJournal of Agile Manufacturing.

Petrie, C. 1998. JATLite. Online Documentation:http://java.stanford.edu/.Shoham, Y. 1993. Agent-oriented programming. Ar-tificial Intelligence 60:51-92.White, J. 1995. Mobile agents. In Bradshaw, J. M.,ed., Software Agents. MIT Press.

Winograd, T., and Flores, F. 1986. UnderstandingComputers and Cognition. Addison-Wesley.

82