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.
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.
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}
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.
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.
- Connection/Registration -- This issue addresses communication among agents developed from heterogeneous agent-based systems. Although KQML is an excellent agent communication language that has provided a standard for several years, it does not define a connect/register mechanism. This is due to a view in the KQML developer community that this issue should not be defined at the level of language; a view with which we disagree. Lack of standardized connect/register performatives makes it difficult for any agent to connect to foreign agents in a reliable manner. It is a mistake to ignore low-level connection dialogues among agents that allow a more task-oriented discussion to take place.
Transport protocol -- Lack of a standard transport protocol is another barrier for foreign agent communication. The lack of a standard protocol makes interoperability a matter of ad hoc agreement among developers. Even if software tools agree on TCP/IP as the underlying transport mechanism, the implementation details of a transport protocol are not standard and may not be compatible with each other. For instance, Afterburner {3} uses \n as a message terminating character but KAPI uses \04 and accordingly, Afterburner agents can not correctly communicate with KAPI agents. It is excellent that FIPA does specify a foreign agent interoperability protocol and architecture but so far this is just "yet another" ACL and agent systems specification.
Reliable, Robust Message Delivery -- Some tools like COOL address the issues of lost messages in terms of deciding the individual agent coordination strategy, but there has been little attempt to devise a safe, correct and robust architecture for reliable message delivery, other than depending only on the underlying TCP/IP transport. Lost or damaged messages due to accidental failure of an agent or networking malfunction may result in confusion to the entire agent conversation and essentially destroy any distributed computation.
Security -- Relatively little attention has been paid to security for agents relying on a message-passing paradigm. Because a message uses a declarative language which is shared among an agent community, and its high-level semantics are typed and independent of the application, a system with typed-message agents seems to be less vulnerable to hostile intrusion than a system sending/receiving mobile executables. However, as noted by C. Thirunavukkarasu [Thirunavukkarasu 95], secure communication regarding protection of the privacy and integrity of data would be important from practical point of view.
Migrating Agent Communication -- The migrating, or portable, agent has been an evolving issue for agent developers since Sun, together with WWW browsers, such as Netscape or Internet Explorer, established Java applets as an important Internet technology. Java applet technology enables portable agents to be downloaded and executed from WWW browsers. But applets were initially restricted to making TCP socket connections only with the server that spawned them. This meant immediately that applets could not be typed-message agents able to communicate with any other agent using the standard ANS mechanism. The security limitation is a critical hurdle that must be overcome to develop a portable agent which needs peer-to-peer communication with other agents through WWW browsers. Even today's security relaxation of trusted applets provides a general barrier to the free exchange of messages among applet agents. Use of the trust mechanism requires the user to anticipate what applet agents may be trusted and what capabilities they may have. What is needed initially is a mechanism that allows any applet agent to at least communicate with other agents without any special user intervention.
Within the scope of at least the engineering domain, this problem is not restricted to applets. Standalone agents also may change IP addresses. This issue is related to but distinct from the issue of providing support of mobile agents. Applets and standalone agents may be moved from machine to machine by users at will, rather than moving themselves via pre-installed software on each machine.
- Debugging Tools -- Agent development systems to date have not emphasized debugging, yet debugging of distributed systems can be very difficult. We do not propose a general solution to this problem here, but only note that it is an important but widely neglected issue in agent development systems. The debugging tools in JATLite, as in most of these systems, are minimal: there is an Administrative Agent that can be used to display the flow of messages among agents. However, as described in our application experiences, we find that the centralized communication services of JATLite simplifies both the development and debugging of agents.
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.
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.
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.
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:
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.
- The abstract layer provides the collection of abstract classes necessary for JATLite implementation. Although JATLite assumes all connections to be made using TCP/IP, one can implement different protocols such as UDP by extending the Abstract layer.
- The Base Layer provides basic communication based on TCP/IP and the abstract layer. There is no restriction on the message language or protocol. The Base Layer can be extended, for example, to allow inputs from sockets and output to files. The Base Layer can also be extended to provide agents with multiple message ports, etc.
- The KQML Layer provides for storage and parsing of KQML messages. Extensions to the KQML standards include a set of administrative performatives, previously proposed to the KQML community and discussed{2}. The administrative protocols include connection, disconnection, reconnection, registration, unregistration, identification, agent listing and address request , those has been neglected by standard KQML specification.
- The Router Layer provides name registration and message routing and queuing for agents. All agents send and receive messages via the AMR, which forwards them to their named destinations. When an agent intentionally disconnects, or accidentally crashes, the AMR stores incoming messages until the agent is reconnected. The AMR is particularly important for applet agents, which can only initiate socket connections with the host that spawned them, due to WWW and Java security restrictions.
- The Protocol Layer provides several open Internet protocols such as FTP and SMTP. Built-in FTP functions both for stand-alone and applet agents provide a convenient way for transferring large amounts of data among agents. A KQML message will contain the file location so that the receiver can retrieve the file and perform any desired action on it. Built-in SMTP functions for both for stand-alone and applet agents make it possible to send a KQML message as an email to an SMTP server, perhaps to bypass a firewall that prevents socket connections.
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.
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.
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.
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.
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.
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.
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.
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.
We note that debugging is an interesting topic for agent systems. There are at least three levels of debugging.
One is communications: are the agents and the AMR actually sending and receiving messages when they should?
The next level of debugging is at the ACL level. In the case of JATLite, is each agent, including the AMR, properly parsing KQML messages?
Finally, there is the task level of debugging. Is each agent properly parsing the content of each message and acting appropriately?
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.
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.
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.
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.
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.
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.
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.
{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
{10} http://www.paoli.atm.lmco.com/kqml/
{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/
{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
{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/
[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.
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)
