Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
Java Books Media Programming Book Reviews IT Technology

Jess in Action 120

Posted by timothy from the two-for-one dept.
Simon P. Chappell and Eric Kaun contributed reviews of Jess in Action, Ernest Friedman-Hill's introduction to Jess, a pure Java rule-based system developed at Sandia National Laboratories. Kaun writes "Jess in Action presents the Jess rule-based framework, and explores it through four meaty and well-chosen examples: a console tax forms advisor, a console PC repair assistant, a Swing HVAC controller, and a servlet-based purchasing agent. The examples vary greatly in their designs and styles of interaction between Jess and Java, and expose patterns in a concrete context. It's especially nice the way each example builds on the functionality of the one before, such as a text-based question/interview module that is extended into a Swing GUI." Chappell points out that the book's author is also Jess' creator, so he speaks from authority. Read on for both reviews.
Jess in Action
author Ernest Friedman-Hill
pages 480
publisher Manning Publications
rating 9
reviewer Simon P. Chappell, Eric Kaun
ISBN 1930110898
summary Introduces rules and declarative programming style using JESS.

Eric Kaun's review, continued

Jess in Action starts with an introduction to rule-based systems, goes through the basics of the Jess language, and then dives into the examples; the appendices include API references to both Jess functions and Jess's Java APIs, and numerous links and references are scattered throughout the book. If I have any complaint about the organization, it's that the book could have been even more example-driven, abandoning (or shortening) the chapter on syntax and basic functions and introducing them only when used in an example; the rest could have been left to the appendix of Jess functions.

The book is interesting and readable, but dense with concepts, so it contains only 388 pages of actual text, and 50 pages of appendices will take some (well-spent) time to get through. A second skimming impressed me anew with the richness of the material, and the productive way in which it's presented, so I recommend reading the book once to get the overall feel, and then going through it again with the working Jess command shell, editor, and command line in front of you. Or an IDE if you must. :-)

Jess itself consists of a rule language, a runtime engine which supports forward and limited backward-chaining, and APIs for integration with Java; there are many add-on tools for Jess, referenced throughout the book. As with most rules engines, rules are specified as declarative patterns, not procedural code.

Jess in Action is well worth your time and attention, at the least for its exploration of rules, and at most for presenting a strong, flexible platform to tackle what is probably one of the uglier parts of your development process: the sequencing and parameterization of business decisions. Although the list of Cons below is longer, they're just nit-picking; this is an excellent, entertaining, and productive read that will likely expand your programming horizons considerably.

Pros
  • Clearly, concisely, and entertainingly written for Java programmers of any background
  • A strong introduction to two important topics: rules and declarative programming style
  • Well-chosen and developed working examples, each with a different design style
  • The description of the author's unit test framework for rules in Appendix C is a nice touch
Cons
  • Early discussion of Jess syntax focuses too much on Java-like procedural style
  • More of a tutorial - not long enough to be a good reference (though that would probably require a detailed Jess Patterns book)
  • Discussions of development methodology and knowledge engineering are unnecessary, as they're covered better elsewhere and a short summary adds little to the book
  • There's no single list of rule and Jess-related links; references to tools and discussions are scattered throughout the book
  • There are no general references to rules and rule-based systems for theory and background

Simon P. Chappell's review

While part one of the book has two slim chapters to introduce rule-based systems to the casual reader, the rest of the book is a no-messing user guide, reference manual and tutorial on using Jess. If you want to learn about rule-based systems, this should not be your first book. If you know of rule-based systems and have decided to use Jess, then run, don't walk to the bookstore and purchase a copy of this book.

I liked the solid, yet gentle, progression through part two, where the basics of using Jess are explained. The explanations were clear and each concept was introduced in a sequence that built upon the previous concepts and information. For example, I had thought that rules were all you had to worry about in rules-based systems, but it turns out that because rules operate on facts, designing the representation of those facts is a pre-condition of designing rules. (Right, I know you knew that, but it was new to me! :-)

Parts three through six are complete case-studies of the application of Jess in increasingly complex applications. The examples are well-explained and the rationale for each step is discussed in sufficient detail to educate but not bore.

