Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Book Reviews

Drools JBoss Rules 5.0 55

RickJWagner writes "Drools (sometimes called 'JBoss Rules') is a Business Rules Engine and supporting ecosystem. Drools, like other BREs, promises to lower the barriers to entry for application programming. Armed with this book, can a Business Analyst be used to write application logic? I don't believe so, and I'll tell you why." Keep reading for the rest of RickJWagner's review.
Drools JBoss Rules 5.0 Developer's Guide
author Michal Bali
pages 320
publisher Packt Publishing
rating 7/10
reviewer RickJWagner
ISBN 1847195644
summary Guides you through all of the features of Drools, such as dynamic rules, the event model, and Rete implementation with high performance indexing.
Business Rules Engines, especially those based on the Rete algorithm, strongly favor rules written in 'if/then' format. (Sometimes the marketers will call this 'when/then' logic.) The basic premise is that you write your rules as a series of rules that individually specify matching logic for some objects you make available to the engine, then you specify what to do if any of the objects match your conditions. Example "IF there is a customer with age > 60, THEN allow senior discount". That's the marketing promise, anyway.

This book does a great job of showing you how to build a banking application, complete with validation, data transformation, and reporting functions. Each of these are implemented using Drools, of course, and workable code is provided at every step. The author takes care to explain nearly every line of code provided and highlights important classes and features as they occur. I think the author did well here.

Writing business rules is quite a bit different than writing logic in a language like Java or C++. I'd compare it more directly to writing SQL-- you're declaratively specifying which objects (out of a group) you want something to happen to, so you're thinking in terms of matching logic rather than ordered steps in an algorithm. You also don't always have complete control over the order in which your rules are fired, so it's not like garden-variety coding where it can be treated like a 5-step recipe. It just takes a different mindset. Once you're used to it, things are easier to understand, and this book can help. (By the way, I've fooled around with BREs for about a decade now, and support a production application that uses Drools, so I'd consider myself moderately skilled in BRE usage.)

In the course of writing the banking application the book is anchored upon, the author occasionally makes design decisions that are specific to doing things "The Rule Engine Way". One example is the use of 'global' facilities for validation reporting. The author might have chosen to implement this another way, but chose what he considered the best path and briefly explained his reasoning in making the choice. That's exactly the kind of thing that I think a BRE-literate reader would find of value-- expert insights into how to use this tool, not mere explanations of syntax, etc. Unfortunately, these insights were relatively few in nature and not highlighted where they were presented, so they might not be apparent to readers that aren't already thinking in the BRE way.

One thing the book glossed over that I wish was given more coverage is Guvnor, the Drools Business Rule Management System. Basically, a BRMS is a web application used to change existing rules, write new rules (provided they have been pre-templated by a rule author, usually), and version the rules. I'm told this is one of the key differentiators between Drools and commercial offerings like IBM's JRules, so it's a little disappointing that it was given virtually no coverage in this book.

As the author fleshes out the banking application, we encounter a little scope bleed as the reader is introduced to iBatis, Spring and Tomcat. While I see how these are necessary for the provided application, I viewed them as distractions and potentially barriers to successful implementation for some readers. To counter that, I offer the author kudos for covering a multitude of Drools facets like Domain Specific Language inclusion, Complex Event Processing, and rule ordering through "Drools Flow". All these are valuable tools in the Drools user's toolbox and they are given adequate coverage.

As I hinted at in the opening paragraph, marketers of BREs love to show demonstrations where rules are written in shocking clear 'if/then' syntax. These rules are purported to control powerful application logic and can be maintained by low-cost business analysts. Is this reality with Drools? No, I'm afraid not. It's also not true with JRules, Blaze, or any other Rete-powered BRE. What marketers will show you is how easy rule maintenance can be-- but they're not showing you how difficult things can be when your logic doesn't neatly fit the 'if/then' paradigm. For example, commercial vendors love to show insurance logic where they offer rules like 'IF the driver's age is over 25, THEN give them a discount'. Next time you see one of those, ask the marketer to show you something along the lines of 'Calculate the average age of the drivers in the household'. Notice how that doesn't say 'IF'? Requests of this type will typically require a skilled rule author, not a business analyst copying from a rule template. This type of logic does not play to the strengths of the engine. Actually, implementing this type of logic can be fiendishly difficult-- that's the reason BRE developers are among the best paid of application developers (Check Dice or I say all this to let you know BRE usage sometimes is easy, sometimes is really hard. In a workspace like that, I like to have advice handy from a multitude of providers, and I'll be happy to add this book to my reference collection. I just wish there were more highlighted best practices in this book to help the user leverage the author's expert experience. (By the way, there are a few more books on rules engines available, but most all of what I've seen is truly awful. I do believe they were written by business analysts, and probably ones who have never actually written an application powered by a BRE. I do not find that fault with this book.)

