Jess Information

Jess Home
Jess 7 Features
Download Now!
Online Demo

Documentation
FAQ
Manual
Mailing List
Jess Wiki

More information Related Web Sites
User Contributions
JSR94 Info
Developer's Log
About This Site

JESS ®, the Rule Engine for the JavaTM Platform

Jess Wiki: Jess Not Java

Jess allows a programmer to construct and call methods on external Java objects as a convenience to interact with the host Java system. This interaction is vital since Jess itself doesnít have the facilities that Java does for database access, network communication, etc. In short, Jess depends on Java to interact with the outside world. In many previous expert system utilities, such as CLIPS, the interaction with the host language was complex and required special data structures and method calls. Hence, the sheer complexity of interacting with the host language encouraged the expert system developer to do it as little as possible. This usually encouraged a good design because business logic that belonged in the expert system usually wound up there.

Reflection simplified the interaction with the host language by providing a way for objects to be constructed and methods on them to be called from a fully scripted environment. The "call" method was born. Expert system developers that have struggled and agonized for years with the CLIPS external function interface praised it as the greatest thing since sliced bread. Going even further, Jess provided the "shadow fact". Now, there was an easy way to represent your Java bean objects as facts in the Jess system. Fabulous!

Hereís the rub: the interface is so easy that experienced Java programmers just starting out with Jess will invariably overuse it to the point that they may as well be programming in Java rather than Jess. Iíve repeatedly seen examples like the following:

 (import com.xyz.app.myapp.Supply)
 (import com.xyz.app.myapp.Product)
 (import com.xyz.app.myapp.Order)
 (import com.xyz.app.myapp.Shipment)

 (defclass supply com.xyz.app.myapp.Supply)
 (defclass order com.xyz.app.myapp.Order)

 (defrule process-order
     (order
         (product  ?PRODUCT)
         (count	   ?COUNT)
         (OBJECT   ?ORDER))
     (supply (OBJECT ?SUPPLY))
     =>
     (if (> (call ?SUPPLY getSupplyCount ?PRODUCT) ?COUNT)
         then
             (bind ?SHIPMENT (new Shipment ?ORDER ?SUPPLY))
             (bind ?SHIPMENTS (fetch "shipments"))
             (if (eq ?SHIPMENTS nil) then
                 (store "shipments" (new java.util.ArrayList)))
             (call ?SHIPMENTS add ?SHIPMENT)))
What is the LHS of this rule doing other than grabbing every possible combination of order and supply? What is the RHS doing other than constructing a new "Shipment"? What happens when you construct the "Shipment"? Who is it shipping to? Does the supply get updated? How does this rule ensure the same order isnít satisfied by more than one supply? Looking at this code you may wonder if it is even logically correct. The shame is that it may be correct depending on what is going on in the Java code. You see, Java developers unfamiliar with Jess will be more likely to place the business logic in the environment that theyíre familiar with, i.e. Java. The Jess code then becomes trivial and very often inefficient.

Submitted by:
GeorgeWilliamson
Union Pacific Railroad
gawillia@up.com



FrontPage, JavaPitfalls


Front Page | Sandbox | Recent Changes | Powered by Friki | Last Edited: 18 August 2006