Will JBoss Rules 3.1 Do for BRE’s What mySQL Did for RDBMS’?

Dietrich Kappe, Sunday, April 22, 2007 @ 1:55 pm

While JBoss Rules 3.0.x has been a great step from its predecessor (the unfortunately named Drools) -- providing a rule editing environment, universal and existential quantifiers (the "not" A is the same as "for all" ~A), and Domain Specific Languages (DSL's) -- there were still a few things missing. I've watched the progress on 3.1 with barely contained excitement and impatience, but the result has been worth the wait. The 3.1 M1 drop contains operations on collections:

rule "Find interesting crash events, with 10 or more port scans within a 1 day window"
when
$crash : OutageEvent( eventType == OutageEvent.SERVER_CRASH)
ArrayList( size > 9) from collect ( HackEvent(hackType == HackEvent.PORT_SCAN, $date : eventDate -> (DateHelper.withinDayWindow($crash.getEventDate(), $date, 1))))
then
suspicious.add($crash);
end

There is also the accumulate operator, which is even more powerful than the collect operator. The documentation has lagged a little behind (it isn't a full on release, after all), but you can see some examples of it's use here. I find that I use these sorts of collection operations quite a bit. That being said, the above rule isn't terribly efficient. If you have about 50 of those rules and lots of events of both categories, you will run into some cross-product hell (sort of like a poorly thought out database join). I'll show some ways of making this sort of rule more efficient in an upcoming entry.

Finally, the system now in theory allows better debugging of rulesets. The various views into the working memory have been around for a while. See below for some of my issues.

A few nits that I'm sure the JBoss Rules team will work out:

• The system desperately needs better syntax error handling in rule files. Right now the stack traces you get out of the parser/builder are pretty cryptic.
• While you can now set breakpoints in the rule files, it doesn't seem that they are recognized by the debugging environment. As of now, you can only set breakpoints on a WorkingMemory fireAllRules call. Not that useful for debugging rule issues. I'm not sure if this mod is supposed to address that problem, but regardless, it would be handy to have a fireSingleRule call so one can control the execution of the rule engine more closely.
• A real-time audit view to inspect engine events would be handy.
• The graphical RETE display would be more useful if the nodes were labeled. A display showing the facts in each node during execution would be too much to hope for, but one can dream.

The best thing about this latest version of JBoss Rules is, of course, that I can now start developing non-trivial examples and publishing them without having to constantly caveat that "this feature is present in Blaze and ILog, but not here." An even more interesting question is this: since JBoss Rules is getting close on being a reasonable alternative to some of the commercial products, will what happened in the database arena with mySQL also happen in the BRE arena? Will costs come down, interoperability increase? Will the commercial vendors concentrate on service, support and high end features? Will these same vendors become more open and share more information with the public? I don't think BRE's will ever be as widespread as RDBMS's, but I think the same dynamics might apply.

Some things to look forward to that I hope the JBoss Rules team is thinking about: rule management, specifically rule repositories and deployment management, e.g. revision control for rule sets and deployment of rule modifications to distributed, live production engines; Rule analytics, e.g. analysis of a rule set to see if it contains likely problems (infinite loops, possibly bad logic, etc.), and stats on actual rule execution, performance, etc.

Technorati : bre, business rules, drools, jboss rules

business rules

Comments: 3 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   One of the biggest benefits of 3.1M is the huge performance improvement. The memory foot print is way smaller than before and the hashed memory implementation is much much better now. The enhanced DSL feature should also make things easier for people using DSL. I’m not a member of jbossrules and don’t speak for them, but users should get an instant benefit at runtime with the next release.

   peter

   Comment by Peter Lin, Monday, April 23, 2007 @ 7:25 pm

2. 

   You may want to check this out: http://markproctor.blogspot.com/2007/05/brms-has-landed.html

   There are a couple other previous posts about it too.

   Comment by Edson, Saturday, May 12, 2007 @ 4:19 pm

3. 

   I’ll second that about the ‘end user tools’ (like the BRMS) being the tipping point for the JBoss rules Engine.

   Sad fact of life that you can have all the optimizations you like in the core engine , but it’s the pretty GUI for writing rules that gets noticed

   I think the MySql comparison is particularly Apt: Both appeal to people who might not have been able to consider / afford a full featured db/rule engine in the past.

   Paul

   Comment by Paul Browne, Friday, March 7, 2008 @ 8:17 am

Leave a comment