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?

What are the JATLite assumptions?

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.

• 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 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 standard, proposed by the Center for Design Research (see http://cdr.stanford.edu/ProcessLink/kqml-proposed.html), are implemented to provide a standard protocol for registering, connecting, disconnecting, etc.
• The Router Layer provides name registration and message routing and queuing for agents. All agents send and receive messages via the Router, which forwards them to their named destinations. When an agent intentionally disconnects, or accidentally crashes, the Router stores incoming messages until the agent is reconnected. The Router 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.
• On top of Router Layer, Protocol Layer will support diverse standard internet services such as SMTP,FTP,POP3,HTTP, etc both for stand alone applications and applets. Current beta version supports SMTP and FTP but other protocols can be easily extended from Protocol Layer. If your agents are expecting to transfer non-sentential,lengthy data or your agents need to send KQML message through email, the Protocol Layer will be a good starting point.

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.