1. Introduction
1.1. Compatibility
Jess is compatible with all versions of Java starting with Java
1.1. In particular, this includes JDK 1.2 (or "Java 2" as it is now
known.) All versions of Jess later than version 4.x are no longer
compatible with Java 1.0.
1.2. Mailing List
There is a Jess email discussion list you can join. To get information
about the jess-users list, send a message to majordomo@sandia.gov
containing the text
help
info jess-users
end
as the body of the message. There is an archive of the list at
http://www.mail-archive.com/jess-users@sandia.gov .
1.3. Bugs
This is the first beta release of Jess 5.0. There are probably
bugs. Please report any that you find to me at
ejfried@ca.sandia.gov so I can fix them for a later release.
1.4. Assumptions
Jess is a programmer's library. The library itself is written in
Java. The library serves as an interpreter for another language, which
I will refer to in this document as the Jess language. The Jess
language is very similar to the language defined by the CLIPS expert
system shell, which in turn is a highly specialized form of LISP.
Therefore, I am going to assume that you, the reader, are a programmer
who will be using either one or both of these languages. I will
assume that all readers have at least a minimal facility with
Java. You must have a Java compiler and runtime system, and you must
know how to use it at least in a simple way. You should know how to
use it to
- compile a collection of Java source files
- run a Java application
- deal with configuration issues like the CLASSPATH variable
If you do not have at least this passing familiarity with a Java
environment, then may I suggest you purchase an introductory book on
the topic.
For those readers who are going to program in the Jess language, I
assume general familiarity with the principles of programming. I will
describe the entire Jess language, so no familiarity with LISP is
required. Furthermore, I will attempt to describe, to the extent
possible, the important concepts of rule-based systems as they apply
to Jess. Again, though, I will assume that the reader has some
familiarity with these concepts and more. If you are unfamiliar with
rule-based systems, you may want to purchase a text on this topic as
well.
Many readers will want to extend Jess' capabilities by either adding
commands (written in Java) to the Jess language, or embedding the
Jess library in a Java application. Others will want to use the Jess
language's Java integration capabilities to call Java functions from
Jess language programs. In sections of this document tagreted towards
these readers, I will assume moderate knowledge of Java programming. I
will not teach any aspects of the Java language. The interested reader
is once again referred to your local bookstore.
This document contains a bibliography
wherein a number of books on all these topics are listed.
1.5. Getting ready
1.5.1. Unpacking the Distribution
If you download Jess for UNIX, you can extract the files using tar and
uncompress:
uncompress Jess-5.0b1.tar.Z
tar xf Jess-5.0b1.tar
If you downloaded Jess for Windows, you get a .zip file which should be
unzipped using a Win32-aware unzip program like WinZip. Don't use PKUNZIP since it
cannot handle long file names.
When Jess is unpacked, you should have a directory named Jess50b1/.
Inside this directory should be the following files and subdirectories:
docs/
|
This documentation |
jess/
|
A directory containing the jess package. There are many source
files in here that implement Jess's inference engine. Others implement
a number of Jess GUIs and command-line interfaces. Main.java implements
the Jess command-line interface. Console.java is a very simple
GUI console for Jess; ConsoleApplet.java is an applet version
of the same. |
jess/awt
|
Java source which help you to create Java GUIs directly from Jess. |
examples/
|
A directory of tiny example Jess files. |
jess/examples
|
A directory of more complicated examples, containing example Java source
files. |
Makefile
|
A simple makefile for Jess. |
1.5.2. Compiling Jess
Jess comes as a set of Java source files. You'll need to compile them first.
If you have a make utility (any UNIX-like make; you
could use the CygWin
environment on Windows), you can just run make and the
enclosed makefile will build everything. You might have to edit it a bit
first. Otherwise the command:
javac -d . jess/*.java jess/awt/*.java
would work just fine, given that you have a Java compiler named javac
(as in Sun's JDK) and that Jess50b1/ is your current
directory. If you have problems, be sure that if you have the
CLASSPATH environment variable set, it includes '.', the
current directory. Don't try to compile from
inside the Jess50b1/jess/ directory; it won't work. You must
use a Java 1.1 or later compiler to compile Jess. The resulting code
will run on a Java 1.1 or later VM. Jess works great with Java 1.2.
There are a number of optional example source files in the subdirectories
Jess50b1/jess/examples/ that aren't compiled if you follow
the instructions above. You can issue a command like:
javac -d . jess/examples/*/*.java
Again, don't set your current directory to, for example,
Jess50b1/jess/examples/pumps/ to compile the pumps example: it will not
work. The compiler will report all sorts of errors about classes not being
found and the jess package not being found. Compile everything from the
Jess50b1 directory. I can't stress this enough: this is by far the most
common problem people have in getting started with Jess!
I personally use the Jikes
Java compiler from IBM. The compiler itself is very fast (compiles all
of Jess in just a few seconds on my machine!) I highly recommend it,
and it's free!
1.5.3. Jess Example Programs
There are a few trivial example programs (in the examples/ directory)
that you can try to confirm
that you have properly compiled Jess. including fullmab.clp,
zebra.clp, and wordgame.clp. fullmab.clp is
a version of the classic Monkey and Bananas problem. To run it yourself
from the command line, just type:
java jess.Main examples/fullmab.clp
and the problem should run, producing a few screens of output. Any file
of Jess code can be run this way. Many simple CLIPS programs will also
run unchanged in Jess. Note that giving Jess a file name on the
command line is like using the batch command in
CLIPS. Therefore, you generally need to make sure that the file ends
with:
(reset)
(run)
or no rules will fire. The zebra.clp and wordgame.clp
programs are two classic CLIPS examples selected to show how Jess deals
with tough situations. These examples both generate huge numbers of partial
pattern matches, so they are slow and use up a lot of memory. Other examples
include sticks.clp (an interactive game), frame.clp
(a demo of building a graphical interface using Jess's Java integration
capabilities), and animal.clp. Note that animal.clp
is hardwired to expect a data file to exist in a subdirectory
examples/ of the current directory.
In the jess/examples/* subdirectories, you will find some more complex
examples, all of which contain both Java and Jess code. As such, these
are generally examples of how to tie Jess and Java together. The
Pumps examples is a full working program that demonstrates how
Jess rules can react to the properties of Java Beans.
1.5.4. Command-line Interface
Jess has an interactive command-line interface. Just type java jess.Main
to get a Jess> prompt. To execute a file of CLIPS code from the
command prompt, use the batch command:
Jess> (batch examples/sticks.clp)
Who moves first (Computer: c Human: h)?
Note that in the preceding example, you type what follows the
Jess> prompt, and Jess responds with the text in bold. I will
follow this convention throughout this manual.
You can use the Jess system command to invoke an editor from the
Jess command line to edit a file of Jess code before reading it in with
batch. system also helps to allow non-Java programmers
to integrate Jess with other applications. Given that you have an editor
named notepad on your system, try:
Jess> (system notepad README &)
TRUE
The & character makes the editor run in the background. Omitting
it will keep the system command from returning until the called program
exits.
The class jess.Console is a graphical verison of the Jess command-line
interface. You type into atext field at the bottom of the window, and
Output appears in a scrolling window above. Type java jess.Console
to try it.
1.5.5. Jess as an Applet
The class jess.ConsoleApplet is a generic Jess applet that uses
the same display as the jess.Console class. It can be used in
general question-and-answer situations simply by embedding the applet class
on a Web page. The applet accepts two applet parameters. The value of an
INPUT parameter will be interpreted as a Jess program to run when
starting up. Note that when this program halts, the Jess prompt will appear
in the applet window. The applet also accept a COMPACT parameter.
If present, ConsoleApplet will contain only a bare-bones version
of Jess (no optional functions will be loaded).
Note that the ConsoleApplet and ConsoleDisplay classes now use the Java
1.1 event model, which is still not supported by much of the installed
base of Web browsers. Don't use them if you want to deploy highly
portable applets! Actually, the idea of deploying Jess as an applet
makes less and less sense these days; a much better alternative is to
run Jess on the server side (as a servlet, for example) and run only
the GUI on the client. Good applets are generally very small (a few
tens of kilobytes), while Jess's class files now occupy hundreds of
kilobytes.
1.6. What makes a good Jess application?
Jess can be used in two overlapping ways. First, it can be a rule
engine - a special kind of program that very efficiently applies
rules to data. A rule-based program can have hundreds or even
thousands of
rules
, and Jess
will continually apply them to data in
the form of a
knowledge
base
. Often the rules will represent the heuristic knowledge
of a human expert in some domain, and the knowledge base will
represent the state of an evolving situation (an interview, an
emergency). In this case, they are said to constitute an
expert system. Expert systems are widely used in many
domains. Among the newest applications of expert systems are as the
reasoning part of intelligent agents, in enterprise resource
planning (ERP) systems, and in order validation for electronic commerce.
But the Jess language is also a general-purpose programing language,
and furthermore, it can directly access all Java classes and
libraries. For this reason, Jess is also frequently used as a dynamic
scripting or rapid application development environment. While Java
code generally must be compiled before it can be run, a line of Jess
code is executed immediately upon being typed. This allows you to
experiment with Java APIs interactively, and build up large programs
incrementally. It is also very easy to extend the Jess language with
new commands written in Java or in Jess itself, and so the Jess
language can be customized for specific applications.
Jess is therefore useful in a wide range of situations. One
application for which Jess is not so well suited is as an applet
intended for Internet use. Jess's size (a few hundred kilobytes of
compiled code) makes it too large for applet use except on high-speed
LANs. Furthermore, some of Jess's capabilities are lost when it is
used in a browser: for example, access to Java APIs from the Jess
language may not work at all due to security restrictions in some
browsers. When building Web-based applications using Jess, you should
strongly consider using Jess on the server side (in a servlet, for
example.)
1.7. About Jess and performance
Jess's rule engine uses an improved form of a well-known algorithm
called Rete (latin for "net") to match rules
against the knowledge base. Jess is actually faster than some popular
expert system shells written in C, especially on large problems, where
performance is dominated by algorithm quality.
Note that Rete is an algorithm that explicitly trades space for speed,
so Jess' memory usage is not inconsiderable. Jess does contain some
commands which will allow you to sacrifice some performance to
decrease memory usage. Nevertheless, Jess' memory usage is not
ridiculous, and moderate-sized programs will fit easily into Java's
default 16M heap.
1.8. Command-line, GUI, or embedded?
As we've discussed, Jess can be used in many ways. Besides the
different categories of problems Jess can be applied to, being a
library, it is amenable to being used in many different kinds of Java
programs. Jess can be used in command-line applications, GUI
applications, servlets, and applets. Furthermore, Jess can either
provide the Java main() for your program, of you can write it
yourself. You can develop Jess applications (with or without GUIs)
without compiling a single line of Java code. You can also write Jess
applications which are controlled entirely by Java code you write,
with a minumum of Jess language code.
The most important step in developing a Jess application is to choose
an architecture from among the almost limitless range of
possibilities. One way to organize the possibilities is to list them
in increasing order of the amount of Java programming involved.
- Pure Jess language scripts. No Java code at all.
- Pure Jess language scripts, but the scripts access Java APIs.
- Mostly Jess language scripts, but some custom Java code in the
form of new Jess commands written in Java.
- Half Jess language scripts, with a substantial amount of Java code
providing custom commands and APIs; main() provided by
Jess.
- Half Jess language scripts, with a substantial amount of Java code
providing custom commands and APIs; main() written by
you.
- Mostly Java code, which loads Jess language scripts at runtime.
- All Java code, which maniulates Jess entirely through its Java
API. This option is not fully supported at this time, but hopefully will
be by the Jess 5.0 final release.
Examples of some of these types of applications are package with
Jess. The basic examples like wordgame.clp,
zebra.clp, and fullmab.clp are all type 1)
programs. draw.clp and frame.clp are type 2)
programs. The pumps example is packaged two ways. If you run
it using the script file pumps.clp, it is a type 4) program;
if you run it using MainInJava.java, it is a type 6)
application.
Your choice can be guided by many factors, but ultimately it will
depend on what you feel most comfortable with. Types 4) and 5) are
most prevalent in real-world applications.