×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Drools JBoss Rules 5.0

samzenpus posted more than 3 years ago | from the read-all-about-it dept.

Book Reviews 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.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.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

55 comments

drools, really? (2, Funny)

Anonymous Coward | more than 3 years ago | (#33886310)

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

Re:drools, really? (1)

Alain Williams (2972) | more than 3 years ago | (#33888652)

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

Woot! (0, Troll)

Disgruntled Goats (1635745) | more than 3 years ago | (#33886326)

Woot! Another shill review of a Packt Publishing book by RickJWagner!!! Keep the shilling coming, bro!!

Re:Woot! (0)

Anonymous Coward | more than 3 years ago | (#33886486)

Yeah what nerve posting a review for a programming book on a technology blog. That sonova bitch.

Re:Woot! (3, Insightful)

kg8484 (1755554) | more than 3 years ago | (#33886548)

If he was a shill, wouldn't this be a positive review?

Re:Woot! (0)

Anonymous Coward | more than 3 years ago | (#33886586)

How is it not?

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.

So he would recommend it to anyone who is a drools user and calls it a keeper but that's considered a negative review? lolwut?

Re:Woot! (1)

maxume (22995) | more than 3 years ago | (#33886838)

So does positive require that he give it a 10/10 or something?

Re:Woot! (1)

kg8484 (1755554) | more than 3 years ago | (#33887528)

For it to be a shill, yes.

Re:Woot! (1)

Lunix Nutcase (1092239) | more than 3 years ago | (#33887690)

For it to be a shill, yes.

Why? The importance of shilling is to get the advertising out there. If you were to constantly give things 10/10 you would eventually just get filtered out as spam. A clever shill will be far more subtle.

Re:Woot! (1)

kg8484 (1755554) | more than 3 years ago | (#33888318)

A clever shill will create a new user account when their old one is being filtered. They will not submit a review whose summary states, "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."

Re:Woot! (1)

gl4ss (559668) | more than 3 years ago | (#33891058)

no. a clever shill never gets banned, because he is not obvious. you think business analysts read slashdot for book tips? probably no, so they're a group that you can insult slightly in the review. "they can't understand anything from this, but surely you could" the review probably isn't by a shill, but it's about a book on a system nobody should care a rats ass of, except if you're working with it, which the author is, so for the review author to pimp drools is perfectly logical.

Re:Woot! (1)

Lunix Nutcase (1092239) | more than 3 years ago | (#33892868)

A clever shill will create a new user account when their old one is being filtered.

A clever shill would never get filtered. If you are being filtered and have to make a new user account to continue shilling means you're a huge failure.

They will not submit a review whose summary states, "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."

And then you ignore the part where it says the book is recommended for Drool users and that it's a keeper. It's hilarious how you focus on a single sentence to claim this is a negative review and then ignore the fact that he's telling people to buy the book.

Re:Woot! (4, Informative)

RickJWagner (1297357) | more than 3 years ago | (#33889354)

Yes, it's true I do a few book reviews. But there are a few things you should consider: - I never accept any payment from Packt or any other publisher. My reviews are done purely for the joy of reading and learning. - I always write what I honestly believe to be true. If a friend were to ask me what I thought of a book, I'd tell that friend just what you see in the review. - I always post reviews under my real name. It's part of giving you my honest opinion. So does that make me a shill? I don't think so, but it's in the eye of the beholder. Rick

Silly question (4, Funny)

$RANDOMLUSER (804576) | more than 3 years ago | (#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 (3, Funny)

genner (694963) | more than 3 years ago | (#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!

Re:Silly question (0)

Anonymous Coward | more than 3 years ago | (#33890620)

Ah, how I yearn for the good ol' days when we didn't need no stinkin' business analysts. We programmers made the users run the applications they wanted, whether they liked them or not.

Declarative is nice, but... (0)

Anonymous Coward | more than 3 years ago | (#33886594)

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.

Re:Declarative is nice, but... (1)

dodobh (65811) | more than 3 years ago | (#33890476)

Unless LINQ expresses your intent better, and in the process renders the formal looping construct redundant.

Author is a rule newbie (0)

Anonymous Coward | more than 3 years ago | (#33886640)

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!

Non-programmers should not program (2, Insightful)

bluefoxlucid (723572) | more than 3 years ago | (#33886676)

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:Non-programmers should not program (1)

Splab (574204) | more than 3 years ago | (#33886824)

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... (2, Interesting)

TheTrueScotsman (1191887) | more than 3 years ago | (#33886680)

'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... (4, Insightful)

Shayde (189538) | more than 3 years ago | (#33886798)

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... (0, Troll)

Anonymous Coward | more than 3 years ago | (#33886920)

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

Re:Sigh... (3, Insightful)

bill_mcgonigle (4333) | more than 3 years ago | (#33887234)

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.

Call me when you want (1)

Giant Electronic Bra (1229876) | more than 3 years ago | (#33890384)

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.

Re:Call me when you want (-1, Troll)

Anonymous Coward | more than 3 years ago | (#33890970)

Stock exchange? You mean the stuff that only runs a few hours each day and only 5 days in a week?

Stuff is so much easier if you get scheduled downtime every day.

As for integrity, it's no big deal: they already roll back transactions not because the system has a bug but because a favored company makes a mistake... So there's already no integrity ;).

Meh.

Re:Sigh... (0)

Anonymous Coward | more than 3 years ago | (#33892374)

Servers are cheap, RAM is cheap, CPU cores are cheap, VMs are cheap.

Programmers aren't.

Java performs like C++, but with far less development overhead. It's far far faster than PHP, Ruby, etc. It also has bazillions of libraries available, and the bloat probably comes from projects using loads of them instead of reimplementing them from scratch with bugs.

Re:Sigh... (0)

Anonymous Coward | more than 3 years ago | (#33887324)

I've programmed in many different languages, the only one that never intrigued me in any way was Java. I do like that you are now willing to admit that J2EE v1 and v2 are crap, because I experienced that crap first hand. I was programming in them many years back, they were all the rage, Java developers around the world were going nuts, claiming the second coming, and oh yeah you had to use these tools if you wanted to build an "Enterprise" application. My head still spins from all the nonsense that these guys put out, and now they freely admit they were lying to us before about how great things were, but yet expect us to go for that ride again.

No thanks, I will not be picking up a J2EE v3 book or some book about a bloated JBoss application server! Long live the LAMP stack and go Ruby! By the way a lot of the financial sector runs on Python and/or Perl and 90% of Bioinformatics is done in Perl. Java is pure garbage if you want to go the "Enterprise" route go .NET at least you'll get a nice IDE for putting up with all the bloat!

   

Re:Sigh... (1)

TheTrueScotsman (1191887) | more than 3 years ago | (#33891144)

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 weekends to put that together).

No smart companies are using J2EE (do you think Google use it?) - only old-fashioned banks and sundry other MBA containers.

googled it... (0)

Anonymous Coward | more than 3 years ago | (#33886902)

Found a Friends episode... You're going to need to provide us with more keywords there, buddy.

Re:Sigh... (1)

kevinNCSU (1531307) | more than 3 years ago | (#33887024)

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.

Why RTFA? (1)

mujadaddy (1238164) | more than 3 years ago | (#33886860)

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.

Fiendishly difficult (1)

PCM2 (4486) | more than 3 years ago | (#33887922)

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?

Re:Fiendishly difficult (1)

not-my-real-name (193518) | more than 3 years ago | (#33888618)

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.

Re:Fiendishly difficult (1)

RickJWagner (1297357) | more than 3 years ago | (#33889292)

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 Regards, Rick

Learn JESS before Drools (0)

Anonymous Coward | more than 3 years ago | (#33888274)

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.

Doesn't IBM JRules have BRMS... (1)

alchemy101 (961551) | more than 3 years ago | (#33888834)

Doesn't JRules have a BRMS in the form of their Rule Team Server?

Re:Doesn't IBM JRules have BRMS... (1)

RickJWagner (1297357) | more than 3 years ago | (#33889306)

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 (2, Informative)

eap (91469) | more than 3 years ago | (#33888852)

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.

Re:BREs can't solve every problem (1)

RickJWagner (1297357) | more than 3 years ago | (#33889324)

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

Re:BREs can't solve every problem (0)

Anonymous Coward | more than 3 years ago | (#33890540)

I can't understand why would one want to use BRE to compute average age?

Re:BREs can't solve every problem (1)

hattig (47930) | more than 3 years ago | (#33892492)

It would be one step in a process that involves hundreds of steps.

So why not calculate the average at data collection time and store it alongside the other data? Rules change. Often. It's average age this week, but last week it was absolute age of drivers. Your programmer was on holiday during the change (which was told to the business rules team two days before going live date). Your rules engine needs to be able to do calculations.

So you submit facts you've gathered (from customer, credit agencies, etc) into the system, and get answers out, and all the volatile, mutable business rules, including calculations, go into the rules, workflows, etc. Hopefully the rule engine is extensible, so you can add custom steps (e.g., call a webservice, etc) into your workflows.

If you want dummies to understand it, (1)

Kaz Kylheku (1484) | more than 3 years ago | (#33890504)

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!

I don't believe it (1)

stonecypher (118140) | more than 3 years ago | (#33894336)

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.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...