JATLite: A Java Agent Infrastructure with Message Routing

Heecheol Jeon
Charles Petrie
Mark R. Cutkosky
Stanford Center for Design Research (CDR)
Stanford, CA 94305-2232
<jhc, petrie, cutkosky@stanford.edu>
An unabridged version of the shorter paper that appears in IEEE Internet Computing

Abstract

JATLite (Java Agent Template, Lite) is a package of Java classes and programs that allow users to create quickly new systems of software agents that communicate over the Internet in order to perform a distributed computation. The agents may be newly created software or legacy software "wrapped" with software that generates and receives agent messages as an integration mechanism. In addition to code for creating agents, JATLite provides a robust agent infrastructure in which agents register with an agent Message Router (AMR), using a name and password, in order to be able to exchange buffered messages with and transfer files between other agents on the Internet (some of which may be Java applets), and connect/disconnect/reconnect from/to the joint computation. Communication may be asynchronous and intermittent agents are supported. There is no requirement for installation of special software to host agents and no special host is assumed for any agent.

JATLite facilitates the construction of agents that send and receive messages using the communication language, KQML, an early standard. However, developers may build systems in JATLite using other languages such as the FIPA ACL communications are built on open Internet standards, such as TCP/IP, SMTP and FTP.

1. Introduction

In the early 1990's, an experiment named "PACT"[Cutkosky et al 93] resulted in the recognition of the need for a common agent language to integrate heterogeneous large complex software systems. This resulted in the Knowledge Query and Manipulation Language (KQML) in 1993, updated in 1997[Labrou and Finin 97], that has continued to be used and revised since that time. In attempting to use KQML for the integration of engineering software and designers, we found that certain infrastructure issues had been ignored and the resulting tools for supporting KQML were inadequate for our task.

We conjecture that most of these issues were too low-level for most researchers to bother with in the early 90's. They were not a good conceptual basis for papers. For instance, there was a lack of KQML specification for protocols for connection and registration of agents. And the earliest KQML APIs for LISP had never been tested over long distances on the Internet and there were subtle timing problems that took several months for us to debug, indicating a lack of attention to low-level but practical issues.

Most disconcerting, the KQML API assumed that every agent was responsible for managing its own communications with other agents. This meant that when our engineering programs crashed, or moved to different platforms, either the distributed computation was disturbed, or each individual agent had to be very clever and spend significant resources in communications management. And with the introduction of Java, we found that we were severely limited in our use of Java applets given the assumptions about agent communications management and security restrictions.

In particular, agents were assumed to be able to send messages directly to any other agent, perhaps using TCP sockets. However, applets, unless using the more recent trust capabilities, requiring special local installation, may not connect with platforms other than the server that spawned them. Even stand-alone agents were required to keep track of the current IP address of other agents. If the other agents changed IP addresses, this would be discovered only by message delivery failure. And each agent was supposed to manage the buffering and resending of messages that failed to be received by other agents with which it was communicating.

While this distributed management was commonly perceived to be necessary for scaling, we found that the agent engineering systems using this philosophy were brittle: any distributed computation could be destroyed by the failure of any one agent to properly manage its communications with others. It was analogous to an email system with no email servers and each individual being responsible for the correct routing of all messages, while this email system was being used to coordinate a distributed project. If one agent misses a message that, say, a piece of work needs to be redone and passed to another, some of the threads of communicaton, and thus work, may be broken, and it may be difficult to recover the missing messages.

In the case of engineering agents, they often needed to be kept involved in the project, despite crashing, or being moved to different machines during the project. This meant that we needed an agent infrastructure that would allow any agent to die at any time, and then reconnect to the distributed computation, perhaps from a different IP. Our mobility requirement was also that no special software be required to install an agent on a machine. If, for example, a Finite Element Analysis (FEA) agent needed to be moved from one computer to another, it should only be necessary to copy the agent software to that machine and run it there (ignoring for the moment storage of work files).

This was especially true for applet agents. In order to take advantage of the Java technology, we wanted to be able to download a particular applet agent onto any machine on the Internet with no special pre-installation procedures (except for any special plugins that could be also dynamically loaded). The existing infrastructures requiring each agent to manage its communications with other agents were incompatible with these requirements.

We found no other exisiting solution to these problems, and so we were forced to develop a new infrastructure, JATLite, beginning in 1996. This three-year old isolated effort is now free software under the GNU license and is widely used around the world. This paper explains the design rationale of this agent infrastructure, compares it to other more recent systems, and draws conclusions from our experience using it. We realize there may be alternatives to this particular design and hope this explantion will be useful to other agent infrastructure designers.

1.1 Scope of Agent Support

A variety of software tools have been developed to facilitate agent (system) construction {1}. However, any discussion of development tools should be informed about the properties of the software artifact being constructed. Unfortunately, there is no clear consensus definition of "agent." Properties such as intelligence and autonomy are often deemed to be essential but these are ambiguous terms subject to interpretation. Without operational definitions, it is hard to determine whether a software candidate is an agent much less whether a particular tool will create the kind of agent desired.

JATLite is based on the agent theory of Typed-Message Agents[Petrie 96] (that builds on the seminal paper [Genesereth and Ketchpel 94]), where an agent is defined in terms of agent communities that perform a distributed computation using typed-messages. Such messages have some semantics defined prior to run-time. KQML is one example of such a message protocol. Further, the agents are such by virtue of the necessity of using peer-to-peer communication protocols, versus client-server protocols, because they are able to initiate messages, rather than only respond once to a query. They are agents to the degree that such initiative improves the computation, and are thus minimally pro-active.

This sliding scale definition has the distinction that it is an operational one, not dependent upon subjective measures of "autonomy", "sensing", or "intelligence". The degree to which individual agents may be described as autonomous or intelligent depends upon the intensions of the developers and the judgment of the users. We agree with the thesis that communication dialogue prescription is more important than internal agent architecture[Haddadi 96] and it is a mistake to base language upon mental qualities ascribed to agents [Singh 98]. Further, the typed-message definition does not rely on a notion of "doing something for the user", a notion which does not distinguish agents from most computer programs.

The definition does distinguish at least typed-agent technology from other well-known techniques in computer science and engineering. It is true this definition may depend upon the computation being performed and the measure of its being "better". We do assume that one can tell if one's computation is improved or not. This is a far less murky measure than those that use the terms mentioned above. Some computations may show no change regardless of the software technology employed, but this only says agent technologies are only better for some purposes. This discussion also implies that not all systems built using systems like JATLite are necessarily agents. But this definition indicates the importance of agent communications, protocol, and infrastructure.

Another commonly used category of agenthood is "mobility." Neither the Typed-Message Agent theory, nor JATLite, makes any commitment to or restriction on mobility. As will be described later, the JATLite Agent Message Router (AMR) allows agents, especially applets, to change IP addresses during the computation, but does not provide or depend upon any special framework that allows agents to migrate autonomously. That is, there is no docking framework support in JATLite for allowing agents to "push" themselves from one computer to another, although they may do so with additional software. The AMR is independent of the method of transport. This paper will not deal with mobile agent frameworks such as Aglets{12} or Mubot{11} as issues concerning such frameworks have been extensively analyzed elsewhere.{15}

1.2 Typed-Message Agent Development Tools

