Pathfinder Blog
Topic Archive: Business Rules

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.

Topics: , , , ,

agile ajax Agile Ajax

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: , , , , , ,

Topics: ,

business rules Business Rules

BRE Patterns III: Collaboration Cop, Part II

Dietrich Kappe, Saturday, May 12, 2007 @ 9:58 pm

In explaining this pattern, I wanted to take a step back and explain where and how OO and BRE's intersect. To start with, this excellent post over at Mark Proctor's blog makes the following statement:

Assert all your objects as facts: Rule engines usually know how to handle a fairly heavy load of facts, so let the engine do its magic. If you want to reason over a nested set of objects, assert all of them (not only the top level ones) into the engine and make sure your business model models the relationship between them. After that, writing your rules will be easier and the engine will be able to optimize execution (when compared to using eval and other constructs to access deeply nested structures). Example: if you have an Order fact that contains a list of OrderItems, assert both Order and OrdemItems as facts (if you need to reason over OrderItems too, obviously).

Why, by all that is object oriented, do you have to turn your domain model inside out, exposing what was hidden, unencapsulating what was encapsulated? Isn't this defeating the purpose of object orientation? The answer is, in short, yes. You are defeating the purpose of OO when you expose the innards of your model to the BRE. But it is a tradeoff. You get something for your trouble. Specifically, you get the super efficient rule matching of RETE and it's decendents.

This sort of exploding of the object model happens all the time in systems, and it isn't necessarily always bad. Alen Hollub (author of Why getter and setter methods are evil and other Edsger Dijkstra-like articles) has identified the "procedural boundary layer" and explains it nicely in his book Holub on Patterns: Learning Design Patterns by Looking at Code:

One big exception exists to the no-getter-or-setter rule. I think of all OO systems as having a "procedural boundary layer." The vast majority of OO programs run on procedural operating systems and talk to procedural databases, for example. The interfaces to these external procedural subsystems are by their nature generic. The designer of JDBC hasn't a clue about what you'll be doing with the database, so the class design has to be unfocused and highly flexible. UI-builder classes such as Java's Swing library are another example of a "boundary-layer" library. The designers of Swing can't have any idea about how their classes will be used; they're too generic. Normally, it would be a bad thing to build lots of flexibility that you didn't use because it increases development time. Nonetheless, the extra flexibility is unavoidable in these boundary APIs, so the boundary-layer classes are loaded with accessor and mutator methods. The designers really have no choice.

BRE's are not OO. Yes, the facts can be viewed as objects and the BRE's can be implemented using and OO language and design, but really the internal working of the BRE are most definitely not OO, the more the rule engine knows about each and every object and its innards, the more efficient it can be. Thus the PBL (procedural boundary layer) applies.

As an example why you need to expose all object, consider an order that is made up of line items.

public interface Order {
[...]
void addItem(OrderLineItem item);
boolean removeItem(OrderLineItem item);
[...]
}

Now normally you would hide the details of all the line items inside the class that implements the Order interface. Let's suppose now that we haven't added any of the encapsulated line items to the working memory of the BRE's, just the order. Now let's say we update one of the line items through an operation. The only way we have to telling the BRE that something has changes is by flagging the enclosing Order object. That will trigger a reevaluation of every rule in which the Order plays a part, even ones where the line items play no part.

There are all sorts of ways of dealing with exposing the internals of your domain model to the BRE without breaking encapsulation. One way is to implement both the business interface and a bean interface (getters, setters, etc.) in the implementation (see diagram). The business interface is used within the domain model, the bean interface in the BRE.

BREExample.png

Another approach is to wrap the domain objects in bean containers that access the private instance variables through reflection.

Of course lots of this depends on the specific BRE you are using. Some require you to expose your instance variables directly and don't deal well with method calls. I'd suggest not using those.

Next time I'll go through a simple example using JBoss Rules showing how to convert a domain model to a Collaboration Cop rule base.



Technorati : , , , , ,

Topics: ,

business rules Business Rules

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.

agendaview.PNG

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 : , , ,

Topics: , ,

business rules Business Rules

