Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Book Reviews

Drools JBoss Rules 5.0 55

Posted by samzenpus from the read-all-about-it dept.
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 Monster.com). 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 amazon.com. 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 More

Drools JBoss Rules 5.0

Comments Filter:

  • drools, really? (Score:2, Funny)

    by Anonymous Coward

    You open-source guys need to pick some better names.

    • The initial design of JBoss was on a napkin, then they wondered what else they could do with the napkin .....

  • Silly question (Score:5, Funny)

    by $RANDOMLUSER ( 804576 ) on Wednesday October 13, 2010 @03:28PM (#33886392)

    ...can a Business Analyst be used to write application logic?

    No, however, they can be sliced open like a tauntaun and used as a sleeping bag, if you happen to be trapped at night, out in the open, on an ice planet.

    • Re:Silly question (Score:4, Funny)

      by genner ( 694963 ) on Wednesday October 13, 2010 @03:37PM (#33886546)

      ...can a Business Analyst be used to write application logic?

      No, however, they can be sliced open like a tauntaun and used as a sleeping bag, if you happen to be trapped at night, out in the open, on an ice planet.

      ....and I thought they smelled bad on the outside!

  • Confused? (Score:5, Informative)

    by improfane ( 855034 ) * on Wednesday October 13, 2010 @03:29PM (#33886418) Journal

    Take a look at this to see what Drools can really be used for:

    http://www.redhat.com/f/pdf/jbw/amollenkopf_430_applying_drools.pdf [redhat.com]

    It's quite powerful when used right..

  • Non-programmers should not program (Score:3, Insightful)

    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: (Score:2)

      by Splab ( 574204 )

      We use drools for quite a lot of stuff, some of it is high level and not for the KAMs, but we expect them to maintain decision tables for our core engine based on their sales.

      The "programming" of rules can be quite daunting, but using the spreadsheet option, it's a walk in the park.

  • Sigh... (Score:2, Interesting)

    by TheTrueScotsman ( 1191887 )
    'The Last One' all over again. If you were a developer in the UK in the 80s, you know what I mean, otherwise google it. And J2EE.. is anyone still using that heap of shite? (and I speak as someone who writes boatloads of Java code).

    • 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."

      • I agree with you man it takes a crap load of hardware to run it thus my passionate love for it.

      • Been there, done that. I was writing huge J2EE apps 8 years ago. It's a great framework if you want to keep a few hundred offshore programmers employed, but some of us have moved beyond that.

        I now write massively distributed Java server apps which include automatic deployment and load-balancing, abstracted distributed file systems and distibuted scalable DBs. We use a 'servlet-style' web application framework - but not servlets. We have something tighter, faster and far more scaleable (took a couple of we
    • Yea, I'd say so: J2EE Statistics [builtwith.com]. Considering it's more fitting for larger clustered applications I'm actually surprised it shows up as high as it does on there. It's definately not the choice technology to crank out a quick lightweight webpage but for larger projects with interconnected applications J2EE fills in nicely.

  • ...oh wait. :(

  • Why RTFA?

    can a Business Analyst be used to write application logic? I don't believe so

    You either agree with this statement, or you're a BA yourself, or worse.

  • Calculate the average age of the drivers in the household ... implementing this type of logic can be fiendishly difficult

    Really? Or was your example too simplistic?

    Either the data is readily available or you need a human to obtain the data. Add, divide... pretty easy, no? What am I missing?

    • I think that the point that the author was making is that the logic contains IF, THEN, and comparisons, not add and divide. It may be that the business analysts do not understand math.

    • Hi PCM2. The point I was making is that IF/THEN questions are very easily answered. (And verified by the reader above who mentioned the ease of using spreadsheets.) But if you have a problem that isn't predicated on the attributes of a single object, things can get much trickier. But don't take my word for it-- go download Drools (especially with the excellent Eclipse plug-in) and give it a shot. You'll soon see that there are questions that are easily answered, and questions that are not.... Best Reg
  • Doesn't JRules have a BRMS in the form of their Rule Team Server?
    • Yes, they do. (I've recently worked with that one a bit, too.) But at it's heart ILog (the IBM product) is still a Rete implementation, which means it conforms to the 'IF/THEN' or 'WHEN/THEN' advantage/disadvantage. Interestingly enough, many vendors of BREs view their BRMS as the 'strategic advantage' that commands a higher price. The basic rule engine doesn't seem to be treated this way.... BR, Rick

  • BREs can't solve every problem (Score:3, Informative)

    by eap ( 91469 ) on Wednesday October 13, 2010 @07:19PM (#33888852) Journal

    Having worked on a project from conception through production, written in JRules, I'd have to agree that the marketing examples for rules engines are way oversimplified.

    You're right, they present simple if/then logic as being applicable to every problem. As you demonstrate with the "compute average age" example, this can quickly break down. The problem is that it's hard or impossible to maintain context on an object from rule to rule. BREs expect each rule to be independently applicable to an object. This works in some domains, but many business rule flows require that context be maintained throughout the flow.

    Another problem is database access. BREs expect that the object will be pulled completely from the database at the start of execution, and no further database interaction is required until the object is finalized and persisted. Again, this is way too simple for many business requirements.

    To extend your insurance example, ask how you would calculate a driver's premium based on a code associated with the object. There can be millions of codes for which the premiums may change at any time, so they must be pulled from a database at execution time.

    Extend this to similar db transactions on nearly every decision in the tree, and execution quickly bogs down. Yes, you can cache a certain amount of this data, but with a large enough set, the model breaks. Multithreading and parallel processing will buy some speed, but only so much. If database transactions are dependent on path of execution in the tree, the BRE model will have problems.

    Perhaps the reason rules authors are so well paid (if this is true) is perhaps because they're often required to use the wrong tool for the job. If I were required to use a sledgehammer to chop down trees I would expect better pay.

    • Ah, I believe you are enlightened to 'the Rule Way'. Thank you for the comments, I believe we'd agree on many aspects of the topic. Best Regards, Rick

  • ...and you're in the Bay Area, head on down to the last day of Rulesfest, which includes a Drools bootcamp:

    http://rulesfest.org/html/bootcamps.html [rulesfest.org]

  • don't compare and contrast with C++ or Java. How about something more familiar?

    Let's see, "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. "

    Hmm.

    .group { happen: something; }

    <div class="group">object1</div>
    <div class="group">object2</div>

    Aha, now I get it!

  • The Packt book I bought - Spring Security 3 - is single handedly the worst technical book I've ever owned. The XML build scripts don't even have matching closing tags. When I told the company, they offered me half off on a PDF and asked me to stop telling people in public.

    7/10 my ass. This is a slashvertisement.

Slashdot Top Deals

For God's sake, stop researching for a while and begin to think!

Close