The earliest agent tools exploited primarily the idea of agents that communicated with each other via typed-messages from fixed IP addresses. This notion of communication is very useful for "wrapping" existing legacy software with new software that can send and receive  messages according to a predefined Agent Communication Language (ACL) and an application-dependent set of specific messages, usually expressed in a "content", or "inner," language. A key idea is that agents work together by exchanging simple ASCII text messages. Each agent may be written in a completely different programming language and no information is revealed about any of the participating software except that exchanged in the messages. Since what is exchanged is ASCII text, there is no commitment to software objects, much less to a particular language such as JAVA. This "least commitment" strategy was intended to facilitate the interoperation of independently-developed agent systems programmed in different languages: "foreign agents".

Agent tools emphasizing ACL communication typically provide essential functionality such as an ACL parser, an agent identity/address directory usually called an Agent NameServer (ANS), and direct message exchange through TCP/IP socket transport (as well as email and other possible transports). In such systems, agents communicate with each other by looking up an IP address on the ANS and making a connection with the desired agent.

We will not here address the complex and often argued{13},{14} merits of objects versus agents except to say that such agent systems are typically simpler than distributed object systems such as CORBA that provide for the transfer or virtual replication of complex objects. Typed-message software agents are generally presumed to be persistent executables that can receive text messages, and take the initiative in sending text messages, in a way analogous to humans exchanging email. The ANS of such systems can much simpler than say, a CORBA ORB{18}.

The KQML API (KAPI){4}, developed as part of the DARPA SHADE project [McGuire 93], [Kuokka 95], is one of the earliest tools of this type. Like many other agent wrapper tools, KAPI assumes KQML as the ACL. Agent identity is established by an ANS via HTTP. KAPI is written in C and works with agents developed in C or any language with a C interface. KAPI also provides a set of Lisp foreign function calls so that Lisp agents may be developed. (KAPI, though developed at Lockheed, should not be confused with the current Lockheed-developed API for KQML{10}.) KATS{5} is another tool of this kind for diverse platforms and supports various languages including C, Lisp and Java.

JAT[Frost 96] was the first agent development tool written in the Java language. Rather than simply providing agent wrapper libraries, JAT provided templates for newly developed Java agents. It also supported automatic loading of class libraries, with a mix of procedures and declarative information. However, JAT incorporated specific research theories that were not necessary in a general agent infrastructure and did not support Java applet agent communication. This provided the motivation for the design and development of JATLite.

Like previous KQML APIs, JATLite does not endow agents with specific capabilities beyond those needed for communication and interaction. In particular, JATLite does not, itself, facilitate construction of "intelligent agents" that seek information or automate human tasks, as discussed in the Artificial Intelligence community, nor does it enforce any specific agent coordination strategy. The issues of doing so are beyond the scope of this paper. JATLite does add basic infrastructure functionality over and above that of these systems: especially centralized message routing and buffering services.

2. Neglected Communication Requirements

Above the layer of standard Internet protocols,such as TCP/IP, agreement upon agent standards has been difficult. Other than the high-level coordination strategy of Contract Nets [Davis 83] and ACLs such as KQML or the FIPA ACL{9}, the lack of some essential standards has delayed the deployment and acceptance of typed-message agent systems.

Despite being a stated goal of the Multi-Agent System (MAS) community, after years of effort and many systems, there are few, if any, examples of independently-developed MASs working together. Examples of essential but neglected issues are standards for agent connection/registration, transport protocol, reliability, security and portable agent (e.g., applet) communication. Without even a standard for connection to a foreign ANS, it is no wonder that there is a dearth of interoperating agent systems. (Note: there are systems, such as our own ProcessLink [Petrie 99] and TIE-97{8} that use a common agent infrastructure, such as KAPI, and a common high-level model or theory to integrate otherwise independently developed software modules by converting them into a common agent system. This is not the same as independently-developed agents interoperating by virtue of common agent standards.) We note here that FIPA, being somewhat more industrial in its membership, agrees with this view and has developed designs to deal with connection issues in recent years.

In the following list we describe several basic capabilities that we feel are essential to support agent interaction.

3. The JATLite communication approach

Like popular C++ development environments for PCs, JATLite provides  front-end templates for communication with other agents -- sending/receiving messages, files, emails, etc. Developers use the templates to add software that defines agent reactions to received messages, without having to have a working knowledge of system programming or networking. Existing programs can be wrapped with JATLite code to allow them to communicate with other agents with minimum effort. Figure 1 illustrates the template and the wrapper concept in the JATLite infrastructure.


Figure 1: AMR infrastructure with Wrapped Legacy Code

An Agent Message Router and its protocols

The most important service of  JATLite  is the Agent Message Router (AMR) that allows agents to fail and recover, to migrate, and to be applet-based. A traditional ANS only provides the address of an agent upon request from another agent. Each agent is responsible for keeping track of the IP addresses of all other agents with which it corresponds. Message failure handling is likewise up to each agent, whether the failure is due to a changed IP address or simple failure of the intended recipient agent software. And finally, recovery of messages by a restarted agent is individually handled.

In contrast, the AMR buffers and forwards messages  like an email server. Each agent makes a single socket connection to the AMR - this is the only IP address each agent knows, in addition to its own. The AMR then forwards the message to the correct IP address for the recipient. If the recipient agent is not connected (there is no active socket connection), the message is delivered to the agent when it does connect again. The messages are saved on the AMR until the recipient agent sends a delete signal. This simple idea eliminates lost messages due to temporary agent failure, the necessity for agents to track IP addresses, and the restriction on applet communications, as there now need be only an AMR on the server that spawned the applet in order for it to exchange messages with any other agent connected to the AMR. A similar store-and-forward paradigm was previously used in April [McCabe 95]: a process exchange system that could support mobile agents. However, unlike JATLite, this system required a mechanism to have been previously installed on each participating host (as is necessary with all multi-hop mobile agent systems) and was not a complete agent infrastructure.

It is perhaps worth noting that email could be used to the same effect, instead of using persistent socket connections. In fact, JATLite has built-in support for SMTP and FTP. However, the disadvantage of email is that each agent must have its own email address. Because this is a system installation issue, it restricts the ability of agents to be moved from one machine to another. In the case of applets, they would need to have access to an email server on the host to which they were downloaded, thus requiring some special installation procedure. In the case of non-applet agents, a special email address would have to be installed on each host. In some cases of firewalls that prohibit socket connections, applets may not be allowed, and email may be the only reliable transport mechanism for non-applet agents, thus restricting Internet functionality, as firewalls do.

With one exception, JATLite message security depends upon the current open standards on encryption and authentication. The one simple feature that JATLite adds is the idea of a password associated with the agent name. This is necessary as the AMR allows agents to change IP addresses. When an agent disconnects, or timeouts, from the AMR, it may reconnect from a different IP address than originally registered. To prevent agent "spoofing", it is then necessary for the agent to provide a password, from the original registration, to prove its identity. This is not sufficient for business applications and more sophisticated encrypted passwords, and possibly KERBEROS and Secure Sockets Layer (SSL) mechanisms may be added to JATLite in the future.

No tool can establish a consensus where one does not exist, except by being so useful as to be ubiquitous, but JATLite has made every effort to make its registration/ connection commitments at least clear. In particular, JATLite uses KQML performatives for registration and connection( i.e., REGISTER/ UNREGISTER for registration, RECONNECT/ DISCONNECT for connection and IDENTIFY/ WHOIAM authentication described below). Some of these notions, in particular REGISTER, can be found in both the latest KQML and FIPA specifications. However, the distinction between registration and connection, and reconnection, depends upon having AMR-like functionality and so is not in these specifications.