BRE Patterns III: Collaboration Cop, Part I

Dietrich Kappe, Tuesday, February 6, 2007 @ 12:28 am

The pattern I'm writing about today -- Collaboration Cop -- is much meatier than the two previous ones, in my opinion. This one is all about transplanting the implicit and explicit business rules of an OO system from its objects to an external BRE.

This is a somewhat involved pattern, and I'll provide some more examples and references in part II. Also in part II, I'll run down the differences between the rule classifications that come out this pattern and the ones you commonly see in works by Ross.

Pattern Name: Collaboration Cop

Synopsis
Extract the business logic that is in an OO domain model -- collaboration rules, property rules and controller logic -- and express it as a set of business rules. Activity in the system is triggered by the UI inserting events into the working memory and firing the rules. Objects can be persisted by something like and ORM framework.

Slightly longer version: if you strip away the user interface and the persistence mechamism, a typical OO application is designed around a domain model and controller or service classes that set object collaborations within the domain model in motion in response to external events. The methods of the controller/service classes often correspond to steps in a Use Case. Embedded in the various domain classes is logic about how object can be modified and accessed, what collaborations can be created or desolved, etc. With this pattern, you extract all the service/controller and validation and collaboration logic into business rules. You populate the working memory with the objects that comprise the context for a Use Case. Finally, in response to an external event, you inject an event object into the working memory and fire the rules that modify the state of the object model (and persist it).

