Topic: RETE

GWT Showcase – BRMS for JBoss Rules

Dietrich Kappe, Thursday, June 19, 2008 @ 9:06 pm

JBoss Rules (the former "Drools," though it's sad to see that cringe-inducing name making a comeback) is a Business Rules Engine (BRE). Those are the logic engines that allow you to execute a large set of "if-then" rules against a large set of facts (the most common algorithm to achieve this kind of performance is called RETE, from the ancient Greek for "net"). For more on BRE's and how to use them, have a look at our Business Rules blog.

One of the things that has differentiated commercial BRE's like Blaze Advisor and ILOG JRules from the Open Source JBoss Rules is the tools. The commercial BRE's were part of a suite of development and management tools -- IDE's, "natural" language support, Business Rules Management Systems (BRMS) -- that made their use in a corporate IT "ecosystem" much easier.

With version 4 of JBoss Rules, you now get a powerful workbench plugin for Eclipse, support for Domain Specific Languages (DSL) that mimick natural language, and a web-based BRMS. With it you can deploy, roll back, and report on your rules.

The BRMS has a nice Ajax interface and is in fact written in GWT. This is a natural for a Java-based system like JBoss Rules. If the developers who use and develop JBoss Rules can also tinker with the BRMS interface (GWT==Java in the browser), the odds are better that the BRMS will evolve apace with the core system.

Compare this with a framework like Echo2/3 where there is only a small cadre of developers who develop the JavaScript piece of what is essentially a Java centric framework, and consequently the development has lagged relative to other frameworks. So, good decision for JBoss Rules and probably a good decision if you are adding a web interface to your own Java system.

• Digg
• Reddit
• del.icio.us

Comments (2)

Software Development

Something to watch: Ruleby, a Ruby RETE Implementation

Dietrich Kappe, Friday, December 14, 2007 @ 2:20 pm

As Rails (and Ruby) climbs the hype curve, more and more systems are getting implemented that could benefit from a BRE. There are two (Rools and SIE) that don't use RETE. But Ruleby does, though it is in version 0.1 now. I'll post a couple of examples in it in the next couple of weeks.

Technorati Tags: bre, ruby, rails, rete, rools, SIE, Ruleby

• Digg
• Reddit
• del.icio.us

Comments (1)

business rules engines

Resources and Announcements

Dietrich Kappe, Sunday, September 3, 2006 @ 2:51 pm

It's been a busy month that has taken me away from focusing on Business Rules, but things are almost back to normal and I should have another entry on BRE patterns out this coming week. In the meantime, I thought I'd share with you two interesting resources that I came across recently.

The first is Pychinko, a native Python RETE-based business rule engine. This points out that Java, C# and C are not the only languages that can benefit from a business rules approach. In fact, as you'll see in my next BRE patterns entry, I'd argue that object orientation and business rules are a natural fit, regardless of the specific language used. If your requirements call for any sort of embedded scripting, this solution might be worth considering.

I'm experimenting with a new way of finding resources on the Internet. With this new method, I was able to find the second item, a thorough introduction to business rules and RETE over at InfoQ, entitled Real-World Rule Engines. The article covers quite a bit of territory. Among the topics addressed are:

• What are rule engines
• How do you use them
• Architecting with Rule Engines
• Managing Rules
• Rule Engine Patterns and Anti-Patterns
• Governance
• Thoughts on rule writing

Definitely a good resource for those wanting to get started with business rules engines.

Last, I wanted to pass on the news that James Taylor has moved his blog over to a new url: http://www.edmblog.com/weblog. If you are a regular reader of his blog, you already probably know this. If you aren't a regular reader of his blog, you really should be.

 
  Technorati : RETE, business rules

• Digg
• Reddit
• del.icio.us

Comments (0)

business rules engines

Conflict Resolution – Why BRE’s Give Different Results

Dietrich Kappe, Tuesday, July 11, 2006 @ 9:00 am

A while back in 2004, Daniel Selman, the JSR-94 Specification Lead, published an article on the future of the specification. It's well worth reading in any case, but one particular observation stuck out:

In my opinion the root problem is not the lack of a standard rule language, it is the lack of a standard execution semantic for rule engines.

What the heck does that mean and why is it important? Well, without getting too technical, a BRE engine has a way of expressing rules. This way of expressing rules constitues a programming language. Any programming language has a syntax -- what are the valid programs, made up of keywords, identifiers, operators, etc. that can be written in the language -- and semantics -- what the program actually means or does. There are ways of formally specifying the semantics of a programming language, typically by translating the programming language into another language that already has a semantics or by mapping a trace-based semantics to the syntax of the language. I said "without getting too technical," so we won't go there.

In the case of BRE rule-sets, we can think of them being translated into data structures for a production systems pattern matching algorithm such as the RETE algorithm, which provides the execution semantics for the rule language. There are at least two ways that this can make for different semantics, i.e. different results from the execution of a rule-set. First, different algorithms can have different execition semantics, i.e. they process the rule-sets in ways different enough to give different results. Second, some parts of an algorithm can be variable.

The one bit of variability that immediately comes to mind is conflict resolution. Whenever a rule engine evaluates a rule-set, there is a likelihood that more than one rule will be activated. How to choose amongst these rules? There are a few different conflict resolution algorithms, each designed to achieve a different effect. Just a few examples:

• Salience. This is where the rule author assigns a priority to a particular rule. The highest priority rule is picked from all the matching rules. In a medical scenario, you may want the cancer rules to have a higher priority than the asthma ones.
• Longest matching. With this strategy, you execute the rules with the most number of clauses, i.e. the greatest number of AND'ed an OR'ed conditions. The idea here is that the rule with the most clauses is the most specific and should be fired first.
• Newest facts. Here the rule that was triggered by the newest fact or facts takes precedence. If you view the firing of foward chaining rules, this is sort of like a depth-first search -- keeping going down the branch that generated the latest new facts.
• Don't choose instantiations that have previously fired. If a rule already matched on certain facts and was fired, don't fire it again. The idea is to always do new things.

There are quite a few other conflict resolution strategies, of course, but I've listed a few of the more common ones here. (We haven't really touched on domain specific conflict resolution strategies here.) You can chain these together, i.e. salience first, then, if you have several rules of the same salience, pick the longest matching one, etc.. The important point is that different resolution strategies can result in rules being fired in a different order. A change is some facts can result in some rules that were matched early on, but passed over by the conflict resolution strategy, not being executed at all.

Now you should probably write your rule-sets so that order of execution doesn't matter. But in practice, this ideal isn't the case. Often, rules are harvested from existing business processes where order is already enforced in some way.

While building rule-sets that are execution order independent is a good best practice, it isn't always practical. BRE's are complex systems with complex behaviors. Having different conflict resolution strategies is often necessary and desirable. I'm not proposing a silver bullet here to make all rule exection semantics the same, though it might be nice to make them more transparent and configurable. Just be aware that standards like JSR-94 are great for integration, but don't guarantee that you'll get the same results with those different engines. Understand the tools you use.

• Digg
• Reddit
• del.icio.us

Comments (1)

business rules engines