Figure 2 shows the sequence of message exchanges for an agent registration. An agent that wants to register needs to initiate a connection to the AMR and send a REGISTER message with its name and password. If there is a registered agent with the same name, the request is denied and the ERROR message is sent.

Otherwise, the AMR sends an IDENTIFY message to the agent. Then, the agent needs to introduce itself using the WHOIAM performative that includes the agent's address, description, email address (optional), etc. (see the WHOIAM performative listed in the Appendix). Upon successful registration, the AMR sends a REGISTER-ACCEPTED message back to the agent. To unregister, an agent sends the UNREGISTER performative with its password. If the password is incorrect, unregistration will be denied. Once registered, the agent can connect to the AMR by sending a RECONNECT message with its password and address. If the address is different from the previous address, the AMR replaces the address information. If a connection from the same agent is still alive, the connection will be disconnected and a new connection will be established (footnote : A  loss of connection is detected only when a message needs to be sent to the connection. Once detected, the connection is closed by the AMR). An agent can intentionally disconnect from the AMR by sending a DISCONNECT message.
 
 


Figure 2: Connection Protocol Diagram

AMR functions

The AMR is based on the message store and forward paradigm. Though well-known, store and forward has not been previously used for a complete typed-message agent architecture. As SMTP and POP servers are used to process email messages, the AMR is used to process KQML messages. An agent can connect/disconnect/reconnect to the AMR and retrieve buffered messages just as one retrieves emails from a POP server. The AMR functions are described as follows:

Message buffering:
A message sent to the AMR is buffered to a file system so that there is little chance of losing messages even if an agent is migratory or crashed. Using the AMR, an agent can recover the possibly lost messages while it was disconnected from the Internet. An agent thereby has the flexibility to control its process and to coordinate outgoing messages. For instance, if an agent expects to take a long time to process a message, the agent may not want to accumulate messages in its own memory. The agent can disconnect from the AMR at will and the AMR buffers the received messages while the agent is disconnected. Whenever the agent reconnects to AMR, AMR will send the buffered messages to the agent. The buffered messages will be deleted from the file system only by a request of the recipient agent. Also, the agent can always send a message to other agents, regardless of the receiver's connectivity, just as one can send email to someone without knowing if they are currently connected.

Agent Name Service:
Agent Name Service is supported by default. An agent can register to AMR with its name, Internet address and description field. The agent's address as well as its description do not need to be statically defined and can be changed whenever the agent reconnects to the AMR. The AMR traces changing addresses and possibly varying descriptions for registered agents. Simply, each agent can ask about another agent's address using the REQUEST-ADDRESS performative. The AMR responds with the AGENT-ADDRESS performative that includes requested agent's Internet address and description field. The agent description fields in the WHOIAM performative described below may be used for diverse coordination strategies. Thus, the AMR can function as a simple ANS if desired.

Message Forwarding: The AMR uses the value of the KQML :receiver to route the message to the receiving agent, rather than a forwarding special performative. If the receiver is currently connected to the AMR, the AMR sends the message. If the receiver has ability to accept socket connections (e.g., stand-alone applications), the AMR tries to send the message to the receiver by initiating a connection, several times until the connection is established. If the receiver is intentionally disconnected or the AMR can not initiate a connection (e.g., an applet agent connection), the AMR buffers the messages  to be sent when the receiver is connected.

Java Applet Agent Communication:
As previously noted, as long as there is an AMR installed on the same server as spawned a Java applet agent, that agent can use the AMR forwarding mechanism to exchange messages with any other registered agent. This scheme violates no browser security mechanism and requires no special setup on the part of the user. The user can simply click on the URL for the agent applet, download it, connect to the AMR if that is not done automatically by the applet, read the outstanding messages, and respond to them or send new ones as is appropriate.

Maintenance of state:
Saved messages represent part of the state of the distributed computation. Thus, the AMR allows automatic state-saving to a degree. This allows the state to follow a migrating agent, which might be either an applet, or application software that is executed on different machines at different times. For instance, a mechanical engineer may want to run the same thermal analysis program on different computers at different times. By wrapping this software with JATLite-based code, this program can be used with the same identity at different times on different computers playing a consistent role with other analysis and simulation programs in the iterative design of an artifact.

File Transfer and Email:
As well as KQML message passing, AMR supports standard FTP and SMTP for both stand-alone and applet agents. Using built-in the FTP protocol support, an agent can save/retrieve a large amount of data to/from FTP server elsewhere in the Internet. SMTP protocol support makes it possible for the agent to send data, including KQML messages, to any SMTP server. For both cases, for Java applets, the AMR takes the role of a proxy to create a connector that links  the applet and FTP/SMTP servers without caching the data to the AMR.

Administrative protocols:
The AMR provides password service for each registered agent. Each agent needs to register with a password and the password is checked whenever the agent reconnects to AMR. The password service is independent from Java language specific security mechanism so that an agent implemented by other languages can utilize the service.

In addition to the password service,  the AMR implements non-standard KQML administrative protocols, suggested as a grassroots effort by CDR, in 1997{22}. Connect/register protocols of KQML has been discussed in the KQML-ADMIN-MSGS mailing list{2}. Although the protocols are results of open email discussion, they are still under a discussion and need further refinement and consensus from KQML agent communities.

We note here that the standards for administrative protocols for agents is still open. Progress in the KQML community has been slow while FIPA has placed much more emphasis on this topic and has more complete specifications in place{9}. However, none of these standards is yet driven by "killer app". One new contender is Sun's JiniTM{23} that includes registration and connection protocols for low-level device services with two significant advantages. One is that the protocols are implemented as extensible Java classes. The other is that there is an immediate ubiquitous application for the protocol. JiniTM may well supersede other agent administrative and low-level connection protocols in the near future.


4. JATLite architecture and specifications

4.1 Capabilities

JATLite is a collection of objects and class libraries developed in Java programming language. JATLite exploits the object-oriented nature of Java to allow programmers to extend classes, building atop the basic template and specializing it for their own purposes, or omitting Java classes as desired. The features of JATLite can be summarized as follows:

4.2 Architecture

The JATLite architecture is organized as a hierarchy of increasingly specialized layers, so that developers can select the appropriate layer from which to start building their systems. Thus, a developer who wants to utilize TCP/IP communications but does not want to use KQML can use only the Abstract and Base layers as described below. Figure 3 shows JATLite layers and user accessibility.


Figure 3: JATLite layered architecture


The reader may wonder at the rationale for this particular layering. For instance, why isn't the KQML layer on top of the router to facilitate the use of other languages? First, there were no good alternative ACLs when JATLite was first designed. Second, because all other systems used an agent-to-agent direct connection technique, we made the router optional, which meant that it should be a higher language. In short, at design time, KQML seemed more basic than the routing functions. A more technical reason has been the lack of administrative protocol consensus - this is different for KQML and FIPA and other implementations, yet should be in the router layer, so it is more difficult than it first appears to make a router layer that would interoperate among different ACLs and agent management systems.

It also may seem unintuitive that the protocol layer is on top. But the protocol layer needs to use the router as a proxy for applet agents. FTP, SMTP and other Internet protocols would need to open a socket to a host other than the host from which the applet was downloaded. But security restrictions on applets generally restrict such connections, so the router needs to be used as a proxy. Therefore this layer contains the agent-side code that uses router functions.

5. Assumptions and limitations