ContextBRE3.PNG
Take the somewhat simplified Use Case where a customer is trying to rent a tape (he's a sucker for punishment and doesn't like DVD's). In a OO system, we would try to create a collaboration as follows (yes, very simplified):

customer.addRental(new Rental(title.getTape()));

The customer object knows how many active rentals a customer has and knows hat he cannot have more than three. This attempted collaboration would throw an exception to indicate that it is not permitted.

In the Collaboration Cop version we would create an event and insert it into the working memory:

VideoStoreEvent event = new VideoStoreEvent();
event.type = VideoStoreEvent.RENT_TAPE;
event.value = "Gone With the Wind";

IF event.type == VideoStoreEvent.RENT_TAPE AND title.getTitle() == event.value AND title.isInStock()
AND customer.activeRentals() < 3
THEN
customer.addRental(new Rental(title.getTape()));
externalObjectSet.add(customer);
externalResponse.message = "Rented tape.";
externalResponse.success = true;
ELSE
externalResponse.message = "Unable to rent tape.";
externalResponse.success = false;

You can wrap a transaction around the sequence of event injections, then save (using an ORM) all of the modified objects in the externalObjectSet.

-----------

This pattern is complex and powerful, and it's implementation is very much dependent on the capabilities of the chosen BRE, how you choose to deal with concurrency, etc.. In part II, I'll also construct a simple example using JBoss Rules.



Technorati : , ,

Topics: ,

business rules Business Rules

A Performance Comparison of Jess, Drools and MS-BRE

Dietrich Kappe, Wednesday, August 16, 2006 @ 1:36 pm

I have to apologize in advance. I'm in the middle of squeezing out a book chapter and haven't had time to tackle any of the BRE articles on my writing TODO list. So today I'm going to have to do what I usually hate to do -- become a blog echo chamber. The post I want to alert you to is one posted almost a year ago by Charles Young, entitled Microsoft's Rule Engine Scalability Results - A comparison with Jess and Drools. The article claims to show that Microsoft's BRE cannot be criticized about not implementing RETE properly based on MS's published test results. That's a long way to go for such an ephemeral point.

I don't recommend the article because of the claims it makes, but rather because it both demonstrates the use of three different BRE's through actual code samples, and it provides an approach to benchmarking and comparing BRE's for scalability and performance. I'm a firm believer in benchmarking BRE's based on your actual use cases rather than on abstract worst-case scenarios like Miss Manners. Read through this blog entry. Even if his approach is flawed, as I believe it is, he deserves full credit for publishing the full code to his test and opening it up to public scrutiny.


Technorati : , , , , ,

Topics: , , , ,

business rules Business Rules

The Short Circuited OR Considered Harmful

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

In my discussions with James Taylor about using wizards to write rules, I was reminded of some cases where it was necessary to create a wizard for this purpose. They all shared two things in common: the need for justifications and non-shortcircuited OR's. Let me give you an example.

Let's suppose you are designing a system that decides whether or not to recommend prisoners for early release. Your facts inlcude the prisoners' criminal records, the details of their behavior behind bars, recommendations by prison officials and the district attourney, enrollment in treatment and rehabilitation programs, and mitigating circumstances such as aged parent or infirm spouses or children. You formulate the state's sentencing and release guidelines as business rules and implement them in your vendor platform of choice. When a feed of data comes from the department of corrections, you add it to your database and run it through your rule system which issues recommendations to a board charged with making the final decision. This board makes a judgement call based on the information you provide them.

When they look at your recommendation, they don't just want to see a yes or no, they want to see an explanation or justification. Something like "Prisoner Joe Smith, #54-56, is not recommended for release because he had at least 3 incidents of misbehavior in the last 6 months and was convicted of at least a Class C felony." Ideally, you'd want to spell out exactly what the issues were:

Prisoner: Joe Smith
Number: 54-56
Recommended for Early Release: No
Reasons: At least 3 incidents of misbehavior in the last 6 months (stabbing of guard, 4/5/2006; assault of fellow prisoner, 4/22/2006; contraband in cell, 5/17/2006) AND convicted of at least a Class C felony (Criminal Possession of Stolen Property, 6/11/2004)

Now as a board member, I can look at the prisoner and see that while he was convicted of a nonviolent crime, he looks to have been violent while in prison. If he had just been flagged for contraband, maybe I might consider releasing him.

OK, so justification is useful in this context, as it is in many other fields, like healthcare, insurance underwriting and claims, criminal science, etc. How do we produce a justification with our rule engine? The sad truth is that none of the commercial vendors of forward-chaining BRE's will do that for you automatically. You have to roll your own. One approach is to use the Fact Harvest pattern to construct and build a ReleaseRecommendation object. This fact would tell us whether a particular prisoner was recommended for release (true or false) and all of the conditions that contributed to this recommendation. It might contain a list of all of the misbehavior's over the last 6 months and the crime for which he was convicted.

Here we come to the first reason for using a wizard to write rules: if you are testing a particular condition in the 'IF' part of your rule and then updating your ReleaseRecommendation object with the details of that same condition in the 'THEN' part of the rule, you're essentially recapitulating the condition in the action part of the rule. Aside from being a pain in the neck, it's also a maintenance problem. Every time you update a condition, you have to make sure to update the corresponding action. If you don't, Charles Manson gets released by accident -- or, rather, because of your bug. It voilates the DRY principle (Don't Repeat Yourself). One way of handling this is to have your wizard generate the rule for you, with both the condition and action parts. Now you make one change and the rule is generated in a way that is guaranteed to maintain consistency.

The second reason for using a wizard has to do with the short-circuited OR of the title. If our rule above actually tests for

has had at least 3 incidents of misbehavior in the last 6 months OR is a drug addict

then what happens with our rule? If you've programmed much, you know that most languages use what is known as "short-circuited OR," i.e. if you are testing A OR B and A evaluates to true, then B is never tested. If you are depending on side effect of B (such as the building of a list of incidents, etc.), you can forget about it ever happening. The 'is a drug addict' part of the condition is never tested. To make things worse, if we are constructing a justification, we have to test in the action which parts of the OR clause in the condition actually evaluated to true. Imagine now a complex condition with lots of OR, NOT's, AND's and parentheses. Yuck.

A way around this mess is to break apart the OR clause into seperate rules and accumulating them in the ReleaseRecommendation object. The drawback, of course, is that now we have to create several rules where before we had only one. Again, generating these rules with a wizard is a more or less elegant way out.

If anyone has a niftier solution to justification or non-short-circuited OR, I'm more than happy to hear about it.

