Friday, November 09, 2007

IJTC and new Production Rule (Rete) explanation in slides

Just got back from the Irish Java Technology Conference, for this presentation I had another go at trying to explain how a production rule engine works - the behaviour, not the algorithm. As I've mentioned in the past I'm finding it easier to talk about SQL to begin with, to frame people's minds. If you jump into an example, straight away they are thinking, or asking, "how is this different from an 'if' statement in java". By taking the SQL approach you hopefully break that problem.

The presentation takes 3 tables with data and shows the resulting rows for 2 different views, and how data might change if we had triggers on those views. So it gets people thinking in terms of cross products and rows of data (tuples). I then show the same data against rules and the resulting rows, which is identical to the views. Showing that basically a rule is a view on data, resulting in rows (tuples) of matched facts. The consequence is executed for each resulting row. This concept is taken further to say that if each rule is a view then the agenda is just an aggregate view of all the rule views. As you insert, retract and update data, rows are added and removed from the "agenda view". I then introduce the idea of conflict resolution and salience, along with two phase execution, as a way to determine which of the rows in the agenda view have their consequences fired first; a new simple rule with a salience is added, along with the resulting agenda view tables show the impact of this. The presentation then goes on to touch first order logic, specifically 'not' and 'accumulate' and details our ruleflow work, the normal screen shots are supplied for explaining the rest of the capabilities of the system. I also did a populated BRMs demo at the end.

Do give me feedback on my approach to helping people understand production rule systems, via the sql and views analogy, I'd certainly like to try and improve the slides to help explain this better.