5.1 Platform requirements

JATLite can run on any platform that supports the Java development kit JDK 1.1x from Sun Microsystems Inc., including Windows95, Windows NT, Solaris, Mac OS8. Modifications may be needed for other Java environments but it should be compatible with any Java 1.1 implementation, such as the GNU free software KAFFE{24}. Applet agents can be run using a WWW browser such as Netscape or Internet Explorer, or Sun's applet viewer, again, compatible with Java 1.1.

5.2 Transport

JATLite assumes TCP/IP as underlying transport but additionally it uses a message delimiter, the default being the KAPI \04 character. This special escape character, \04, can only be used when declared to be a string. Any other ASCII character can be used within the message. For instance, a new line character that is a message delimiter for numerous Internet protocols such as FTP or SMTP can be a part of a JATLite agent message. JATLite does not support any transport mechanism without a specified message delimiter, such as those that use a message length indicator in the message header, instead of a terminating character.

JATLite makes no guarantee about message order. The AMR will distribute messages in the same order it receives them. But it does not inspect timing stamps to determine if one agent actually sent a message before another. There is no notion of a distributed synchronized clock.

Allowable maximum message size is another transport issue. An ability to respond to a message the size of which is longer than the agent's expectation, as is done for standard Internet protocol servers, may be an important function for an agent. This is especially important for a foreign agent connection, where each agent does not know other agents' transport mechanisms. JATLite allows an agent to set an expected maximum message size for each connection to the other agents.

5.3 Scaling

As with any Internet server, the AMR's average message processing time may restrict the speed of the distributed computation. JATLite is designed for applications in which agents typically perform significant computation between messages. If the AMR's average message processing time exceeds the average latency between agent messages, the system will bog down as messages are increasingly accumulated on the AMR socket buffer. So far, the performance of our own agent systems is more like that of an email system so that the server is not overrun. However, it is easy to anticipate systems of many small quickly responding agents that would overrun a server of any given speed.

Some systems, such as JAFMAS{7}, do away completely with the notion of any central facilitation by a method of message multicasting. However, this scheme sacrifices some of the robustness of the AMR that allows agents to fail and then recover. Our preferred method for dealing with the scaling issue is to add the ability to connect multiple AMRs in a hierarchical network, much the same as Internet domains.

5.4 Single point failure

Since all messages are assumed to be processed through an AMR, the JATLite architecture  inherits the chief disadvantage of any server application: single point failure of the AMR results in communication blocking for all the registered agents to the AMR. The AMR is subject to failure of a file system as well as networking malfunction. However, we believe that diverse, well-proven server technologies can be applied to the AMR for robust operation and recovery. JATLite does not have any assumptions that restrict such technologies from being adopted for the AMR.

A related issue is control over message delivery. Whenever an agent connects (or reconnects), the AMR delivers all messages not previously deleted by that agent. We assume all agents will be able to buffer their incoming messages and decide, independently of the AMR, which to read in what order. All of our agent applets written in native JATLite code have such queues.

5.5 Compatibility

By design, JATLite is compatible with the older KAPI system. The JATLite distribution includes a KAPI release with patches to allow use with a JATLite AMR. We routinely use KAPI agents.

The newer FIPA system is more problematic for JATLite. The router layer depends upon KQML ACL constructs, and so would have to be rewritten for the FIPA ACL. It may be that a better approach would be to redesign JATLite to allow greater flexibility at the router layer. However, anyone can use any part of the exiting code freely, and certainly the principles of the AMR may be used in any future infrastructures.

FIPA also defines an Agent Management System (AMS) with several functions, most of which are included in the router layer already. Although FIPA specifications refer to these functions as being done by different agents, there seems to be no object to their being done by a single agent. Finally, current FIPA specifications simply do not address the buffering of messages, so this is not in fundamental conflict with the AMR. Future specifications may however. Current implementations, such as JADE[Bellifernine et al 99] do not seem to provide such AMR-like buffering. A new version of the April system called ICM{25}, was announced in 1999 and is intended to be used as a basis for a FIPA-compliant AMS with message buffering and support for intermittent agents, like JATLite.

The most serious point of incompatibility between FIPA and JATLite seems to be on the point of mobility. There is no direct conflict, but JATLite provides functionality requiring protocol messages not in the FIPA specification. In particular, FIPA seems to assume that if an agent changes an IP address, then it is a so-called "mobile agent" and FIPA handles this by requiring that such agents always have a home system that can relay messages to the migrating agent. This is also the case for the ICM system - names of agents must include a "home" host name.

JATLite does not presume that any agent is mobile or not, much less whether it has a preferred home address. Rather it allows any agent to dynamically change its IP address, regardless of whether it was moved manually by a user or by a sophisticated mobile agent system. This is accomplished via the CONNECT messages. As the FIPA specifications currently read, such messages could not reflect a general functionality. A JATLite system using the AMR functions would have to be treated as a foreign federation with a single IP address for each agent corresponding to the IP address of the AMR.

6. Application experiences

The Java Agent Template [Frost 96] and JATLite grew out of experiences with several agent-based engineering systems starting with PACT [Cutkosky et al 93], an early attempt to integrate heterogeneous engineering agents using a common communication language and protocol, and continuing with NextLink [Petrie 95] and ProcessLink [Petrie 99]. The NextLink system was based on the SHADE KAPI package and revealed several shortcomings of this approach. One was that the Lisp version of KAPI had never been tested over long-distances. We encountered subtle timing problems when we ran one of our agents from Europe that required substantial debugging and patching at CDR with the help of the original Lockheed developers. The current JATLite package includes an improved robust version of KAPI plus patches that allow it to work with the AMR.

More important, we ran into two serious problems. One was that we were using engineering programs for design problems that had durations ranging from hours to days. A design engineer frequently needed to shut down a particular engineering agent and return the next day to continue the design. However, this meant that other agents might be sending messages that would be lost and the distributed design computation would become confused. In addition, some of the complex analysis programs would simply crash from time-to-time, with the same result. If we were serious about Agent-Based Engineering, then we had to have an agent system that support agents that came and went over a long period of time.

The other serious problem occurred when we tried to take advantage of Java applets. The original JAT was fine for stand-alone Java programs but required then that all agents be running on the applet server. This restriction negated many of the advantages of the agent paradigm. After investigation, we found that none of the existing agent infrastructures would solve these problems and we were forced to develop the agent message router for JATLite.

The JATLite AMR has been successful in solving both of these problems. The Java Applets have been downloaded from Germany and demonstrated in a distributed engineering computation to communicate with the router at Stanford robustly with negligible latency. Our current version of JATLite has been extensively tested and refined over a period of three years and seems to be as reliable as the platform on which it runs. In our case, this has been a Sun SPARC running Solaris and the only failures have been when the SPARC was rebooted and the AMR had to be restarted. Even though new connections and messages were blocked, no messages were lost because they were saved on the file system.

6.1 ProcessLink: an example application

ProcessLink {17} is technology for computer-aided coordination of engineering teams working over the Internet. ProcessLink provides automated tracking of constraints, goals, conflicts and dependencies among team members. The team members interact through engineering tools (e.g., a CAD program) that have been wrapped with JATLite to send and receive messages automatically. Engineers may also use JATLite applets that support project planning [Petrie 99] and coordination. All of these user-driven agents interact with a special coordination agent, Redux [Petrie 95], that coordinates the engineering design via a simple ubiquitous model of design based upon depth-first search and backtracking.