Update 1: Michael Chermside correctly points out in the comments that it would be more elegant to have a justification engine that worked directly with the BRE's internals. I agree. Unfortunately, none of the forward-chaining BRE's I've worked with have very good support for justification or supply hooks into their internals to support the building of a justification engine through AOP or something equivalent. If you work with an open source engine like JBoss Rules, you can build in your own justification logic.

Topics: ,

business rules Business Rules

Why Your Engine Should Support Programmatic Rule Generation

Dietrich Kappe, Sunday, July 23, 2006 @ 12:36 pm

I've published an article over at the RealRules Blogzine on programmatic generation of rules, i.e. why and under what circumstances this makes sense. Check it out.

Topics:

business rules Business Rules

Your Business Rule System is a Fool

Dietrich Kappe, Thursday, July 20, 2006 @ 8:00 am

He who knows not, and knows not that he knows not, is a fool - shun him.
He who knows not, and knows that he knows not, is a child - teach him.
He who knows, and knows not that he knows, is asleep - wake him.
He who knows, and knows that he knows, is a wise man - follow him.

The above is either an Arabic, Persian or Chinese proverb. I known not, so take your pick. But you could learn something from it for your business rules project.

Even after you've gone through the trouble of pulling your business rules out of existing applications and processes and centralizing them in a rule repository, you could still face problems of a logical or informational variety. You're business rule system may not have the necessary data, or it may have wrong data, or it may have the wrong kind of facts. The system may further not have all the right rules, or some bad rules or it may even come up with some unpleasant conclusions you didn't expect at all. In short, it may be a fool, a child, asleep or even a wise man, all at once, and even a few other choice epithets not included in the above proverb.