Part seven is a self-described 'grab bag' of stuff that didn't fit in any of the other parts of the book. This section spends some time looking at using XML with JESS, including markup languages for rules, and interfacing with Jess from EJBs and Application Servers.

Lastly, there's the fact that the author of the book is also the author of the software in question. Dr. Friedman-Hill obviously knows Jess better than anyone else in the world and this shows through in the way that he not only explains how to achieve activities in and with Jess, but he also takes time, here and there, to explain some of the design decisions and trade-offs in its creation.

You can purchase Jess in Action from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the (recently updated) book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Jess in Action More

Jess in Action

Comments Filter:

  • Jess (Score:2, Interesting)

    by dolo666 ( 195584 ) *
    "If I have any complaint about the organization, it's that the book could have been even more example-driven, abandoning (or shortening) the chapter on syntax and basic functions and introducing them only when used in an example; the rest could have been left to the appendix of Jess functions."

    To me this says that O'Reilly's methods for writing programming books is favoured to other styles. Personally, I love how O'Relly's PHP Cookbook does just what this reviewer is looking for. You get a problem, a solu

    • Re:Jess (Score:2, Insightful)

      by sketerpot ( 454020 )
      What turned me off Java was not the fact that it had large libraries, but the way the libraries seemed bolted on. I realize that having clear separation between the libraries and the language syntax is a good idea technically, but programming languages are for people [paulgraham.com]. System.out.println() is perfectly understandable, but a convenience function would be nice---or even a "print" statement.

      As libraries get big (as they certainly have in Java), it gets harder to find what you're looking for in them. A big prob

      • There's this thing with Java... It's meant for big things. It is really irritating and a lot of hard work to make something small with Java. However, it's relatively not much more work to make something bigger.

        If you want to log something to a file or so, simply print some debug statements, and you don't want to fight the system, setup Log4J. Make all the config files, instantiate the objects, etc, etc. For a small program that's a lot of work. For a huge program, it's the same amount of work :-) And then

    • Re:Jess (Score:1, Funny)

      by Anonymous Coward
      "If Java had true garbage collection, most programs would delete themselves upon execution."
      -- Robert Sewell

    • What Jess is good for (Score:3, Informative)

      by realfake ( 302363 )
      Jess seems, at first glance, to be equally as redundant. Perhaps some of you could delve into the benefits of Jess, on my account? :) A rules engine like Jess or CLIPS allows you to express a set of rules very economically, expressively, and readably. It's not right for everything, but in many situations it allows you to do things that would be practically impossible if you expressed the same thing as if/then/else statements in code. For example, in a situation where rules need to change frequently, it's g
      • In addition to that, it sounds like its named after a girl. That is the smoothest thing I've heard about this week. Instead of dweeby acronyms, imagine if all languages were named in honor of the ladies.
        • imagine if all languages were named in honor of the ladies.

          Here's a couple to get you started ...

          - Ada [adahome.com]
          - Perl [perl.com]
        • Anybody remember Miranda - not just named after a girl (or rather a Lady), but also named after the first computer programmer (she was a mathematician friend of Babbage's who designed some 'programs' - I use the term loosely - for his analytical engine).

          Neat declarative language (qsort in one short line, and readable to boot!), but crippled by the designers insistance that he controlled all development and distribution.
          • I think you mean Ada... that's her picture on the right of the Ada HBAP site [adahome.com], and the rest of the facts you state are correct. I can't find any information stating who Miranda was named after. (at least through google... so it doesn't exist. :) )
            • Of course, you're absolutely right. Ada Byron Lovelace was the woman I was thinking of, I don't know why my mind replaced it with Miranda - suppose they're both filed under 'languages with girls names' somewhere in wetware.
      • So basically, you're saying that Jess is a repair on Java, to make it more friendly?
  • on the Java Website [sun.com].
    'based on the Chapter 13, "Adding a graphical interface," of the book Jess in Action published by Manning Publications Company. Test your knowledge of Jess, the rule engine and scripting language for Java technology.'

  • licensing -- Jess *not* open source (Score:5, Informative)

    by Anonymous Coward on Monday November 03, 2003 @12:50PM (#7378233)
    3. What are the licensing issues surrounding Jess?
    Jess is and will always be available at no cost for academic use worldwide, with an appropriate license. Commercial users can purchase a Jess license by contacting Craig Smith at Sandia's Technology Transfer office (Telephone 925/294-3358; email: casmith@sandia.gov.) The licensing fees are negotiable and generally quite reasonable. You can also purchase an inexpensive "Home Office" license. Jess is not licensed under the GPL, the LPGL, the BSD license, or any other free software or open source license. Redistribution of the Jess source code under any free software or open source license is prohibited.

    • since when is /. open-source only? (Score:1, Insightful)

      by Anonymous Coward
      Are you implying that beacuse it is a commercial program that we should not be promoting books about it? Oh, yea, its beacuse Java is open source... not.
      • It's a valid enough point, one of the reasons I tend to stay away from Java is that it is not an open standard. Jess appears similarly crippled, not worth the time to parse 400+ pages of text.

        I have a real hard time using any proprietary language or toolkits in the "general purpose" world, I'm sure many do. It doesn't have to be "open-source" (C and C++ aren't technically "open source"), but I would only use proprietary languages/toolkits if I absolutely had to because the boss made me or the situation dem
    • I have actually used Jess in an in-house production system and we where able to obtain a free (as in beer) license from the author as long as we did not distribute it.

  • I see.. (Score:4, Insightful)

    by cK-Gunslinger ( 443452 ) on Monday November 03, 2003 @12:50PM (#7378236) Journal
    Chappell points out that the book's author is also Jess' creator, so he speaks from authority.

    And without bias, I'm sure. =P
    • The book is not a review of the pros and cons of Jess, it is an instructional guide. If you bought this book you either already have a Jess implementation or are seriously considerig one. The bias of the author is as irrelavent as the bias of a Ford engineer writing the product repair manual for a F-150.

      • The bias of the author is as irrelavent as the bias of a Ford engineer writing the product repair manual for a F-150.

        Not necessarily. For example, if a critic of Jess were the author, you might see passges like, "Although Jess *technically* has support for X, the current implementation is some-what of a cludge, and may cause problems with Y, etc...", whereas a proponent of the language may say "Jess was designed from the start with support for X and blah, blah.."

        You will almost *always* have bias in any

  • Comment removed (Score:5, Funny)

    by account_deleted ( 4530225 ) on Monday November 03, 2003 @12:51PM (#7378238)
    Comment removed based on user account deletion
    • I fell out of my chair when I read this! Nice!!! :)

      But seriously... I'm guess that your hits on Jess in Action are more interesting and insightful! Nothing like a bit of grass-roots study to confirm what this reviewer is saying, eh? :P

    • Re:Searching for this. (Score:1, Funny)

      by Anonymous Coward
      Rule: if Jess naughty, then Jess get spanky spank.

    • Re:Searching for this. (Score:1, Funny)

      by Anonymous Coward

      What's even funnier is that the link is Slashdotted now :)

    • I had searched for "Jess in action" on Google, and gotten not quite what I wanted [cum-fiesta-movies.com].

      Ah, thank God for those little URL "hints". There's *one* search I won't be recommending to my boss anytime soon, at least in an office context!

  • Cool... (Score:3, Funny)

    by Black Parrot ( 19622 ) on Monday November 03, 2003 @12:52PM (#7378247)

    ...a Java implementation of some really old stuff.

    Pardon my curmudgeonry.

    • Ironic given the title of you post and that Jess doesn't implement COOL (CLIPS Objecy Oriented Language).

    • Jess is actually new stuff (Score:4, Interesting)

      by alispguru ( 72689 ) <bob.baneNO@SPAMme.com> on Monday November 03, 2003 @02:29PM (#7379107) Journal
      I originally reacted to Jess much the way Black Parrot did, knowing that rete-based rule engines have been around since 1989 or so.

      Jess is a rete-based rule engine, but the implementors have done a lot of work on the innards of rete network processing and have made serious order-of-magnitude improvements in matching speed.

      {snipe}
      They had to - Jess would have been too slow relative to rule engines in native-compiled languages otherwise.
      {/snipe}

      Seriously, Jess is a real improvement over ancient and revered rule engines like CLIPS. You can find out more about Jess by going straight to the sources at Sandia Labs here [sandia.gov].

  • Good book, but dense material (Score:4, Informative)

    by Anonymous Coward on Monday November 03, 2003 @12:56PM (#7378276)
    The content of the book is good. I would agree with the reviews. If you're not familiar with rules engines or how RETE works, you're better off with a simpler book. From personal experience, the hardest part of using rules engines in a production environment is understanding how to use rules engines and the pros/cons of RETE. Rete was originally described by Forgy and has been proven in numerous academic and production systems.

    Rules technology is pretty powerful, but like everything else, you have to know what you're doing. The most common mistake is when a programmer tries to use rules engines in a procedural manner like VB. One area where rules engines are used in production systems is business process management, like processing insurance or handling loan approvals.

  • If you like Jess, check out Drools (Score:5, Informative)

    by Asmodeus ( 10868 ) on Monday November 03, 2003 @12:56PM (#7378277)
    Drools is another rete based rule engine with a java implementation. It has more flexible licencing.

    Asmo
  • Just curious -
    have any of the slashdotters used rule-based frameworks for real-life projects?
    What do you think about Java Community Process Rule Engine JSR [jcp.org]?
    What about frameworks that try to keep things simple, like Ruleaid [ruleaid.com]?
    • have any of the slashdotters used rule-based frameworks for real-life projects?
      Back in a previous life (circa 1988), I did a little rule-based "expert system" programming for a major defense contractor using CLIPS, a forward-chaining tool based on the Rete algorithm. The application was to advise users of a particularly arcane computational fluid dynamics program how to set up its myriad input parameters so that the program wouldn't blow up.
    • Our NeXpose [rapid7.com] security scanner uses JESS to perform vulnerability assessments against remote systems. The expert system is a nice way to have NeXpose not only identify vulnerabilities, but also take advantage of the vulnerabilities to perform more tests. It can be done without an expert system, but it works very nicely using JESS.
    • Theres quite a bit out there using commercial software such as JRules (http://www.ilog.com) - big bucks tho'. I've done a couple of projects in the finacial sector using JRules and it is very good when you have a set of business rules that change frequently (yes, even faster than the build time of a slashdotter project....), or in the rare instances when your users are clueless..........
    • I created a rules-based system for a financial institution back in 1996 using CLIPS (the C-based precursor to JESS). It is still being used on the trading floor today, as far as I know.

      I am also planning on using JESS for the AI for a large Java-based online game I'm currently working on. I am really looking forward to using the backward-chaining capabilities of JESS for this.

      I think JESS (and CLIPS) is best suited for fairly complex systems where you want to break out the rules separately and let non-

    • Actually I am currently trying to use some of this in a new windows-based(java is ok) project and I have been evaulating various systems. Jess happens to be one of them along with it's fuzzy logic counter part, FuzzyJ. Have a quote for both on my desk. So.. If anyone has some recommendations.. :) Ideally It would integrate pretty easily with a database, support mixed chaining, the backward-chaining wouldn't be some form of kludged forward chaining, fuzzy logic, and confidence values. Though when it com
    • Although there are a number of posts that discuss how old rule based programming is, how hard it is to use, how out-dated, etc.; I totally disagree. Every language may have its purpose, so rule based programming isn't a solution for everything. I have never used JESS, but use CLIPS, which it is based upon. I find CLIPS to be an extremely useful system, very well thought out, and easy to extend. Our system is written in C++ and uses CLIPS to implement the business logic. The system has been in place for 7 y
  • Would be nice to have something like this
    for the regular *nix environment.

  • Jess in action somewhat fustrating... (Score:5, Interesting)

    by peter_gzowski ( 465076 ) on Monday November 03, 2003 @01:06PM (#7378362) Homepage
    Jess is very handy, don't get me wrong, and the Java API is great except for one large omission:

    Right now the jess.Defrule class does not expose enough public methods to properly create one outside of the jess package.

    That's straight out of the latest Jess documentation [sandia.gov]. You can't construct rules from Java! Well, you can pass a text string to Rete.executeCommand, but this is hardly elegant. Grrr... Am I missing something here? If not, then PLEASE give me a constructor for Defrules, Mr. Friedman-Hill.

    It's getting frustrating enough that I've been interested in an open-source alternative to Jess (academic license is no charge, but you have to pay for it for commercial use): drools [drools.org]. This has to be the dumbest project name ever, and I haven't even looked at much of the code yet, but it looks promising. Anybody have any experience with it? Please hold back your drool jokes for now...

    • The obvious "solution" (aka workaround) is to create your own local jess package and put your extension in that package. E.g. org.jess.rules is a local directory in your build tree and you can put your new Java rule classes in that package. When you compile your rules will be in the same package and the compilation will succeed.

      I know, an ugly hack it is. But it will work until the class exposes public methods for extension.

    • Trust me, you're not the only one

      A few months ago, we had to implement a rule-based system for our AI course, using Jess. Now, I'm all for CLISP-like syntax, but it's very annoying to actually get something working in Jess: the documentation on the site was incomplete and sketchy (had to discover how stuff worked the hard way, by breaking it) and also to me it seemed Jess wasn't even complete (defqueries were very messy, although using the java API should have proven better results. maybe). Our Mr. Friedma

  • Can anyone tell me if this Jess is related in any way to the JESS [sourceforge.net] language that runs Warcraft 3? ;) They are not exactly the same but I'm trying to figure out if, say, the WC3 version is in any way based off Jess.

  • Less-restrictively licensed alternative (Score:5, Informative)

    by watchful.babbler ( 621535 ) on Monday November 03, 2003 @01:13PM (#7378411) Homepage Journal
    Should you wish an alternative to the commercially-licensed JESS, Stanford has its own Java Theorem Prover [stanford.edu], DAML-compliant and capable of handling forward- and backward-chained reasoning. Object code can be freely redistributed.

    • Re:Less-restrictively licensed alternative (Score:1, Informative)

      by Anonymous Coward
      From my experience, the one problem with Java Theorem Prover is that it doesn't allow for rules. It does reasoning only with properties defined by DAML/RDF. It's a nice piece of software but if you want to specify rules (complicated, or otherwise) you have to use some other system (Prolog, JESS, CLIPS, etc.)


      BTW, DAML is being replaced by OWL, a W3C standard.

  • Rule-based systems (and far better ones than JESS) have been available for nearly 30 years now. I wrote one in LISP for an college AI class. Prolog is a rule engine.

    Implementing rule-based programming in Java is like putting lipstick on a pig (if you don't know, rule-based programming is the lipstick). It is best to leave rule processing to a language designed for it and use Java for other tasks for which its better suited, such as interaction.

    • Just curious. Why do you think Java is ill-suited for rule processing?

      • Why do you think Java is ill-suited for rule processing?

        I didn't say that, but your statement is true: Java is ill-suited for rule-processing because there is no question that it cannot compete with languages designed for that purpose. Its a matter of what a language is suited for:

        1. Java was designed to control appliances and hardware devices, failed there,
        2. Java was remarketed to WWW browsers, failed there,
        3. Java was remarketed to WWW servers, where it now is barely holding off a competitor that charges $

        • Re:Nothing new - Better languages than Java for th (Score:4, Insightful)

          by axxackall ( 579006 ) on Monday November 03, 2003 @04:41PM (#7380570) Homepage Journal
          "why would one perform a task in Java that can be more easily, more quickly and more cost-effectively done in a readily-available language designed for the task?"

          Why managers still insist we use JMS instead of Erlang or Jabber?

          Why managers still insist we use EJB even when a single container is enough and no load-balancing required?

          Why managers still insist we use Oracle for databases with 10 tables of 1000 records each 100 transactions a day?

          Why managers still insist we use MS Exchange server when we don't use anything besides email from it (no tasks or calendars, no public folders)?

          Why managers still insist we use ... wait a minute, now I know "why" - because of managers, they still have no brains in the head and no honesty in the heart. That's why.

  • My favorite is Mandarax [mandarax.org]. It's a Java-based backward chaining rule engine with excellent documentation. I've found it to be fast and extensible. And even better, it's LGPL!
  • It may have 'more flexible' licensing, however it is non-free: 'Jess can be licensed for commercial use, and is available for academic use.' This is not a problem per-se, I'm just a little surprised that this article is nothing more than an advertisement for a book on a non-free, commercial piece of software...
  • GNU Prolog Java [sourceforge.net]

    JavaLog [unicen.edu.ar]

    More Links [kobe-u.ac.jp]

  • CLIPS (Score:2)

    by jefu ( 53450 )
    Jess is really a java embedded version of CLIPS which is still available for free at this site.

    I think the licensing issues are annoying enough - I could get an academic license as I teach at a university, but when (a while back while I was "under" employed) I tried to get a version so I could do some experiments (I wanted to try using it as a bit of support software for a volunteer organization even) and maybe use it in classes at some future point and discovered the licensing was going to make that imp

  • Know about any other books or downloadable papers that provide an introduction to the theory behind rules engines and/or the Rete algorithm? I haven't been able to find anything useful on the web. Any search turns up sites hyping their own product.

  • Nasty Rete Blackboard vs. Ranking (Score:5, Interesting)

    by MonkeyBoyo ( 630427 ) on Tuesday November 04, 2003 @01:00AM (#7384174)
    The Rete [lispworks.com] algorithim [temple.edu] (Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem by Forgy in Artificial Intelligence 19, September 1982) is an efficient solution to a problems given in a specification that should never be used because of conceptual nastiness.

    The attractive promise of declarative rule-based systems is that each "fact" (base or implicational) in the problem domain can be stated as a rule. But this is hardly the case in Rete based systems.

    The Rete algorithm was designed to efficiently implement the non-monotonic forward chaining "blackboard" paradigm. A Rete inference system has a "blackboard" of facts that a large number of rules monitor, and when the some facts on the blackboard match the condition of a rule, the rule can fire and add information to the blackboard (monotonic) or change or delete information from the blackboard (non-monotonic). The main conceptual issue in this sort of system is what to do when the blackboard satisfies more than one rule. The problem is that firing one rule may change the blackboard so that another rule that could have fired can no longer do so. So Rete ranks the applicability or rules.

    Thus a blackboard system winds up with rules whose meaning is not just contained in a rule but has to be inferred from all of the other rules that might be fired by similar input conditions. Most Rete based applications I've looked at wind up using the blackboard to essentially implement program counters to control program flow. And in general, adding a new rule may generate new solutions but it also may break prior solutions.

    Pure monotonic systems (with forward and/or backward chaining) are conceptually very easy to analyze because all of the "facts" are truly independent.

    One can add a form of non-monotonic behavior to monotonic systems by ranking their solutions. E.g. a monotonic system generates N solutions but ranking via some ordering prunes these down to say 1 or 2 best solutions. This external ranking is non-monotonic because adding new facts to the monotonic part may result in different "best" solutions.

    So, basically I am advocating an inference system which is conceptually defined as results = rank(infer(facts, data)). If these functions have good mathematical definitions then it may be possible to implement their combination so that ranking controls or happens during the inference process but the results look as if it was external, and thus one avoids the computational horror of over-generation by the "infer" function.

    Rete however explicitly and globally performs the ranking process during inference and an arbitrary Rete rule set is probably NP complete to analyze. But maybe a good implementation of a conceptual separation of "rank" and "infer" could be realized by a Rete-like network.
  • Wow, this book got the highest rating of any review I've ever seen on /.

    (For those that didn't look it's rated 1930110898)

Slashdot Top Deals

Old programmers never die, they just hit account block limit.

Close