Figure 4: Example of Redux Applet

An example of one the applets we are using is shown in Figure 4. This is a generic applet designed for agent system development. It is capable of displaying the design as a Redux goal and decision graph, answering various queries about the state of the design, and changing the design. Agent messages are produced either automatically or by hand: one option allows the user to type agent messages character by character for debugging purposes. The applet also allows the user to run scripts of predefined messages for testing. Other applets are specialized for constraint management, project management, and special design functions as desired.


Figure 5: PENS-Redux Architecture

The usual agents are applets, stand-alone Java agents, and engineering software converted into agents via wrapping with both KAPI and JATLite code. In addition to these, we have tested the AMR with an electronic engineering notebook program. We have found it useful to take an HTML authoring system for design documentation, PENS{16}, and alter it so that the user can add structure to the text. This structure is created by highlighting text and clicking on icons. This results in embedded XML-like tags in the text. When the text is posted, a proxy agent parses the text and then sends out corresponding agent messages as if they had come from one of the existing registered agents, as shown in Figure 5.

Although this is a form of "spoofing", the authentication comes from the HTML authoring system and the results are very useful. Users can create and send agent messages as a by-product of documenting their designs. The AMR treats these messages like any other and passes them on to Redux that then generates messages to be sent to other agents based upon its coordination model.


Figure 6: ProcessLink Architecture

Figure 6 shows the overall ProcessLink architecture with an example set of domain-specific agents using the generic agents as project management and design resources with JATLite as the agent substrate. Any of these agents may be applets and any may disconnect and reconnect later from a different IP address.I

In addition to the requirement for reconnection, our computation is a joint one that depends strongly on no loss of messages. If one agent fails to recieve a message from another that a particular design change has occured, the first may try to make further inappropriate design decisions. The Redux coordination agent will prevent anything inconsistent from occuring and will inform an agent why some change to the design cannot be accomodated, but this will be inefficient at best and may result in a poor design at worst. In constrast, some multi-agent systems work individually but gain synergy from collaboration. In such systems, the loss of messages is not as disturbing as it tends to affect local rather than global efficiency since there are no global constraints over the indivdiual agent objectives.

Our application domain is not a real-time one The engineering software and people that constitute the thinking part of the agents typically have a reaction time of minutes to hours. Messages have delay times of fewer than two (2) seconds. The only latency experienced by the users occurs with Java applets themselves when the local host has too few resources to run them quickly. When considering the application requirements, an important issue is whether the agents require significant "think time" or are simpler fast acting reflex-driven agents. JATLite is suitable for the former type of systems.

Related to throughput is the issue is the number of agents. In our application environment, there are typically fewer than ten (10) agents contributing to the engineering project. In a system with a significantly greater number of agents, typically ones each doing a relatively small amount of processing, one central AMR would be a bottleneck. We suggest that a federation of AMRs, such as described by the FIPA specifications or that of existing email servers, will be sufficient. But all we can claim now is that the AMR is not a bottleneck for a relatively small group of agents with large processing times that is characteristic of some large class of agent systems, especially in engineering domains.

Our Agent-Based Engineering work has included various "agentified" engineering sofware modules, such as Finite Element Analysis (FEA)[Dabke 94] and various CAD tools[Mori 98]. We have also interfaced with various ontological tools from the Sanford Knowledge Systems lab[Ozawa 98]. All of these agent systems were done using JAT or JATLite. All consisted of simple engineering software with no internal agent architecture. The agents were created by adding agent message passing softwre to existing engineering tools or software modules created elsewhere. Some analysis of the software operation was necessary in order to characterize design decisions. These were then automatically parsed into the appropriate agent messages at runtime.

The strategy of placing the agent communications management in one AMR rather than distributed in more complex agents strongly facilitated the agent-based integration of these software systems. The developers did not have developsoftware for each agent as complicated as would have been necessary were each agent responsible for maintaining its cache of other agent addresses and tracking the success and/or failure of messages, or incorporating a scheme that was failure-tolerant.

We have not yet found another agent infrastructure that would provide the functionality we require for such engineering applications. Even the new FIPA specifications lack the required functionality and the compliant implementations so far do not include the message buffering and connect/reconnect functions.

6.2 Debugging

We note that debugging is an interesting topic for agent systems. There are at least three levels of debugging.

Each level of debugging can be done on each machine where the agent is running and watching or logging messages in response to a known good stimulus message. We have found that the AMR mechanism itself facilitates such debugging as it buffers the messages. If we are testing one agent, there is no need to repeatedly run the other agents involved in the distributed computation. Once the others have sent their messages via the AMR, the AMR will resend their messages each time the agent being tested reconnects. The same scenario can be replayed indefinitely without the necessity of participation by the other agents and the possiblity of slightly different messages being sent.

The AMR also simplified debugging simply because the agent communication management services were centralized and did not have to be tested on every agent. (Likewise, there was no coordination scheme implemented for each agent that had to be tested as we used a centralized coordinator.) Instead, we could rely upon the AMR for IP address caching and message buffering.

It is important to note that with such centralized communications support, agent development is largely a matter of message agreement. As those of us involved in the project change our agents, we only post changes to the messages to others. We do this by changing the formal description of the message on a web page and publishing the notice of the change and the URL via email (see examples at the Redux protocol listing{17}.) Other agent developers change their parsers if needed. Usually, such a change is preceded by a long discussion among the affected parties. The process is simplified by the restriction that agents do not send code, such as methods, to each other, but only text messages. Other agent developers change their parsers if needed.

6.3 Other Applications

Several (unamed) companies have or are experimenting with JATLite for commercial applications ranging from distributed engineering to electronic commerce and telecommunications. Toshiba and NTT have conducted or are conducting extensive agent-based research at the CDR. Three other applications of JATLite may be useful to mention here as examples of the kinds of systems people are building and useful extensions they are developing.

Joerg Schreck of the German National Research Center for Information Technology is developing user security technology for agent-based Electronic Commerce applications. He has already developed Secure Socket Layer (SSL) message encryption for KAPI and is usuing this in conjunction with JATLite for produce a "mix" for KQML{28}. Description of a mix is outside the scope of this paper but this method is used in so-called "anonymous remailers" and "mixmaster" for the delivery of emails as described first by David L. Chaum [Chaum 81] and is a general tool which might be of importance for all applications which have to cater for anonymity/pseudonymity.

At the University of South Carolina, Professors Huhns and Stephens are using JATLite to teach classes on agent technology, in conjunction with JESS, which is the Java version of NASA's CLIPS rule system{29}. One application of this technology is for DARPA military heterogeneous database integration using ontologies and mediator agents for the semantic unification in order to answer queries that span the databases.

At the AI Lab of the Swiss Federal Institute of Technology (EPFL), Monique Calisti and students are building two kinds of JATLite aplications{30}. Some of the agents together form a Multi-Agent Intelligent Secretary (MAIS) for handling the personal agenda of every human user registered within MAIS, and for organizing meeting among users. Another application uses constraint satisfaction to route Telecom service demands that cross several network domains. This work is planned to include a FIPA ACL package for JATLite.

7. Related Systems

Some agent systems such as WARREN [Decker et al 97] provide agents that are individually intelligent enough, and incorporate a sufficiently robust coordination scheme, that individual agents can fail and not interrupt the distributed computation. The essential difference is that JATLite does not require this level of intelligence from the individual agents. It is thus more suitable for the integration of legacy software tools, especially relatively simple-minded engineering software packages such as Finite Element Analysis (FEA)[Dabke 94] and various CAD tools[Mori 98] done successfully with JATLite.

