As in any discipline or trade, progress is more easily achieved when one has the proper tools. Depending on the level of expertise one has mastered and the products one is attempting to create, the tools (and the complexity therein) may vary.
Researchers [Marr pg. 25, Newell] in Artificial Intelligence (AI) have categorized research in the field into three levels: the knowledge level, the symbol level, the systems (machine) level.
Even though it is "just a language", this paper illustrates the power of the programming language Java to benefit each of these levels of AI study as follows:
The purpose of this paper is to
It is as though AI were a well-kept secret. Or perhaps it is construed as an intellectual extravagance. Institutions of Higher Learning have long been known for their research facilities and "interesting" results. But how often do these creative endeavors create products?
In the 70's and 80's if one was privileged enough to be at an institution where AI research was funded, they learned and saw marvelous potentials. It was well known that much of this work might be published, but probably never produced. In lay terms, it would "never see the light of day" for a decade - or more - and some would never be seen. Research. But the excitement was there and marvelous work was achieved. So where is it?
In 1998, the cover of AI Magazine [Allen] announced that AI had reached adolescence. Still, unless one was an "AI researcher" most of the work remained unknown, inaccessible, to some "dead".
Why?
The focus here is to bring the forces of AI, Java, and the WorldWideWeb (WWW) together to provide this access. Specifically, this union will provide availabilty through the following mechanisms:
One of the reasons that students new to AI have a difficult time is that instructional resources are often not provided. Specifically, there are a number of web sites that provide AI materials (jess, neural nets, repository CMU), but these sites often provide tools which new researchers find lacking in one or more of the following:
This paper is divided into two sections. The first section provides examples of two ubiquitous tools (Structured Matching and Classification) written in Java, useful for AI. The second section discusses various Java constructs that are useful for further AI development.
The design of the tools provided here is from work completed at The Ohio State University's Laboratory for Artificial Intelligence Research [Chandra, Bylander]. These tools were first written in Interlisp-D[Tanner], translated to CLOS[Fafner stuff], then to Smalltalk[Michigan Sticklen], and now they are available in Java.
First, low-level language constructs of Threads, Java Native Interface (JNI), and Remote Method Invocation (RMI) are discussed to illustrate their potential for parallelism, use of legacy code, and distributed programming. This is followed by aspects of JINI which can be used for distributed programming and agent implementations.
See [Paulson] for an example program which uses all of these constructs.
Threads are a core java class provided in the basic package java.lang.
A thread represents a single process in execution on a system. Threads are sometimes referred to as light-weight processes or execution contexts. Typically, each thread controls a single aspect within a program, such as monitoring a particular input device, handling all of the disk I/O, or for AI problems, testing various branches of a knowledge structure (say a tree or graph).
A single-threaded program uses only one thread to control its execution. vonNeumann machines predicate applications are single-threaded.
Multithreaded applications use several execution contexts to accomplish their tasks. They make use of the fact that many tasks contain separate and distinct sub-tasks. One thread can be used for each subtask.
It is easy to see the use of threads in AI programming. Parallel machines remain expensive for the average user, but there is no reason that programmers can not start testing their parallel algorithms through the use of java threads. Pruning a space in parallel greatly reduces the complexity. A multithreaded program allows each thread to start and finish as quickly as possible; this behavior provides better response to real-time input.
See Thread tutorial and books for more information.
RMI (Remote Method Invocation) enables the programmer to create distributed Java-based applications in which the methods of remote Java objects can be invoked from other Java virtual machines (JVM), possibly on different hosts. It closely parallels the older RPC (Remote Procedure Call) sockets-based client-server mechanism [Gunter]. A Java program can call a method on a remote object after it obtains a reference to the remote object. This reference is obtained either by looking up the remote object in the Java naming service provided by RMI or by receiving the reference as an argument or a return value. A client can call a remote object in a server which itself can be a client of other remote objects, so that RMI can be bi-directional between a client and server.
RMI is itself implemented completely in Java, and uses a mechanism in which the client's remote method calls are forwarded to a stub class, which runs in the local client JVM. This stub class meets the interface requirements of the server's remote methods. A local JVM does not actually internally contain the support for remote method features. The server has a corresponding skeleton class that also runs in the server's local JVM. The stub and skeleton classes are created using the `rmic' utility on the class file containing the remote method interface definition. These stubs and skeletons actually handle the entire networking interaction through the RMI package functionality. The RMI package is in turn built on the TCP/IP sockets methods in the `java.net core' Java package.
One of the biggest advantages of RMI over other remote processing methods is that in a purely Java system design, the RMI remote methods calls look identical to normal, local, method calls. There are, of course, rules to follow to be sure code will work with RMI and there is some small overhead to initiate the client/server connection. The fact that remote methods look like local methods helps promote good object-oriented design without encumbering the design with too many client/server communication details.
JNI (Java Native Interface) is the native programming interface for Java, and has been a feature of the JDK since Java release 1.1 [Gordon]. JNI allows Java code that runs within a JVM to call applications and libraries written in other languages, such as C, C++, and assembly. JNI is needed to write native methods to handle situations in which an application cannot be written entirely in Java. For example, a need may arise to use native methods and the JNI in the following situations:
In using JNI to call legacy code, the utility `javah' is used to create an ANSI `C' compatible header file from a class file containing methods marked as `native'. The programmer must then create the platform specific native library using the untouched and unmodified header file. A Java application can then load this native library at runtime and complete the calls to the native code. The JNI calling functionality is, of necessity, partially built-in to the JVM, as part of the platform specific adaptations of a specific JVM port.
JINI is a new set of Java networking protocols [Sun] intended to make Java-based devices or services network mobile. Note that JINI is not an acronym but an invented brand name. The JINI concept was actually part of the original Java concept when Java was still called Oak and was targeted as an OS for small, smart appliances [Edwards]. Part of the concept is built on the fact that modern appliances often have a lot of computing horsepower built-in, but are still reliant on some central system for the device to be network accessible. That central system will have operating system specific drivers installed to access the appliance. JINI provides the infrastructure needed for smart devices to advertise their features or services directly on the network and for other devices or applications to find and make use of those services. JINI was designed as an ideal object-oriented infrastructure for networking devices unencumbered by a target application or platform, just as Java was designed as a pure object-oriented programming language. A few essential design goals of JINI were:
Discovery is the process used by a service object to find and join a JINI community. In practice, Discovery is made up of three announcement protocols by which an object sends out self-descriptive packets. Either these are sent as a network broadcast to the entire network, called Multicast Request and Announcement, or to a specific JINI community Lookup server if one is known, called Unicast Discovery. Note that the range of multicast discovery is limited by the network topology, specifically whether inter-subnet routers are configured to pass multicast packets.
The Lookup service is a required central JINI service, although a given JINI community could have several instances. The Lookup service intercepts the Discovery requests and registers the object's services as available. Part of the registration includes capturing a variety of details about the service: name, physical location, community name, duration of availability, etc. It also includes an actual proxy object, which an eventual user will download to access the service. Discovery and Lookup comprise the core features of JINI. The other protocols are features that enhance JINI's network reliability.
Leasing is a mechanism for monitoring the availability of a service. When the service registers itself, the Lookup service creates a lease object. A lease object defines how long the service will be advertised as available on the lookup server. The lease may be retrieved and the lease extended. If the service does not renew before the lease expires, it will eventually be dropped from the Lookup service as an available service and any associated proxy objects will be dropped from memory. This makes the services self-cleaning in the sense that inactive services do not waste network bandwidth or Lookup server resources. Thus, the lease mechanism serves as a type of networked garbage collection.
Remote events, as the name implies, extend the local JVM's event notification mechanism to network distributed objects. These are used by the JINI protocols and are available for use in user created services. An example is the case of the JINI Lookup service sending a notification to a particular service if a service of some specific type joins or leaves the community.
Transactions provide a protocol very similar to the two-phase commit protocol used in many databases. The purpose is to ensure some set of events has occurred without partial completion. JINI implements a Transaction Participation Interface in which a set of objects registers with a Transaction Manager object. The Transaction Manager then invokes specific methods: `prepare' followed by `commit', within each registered object to guarantee in advance that the entire sequence could complete. The Manager gives each object a chance to abort, negating all of the transaction chain. Transactions will probably not be a frequently used part of JINI but are provided for completeness of the reliability of the JINI distributed object architecture when complex distributed sequences are needed.
Some examples of the use of JINI in AI related work (agents).
T. Bylander and S. Mittal. CSRL: A Language for Classificatory Problem Solviing and Uncertainty Handling. AI Magazine 7(3):66-77, 1986
T. Bylander, T. Johnson, A. Goel, Structured Matching: A Task Specific Technique for Making Decisions. Knowledge Acquisition, 3(1), 1-20, 1991
B. Chandrasakeran, Towards a Taxonomy of Problem Solving Types. AI Magazine 4(1):9-17, 1983
K. Edwards, Core JINI Upper Saddle River, New Jersey: Prentice Hall PTR.
R. Gordon, Essential JNI: Java Native Interface. Upper Saddle River, New Jersey: Prentice Hall PTR. 1998
D. Gunter, Client/Server Programming with RPC and DCE Indianapoilis, IN: Que Corp., 1995.
L. Heinke, Structured Matcher: A Case Study in Object-Oriented Redesign Masters Thesis, California State University, Chico, 1999 http://ai-web.ecst.csuchico.edu/tasks/SM/heinke/sm-intro.html
Doug LeaConcurrent Programming in Java:Design Principles and Patterns Second Edition, Addison Wesley Java Series, 2000
D. Marr. Vision, 1982 W.H. Freeman and Company
A. Newell. The knowledge level. Artificial Intelligence, 18:87-127, 1982.
Scott Oaks and Henry Wong Java Threads O'Reilly & Associates, 1999
D. Paulson JINI-based Test and Measurement Systems Masters Thesis, California State University, Chico, 2000 http://ai-web.ecst.csuchico.edu/masters/paulson/project/index.htm
Sun Microsystems, "Thread Tutorial," [corporate web site] http://java.sun.com/docs/books/tutorial/essential/threads/index.html
Sun Microsystems, "RMI Tutorial," [corporate web site] http://java.sun.com/docs/books/tutorial/rmi/index.html
Sun Microsystems, "JNI Tutorial," [corporate web site] http://java.sun.com/docs/books/tutorial/native1.1/index.html
Sun Microsystems, "JINI Connection Technology," [corporate web site] http://www.sun.com/jini/overview/