Jess in Action 120
| 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
- 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.
Jess (Score:2, Interesting)
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 solution and examples to go with it. The zen of O'Reilly how-to books.
I'm not a Java programmer, but I might have a look at Jess. To me, Java is fairly redundant. I don't like it very much because it's not thin. I'm a bare-bones kinda programmer. Cut, cut, cut!
Using Java in college, you had to load all sorts of extra libs you might not use, which seemed wasteful to me. Don't get me started on web applets, which is what they taught at school. How to turn someone off Java? Applets!
Jess seems, at first glance, to be equally as redundant. Perhaps some of you could delve into the benefits of Jess, on my account?
There's a quiz about this (Score:2, Interesting)
'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.'
Jess in action somewhat fustrating... (Score:5, Interesting)
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...
Re:If you like Jess, check out Drools (Score:2, Interesting)
Jess is actually new stuff (Score:4, Interesting)
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].
Nasty Rete Blackboard vs. Ranking (Score:5, Interesting)
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.