Some more recent tools focus on the coordination mechanism. Magenta implements a coordination technology - Anonymous Agent Interaction[Genesereth 95]. With the proposed federation architecture, an agent can dynamically connect/disconnect to feed its capabilities and requirements, represented by a shared common ontology, to a facilitator that takes charge of diverse coordination functions such as query manipulation for agent connectivity, request broker, content based routing, problem decomposition, translation of local agent languages to the shared common ontology, monitoring of updated knowledge and notification of changes. The shared common ontologies are based on the knowledge interchange format(KIF){19}. The logic predicate "handles" is used for the declaration of an agent's capability, and "interested" defines an agent's need. Thus, each agent does not need to know details about coordination processes performed by the facilitator, nor even the other agents' names in the federation. Instead, each agent uses the ontology for query and notification. Though the federation architecture is similar to JATLite, JATLite focuses more on basic communication services. Both systems are similar in that they make provision for the persistence of some objects in case of agent failure. But Magenta does this by providing functions that may be used by an individual agent to save to a file or database, while JATLite builds in message recovery with the AMR.

The COOL Agent Development Shell [Barbuceanu 95] facilitates designing and simulating protocols and acquiring cooperation knowledge by providing a domain independent, high level coordination language - COOrdination Language. The coordination is governed by structured "conversations" that define agent activities based on rules. The basic concepts are similar to production system rules where the premises of a rule define finite state information and conclusions are executable rules if the premises are valid. Therefore, COOL agents should agree with planned sequences of activities, the existence and control structures of which are all enumerated and programmed for execution. Furthermore, for errors during execution such as message delays, message shuffling, lost messages, etc., "error recovery rules" need to be defined with several different strategies such as discarding inputs, changing the state of the conversation, initiating clarification conversations with the interlocutor or just reporting an error. As with Magneta, individual agents are programmed to handle error recovery.

The KAoS{27} agent development architecture similarly focuses on facilitating the development of agent conversations. Neither COOL nor KAoS have anything similar to JATLite's registration and reconnection schemes with agent names and passwords, much less the message buffering of the router. KAoS is notable though as an example of a CORBA-based system, with that standard object directory service.

There have been attempts to integrate KQML with agent mobility. TKQML[Cost et al 97] is an integration of the highly portable script language Tcl with KQML, attempting to bridge the gaps between low level mobile agent communication and sufficiently flexible support for a higher level language, e.g. KQML. As a commercial version, Afterburner{3}, provides a set of Java libraries for communication based on KQML including an ANS as well as basic agent mobility functions. This is distinct, however, from JATLite's notion of agent migration.

JAFMAS{7} is a newer Java-based system that does not depend upon any centralized server. It, therefore, does not include any centralized message communication services such as those of JATLite. There is no buffering of messages. It is intended to be more robust and scalable because it is distributed, but networks of centralized servers have shown to be very robust and scalable: e.g., email servers on the Internet. Further, JAFMAS does not include AMR-like support for message delivery failure.

Starting in 1997, FIPA has begun developing the specifications for an agent infrastructure and new ACL{9} similar to but distinct from KQML, and using the CORBA protocol for inter-ORB communication for foreign agent systems communications. There are now some implementations such as JADE. A more detailed comparison with FIPA will be found below, but it is sufficient to say here that while JATLite is not in theory inconsistent with the FIPA specifications, it may require significant implementation work to reach compliance, such as providing CORBA IIOP transport between AMRs. It is also the case that FIPA specifications do not address the novel message routing and buffering services, and resultant functionality, of JATLite.

FIPA has however treated administrative functions, including agent registration and other administrative functions as high-level objects on a par with other language primitives. In addition, there is some movement in this direction in the KQML community. JACKAL is a relatively new Java-based system only published in workshop working notes[Cost et al 98] but seems to include a new agent naming scheme: KNS{26}. This design emphasizes the distributed name management of agents across different agent directories. It differs from the JATLite scheme of identification by password as well as name. The KNS, like most other directory schemes, including that of FIPA, makes changing the IP address of an agent require an update protocol. In JATLite, the current IP address of agent is simply noted whenever the agent reconnects to get its messages so there is no need for such an address update protocol.

8. Status and future work

8.1 Current status

