JATLite Introductory FAQ

General Information Questions Background and Status Questions JATLite Top Level Technical Questions
JATLite Detailed Technical FAQ

General Information Questions

Background and Status Questions

Why was JATLite built?

The roots of JATLite date to 1993, when CDR began to use the KQML language for agent communications. After developing a number of C, C++ and Lisp agents with KAPI, it was clear that a standard approach was needed for providing the basic communication and interaction functions needed by all agents. In early 1996, a CDR Masters student, H. Robert Frost[1] developed the Java Agent Template, under the guidance of Prof. Mark Cutkosky and a senior PhD student, Gregory Olsen, who had developed some of the earlier agents. The Java Agent Template was made available to researchers who wanted to download it from the CDR web site. The philosophy and guiding ideas behind the Java Agent Template were outlined in a paper by Frost and Cutkosky in September, 1996 [1]. Three increasingly sophisticated versions of the Java Agent Template were developed by Mr. Frost before his departure from CDR. The final version included provisions for automatically loading class libraries, with a mix of procedural and declarative information.

In 1996 Messrs. Frost and Olsen left CDR to join a software startup called Cross Route Systems Inc., in Redwood Shores, CA. (The technology being developed by Cross Route is unrelated to Java agents.) With the departure of Mr. Frost, it was decided by Prof. Cutkosky his students, and CDR Research Associate Dr. Charles Petrie, that the Java Agent Template had become too complex for follow-on support. Further, it incorporated specific research theories of agenthood that were not necessary in a general agent infrastructure. And finally, this original system did not include the Agent Message Router, which we found to be necessary to run applets as agents.

We decided to do something different. In 1996, Mr. Heecheol Jeon had already modified a version of the JAT in March of 1996 to include an early prototype of the AMR so that we could run applets. Stripping out the code that committed the builder to the specific agent architecture was difficult, so we largely started over with the experience we had gained from the first JAT.

The result was JATLite, a new software package that was smaller, faster, and more robust, and focused only on providing the connection and communications infrastructure that all agents need. The principal developer of JATLite has been Mr. Heecheol Jeon, a PhD student at CDR, with assistance from a few other CDR students and under the supervision of Prof. Cutkosky and Dr. Petrie.

What is the current status of JATLite?

The current version of JATLite, version 0.4 Beta, has been made available to researchers who download it from this web site. To obtain the software, users fill out a form giving their name, address, email address, and company affiliation. You should have a good familiarity with the JDK 1.1. Then follow the JATLite Setup Guide.

Our intention is to continue to provide JATLite free of charge for researchers who wish to evaluate it. Thus far more than a 1,000 researchers from around the world have downloaded various versions of JAT and JATLite. We also encourage users to send technical questions and comments to <jat-develop@cdr.stanford.edu>. We do not formally support the software, but we do our best to answer questions, fix bugs, and make improvements. For more information, see the JATLite Support page.

How do I license JATLite?

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. JATLite source code is available free under the GNU Public Licence. You can directly download the source codes from download area.

At this point we at CDR have no particular plans to commercialize the JATLite technology. We would be very happy to cooperate with anyone wishing to do so.

JATLite Technical Questions

What are the JATLite capabilities?

  • Modular construction consisting of layers, each of which can be be exchanged with other technologies without affecting the operation of the rest of the package.
  • Low level communications based on TCP/IP, as supported by commonly used operating systems (e.g., Unix, Windows, MAC OS, ...). Other protocols (e.g., email) can be added easily.
  • Agent messages based on the KQML language and protocol, with built-in parsing for the outer layer of messages. The inner "contents" of messages can be in any language (e.g., SQL, Express, KIF).
  • Multi-threaded operation, with multiple server sockets and message receiver sockets. Socket connections are persistent and have timeout provisions.
  • Provides Agent Message Routers (AMR) for agent registration, connection, name, and password services.
  • AMR provides storage and queuing of messages for mobile and sporadic agents.
  • Supports stand-alone agents in Java and C++, and applet agents through popular WWW browsers (e.g., Netscape, Internet Explorer).
  • Built-in FTP file transfer capability.

What are the JATLite assumptions?

JATLite can run on any platform that supports the Java development kit JDK1.1 from Sun Microsystems Inc., including Windows95, WindowsNT, Solaris, Mac OS8. Modifications may be needed for other Java environments. Applet agents can be run using a WWW browser such as Netscape or Internet Explorer, or Sunís applet viewer. JATLite agents also utilize standard TCP/IP communications and sockets for interprocess communication. All communications are assumed to take place through Agent Message Routers (AMRs), which are stand-alone Java programs running on hosts connected to the Internet.

In order to be JATLite-compliant, it is only necessary that an agent send ASCII messages conforming to the general KQML syntax and also make connections with the AMR using the JATLite AMR connection protocol. We have provided special patches to facilitate using KAPI agents in particular.

The general operating assumptions are:
  • TCP/IP based connections
  • Agent communication through message passing
  • One live connection for each connected agent
  • A single address(name,host,port,message-method,description) should be assigned to each agent. If the agent can not have a ServerSocket, as is the case with Applets, the host can be set to be "null" and port can be set to -1.
  • The message end character should be set/reset tothe default '\004' and the maximum idle time should be zero.

What are the JATLite layers?

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 2: JATLite is built as a series of increasingly specialized layers

These layers are the JATLite API.

What are the future extensions planned?

In the future we hope to add an email communications layer to complement the TCP/IP and FTP capabilities. The email layer using SMTP will allow JATLite agents to communicate with other agents (software or human) via electronic mail. This capability will be useful for communicating with programs that are inside corporate "firewalls."

We and others continue to work actively on several extensions, one of which is a method of allowing a hierarchy of AMRs to be used in much the same way that the Internet domain names work. This will allow JATLite based-systems to scale in the same way. To get the latest news, be sure to join the jatlite-users list.

Although the AMR is by now well-tested, the architecture is certainly subject to single-point failure. In practice, we note that a) the crash of a single agent can disturb a distributed computation using an ANS, and b) most Internet systems, such as email servers, work on the same principle. In order to make the AMR more robust, we do plan to add a self-checking and self-restarting daemon to the AMR to make possible AMR crashes, perhaps due to a machine crash, less problematic. In any case, the messages are saved to files.

In our own work we will continue to use the KQML language capabilities, but we recognize that many others will take advantage of JATLite's modular construction to swap out the KQML layer and use their own language such as SQL, for database transactions, or the FIPA ACL.

Why not use CORBA and Java RMI?

CORBA and RMI are certainly compatible with JATLite and can be used together in a number of ways. If the language of your agent does not have a Java interface, for example, you may want to use CORBA as a translator.

As a complete replacement for JATLite, there are two disadvantages. One is the requirement that all software modules send CORBA objects. The other is that one has to rewrite the AMR.

Are there some example applications?


[1] H.R. Frost and M.R. Cutkosky, "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.

[2] C. Petrie, " Agent-Based Engineering, the Web, and Intelligence," IEEE Expert December 1996.

[3] H. Jeon, C. Petrie, M. R. Cutkosky, " JATLite: A Java Agent Infrastructure with Message Routing,", IEEE Internet Computing Mar/Apr 2000.

©1996,1997, 1998, 1999 CDR,Stanford University. All Rights Reserved.
Heecheol Jeon

Last modified: Tue Feb 15 10:47:45 PST 2000