You can get the slides here


  1. I've never understood the under-the-hood intricacies of SQL (and I've tried to keep it that way - higher level logic is more interesting to me).

    But I know all about rule firings and the Rete algorithm all too well. Maybe you could explain the DB to me in terms of rule engines. :)

    Actually, it sounds like a great idea 1) if your audience is DB savy or 2) if they're untrained code slingers.

    [CS Biggoting] I think any respectable Computer Science degree would inform you of reverse-chained rule engines, but most of my fellow programmers have Engineering, Physics, English, et al. degrees.

    And DBAs, they're the only ones that should understand the SQL - like the Spacing Guild and navigation.

  2. Yes, knowledge matters. God is mysterious. The Earth turns and we are all getting older. That being said, I have always felt that it was a mistake to try and relate a rulebase to something that was procedural in nature just to make the audience feel good about it. I have seen terrible explanations of the Rete Algorithm becasue it was felt that the audience could not understand the real thing.

    With regards to rule flow, decision tables, decision trees, and other obvious attempts to "commercialize" the product, this also has backfired on Fair Isaac, ILOG and Corticon. Their customers have NO IDEA how to build a rulebase but since they understand a spreadsheet then surely they can understand a rulebase. The end result is that they simply start throwing in rule after rule and flow afer flow that leads to disorganization and ultimate collapse. Just as you do not let the users design and manage a DBMS, you do not allow business users to design nor manage a rulebase system.

    Just my thoughts. So how DO you teach it? Might I suggest using set theory and pattern matching theory rather than database? Yes, they are similar, but basic linear algebra approach would be just different enough to show that a rulebase is NOT a database and, at the same time, approach the problem correctly, from a declarative programming slant.

    BTW, I have met with many a CS graduate who had no idea HOW a rulebase worked - but they used it in college so they must be experts, right?


  3. You have < 60 minutes in a talk to get the basics across - this is aimed at java developers. If you show java developers any type of rule or ruleset they will instantly fall back to what they know and think of it as multiple if statements and be comparing this to java - it's how the human brain works, it falls back to concepts it understands for comparison to help try to make the jump to the new paradigm - once they are stuck in the 'if' mentality it's really hard to get them to make that jump. However All java develops understand sql and the concepts of thinking of rules as views and the agenda as an aggregate view are a near enough 1 to 1 mapping in behaviour in understanding cross products and result rows/rules. So from that point it's easy to get them to understand conflict sets and resolution. The idea is to take a concept they understand use that as a starting point of reference and then move them across into rules. While this seems crude, I've done many developer talks and over time I'm finding using SQL as the starting point to be the most effective to get people to understand patterns, cross products and resolution with minimum confusion - something must have worked as it's one of the first talks where someone didn't ask why you wouldn't just use java code and 'if' statements.

  4. jco:
    They have all these features because they try to sell BUSINESS Rule Engine.

    Always wondered what genius started to use the name BRE for something one has trouble to explain to a bunch of engaged java programmers?

  5. Mark: First, you and I rarely disagree. And I do not think that we are disagreeing this time either. But, if no one asked the now-infamous question, "Why not use Java and if-then-else statements?" then you either did a truly outstanding job OR the audience zoned out somewhere along the way OR the audience was under the influence of mass hypnosis. :-)

    Seriously, my point is that trying to "teach" declarative programming to a pack of procedural programmers using procedural examples is just leading them down the garden path of self-deception. They have to understand the principles of non-monotonic nature of declarative programming and THEN move on to if-then programming. Otherwise, the totally monotoic nature of procedural progamming becomes completely ingrained into their thinking.

    60 minutes? Most people can't focus for 5 minutes on a problem. Programmers usually last 20. Only true developers can go for two or three hours on the same train of thought. And only a genius will go for days or weeks focused on a particullarly obtuse problem.

    Anyway, good luck with the SQL guys. Let me know how it works out in the long run. :-)

  6. snshor:

    The genius of the BRMS moniker (Business Rule Management System) presently being used for a rulebased system with lots of bells and whistles was started by Fair isaac and ILOG in late 2003 and early 2004 with the help of Ron Ross and the Business Rules Forum. Unfortunately, before I realized my mistake, I helped to propagate that bit of foolishness thinking that I was doing the industry a favor.

    Today, we no longer have true rulebased systems - we have interface after interface after interface layered upon layer upon layer that ultimately totally obfuscates the original delcarative engine. It's a terrible thing and I helped to get started. May all of you one day find it in your hearts to forgive me.


  7. And every converted sinner is a saved sinner; delivered from sin and wrath

    We are off to a good start here. Once confessions begin, they may become contagious. How are Rete rules more declarative than SQL, anybody?

    I recall, when I tried (and failed) to impress some lady programmer friend of mine I would go: Imagine a database where different select, update and delete queries are being performed simultaneously and in no particular order whatsoever :))

  8. I have no problem with the way Mark approached explaining. Two points though.. Why should he have to explain at this level of detail? Many programmers don't understand the internals of compilers but they still use software development tools. Isn't that what a RETE is (loosely defined)? Shouldn't we focus on the question of explaining the benefits of a rules based solution versus procedural programming? If you have a problem that has many conditions and actions that need to be assessed (let's say 10 conditions with an average of 4 actions per condition) you have a large potential number of rules. Let's say you only actually have 1500 rules out of this potential rule set. How hard is it to produce a control structure in the procedural world to deal with this executing these 1500 rules correctly? How hard is it to maintain this logic in a procedual control structure? Isn't the power of a rules based approach that you get to focus on describing the problem, not how to structure the logic to solve the problem? Isn't the power of the rules based approach that you can build more sophistication in your logic because you don't have to deal with these control and flow structures?

  9. "First, you and I rarely disagree. And I do not think that we are disagreeing this time either."... heh no worries, I think we are argueing shades of grey, probably easier to do this in person. In some ways I think you are totally right I do prefer a more purist approach to giving people a thorough understanding of production rules systems, but after doing many talks I wasn't succeeding too well. I've been working on this approach for a while now and several Drools users, who have heard me talk before, say it's the first time they've starting to understand how rules and the Agenda actually works.

    An SQL view is declarative, a view is no less declarative than a rule, in fact a view+trigger is pretty much a rule just with no agenda and inference. This is almost a 1 to 1 analogy, so I don't think its polluting the mind or teach proceduralness. The extra step is understanding that the agenda is an aggregate view and the rows are evaluated by a conflict resolution strategy. Again none of this is procedural at all, and it all maps quite cleanly. I guess it would definitely be easier to understand if there is voice with the talk - but I do feel that I haven't betrayed my purist roots by negatively confusing things taking this route - it makes it much easier to bring in more concepts in a way people can relate to. This isn't aiming the talk at DBA or SQL people - ALL developers do some basic level of SQL and DBs, they all understand the concepts of views, and they all undertand SQL like cross products, so I'm simply setting their mindset into some existing and similar concepts they understand in an attempt to help them make the transition to the production rules concepts with minimum of confusion.

    "How are Rete rules more declarative than SQL, anybody?". Think I just answered this, I don't believe sql or a view is any less or more declarative than a rule. You could probably say that SQL alone can be procedural as its normally called and executed as part of procedural execution. Which is why I stress rules are views, not SQL that you call.

    "Many programmers don't understand the internals of compilers but they still use software development tools. Isn't that what a RETE is (loosely defined)?"... I think you misunderstand the slides at no time do I try and explain the Rete algorithm or any internal compilation processes, its just too much for end users. What I do though is explain execution control and rules - if I have these rules, what are the potential rule firings and how does it choose which of those rules it executes first. This is pretty essential understanding to doing anything with a Rete based engine and certainly not low level stuff. To write an SQL view you have to understand cross products and constraint concepts, you don't need to understand indexing, explain plans etc - this is all I have done here, I explain the cross products and constraints, I don't explain any compilation/engine stuff.

  10. Final Comments from jco:

    snshor: Declarative versus Procedural differences is that in declarative you can add rules in any order and let the conflict resolution process work out the order of firing. Also, declarative (normally) is non-monotonic and continues to examine all of the rules until there are no more rules to fire whereas procedural is a one-time sequential process. This is what separates the boys (Java, SQL, etc.) from the men (rulebased systems.) And, yes, I really am a male, chauvinist pig - and I like it that way.

    David: The talk was to geeks, not business folks. As such, they "should" be able to grasp the fundamentals of declarative programming versus procedural. If they can't, then they should go home and do some reading. And,yes, technically, a rulebase is a really cool compiler for a declarative language.

    Mark: I still maintain that we should not molly coddle the techies in the interst of more sales. They don't buy - they only make suggestions to the business folks who buy. For the techies, you first kick them in their nads to get their attention and then have them do about 50 knuckle push-ups, or press downs as you call them there. NOW you can explain the basics of declarative, non-monotonic programming.

    When you teach bank tellers how to tell the difference between a real $100 bill and a fake, you don't teach the about the fakes. You focus ONLY only on the real deal. Once they are totally familiar with that, nothing else is important. When teaching on cults versus Christian theology, you focus totally on the bible. Then, when some cult group spouts off about something, it doesn't ring true and that person cannot be led astray.

    All: I think we've kind of beat this one to death, don't you? I'm going to drop out of this thread and wait for Mark to post something else cool.

    Don't forget to drop around to once in a while and see what we have over there. :-)

  11. Hi Mark,

    Unfortunately I was too late to see the presentation live, although I came close to flying out just for the Friday to see your and Paul's presentations.

    All I can go by therefore is you summary and your slides and I have a few comments based on that.

    My first thought on seeing the slides was that some were very cluttered. There is a lot going on behind the scenes with the rule engine, but does the user (sic) need to know all this at this stage. For example, if you were going to use JBOSS App Server, would you need to understand the internal workings of the App Server or merely understand how to get it to do what you want it to do.

    I am in the process of preparing a presentation for senior managers at work on Drools. This is my pitch, with a slightly better understanding of what rules is and how to use it, to reaffirm the convictions of our Technical Architect that this is the tool to use.

    My pitch will be to present a problem - and the example I am thinking of is seating allocation within the bank. My aim is to first of all present the problem - who is going to sit where and on which floor. The introduce the facts and rules - managers must be allocated an office, teams must sit together, floors have sections, and sections have a capacity.

    My next task is then to look at the possible solutions - java (lots of ifs and elses), and drools. Talk very briefly about drl and quickly move on to brms - because people can understand a rule title more easily than the rule syntax (but they need to understand what is going on behind the scenes).

    I would then demo a solution using both technologies. So far there is no clear winner as to which technology is best suited to the task.

    Then, and this is where drools comes into its own, introduce a new manager who has joined to organisation who wants to change the rules for seat allocation - managers must sit with their teams regardless of whether or not there exists an office for them.

    Talk through the steps involved in changing the java code.

    Then, demo how in brms, the manager could change the rule himself without the need of a techy, he coudl set it to state test, hot deploy it to the rule server and get a new seating plan.

    My argument is that we need to sell the real power of Drools and rule engines - which is total configurability by changing, ignoring or adding rules - as opposed to java that requires re-compile etc.

    Then, once we have sold the concept and the strengths, we can start drilling down into the technology you have developed.

    It's a bit like kicking the tyres on a car in the show room. You want to know - does it look good, what is the 0 to 60, what does it do to the gallon, is it nice to drive, can I afford it. Once you have got a yes to all of those, then you can start looking under the bonnet and seeing what the engineers have put into the design and implementation.

    Hope this is helpful.

  12. D'oh! You can't edit these posts once you've submitted them - so please excuse the typos above.

    Just read through your blog entry again and I would be inclined to use all the stuff you have included in it, but after demoing the system working with an understandable example as I mentioned above.

    Drilling down, or looking under the bonnet is important, but after people have understood what the rule engine is about.

  13. jco (he dropped from the thread, I can get away with anything now):

    SQL is declarative because you just define which data you want to retrieve, and no internal knowledge about db server is required. It stays declarative while it stays in it's domain, until people start to abuse it beyond it's initial goal - being a language for relational data storage, retrieval and manipulation.

    The same is true for Rete rules - until they stay in their domain for pattern matching and FOL - they shine, once people start to use it for everything else - it becomes ugly.

    And what about rules containing java code - what kind of man-boy relationship is it?
    Ok, now it seems as a good time for me to drop from this thread too ;)

  14. Up front I'll declare my bias: I invited Mark to present at the IJTC (to a room full of Java developers, not rules specicialists). It was clear that the audience may have heard of the term 'rule engine' but certainly wouldn't know what one was , far less why they should be using it.

    So Mark, in full evangelical / convert the masses mode launches in to the SQL comparison that seems to have upset a few people here. About half way through I was worried that he was going to lose the audience with detail (there was quite a bit in there that I didn't know already, and I've been dabbling in the rules area for a while). But at the end there was 20 mins of intelligent questions. Not just 'could you repeat all that again' , but people interested in fairly specific and technical details of what he said, and relating it back to problems that they had. Maybe I underestimate the intelligence of Irish Software developers :-)

    So if you take the slides, yes there is a lot of detail. I tend to go to the other extreme of big pictures and few words (see my presentation in the slot before -
    I'd also tend towards John's suggestion of business-problem-first -then- technical-solution
    But it's a personal thing and if you're standing up in front of a crowd , you have to go with what you're happy presenting.

    Would I give the 'Rules explained via SQL' to a group of Rules experts .. No. Would I use it in my own presentation on the subject to a similar group of Java developers? Yes.

    John: You missed a good conference, pity that you didn't come over :-)