As of December 1998, we have made JATLite open source free software under the GNU General Public License. The currently released Beta version of JATLite is available from (http://java.stanford.edu/). To obtain the software, users fill out a form giving their name, address, email address, and affiliation. Over 2000 researchers from around the world have downloaded the current version of JATLite and it is being used or evaluated for creating agent interfaces for a variety of fields including research, education, military and commerce. We encourage users to send technical questions and comments to jat-develop@cdr.stanford.edu. A look at the archive of these messages ( http://cdr.stanford.edu/ABE/java_agent_template/hm/) reveals a high level of experimentation. There is also jatlite-users@list.stanford.edu forum for users. Most recently, a JATLitBean (a JavaBean) was announced for JATLite{31}.

We have also developed a C++ JATLite-compatible agent template for Windows95 and Window NT platforms. The C++ versions is easier to connect to commercial software written in C and C++ than the native Java version of JATLite. However, this version has not been publicly released because we cannot afford to support it.

8.2 Ongoing developments

Our long term goals are to continue to refine JATLite and to use it as a substrate for agent-based applications in engineering and business. As for robust communication support, we are currently investigating several issues for further refinement together with industrial partners.

Foreign agent communication:
JATLite implements registration and connection performatives that are outside of the current KQML draft but were first proposed at the Agent Society meeting on standards in 1997{6}. These performatives were publicly discussed in the KQML-ADMIN-MSGS mailing list but have not yet been added to the either the most current KQML draft specification or the FIPA standards. We believe them to be useful and perhaps similar standards will be used as JATLite is increasingly used for typed-message agent applications. We also hope the JATLite protocol for connecting to an ANS/AMR will become standard. At the very least, we have clearly published features and JATLite is a testbed for experimentation with options until a consensus is established in the agent community.

Secure communication:
As a first cut, JATLite supports authentication by agent name and password service. Advanced security issues such as message encryption or protecting integrity are important for practical purposes and those will be investigated in the future.

Router-to-Router communication:
Even though the AMR makes no assumption restricting router-to-router communication with hierarchical AMRs, it is not currently implemented. JATLite will provide a standard way of forwarding messages to the agents those are not registered to the domain router in a future version, possibly using the JiniTM protocols. The preferable method at this point though, is to use the FIPA AMS design and achieve interoperability with FIPA systems if the specifications become fixed.

The future direction of JATLite development consistently focuses on lightweight, but robust and secure agent communication. We intend to continue to address the issues of standardization, security, and scaling.

9. Summary

A variety of software tools has been developed to facilitate typed-message agent construction but JATLite is the first agent toolkit to implement a store and forward AMR that addresses the issues of robust message delivery and migrating agents, especially Java applets, while offloading message delivery and connection functions from individual agents. In particular, by using the JATLite AMR, individual agents do not need to ask/cache/update the addresses of other agents in order to communicate with them. Individual agents may crash or deliberately disconnect from the distributed computation without losing any messages. Applet agents may freely communicate with other agents, regardless of the WWW browser security restrictions.

There are three points that characterize the novel aspects of the JATLite approach to providing a robust standard agent infrastructure.

First, our thesis is that administrative functions should be in the agent language: performatives in KQML. A frequent alternative argument in the KQML community is that one could do all this with existing performatives such as "Ask" and "Tell", pushing the administrative functons down into the content language. But content language varies from application to application. The point of having a standard outer language like KQML is to have a single standard for standard functions. Administrative functions like registration, connnection, and agent identification are such important standard functions. (We do not claim that our performatives are the only solution but merely that they are some of the first and were only put forth as suggestion initially. When a call for discussion failed to generate much, we went ahead and implemented the particular ones described above.)

At the risk of diluting the point that administrative functions belong in the standard agent language, we also note that there must be very low-level standards such as TCP/IP codes for connecting to an ANS or AMR, and termination codes. But this is also a specific case of the more general issue of the need for administrative function standards.

Second, and perhaps most important, providing for the buffering of messages is a viable solution to the problems of robust message delivery in the face of uncertain and shifting standalone and Java applet agents. Message buffering also facilitates the construction of agents because each agent need not manage failed communications and the addresses of other agents. A side benefit is improved debugging: once they have sent their messages, other agents may be taken off-line and the problematic agent run again and again with their messages stored by the AMR. Message buffering runs against a long "tradition" in the agent community of having each agent make a direct connection to each other agent. Our experience with JATLite to date shows that message buffering is useful.

Third, message buffering makes possible a novel concept of agent identity. Rather than identify an agent by a name and IP address, we use a name and password. That (together with the timestamping of agent names in JATLite) provides a simple method for unique agent naming that allows the agents to move between hosts at will.

This means that there is no necessity for any IP address updating dialogue between the agent and the AMR. It also means that JATLite may agnostic on the subject of mobile agents. Any agent may move and JATLite does not care how it moves; either by human intervention or migration on pre-installed docking mechanisms, of any kind. This also shows that there is a logical distinction between inital registration and connection/reconnection.

Again, while the JATLite primitives are only one design, the principles of having the administrative functions in the language, providing message buffering, and a password-based agent identity that allows disconnecting and reconnecting from different hosts are principles that other system designers may either use directly or as touchstones in designing better alternatives.

Acknowledgments

Stanford Center for Design Research work was funded by Navy contract SHARE N00014-92-J-1833 under the US DARPA RaDEO program. Andreas Raquet wrote the current ProcessLink applets and a new KQML parser for JATLite as well as working with a number of other people at the CDR on development of JATLite. Theresa Webster made the patches on the original NextLink system and Vikash Marda wrote the new administrative applet.

URL References

{1} http://www.agentbuilder.com/AgentTools/

{2} http://www.cs.umbc.edu/kqml/mail/kqml-admin-msgs/1997/

{3} http://riz.saic.com/AIT/agentref.html/saafbck.html

{4} http://www-ksl.stanford.edu/knowledge-sharing/papers/shade-overview.html

{5} http://www.cs.umbc.edu/kqml/software/kats/kqml-sdd_ToC.html

{6} http://www.agent.org/society/meetings/workshop9702/index.html

{7} http://www.ececs.uc.edu/~abaker/JAFMAS/

{8} http://www.ai.sri.com/~wilkins/mpa/tie-97.html

{9} http://www.fipa.org/

{10} http://www.paoli.atm.lmco.com/kqml/

{11}http://crystaliz.com/

{12} http://www.trl.ibm.co.jp/aglets/

{13} gryphon.elec.qmw.ac.uk/dai/atal/

{14} www.csee.umbc.edu/agentslist/archive/digests/v01.n184

{15} computer.org/internet/ic1997/w4toc.htm

{16} www.ncsa.uiuc.edu/SDG/IT94/Proceedings/Educ/hong/hong.html

{17} http://cdr.stanford.edu/ProcessLink

{18} http://www.omg.org/corba/beginners.html

{19} http://logic.stanford.edu/kif/kif.html

{20} http://www.cnet.com/Resources/Info/Glossary/Terms/sql.html

{21} http://www.nist.gov/sc4/www/stepdocs.htm

{22} http://www.agent.org/society/meetings/workshop9702/

{23} http://www.sun.com/jini/

{24} http://www.transvirtual.com/

{25} ftp://www.nar.fla.com/pub/documentation/icm/icmmanual.html

{26} http://jackal.cs.umbc.edu/KNS/

{27} http://ksi.cpsc.ucalgary.ca/KAW/KAW96/bradshaw/KAW.html

{28} http://www.KQMLmix.net

{29} http://cdr.stanford.edu/~petrie/jat/CoopIS99-paper.pdf

{30} http://iawww.epfl.ch/~calisti/intagents.html

{31} http://kmi.open.ac.uk/people/emanuela/JATLiteBean/

Bibliography

[Bellifernine et al 99] Bellifernine, F., Rimassa, G., and Poggi, A., "JADE - A FIPA-compliant Agent Framwork," Proc. of PAAM99, 1999.

[Barbuceanu 95] Barbuceanu, M., Fox M.S., "COOL: a language for describing coordination in multi-agent systems", Proc. of 1st Intnl. Conf. on Multiagent Systems. ICMAS-95, 1995, p. 17-24.

[Chaum 81] Chaum, David L., "Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms," Communications of the ACM, 24:2, 1981, pp. 84-88.

[Cost et al 97] Cost, R. S., et al., "Agent Development Support for Tcl", Proc. of 5th TCL/TK Workshop, 1997 p. 177-178.

[Cost et al 98], Cost, R. S., Rinin, T., Labrou, Y., Luan, X, Peng, Y., Soboroff, L., Mayfield, J., and Voughannanm, A., "Jackal: A Java-based Tool for Agent Development", Working Notes of the Worshop on Tools for Developing Agents, AAAI'98, WS-98-10, AAAI TR 73-82, AAAI Press, 1998.

[Cutkosky et al 93] Cutkosky, M., Engelmore, R., Fikes, R., Gruber, T., Genesereth, M., Mark, W., Tenenbaum J., and Weber, J., "PACT: An Experiment in Integrating Concurrent Engineering Systems," IEEE Computer, special issue on Computer Support for Concurrent Engineering, January 1993, pp. 28-37.

[Dabke 94] Dabke, P. "Developing a Finite Element Analysis Agent, " CDR Technical Report, available as
ftp://cdr.stanford.edu/pub/CDR/Publications/Reports/DevelopingFEAAgent.ps

[Davis 83] Davis, R., and Smith, R., "Negotiation as a Metaphor for Distributed Problem Solving,", AI Journal 1983, 20(1): 63-109.

[Decker et al 97] Decker, K., Sycara, K., Pannu, A., and Williamson, M., "Designing Behaviors for Information Agents," Proc. First Internat. Conf. on Autonomous Agents (AGENTS-97), Feb-97.
Also http://www.cs.cmu.edu/~softagents/papers/autoag96.ps.gz

[Frost 96] Frost, H. R., Cutkosky, M.R. , "Design for manufacturability via agent interaction", Paper No. 96-DETC/DFM-1302, Proceedings of the 1996 ASME Computers in Engineering Conference, Irvine, CA, August 18-22, 1996, pp. 1-8.
Also http://cdr.stanford.edu/ABE/pubs/Frost-Cutkosky.ps

[Genesereth and Ketchpel 94], Genesereth, M., and Ketchpel, S., "Software Agents"qq, Communications of the ACM, 37:7, July 1994.
See also http://logic.stanford.edu/papers/agents.ps

[Genesereth 95] Genesereth, M., Singh,N., and Syed, M., "A Distributed and Anonymous Knowledge Sharing Approach to Software Interoperation", Intnl. Journal OF Cooperative Information Systems, World Scientific, Dec. 1995, 4(4): 339-367.
See also http://logic.stanford.edu/software/magenta/.

[Haddadi 96] Haddadi, A., Communication and Cooperation in Agent-Systems: A Pragmatic Theory, Springer Verlag, Lecture Notes in Computer Science, No. 1056, 1996.

[Kuokka 95] Kuokka, D. and Harada, L., "A Communication Infrastructure for Concurrent Engineering," Journal of Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AIEDAM), 1995, 9.