To make sure your business rule system behaves well, there are a few specific factors you should consider. I'll blog about them in the next few weeks, digging a little deeper and proposing some remedies along the way:

  • Data (or Fact) Consistency - If you've got Joe being both 16 and 45 years old, you've got a problem. If that situation seems absurd to you, I tip my hat. You're clearly one of the chosen few whose data is consistent across all of your firms databases. ;-) The kinds of data inconsistencies can go much farther, such as a 5-year-old having a husband, or a dead man requiring a liver transplant. The solutions to these data consistency problems are for the most part very unglamorous techniques from the world of data modeling.

  • The Wrong Kinds of Facts - If you've ever design OO software or designed a database, you know what I'm talking about. If your entities are the wrong kind, the wrong size, or incomplete, you will kill yourself writing awkward code. These entities and associated behaviors are like your nouns, verbs and adjectives. Pick the wrong words and your sentences are hard to write. If you capture only the final bill in a system and not the details of the transaction that incurred the bill, you may still be able to extrapolate the transaction information, but you have to work harder to do it. Too much hard work and the system limits rather than enables your ability to describe your business rules.

  • Rule Consistency - What if given a clean, consistent set of facts, your rule set allows you to arrive at A and Not A -- "Joe is a minor" and "Joe is an adult?" With a few hundred or a thousand rules in your set, this problem may be hard to discover. (I'd add rule execution order independence to this category.) In fact, tracking down rule inconsistencies can be a bit tricky, with a couple of not quite satisfactory solutions available.

We'll leave off from things like decidability, as they probably don't have much bearing on BRE's, and cross product matching, as that's really more of a performance issue. I would advise you to be prepared, however, for your cauldron of rules and facts to sometimes deliver you some unexpected results. If you've done more than just 1 + 1 = 2, they can surprise you and perhaps grow past your own abilities. You've built a child and taught it to be a wise man -- or maybe it's just a fool that's mouthing off.



Topics: , ,

business rules Business Rules

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.

Topics: , ,

business rules Business Rules

JSR-94 - Getting Your Feet Wet

Dietrich Kappe, Friday, July 7, 2006 @ 10:08 pm

Over at the Sun Developer Network, you'll find a nice tutorial on writing a business rules application using JSR-94. It makes use of Jess rule engine for its example.

What is JSR-94? From the tutorial:

The specification for the Java Rule Engine API (JSR 94), developed through the Java Community Process (JCP)
program, defines a Java runtime API for rule engines by providing a
simple API to access a rule engine from a Java Platform, Standard
Edition (Java SE, formerly known as J2SE) or a Java Platform,
Enterprise Edition (Java EE, formerly known as J2EE) Java technology
client.

Beyond being useful in that the JSR-94 allows you to interface with any rule engine that supports the standard, it's also useful from a pure code reading perspective. Rule-based systems are different from OO and procedural systems; you have to think and design the applications differently. Reading the Java code of the example should give anyone who has never written a rule-based application a practical understanding of how these things should be built.

Give it a look and study the code. Of course, the standard doesn't solve all of your problems. While it does allow you to write one set of Java code to interface with any compliant rule engine, not all rule engines behave the same. More on that later.

Topics: , , ,

business rules Business Rules

Business Rules Management and Testing - Avoid the “Mystery Box”

Dietrich Kappe, Friday, June 30, 2006 @ 3:12 pm

I apologize for being tardy this week with my post. The truth is that I just got my hot little hands on the latest Blaze Advisor with the new RETE III engine and have been heads down testing it out. It's too soon for me to really say much about it other than "it's fast." Man is it fast. That's not a benchmark, mind you, just an impression from years of working with rule engines. OK, more on Blaze later.

OK, so over on The Road Hits the Rubber, Peter Lin muses on the shortcomings of Business Rule Management Systems:

  • many users have very specific ideas about how to manage rules, but most don't bother using it. This applies to products from iLog to other vendors.
  • users who actually manage rules actively have very specific ideas about how it should work. In this case, existing tools don't match what they want.
  • an all purpose rule management system must be extensible for it to be useful. I'll go into this in greater detail
  • many companies using rule engines and business rules have poor process in place. the typical horror story is the business analysts deploy a rule without testing it and the production system crashes. It's frightening how many companies do this.
  • many business currently using rule engines are not using RETE algorithm and actually don't bother running compliance due to performance. this is actually very common and many businesses use performance as an excuse not to run compliance.

Here, here. Many companies look at the BRMS offerings of their vendor and say "we don't work like that." Rules end up being dumped out into an export format and checked into a source code repository. This is no way to manage rules.

Peter suggests a number of solutions to the above problems. There's lots to digg into here but I'd like to focus on one thing and take issue with him a little bit. The last two points on testing and compliance are, in my opinion, a very important part of what a BRMS should deal with. Peter doesn't agree:

Many sales guy ask for features like rule validation, spell checking and all sorts of stuff, but that isn't part of managing rules. That's the authoring of rules. To me authoring rules includes things like validation, profiling and application testing. Managing rules is a different discipline than writing rules, so it's best to separate the two activities and provide a clear integration between the two. When an user wants to save a draft of the rule, it sends the draft to the BRMS. If someone like his supervisor wants to review the rule, he should be able download it from the BRMS server.

From my experience, you are managing rule sets, not just individual rules. If you write your tests and run your validations at rule authoring time, you are vulnerable to someone deploying an invalid or nonsensical rule subset to a production system. Rule set validation and regression testing should thus absolutely be a part of the BRMS; adding, subtracting or modifying a rule into a large system can have many unforeseen consequences and unit and regression testing of rules and rule sets is one excellent way of addressing this problem.

Maybe I misunderstand what Peter means here by validation. I take it to mean that you are checking an entire rule set for correctness within a context; that context may be a particular dataset or a particular set of tests. A rule set that is correct for a population of Medicare patients may not be correct for a set of Medicaid patients. Thus the tests you perform on a rule set are specific to where you are deploying that set.

Taking a page from the OO world, writing unit and regression tests and testing for code/rule coverage should be built into the BR system life cycle. If you are authoring a new rule, you are likely doing so to change the behavior of the system. You should have a clear idea of what that change consists of and how it would be expressed in a test case or regression test. Otherwise, if you can't specify what sort of change in behavior you are trying to achieve, you have no business modify the BR System to begin with.

Lack of aggressive and rigorous testing in rule management leads to what I've termed the "Mystery Box." This is the rule based system whose inner workings are so mysterious that no one can tell how it arrives at it's conclusions or whether those conclusions are correct. Imagine a company where fixes in data quality or rule set correctness would result in newly correct behavior for a rule-based system; they would face a crisis because they had been feeding their customers incorrect information for years. Don't let the "Mystery Box" happen to you.

Technorati : , , , ,

Topics:

business rules Business Rules

Do You Really Need RETE?

Dietrich Kappe, Tuesday, April 18, 2006 @ 9:00 am

As anyone knows who has been to a Business Rules presentation, it's all about RETE. Who has the best RETE? Which engines are mere pretenders and don't actually have RETE? Which poor slobs have only partially baked version of RETE?

Which brings us to the overwhelming question: what is RETE and why do you need it? By way of answering this questions, we need to go back to what a BRE really is. In most cases, a BRE is an inference engine or production system. According to the Wikipedia, a production system is

...a collection of productions (rules), a working memory
of facts and an algorithm, known as forward chaining, for producing new
facts from old. A rule becomes eligible to "fire" when its conditions
match some set of elements currently in working memory. A conflict
resolution strategy determines which of several eligible rules (the
conflict set) fires next. A condition is a list of symbols which
represent constants, which must be matched exactly; variables which
bind to the thing they match and "<> symbol" which matches a
field not equal to symbol.

What does this actually mean? It means you have conditions on the left hand side (the "IF" part) that if matched trigger some action on the right hand side (the "THEN" part). The right hand side may add, delete or modify facts that will cause new rules to match. For example, I may have a fact that "Bob has a Cat" and the rules that "IF Person has a Cat THEN Person hates Dogs" and "IF Person hates Dogs THEN Person is a Mailman." The first time through my rules I see that "IF Bob has a Cat THEN Bob hates Dogs" fires, and now we have two facts, namely "Bob has a Cat" and "Bob hates Dogs." Now another rule matches, namely "IF Bob hates Dogs THEN Bob is a Mailman," and after firing we have three facts, namely "Bob has a Cat," "Bob hates Dogs," and "Bob is a Mailman." So from the initial fact "Bob has a Cat" we inferred that "Bob is a Mailman." Essentially these inference engines chain syllogisms to come up with new facts.

There's a little more to it than that, such as if we have several rules that match, which one gets triggered first? If we have a bunch of rules that matched on an original set of facts and those facts get changed, then the rules that no longer match have to be kicked out. Still, you get the idea.

If you think of implementing a production system the naive way, you would scan the left hand side for matches, pick the one you like, then rescan the left hand side for matches if the facts changed and repeat. That rescanning of the left hand side gets very expensive if you have a lot of rules and facts. In fact, it was so expensive in the olden days that nobody really used production rules except as objects of academic study.

Enter RETE. Designed by Charles Forgy in 1979, it took the approach of only reevaluating those parts of the left hand side that were effected by a change in the facts. The implementation uses a network (RETE is Latin for "net") to organize terms, conditions and rules so that facts come in the top and rules (or rule retractions) come out the bottom. The RETE algorithm was a huge improvement in performance over the naive approach and made production systems -- or Business Rule Engines -- feasible.

Still, if you aren't doing inferencing, i.e. you are only doing a single pass on the rules or you aren't modifying the facts, there are other algorithms and approaches that in many circumstances blow the doors off of RETE.

If you're problem involves cleaning data ("If the zip code doesn't match the city and state") or checking for eligibility for discounts ("If the customer has purchased more than $5000 in the last 3 months"), then you may in fact not need an inference engine. If, however, you are doing compex financial or clinical reasoning, you may well need inferencing capabilities (Clinical Events->Diagnosis->Recommended Action).

Fortunatley, many commercial vendors support other models of rule evaluation than RETE, so even if you've already invested in one you're not stuck using RETE. Some even support hybrid approaches, i.e. some RETE and some rule chaining. So, before you fall in love with a rule engine because it has the best RETE implementation, ask yourself: do I really need inferencing capabilities in my BRE, or is my problem like most and can make use of a simpler solution?

Topics:

business rules Business Rules

Exaggerated Claims and the Importance of Hands-on Evaluation

Dietrich Kappe, Sunday, April 9, 2006 @ 9:34 am

Anyone who has worked with more than one commercial rule engine knows that there are some significant performance differences between the various engines. In some cases the performance issues are so severe that you end up scratching your head, looking at the Gartner magic quadrant and trying to figure out how they put some of these turkeys where they did.

With Business Rules Engines we are, unfortunately, in a marketplace where information asymmetry and switching costs are the order of the day. Vendors don't like to have their rule engines compared head-to-head and they use everything from custom rule description formats to alternate rule evaluation algorithms to rule repositories to legal restriction on making any performance measures public in order to make those comparisons difficult.

As a result, you see all sorts of claims from vendors about how nice their super secret algorithms perform. Peter Lin regularly takes on some of the more outrageous claims and, as best as he can, given the lack of information from the vendor, attempts to debunk them. His latest bit of skeptical wisdom, about the HyperRETE algorithm from EWA Systems, can be found here.

Ideally, we would have a standard rule description format, something like RuleML for example, and would use the rule engine as a standard execution environment with a standard set of API's, etc. Vendors could differentiate their product offering by providing nice IDE and Rule Repository functionality or souping up their rule engine to provide better performance. Imagine Java IDE vendors clouding the issue by each shipping their own, non-standard JVM's, tightly integrated with the IDE. If you want to run apps developed with their IDE, you need to use their engine and if you want to use their engine, you need to use their IDE.

In reality, Rule Engines should be a commodity by now. It's just the lack of sophistication by IT managers that prevents them from evaluating BRE technology just like they would OS or database software.

So, what is a product manager to do? My advice is to evaluate as many rule engines as you can. If you need inferencing, i.e. the ability to chain together conclusions across a large fact base, make sure to evaluate RETE engines and make sure those engine are really really RETE. The best way to test the engines for performance and scalability is to build a prototype that replicates the rules and facts you are going to process. The academic benchmarks like Manners are all well and good, but if you are going to write lots of rules that involve 20 conditionals or the existential quantifier ("there are at least 3 instances of a bad credit reference"), you're better off testing using that. If you're expecting to chase a million customers through the rule engine every day, you want to know if you'll need 4 or 400 CPU's, so make sure to use enough representative data so you can accurately estimate performance.

If, instead, you swallow a vendors song and dance and fancy GUI interface, you deserve what you get. So, do your homework.

Topics:

business rules Business Rules

Drools - Getting Your Feet Wet with Open Source

Dietrich Kappe, Tuesday, April 4, 2006 @ 11:33 am

For those not wanting to hemorrhage the $10k plus for a development license of a BRE, there is a way of getting your feet wet with an open source rules engine: Drools

It is a real RETE (RETE OO, but who really cares?) implementation that you can use in your Java applications. There's even a .NET version in BETA.

Rules can be written in several "dialects," such as straight Java

<rule name="Bootstrap 2">    <parameter identifier="f">      <class>Fibonacci</class>    </parameter>    <java:condition>f.getSequence() == 2</java:condition>    <java:condition>f.getValue() == -1</java:condition>    <java:consequence>      f.setValue( 1 );      System.err.println( f.getSequence() + " == " + f.getValue() );      drools.modifyObject( f );    </java:consequence></rule>

There are also dialects for Groovy, a java-like embedded scripting language, Python, etc. There is no "pseudo-natural language" dialect as yet, though this shouldn't be all that hard. Really, most commercial BRE's just rewrite method calls and expressions using a fairly primitive scheme, i.e. "IF truck.willFit(boxes)" translates to "IF the boxes will fit inside the truck." Of course the GUI IDE for this is a bit harder to write (though not impossible).

For me there's still and open question on whether "pseudo-natural language" is really all that useful, but more on that in a subsequent post.

Note that Drools version 2.x does not support the universal or existential quantifiers of first order logic (see here for why this is important), but it is already useful for many different applications and performs pretty well in comparison to many commercial products. Support for full first order logic is planned for 3.x.
 

Topics: ,

business rules Business Rules

About Pathfinder

  • We design and build extraordinary applications for companies looking to make the next great idea a reality.
  • learn more

Topics