Slashdot Mirror
Drools JBoss Rules 5.0
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 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.
You open-source guys need to pick some better names.
Woot! Another shill review of a Packt Publishing book by RickJWagner!!! Keep the shilling coming, bro!!
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.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
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
It's quite powerful when used right..
Slashdot needs Geekcode | Can anyone recommend any good SCIFI? My tastes: Foundation, Startide Rising, CITY, Ringworld,
Declarative languages are nice. By their nature they're closer to "Do What I Mean" than other languages, but it's still possible to screw them up. They can also quickly devolve into extremely complicated programs that would be trivially simple in procedural languages. Like any tool, declarative languages are best used when appropriate and ignored when they're not appropriate. Never send LINQ to do an loop's job.
The reason the author has few insights is because the author is a newbie to rules. There are far better books on production systems and proper rule usage like Jess in Action. Read it to learn how not to use rules!
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.
Support my political activism on Patreon.
'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).
...oh wait. :(
There's no -1 for "I don't get it."
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.
Populus vult decipi, ergo decipiatur...
"Force shits upon Reason's back." - Poor Richard's Almanac
Found a Friends episode... You're going to need to provide us with more keywords there, buddy.
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?
Breakfast served all day!
If you want to REALLY learn how to use a rule based expert system (and this is embedded deep in the Drools documentation by Marc Proctor himself) get the book: JESS IN ACTION.
It teaches the best principles of declarative programming with lisp syntax. After going through that book, i was able to code rules in the Jess Rule Engine, and transition to CLIPS,LISP, and Drools quite easily because i knew a good foundation for rule engines. Think of it as learning Object oriented programming in Java and then applying those principles to other languages becomes much easier.
It's pretty easy to Google it just from the information given.
I don't believe in time. It's a grand conspiracy designed to sell watches.
Doesn't JRules have a BRMS in the form of their Rule Team Server?
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.
...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
to implement say a stock exchange where you have to deal with 100's of thousands of business messages a second with absolute 100% reliability and fault tolerance. Call us whatever names you like, but in this business you walk the walk and bullshit lasts 9 seconds. There really is no other tool out there that lets you build REAL line of business application systems with anything like the scalability and with anything like the efficiency of either manpower or hardware. Anyone who doesn't know that lives under a rock from my perspective.
You can certainly do a LOT of things with other tools, but there simply IS a class of applications that are in high demand for which JavaEE is the right answer.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
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.
<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.
StoneCypher is Full of BS