[Labrou and Finin 97] Labrou,Y. and Finin,T., , "A Proposal for a new KQML Specification," U. of MaylandCS and EE Dept. TR CS-97-03, February 1997. Also http://www.cs.umbc.edu/kqml/.

[McCabe 95] McCabe, F. G., Clark, K. L., "April-Agent Process Interaction Language", Intelligent Agents, Lecture Notes in Artificial Intelligence, 890, Wooldridge, M. J. and Jennings, N. R., Eds., Springer-Verlag, 1995, pp. 324-340.
See also ftp://www.nar.fla.com/pub/papers/aprilsummary.html

[McGuire 93] J. McGuire, et al., "SHADE: Technology for Knowledge-Based Collaborative Engineering," Journal of Concurrent Engineering: Applications and Research (CERA), 1(2), September 1993.
Also available as http://www-ksl.stanford.edu/knowledge-sharing/papers/shade-cera.ps
. See also http://ksl-web.stanford.edu/knowledge-sharing/papers/shade-overview.html.

[Mori 98] Mori, T., and Cutkosky, M. R., "Agent-Based Collaborative Design of Parts in Assembly," Proc. DETC98 ASME, September, 1998.
Also available as http://cdr.stanford.edu/ProcessLink/papers/toshiba/MoriASME98.pdf

[Ozawa 98] Ozawa, T., Cutkosky, M. R., and Iwasaki, Y., "MultiDispciplinary Early Performance Evaluation via Logical Description of Mechanisms: DVD PickUp Head Example," Proc. DETC98 ASME, September, 1998.
Also available as http://cdr.stanford.edu/ProcessLink/papers/toshiba/OzawaASME98.pdf

[Petrie 95] Petrie, C., Webster, T., and Cutkosky, M. R., "Using Pareto Optimality to Coordinate Distributed Agents" Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AIEDAM), 1995, 9: 269-281.
Also available as http://cdr.stanford.edu/ProcessLink/papers/pareto.html.

[Petrie 96] C. Petrie, "Agent-based engineering, the Web, and intelligence" , IEEE EXPERT, Dec. 1996, 11(6): 24-29. Also available as http://cdr.stanford.edu/NextLink/Expert.html.

[Petrie 99] C. Petrie, S. Goldmann, and A. Raquet, "Agent-Based Project Management", to be published, Springer Verlag, LNAI 1500, 1999.
Partially appears as "Agent-Based Process Management", Proc. Intelligent Agents in CSCW, Deutsche Telkom, Dortmound, Sept. 1998, p. 1-17.
See also http://cdr.stanford.edu/ProcessLink/papers/DPM/dpm.html

[Singh 98] Singh, M., "Agent Communication Languages: Rethinking the Principles", Computer, 13(12), Dec. 1998. Abstract at http://computer.org/computer/co1998/rz040abs.htm

[Thirunavukkarasu 95] Thirunavukkarasu, C., Finin, T., and Mayfield, J., "Secret Agents - A Security Architecture for the KQML Agent Communication Language", Proc. CIKM-95 Intelligent Information Agent Workshop, Blatimore, Dec. 1995.
 

Appendix: AMR Protocols and Performatives

TCP Connection Protocol:

Connection certification: The lowest level of connection uses a simple connection certification from the router. By accepting a socket connection request from the agent, the router will send this message to the agent.
example:
Router : 201 AMR Router
or
Router : 500 Internal error
if error.

Connection Performatives:

RECONNECT-AGENT: The registered agent can use reconnect-agent to reconnect to the agent
sender : agent
receiver : Router
password : xxxxxxxx
host : java.sun.com
port : 1234
The host/port is optional. If the agent sends the host/port, the Router checks whether those are different from the most recent one. If different, the Router will update the host/port. This assumes that the agent address can be changed at any time. If your system does not want to check the password, the password slot can be omitted.
example:
(reconnect-agent :sender agent :receiver Router :password xxxxxxxx :host uuu.abc.com :port 4321)

DISCONNECT : disconnect connection
sender : AgentName
receiver : Router
example:
(disconnect :sender me :receiver Router)

REGISTER : Register to the Router
This is a special use of the current draft KQML specification for this performative when sent to an AMR.
sender : AgentName
receiver : Router
password : xxxxxxxx
example:
(Register :sender me :receiver Router :password xxxxxxxx)

IDENTIFY : The Router will ask about the identity of the agent, which wants to register
sender : Router
receiver : agent
example:
(identify :sender Router :receiving agent)

WHOIAM : The agent will introduce itself as a response to an IDENTIFY request.
sender : AgentName
receiver : Router
message-method : The message-method, which is understandable to the Router
KQML-extensions : Tags for non-standard, extended KQML performatives
Contact-information : The agent contact information. This includes host name, and port email address(optional)
Description : The agent description, which may be advertising
example:
(whoiam :sender me :receiver Router :message-method MessageRouter :content (contact-information :host cdr.stanford.edu :port 1234 :email jhc@cdr.stanford.edu)
:KQML-extensions http://java.sun.com/newProtocol :description (advertise :type DesignAgent))

UNREGISTER : unregister from the Router
sender : AgentName
receiver : Router
password : xxxxxxxx example:
(unregister :sender me :receiver Router :password xxxxxxxx)

LIST-AGENT : request current on-line user list to the Router
sender : AgentName
receiver : Router
example:
(list-users :sender me :receiver Router)

REGISTERED-AGENT : Reply from the Router to LIST-AGENT
sender : Router
receiver : AgentName
content : list of the registered agents
example:
(users-agent :sender Router :receiver me :content ((he java.sun.com connected) (she aaa.bbb.com disconnected)))

REQUEST-ADDRESS : Request the agent address to the Router
sender : AgentName
receiver : Router
content : Other agent name
example:
(request-address :sender me :receiver Router :content him)

AGENT-ADDRESS : Reply from the Router to REQUEST-ADDRESS
sender : Router
receiver : AgentName
name : Name of the agent
host : host name of the agent(null if not available)
port : port number of the agent(-1 if not available)
description : description of the agent(optional)
example:
(address :sender Router :receiver me :name he :host cdr.stanford.edu :port 1234 :description (agent-info :service xxxxxx))

RESERVE-MESSAGE : Request message reservation to the Router
sender : AgentName
receiver : Router
time : reserved time(long number, java understandable)
content : list of message numbers
host : host name if receiving location is different from the current one(optional)
port : port number '' ''
example:
(reserve-message :sender me :receiver Router :content (1 3 5) :time 819374635243 :host cdr.stanford.edu :port 1234)

DELETE-MESSAGE : Request to the Router to delete a message.
sender : AgentName
receiver : Router
content : message number
example:
(delete-message :sender me :receiver Router :content 3)