Tools Implementing for Artificial Intelligence Featuring Java
Anne Keuneke Department of Computer Science California State University, Chico Chico, California Abstract Tools for Artificial Intelligence (AI) which are easy to interpret and use are hard to find for the average computer user. With the popularity of the language Java and the potentials it provides for building high-level knowledge constructs and methodologies, Java should be strongly considered for AI programming. The purpose of this paper is to show AI researchers, AI application builders and AI users how the language tools of Java and the tools developed with Java can be used to achieve their research goals and to begin to provide the general populous access to readable, understandable and usable AI tools. Keywords: Artificial Intelligence, Java, programming constructs, tools 1 Introduction 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. This paper addresses the use of Java as a tool to build Artificial Intelligence (AI) systems. Researchers in AI have categorized research in the field into three levels: the knowledge level, the symbol level, and the systems (machine) level [1,2]. 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: Knowledge level: this paper provides links to high-level tools, written in Java, which perform specific tasks [3,4,5] that meet knowledge level issues, and can be used as modules to build higher-level knowledge constructs. Symbol level: the paper uses and illustrates the power and flexibility of Java to make the translation between the machine and knowledge level. Specifically, it demonstrates how readily the constructs of the language allow one to build the necessary symbol level modules by providing tools which address levels of algorithm design, development, and implementation. Machine level: Java's rapid acceptance into the mainstream is due to traits which make it the language of choice for numerous reasons: cross-platform, David Paulson Software Design Engineer Hewlett Packard Co. Roseville, California. modularity, parallelism, remote access, network connectivity, etc. The purpose of this paper is to 1. 2. Provide the general populous access to readable, understandable and usable AI tools Show AI researchers, AI application builders and AI users how the language tools of Java (and tools developed with Java) can be used to achieve their research goals.
2 Background 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 generate products? If one is privileged to be at an institution where AI research is funded, marvelous potentials are observed. In the past, it was well known that much of this work might be published, but probably never be commonly used. 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 exists and outstanding innovative work is achieved. So where are the products of these research efforts? In 1998, the cover of AI Magazine announced that AI had reached adolescence [6]. Still, unless one was an "AI researcher" most of the work remained unknown, inaccessible, to some "dead". Why? "Maybe AI needs a new image. A recent issue if Business Week points out that 70 percent of the Fortune 500 use artificial intelligence technology such as database marketing, agent software, or voice recognition, but the moniker "AI" carries such a stigma that no one will admit to using of selling AI software"[7]. AI is not just an intellectual extravagance. One does not need to put their entire career into the field or have resources to purchase special equipment, or take forever to understand the details or build the needed environment. There should, and can, exist easily accessible works in AI to
give students, industry, and any interested party both the knowledge and the tools of AI. The focus here is to bring the forces of AI, Java, and the World-WideWeb (WWW) together to provide this access. simply because it allows access to millions of users, but since Java can run on the web, individuals can be exposed to AI programs in action. There is no better way to promote a product than to make it visible. Because Java is cross-platform, its use is independent of the user's machine. Resources will not limit the number of people who can use the software. Java is free. Cost will not limit the number of people who can try the software. 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 [8,9,10], but these sites often provide tools which new researchers find lacking in one or more of the following: 1. needed background - Texts in AI are available, but unless these are easily accessible, a resource may not be used since the individual does not know enough background about the tool's functionality or purpose. 2. needed language - There are many tools in LISP available; not too many institutions use LISP in their curriculum anymore. 3. needed tools - The CMU repository [10] provides a number of resources, but unless one already knows what they are looking for, it is difficult to find desired AI tools. 4. needed manual - How does this tool work? The software may be available, but there is no (or insufficient) documentation on how to run it. This paper is divided into two sections. The first section discusses various Java constructs that are useful for AI development. The second section provides examples of systems and information on two ubiquitous tools (Structured Matching and Classification) written in Java which also provide the necessary background and manuals as noted above. Links to web sites focusing on AI in Java are provided. 3 Language Constructs of Java to Assist in AI Research For those AI researchers who are writing new tools, there are many reasons why Java is the language to which one would want to migrate. Java was first presented as "small" and "easy". Although this is true of the basic constructs of the language, one cannot fully appreciate the complexity and utility of the language until becoming familiar with the class library. Sun makes this easy by providing an online API [11]. The Java 2.0 platform API provides a wealth of packages with tools both for beginners and experienced programmers. This section discusses a number of
Specifically, this union will provide availability through the following mechanisms: Use of the WWW will allow AI materials to be seen. Not s capabilities, interesting to AI programmers, that Java provides. It should be noted that not only are these capabilities useful tools, but the organization and mechanisms of each construct makes them astonishingly easy to use. 3.1 GUIs At the surface level, one requires programming constructs to make AI tools visible to the ultimate users. First access will probably be a web page with an applet, servlet, or an application to download. This page should provide access to the introductory material, background information, user manuals, and either demos of systems (via snapshots or actual running systems (applets or servlets)) or possibly jars for downloading applications (jars allow one to package all the needed class files into a single file - similar to UNIX tar). Java provides a plethora of windowing capabilities and GUIs for presentation, user input and system output purposes. Whether applications or applets are chosen for running systems, the same windowing constructs can be used. For more information see the AWT (java.awt) and SWING (javax.swing) packages in the API [11]. For programmers new to Java, one should be aware of where they want their code to run. If one wants to run on the web, then an applet or servlet would be used. However, Applets have strong security constraints, most notably, an applet cannot access files or tools on machines other than the machine serving the web page. Often a database may be on a separate machine. This would cause an Applet security violation. For more on applet security see [12]. Alternatives are thus either using servlets or applications. Servlets and JavaServer Pages (JSP) are dynamically created web pages. Currently the main use of Servlets is for E-commerce pages. Servlets do not have the same security restrictions as applets and thus the programmer can assume the capability of persistent data. JavaServer Pages are a close cousin to the Servlet Technology. JSP offers similar capabilities with the added separation of HTML presentation from application content. The Java Servlets and Java Server Pages APIs support dynamic HTML generation and session management for browser clients, thus making them a feasible tool for running dynamic AI applications on the web. For more information, see Marty Hall's excellent book [13] or the Servlet Tutorial [14] and the JSP page [15]. Use of a database in Java programs is achieved with the help of the JDBC package. Just as Java is cross platform,
the JDBC can be used to connect Java programs to various platforms with a few simple connection calls. Sun provides a tutorial for JDBC as well [16]. 3.2 Harnessing Computational Complexity Given these presentation and connectivity tools, the programmer can then focus on the programming of the AI tool. One definition of Artificial Intelligence, the study of how to make exponentially hard problems solvable in polynomial time, illustrates the close relationship between AI and computational complexity. Complexity can only be tamed when knowledge is represented so that it can be accessed and used. One main constituent in achieving this ease of use is the potential of parallelism. Computing power thus requires distributed architectures. Various techniques can be used to achieve such architectures. The following addresses a number of alternatives provided in Java. First, language constructs from early versions of Java 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, Jiro and additional technologies now available which can be used for distributed programming, blackboard system development and agent implementations. For an example tool that implements and describes the use of the constructs of RMI, JNI and Jini, see Paulson [17]. 3.3 Threads 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 machines can run only one process at a time - one can compare this to applications being 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; using Java, programmers can start testing their parallel algorithms through the use of 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 the Thread tutorial [18] or the books [19, 20] for more information. 3.4 JNI JNI (Java Native Interface) is the native programming interface for Java, and has been a feature of the JDK since Java release 1.1 [21]. 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: The standard Java class library does not support the platform dependent features needed by an application, for example device specific I/O. A library or application written in another programming language may already exist and need to be made accessible to Java applications It may be necessary to implement a small portion of time critical code in a lower-level programming language, such as assembly, which the Java application can then control. 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. See the Java Native Interface(JNI) tutorial [22] for more information. 3.5 RMI Threads are a useful tool for parallelism on a single machine but could also be a useful tool to spawn processes on multiple additional machines. The combination of Threads and RMI (Remote Method Invocation) would allow applications to subtask across the web.
RMI enables the programmer to create distributed Javabased 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 clientserver mechanism [23]. 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. See the Remote Method Invocation (RMI) tutorial [24] for more information. 3.6 Jini Overview "Jini is possibly the most compelling reason to write in Java," says Sun CEO Scott McNealy. "The nice advantage is, if you can write in Java, you can write in Jini today"[25]. The above constructs, Threads, JNI (Java Native Interface) and RMI (Remote Method Invocation), have been available for several years. Jini [26] was fairly recently released, on January 25, 1999. The Jini Technology Starter Kit is not part of the Java 2 Standard Edition but can be downloaded at the Jini Connection Page [27]. Basically, the Jini infrastructure is built on the Java Remote Method Invocation system, but then adds two components: the
discovery protocol and the lookup service. There are not as many well-documented Jini application examples available as with the more mature technologies of JNI and RMI. It is interesting, however, that Jini already has been used for AI applications, in particular, for use in agent research. Benedicto, "Regions: A Scalable Infrastructure for Scoped Service Location in Ubiquitous Computing" [28] Deleo, "A Demonstration of JiniTM Technology and the K Virtual Machine" [29] MITs Hive [30] UMBC example projects, including Ronin a Jini-based distributed agent development framework and a Jini Prolog Engine Service [31]
Jini is a set of Java networking protocols intended to make Java-based devices or services network mobile. The Jini connection technology is presented as a new system architecture that brings to the network the facilities of distributed computing, network-based services, seamless expansion, reliable smart devices, and ease of administration [32]. 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 [33]. 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. Specifically, a great deal of the power of Jini connection technology lies in its ability to move objects (service objects and attributes) across networked systems. Jini was designed as an ideal object-oriented infrastructure for networking devices unencumbered by a target application or platform. However, it is possible to see in its design tools for generating distributed systems development and to observe remedies for many of the issues that are encountered in creating CORBA or RMI-based solutions. A few essential design goals of Jini were: Simplicity: meaning just enough to meet the infrastructure goal without being everything to everybody, and small enough to be usable on appliances. Reliability: planning for the fact that a network is not 100% reliable, although many network systems, like LAN's, often assume that it is. Scalability: meaning that the communities of Jini devices can be organized hierarchically for larger application environments.
Jini connection technology requires the following: an infrastructure which operates as a dynamically distributed system a common language and implementation that enables low-overhead communication between distributed objects a lookup service (which identifies objects that supply those services) an add-in protocol which is implemented on each device--called the discovery/join protocol a subtract-out mechanism--providing resilience when a device is unplugged--which is called leasing
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 twophase 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. General Jini information can be found at the following: "How Jini Technology Makes This Work?" at [26] Jini Connection Technology [27] Jini Whitepapers [32] Core Jini by Keith Edwards [33] "The Jini Vision" by Bill Venners [34] The Jini community [35] "The End of Protocols" by Jim Waldo, the lead architect for Jini [36].
Jini is thus comprised of five new extensions Java to networking functionality: Discovery, Lookup, Leasing, Remote Events, and Transactions. 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
3.7 Jiro Jiro technology is an extension to the Java and Jini technologies for dynamic management of heterogeneous services on a network. For effective, faster and easier management of Jini, developers should consider Jiro. The base management services of the Jiro specification provide a common set of services for managing resources throughout the management domain. Specifically, the Jiro specification introduces an event service, scheduling service, controller service, logging service and a transaction manager. Jiro technology delivers: Simple Manageability -- by enabling creation of automated and policy-based management functionality to handle routine administrative tasks Greater Interoperability -- through platformindependent components and interfaces that simplify integration with other management solutions Dynamic Service Availability -- through a central management domain accessible to all Jiro technologyenabled resources on the network Improved Uptime -- by enabling devices to perform intelligent self-monitoring and corrective actions without waiting for human intervention
3.9 Java Message Service and JavaSpaces Overview See http://www.sun.com/jiro/ for information and downloading. One of the fundamental concepts of Jiro technology is the base management services. But how are these services that are being managed represented? Another fundamental concept of Jiro is FederatedBeans architecturebased components. The dynamic management services of the Jiro specification support the deployment, updating and recall of complete distributed management applications composed of FederatedBeans architecture-based components. The FederatedBeans API is downloaded with the Jiro Software Development Kit. The following discusses what Beans are in Java. 3.8 JavaBeans and Enterprise JavaBeans Java technology currently has a component model called JavaBeans, which supports reusable development components. Specifically, a Java Bean is a reusable software component that can be visually manipulated in builder tools (much like Delphi or Visual Basic). Beans may be visible objects, like AWT components, or invisible objects, like queues and stacks. A builder/integration tool manipulates Beans to create applets and applications. The simplest kind of a bean is really nothing more than a Java class that follows some fairly strict naming conventions for its event listeners and its methods. The Java Developer Connection has some nice tutorials on Beans [37]. To AI researchers, such a construct allows one to program knowledge specific modules that can be manipulated by related components. The tool resembles the idea of Knowledge Sources in a Blackboard system [38,39]. Or more simply, modules which perform a specific task [3]. Whether components are for distributed systems or running on single machines, the use of modularity and interoperability is always a good design plan. Such a construct allows for generic task components that can be added together with minimum user programming to provide higher-level tools. Enterprise JavaBeans (EJB) technology defines a model for the development and deployment of reusable Java server components. Components are, again, pre-developed pieces of application code that can be assembled into working application systems. The EJB architecture extends the JavaBeans component model to support server components (application components that run in an application server) [40]. EJB technology supports application development based on a multi-tier, distributed object architecture in which most of an application's logic is moved from the client to the server. The application logic is partitioned into one or more objects that are deployed in an application server. For more on Enterprise JavaBeans, see the tutorial [41]. In object-oriented programs, objects send messages to objects. In distributed systems, components send messages (and sometimes whole components) to components. Such a flow of objects necessitates advanced mechanisms for message passing and communication between various applications. The Java Message Service (JMS) will work in concert with other technologies to provide reliable, asynchronous communications between components in a distributed computing environment. JMS is a common API and provider framework that enables the development of portable, message-based applications in the Java programming language. The JMS specification provides significant improvements over traditional process-oriented messaging systems and improves programmer productivity by defining a common set of messaging concepts and programming strategies that will be supported by all JMS technology-compliant messaging systems. For more information on the Java Message Service API, visit http://java.sun.com/products/jms. JavaSpaces services are tools for building distributed protocols. They are designed to work with applications that can model themselves as flows of objects through one or more servers. "JavaSpaces technology is a simple unified mechanism for dynamic communication, coordination, and sharing of objects between Java technology-based network resources such as clients and servers. In a distributed application, JavaSpaces technology acts as a virtual space between providers and requesters of network resources or objects. This allows participants in a distributed solution to exchange tasks, requests and information in the form of Java technology-based objects. JavaSpaces technology provides developers with the ability to create and store objects with persistence, which allows for process integrity"[42]. JavaSpaces technology is available for downloading at [42]. A definition of the JavaSpaces application model and terms [43] illustrates a possibly use for JavaSpaces for AI Blackboard or distributed parallel systems: A JavaSpaces service holds entries. An entry is a typed group of objects, expressed in a class for the Java platform. Entries are described in detail in the Jini[tm] Entry Specification [44]. An entry can be written into a JavaSpaces service, which creates a copy of that entry in the space that can be used in future lookup operations.
One can look up entries in a JavaSpaces service using templates, which are entry objects that have some or all of its fields set to specified values that must be matched exactly. Remaining fields are left as wildcards--these fields are not used in the lookup. There are two kinds of lookup operations: read and take. A read request to a space returns either an entry that matches the template on which the read is done, or an indication that no match was found. A take request operates like a read, but if a match is found, the matching entry is removed from the space. One can request a JavaSpaces service to notify an agent when an entry that matches a specified template is written. This is done using the distributed event model contained in the package net.jini.core.event and described in the Jini[tm] Distributed Event Specification [44]. All operations that modify a JavaSpaces service are performed in a transactionally secure manner with respect to that space. That is, if a write operation returns successfully, that entry was written into the space (although an intervening take may remove it from the space before a subsequent lookup). If a take operation returns an entry, that entry has been removed from the space, and no future operation will read or take the same entry. In other words, each entry in the space can be taken at most once. Note, however, that two or more entries in a space may have exactly the same value. The architecture of JavaSpaces technology supports a simple transaction mechanism that allows multi-operation and/or multi-space updates to complete atomically. This is done using the twophase commit model under the default transaction semantics, as defined in the package net.jini.core.transaction and described in the Jini[tm] Transaction Specification [44]. Entries written into a JavaSpaces service are governed by a lease, as defined in the package net.jini.core.lease and described in the Jini [tm] Distributed Lease Specification [44]. 4 Available Generic AI Tools in Java The remainder of this paper provides links to AI tools that have already been developed in Java. Elaborate AI tools can be built by using the lower-level modules implemented by others. Two problem-solving tasks that are modules in almost any AI application are structured matching and
classification. In this section, an implementation in Java of a structured matcher is presented to provide the reader with one AI tool to add to their toolset. The design of the tool provided here is from work completed at The Ohio State University's Laboratory for Artificial Intelligence Research [3,4,5]. These tools were first written in Interlisp-D [4], translated to CLOS [45], then to Smalltalk (no longer available), and now they are being implemented in Java [46,47]. 4.1 Structured Matcher The Structured Matcher program implements a technique called hypothesis testing or matching. This is viewed as matching a hypothesis to a situation using a hierarchical representation of evidence abstractions. Such a tool can verify that a certain hypothesis is valid (or not) in a given case. A structured matcher is a simple matcher or truth table that contains parameters or questions which can be used to determine a confidence level for a hypothesis. To reduce the level of complexity, some of the parameters could be grouped into sub-decisions, which are simple matchers themselves. These simple matchers would be contained within their parent simple matcher just as a parameter would. When the root simple matcher resolves its truth table and encounters a column that represents a simple matcher, the processing of the current simple matcher would be put on hold while the child simple matcher would be resolved. The web pages for the tool [46] include an introduction and how to use the tool: http://aiweb.ecst.csuchico.edu/tasks/SM/paper/SMpaper.html an extendable Structured Matcher: allows a user to add different question types, and the manual for how to use it: http://ai-web.ecst.csuchico.edu/tasks/SM /paper/appendices.html source code http://ai-web.ecst.csuchico.edu/tasks/SM /heinke/download/strmatprg.htm 4.2 Classification The task is seen as determining what categories or hypotheses apply to a situation given a description of the situation. The classification tool consists of a hierarchy of specialists that mirror a diagnostic classification hierarchy. Each specialist (hypothesis) should have a subtask to establish or reject it; the current tool uses a serializable structured matcher as the method of verification. If the specialist is establi...