So, what's the verdict? I'm glad I read this book (twice, to make sure I got everything) and would recommend it to anyone using Drools. If you're not yet a Drools user, I don't think this book offers enough remedial material to effectively help you get on board-- for that I recommend the excellent documentation offered online with the product. (By the way, I hope you like cheese. The Drools doc authors seem to have some sort of cheese fixation, so references to cheese are plentiful.) For a Drools user like me, this book offers a view at parts of the toolkit I hadn't yet used and a view of how an expert user might go about designing an application. I'll call it a keeper.

You can purchase Drools JBoss Rules 5.0 Developer's Guide from Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.


This discussion has been archived. No new comments can be posted.

Drools JBoss Rules 5.0

Comments Filter:
  • Re:Woot! (Score:4, Insightful)

    by kg8484 ( 1755554 ) on Wednesday October 13, 2010 @03:37PM (#33886548)
    If he was a shill, wouldn't this be a positive review?
  • by bluefoxlucid ( 723572 ) on Wednesday October 13, 2010 @03:48PM (#33886676) Homepage Journal
    Seriously, think about this. We want non-programmers to be able to implement their requirements. People are absolutely stupid; even programmers are too retarded half the time to think up the implications of one piece of programming logic against another. When we go from "Customizable POS systems that let you run 'promotions' based on purchase conditions" to "let's define customer financial approval processes, legal processes, and other such things with complex interactions in a simple language that any idiot can use," you've just stepped off a very fucking huge cliff. While it's safe for management to say "10% off PILLOWS if BOUGHT IN PAIRS," it's extremely unsafe for them to say anything even slightly more complex. Anything that needs a huge book to learn syntax and technique is an autofail.
  • Re:Sigh... (Score:5, Insightful)

    by Shayde ( 189538 ) on Wednesday October 13, 2010 @03:59PM (#33886798) Homepage
    Need to get out more, bro. J2EE is enormously powerful for large scale applications, and is in use just about everywhere in industrial, government, and financial sectors. No, it's not applicable for the latest LAMP whack-site that folks crank out by the bjillions, but it has a very good place when designing extremely large scale multitiered interconnected apps. Oh, and btw, servlets are part of the J2EE spec, so you might want to take that into account as well. My big problem is that most folks don't really understand what J2EE is or how it's applicable. And I will freely admit that J2EE v1 and v2 were decent ideas implemented very badly. J2EE v3, with the removal of mounds of XML configuration, is quite a pleasure to work with, and provides a rich environment to build large scale clustered applications with the benefits of OOP design. No, it's not for everything and everyone. But everytime I see someone wank on about the latest Ruby wonder that makes communication between applications possible (Gasp!) I have to go "er, you mean JMS? the messaging / queue management tool that's been in J2EE since the beginning? Gosh, yeah, Ruby sure is pushing the frontier of design, oo baby."
  • Re:Sigh... (Score:4, Insightful)

    by bill_mcgonigle ( 4333 ) * on Wednesday October 13, 2010 @04:28PM (#33887234) Homepage Journal

    J2EE is also awesome for building extremely bloaty applications that require 50% more servers than something running a non-bloated solution.

    The power of Java/J2EE is that it produces acceptable results when used by the small sigmas of the developer population that makes up the largest bulk of the area under the standard distribution curve. Yeah, it's wordy, yeah, it's hungry, but the Fortune 500 can hire people to work on it and they can afford the hardware and connectivity. And when their app needs to scale, it can.

    The top decile can continue to argue the virtues of Rails vs. Catalyst vs. D'jango, and that's fine, but it's also different. The LISP web hackers are making fun of them anyway.

"Never face facts; if you do, you'll never get up in the morning." -- Marlo Thomas