Discussions

News: Building Enterprise Services with Drools Rule Engine

  1. OnJava has posted Birali Hakizumwami's "Building Enterprise Services with Drools Rule Engine," an article that covers how to architect and build a service that uses Drools (also known as JBoss Rules) to provide business decisions. Of course, the ideas behind it can be applied to other rules engines, too.
    A rule engine such as Drools offers matching algorithms that can determine which rules need to be run and in which order, and provide a means of addressing conflict resolution. It allows facts to be reassessed by rules as they are being evaluated, causing the consequence of one rule to affect the fact base, or causing other rules to fire or retract as needed. By using a rule engine, rapidly changing business policies/rules can be externalized so that they can be maintained separately in one place. The rest of the enterprise applications can access the functionality through a service layer with well-defined contracts. The behavior of the service can then be modified without changing the interface contract or needing to recompile/redeploy. Rules are stored in human-readable form in a file so they can be changed with a text editor or rule editor. Many leading industry analysts have concluded that it is significantly more productive to build and change complex, decision-intensive applications with rules-based systems than with custom code.
    The article shows an Underwriting service written in Drools. This involves getting a reference to the service, and passing it an object to be evaluated; Drools then uses a simple script to retrieve and set variables in the object model. An example of a rule from the article:
    rule "Age verification" when Borrower(age < 18) $loanApp : LoanApplication() then $loanApp.addFeedbackMessage(FeedbackMessages.MIN_AGE); end
    As you can see, the structure is very simple; one can easily imagine far more complicated rules. One issue the article doesn't address is a requirement for data outside the rules' source code. For example, if the borrower's age was contained in an external service somewhere (yes, very contrived, work with me!), the article doesn't show getting data from that service. This is a fairly minor quibble, though, and perhaps Drools users can show examples of this from real-world code.

    Threaded Messages (45)

  2. Drools / JBoss Rules is a very good solution to stop your business logic from being fragmented and scattered throughout your code. This article is clear and concise , and a good introduction to the world of rule engines. Of course, we're slightly biased , given that we've also written articles for O'Reilly on JBoss Rules but that should only underline the 'must read this article' recommendation. Paul , Technology in Plain English
  3. Drools / JBoss Rules is a very good solution to stop your business logic from being fragmented and scattered throughout your code.
    There is nothing wrong with business logic being fragmented throughout source code as long as OO principles are used (eg. separation of concerns - no business logic mixed with raw db access etc.) Business rules engines are useful when the business logic changes very often because the changes can be implemented faster and cheaper - purely by configuration (at least in theory). http://www.enterpriseware.co.uk
  4. Re: A very good article on a very useful subject[ Go to top ]

    Drools / JBoss Rules is a very good solution to stop your business logic from being fragmented and scattered throughout your code.

    There is nothing wrong with business logic being fragmented throughout source code as long as OO principles are used (eg. separation of concerns - no business logic mixed with raw db access etc.)
    Business rules engines are useful when the business logic changes very often because the changes can be implemented faster and cheaper - purely by configuration (at least in theory)
    It is also a way to consolidate across toolsets.
  5. Business rules engines are useful when the business logic changes very often because the changes can be implemented faster and cheaper - purely by configuration (at least in theory).
    We're using Drools in a project, and for the most part this does seem to be true in practicality as well. Dan Diephouse Envoi Solutions
  6. from my experience[ Go to top ]

    the key to a successful rule integration is "how" you use it and defining a clear scope. When applied properly, rule engines can externalize "some" business logic. Blindly applying a rule engine is a recipe for disaster, especially if the target user are business users who have a hard time defining requirements. peter
  7. Fragmented Business Logic[ Go to top ]

    There is nothing wrong with business logic being fragmented throughout source code as long as OO principles are used.
    I don't always agree. In my experience , most of the bugs in business logic come from the implementation (code) not matching the spec (from the users). I don't expect business people to write rules, but I do expect them to be able to review and sign off as correct. Paul, Technology in Plain English
  8. Re: Fragmented Business Logic[ Go to top ]

    There is nothing wrong with business logic being fragmented throughout source code as long as OO principles are used.


    I agree: business logic _should_ be fragmented: use "local scoping" as much as possible, just the same as applies to good (OO) design. A nuance: locally defined/executed rules may use globally defined constants or rules.
  9. API design question: method side effect[ Go to top ]

    In both the current article and the one linked in, I see API like: void someRuleEngineInstance.applyTo(someBizObject); Coming out that, someBizObject's state is changed as the consequence of the application of rules. Isn't this directly against the "not to use method side effect" principle? Just for reference, JSR94 API looks like this: void statefulRuleSession.addObjects(someBizObjects); void statefulRuleSession.excuteRules(); List results = statefulRuleSession.getObjects(); That seems much more comforting than the API used in the articles. What is the rational behind the "side effect" API? -Qingtian
  10. Perfromance of Drools[ Go to top ]

    How does Drools perform? Like when the number of rules increase, does time to match also increases linearly? How does it perform compare to Jess?
  11. Re: Perfromance of Drools[ Go to top ]

    How does Drools perform? Like when the number of rules increase, does time to match also increases linearly? How does it perform compare to Jess?
    if you do a google blog search on jbossrules performance, you'll find my benchmark results. peter
  12. for the record[ Go to top ]

    JESS is a kick ass rule engine and is rock solid. when you consider JESS is really the work of one man Ernest, he has done wonders for RETE rule engines. The next release of CLIPS should be faster than most engines and even with OPSJ. Those 2 are the fastest RETE implementations today. peter
  13. Re: Perfromance of Drools[ Go to top ]

    One of the main benefits of Rule engines is that they are very scalable: matching of the rules does not grow linearly with number of rules. In my limited benchmarks I was running tests against ruleset with 1000 rules and I was getting 10 000 runs per second, and this number was not decreasing with increasing number of rules. This performance is due to the fact that systems, implementing Rete algorithm have condition parts of the rules built as tree, thus even if you have 1000 or 10000 rules, the program may have to traverse only limited number of nodes of the tree. If you try to do the same thing using scripting language, then you will have to evaluate all conditional statements one by one, and this will degrade performance for a large ruleset. Interestingly, the above is true only for Rete algorithm: I was doing the same benchmark of Drools with Leaps algorithm and performance was really bad.
  14. In the next major version, we have the "from" statement, which allows you to pull data in from an external data source (which could be anything). This means you could pass in (for instance) a hibernate session as a "global" and then call adhoc queries or named queries to provide data for the rules conditions (you can then add more conditions to the resulting data). This has a key advantage of minimising the amount of data needed to be kept in memory for making decisions, and also lets databases to what they do best (querying lots of data and filtering !). For example when User(rating then ... so the "data source" (the stuff on the right hand side of the from) can return "rows" of data, which the engine reasons over like any other fact (but it is not part of working memory). I think lots of people will find this very useful especially for decision applications, and where there is a database with a large amount of data involved.
  15. Rule Engine vs. Scripting[ Go to top ]

    When I look at the Drools code, it looks a lot like a script code (python for example.) What advantage, if any, is there to using a tool like Drools over using a Scripting language like Groovy, Jython or JRuby to define business rules? Is Drools another scripting language or something else? I have no experience with Drools so these are not rhetorical questions.
  16. Jbossrules aka Drools is a rule engine[ Go to top ]

    When I look at the Drools code, it looks a lot like a script code (python for example.) What advantage, if any, is there to using a tool like Drools over using a Scripting language like Groovy, Jython or JRuby to define business rules? Is Drools another scripting language or something else? I have no experience with Drools so these are not rhetorical questions.
    JBossRules is a rule engine that supports First Order Logic and implements RETE algorithm. Although it looks similar to scripting languages it's quite different. Take this classic example. (not (person.hasTatoo == true) ) How many people understand the difference between that example and (person.hasTatoo == false) If i were to make a simple mistake like that in a scripting language, it wouldn't be too big of a deal. If I make that mistake with a rule engine, it could have horrible side effects. The first one (not (person.hasTatoo == true) ) means "there isn't any person with a tatoo". The second means "an individual doesn't have a tatoo." Now imagine I own a tatoo shop and i want to send a discount to all customers with less than 5 tatoos. if ( not (person.tatoo < 5 ) ) then send coupon versus if (person.tatoo < 5) then send coupon. I think the rule industry hasn't been forth coming about the dangers of using rules and have collectively led customers to believe anyone can write rules. The cold hard fact is it takes experience and solid understanding to write rules. Using rules properly takes skill and experience. A simple concept like pattern matching is actually a huge leap for many developers. my bias 2 bits. peter
  17. Although it looks similar to scripting languages it's quite different.
    Thanks for the explanation. I'll read up on RETE.
    If i were to make a simple mistake like that in a scripting language, it wouldn't be too big of a deal. If I make that mistake with a rule engine, it could have horrible side effects.
    That doesn't seem very positive.
  18. Although it looks similar to scripting languages it's quite different.
    Thanks for the explanation. I'll read up on RETE.
    If i were to make a simple mistake like that in a scripting language, it wouldn't be too big of a deal. If I make that mistake with a rule engine, it could have horrible side effects.
    That doesn't seem very positive.
    Haha, yeah you're right. It doesn't seem positive at all. None of the vendors will tell you this and especially not the sales guys. The third party rule consultants may tell you about these pitfalls if they understand rule theory. Many rule consultants in the industry only know 1 product and haven't bothered to study expert systems, pattern matching and AI. Even fewer can explain clearly what the performance limitations are and the best practices for avoiding the most common mistakes. RETE algorithm is very powerful and expert systems can do a lot. Say i write a rule like this in Blaze if any customer has bought "matrix", then ask them to review it. The key word "any" means any instance of customer. It is different than a single instance of a customer. If I run the rule with 1 customer who has purchased "matrix" the rule would ask them to review the movie. On the otherhand, say I batch process 10K customers. When it finds the first customer that has bought "matrix" it will fire and ask them to review it. It may not ask all customers in that set of 10K to review the movie. These subtle differences have a huge impact on how an application works, but you're not going to warned by the sales guy or even the customer service rep. Neither of them understand this subtle difference and probably wouldn't know when to use "any" versus "a". The problem gets worse when you allow a business user to write rules. when the system blows up at 3am on sunday, who are they going to call? You can bet it won't be the business user who made the mistake. It will be the developer. I sympathize with developers who are asked to give the business users complete control to author rules. having sensible limits for the business user is a good thing, even if they say otherwise :) having said that, I think rule engines can provide real benefits like making it easier to audit, track, report and analyze the business rules. If you have to implement government regulations, you don't want that in java code. The SEC isn't going to read 1 million lines of code to figure out if you're compliant. With the appropriate tools, you can do things like impact analysis to see the impact if x change is made. If a product uses a RDBMS to store the rules, test cases, reports and runtime statistics, you can run SQL queries and do all sorts of analytics to see how the business performs. Most products don't provide these capabilities, so in many cases you have to build your own tools to do this kind of stuff. my bias 2 bits. peter
  19. sympathize with developers who are asked to give the business users complete control to author rules. having sensible limits for the business user is a good thing, even if they say otherwise :)
    We are actually moving more in that direction. Partly because the users are complaining that we are too slow and because some of them think they can program better than the developers (they can't.) Our approach so far has been to give them fairly structured or highly structured interfaces in which they can set up options. I don't think a fully functional rules engine would work even without the pitfalls you mention. But I am going to keep it in mind. Perhaps rules could be used behind one of these structured interfaces or a very simple DSL. I think that as programming languages keep improving there will eventually be a clean break between the technical developers and developers who are essentially logic experts who translate fuzzy concepts and requirements into programs (in the general sense.) Not that there won't be people that straddle the divide but more they won't be lumped into the same job category.
  20. sympathize with developers who are asked to give the business users complete control to author rules. having sensible limits for the business user is a good thing, even if they say otherwise :)
    We are actually moving more in that direction. Partly because the users are complaining that we are too slow and because some of them think they can program better than the developers (they can't.) Our approach so far has been to give them fairly structured or highly structured interfaces in which they can set up options. I don't think a fully functional rules engine would work even without the pitfalls you mention. But I am going to keep it in mind. Perhaps rules could be used behind one of these structured interfaces or a very simple DSL. I think that as programming languages keep improving there will eventually be a clean break between the technical developers and developers who are essentially logic experts who translate fuzzy concepts and requirements into programs (in the general sense.) Not that there won't be people that straddle the divide but more they won't be lumped into the same job category.
    I generally suggest using a custom DSL that gives the biz user just enough flexibility to define the business logic, but not enough to blow up the server. peter
  21. Peter,
    (not (person.hasTatoo == true) ) How many people understand the difference between that example and (person.hasTatoo == false) If i were to make a simple mistake like that in a scripting language, it wouldn't be too big of a deal. If I make that mistake with a rule engine, it could have horrible side effects. The first one (not (person.hasTatoo == true) ) means "there isn't any person with a tatoo". The second means "an individual doesn't have a tatoo." Now imagine I own a tatoo shop and i want to send a discount to all customers with less than 5 tatoos. if ( not (person.tatoo < 5 ) ) then send coupon versus if (person.tatoo < 5) then send coupon.</blockquote> I'm not coming into this discussion with much exposure to rules engines so forgive me if this makes no sense. I think I understand the differences between your two examples. But you could have added a little extra information... Even reading into these simple rules is like reading a Perl regular expression: time consuming and prone to mis-interpretation. I hope you agree and that is the reasoning behind your argument that rule experts should be the ones to changes the rules, or at least QA the changes. I agree with you that the use/modification of such rules could have far reaching consequences for developer - never mind business people. For your "less that 5 tatoos" example, wouldn't the following be simpler: person[numerOfTatoos < 5] This would match and return all people whose numberofTatoos property (could also be written as count(tatoo)) is less than five. You could then iterate over the results or fire off whatever you needed to for those matched. I'm bringing up this syntax and example becuase I'm writing a JavaCC grammar for this kind of thing and it sounds a bit like what James's doing too. Just some thoughts... Thanks. __________________________________________
  22. Peter,
    (not (person.hasTatoo == true) ) How many people understand the difference between that example and (person.hasTatoo == false) If i were to make a simple mistake like that in a scripting language, it wouldn't be too big of a deal. If I make that mistake with a rule engine, it could have horrible side effects. The first one (not (person.hasTatoo == true) ) means "there isn't any person with a tatoo". The second means "an individual doesn't have a tatoo." Now imagine I own a tatoo shop and i want to send a discount to all customers with less than 5 tatoos. if ( not (person.tatoo < 5 ) ) then send coupon versus if (person.tatoo < 5) then send coupon.</blockquote> I'm not coming into this discussion with much exposure to rules engines so forgive me if this makes no sense. I think I understand the differences between your two examples. But you could have added a little extra information... Even reading into these simple rules is like reading a Perl regular expression: time consuming and prone to mis-interpretation. I hope you agree and that is the reasoning behind your argument that rule experts should be the ones to changes the rules, or at least QA the changes. I agree with you that the use/modification of such rules could have far reaching consequences for developer - never mind business people. For your "less that 5 tatoos" example, wouldn't the following be simpler: person[numerOfTatoos < 5] This would match and return all people whose numberofTatoos property (could also be written as count(tatoo)) is less than five. You could then iterate over the results or fire off whatever you needed to for those matched. I'm bringing up this syntax and example becuase I'm writing a JavaCC grammar for this kind of thing and it sounds a bit like what James's doing too. Just some thoughts... Thanks.
    it would be easier to use "person[numerOfTatoos < 5]" for the average developer. please excuse the short explanation. these topics aren't readily explained in short blurbs. the thing I really dislike about the hype around rule engines and business rule management systems is the industry isn't sounding these alarms. Instead, the industry is pushing forward and telling customers they need BRMS. The end result is a lot of people are going to misuse it and walk away with a horrible experience. Ask any rule consultant with 4-8 years of experience and you'll hear tons of horror stories. The "not" example is a classic negation example. the real tricky part is when users start nesting statements within a "not" negation statement. Most people won't have a clue and even an experience rule consultant will have to think it through carefully. If i had to summarize it in a sentence, it would be this. With a rule engine, the simple stuff isn't simple and the hard stuff is really hard. peter
  23. The "not" example is a classic negation example. the real tricky part is when users start nesting statements within a "not" negation statement. Most people won't have a clue and even an experience rule consultant will have to think it through carefully.
    I think it's partly because most people struggle with basic logical propositions. A lot of people don't realize that the negation of "all persons have cars" is "at least one person has no car" and not "all persons have no cars". The other thing with your example is that the syntax seems off to me. The 'all','some','none' are not explicit and it seems that the assumed values are inconsistent. In your example 'person has tattoo' appears to only apply to one person at a time and then the negation seems to refer to every person but I might be misunderstanding the example.
  24. JBossRules is a rule engine that supports First Order Logic and implements RETE algorithm. Although it looks similar to scripting languages it's quite different. Take this classic example. (not (person.hasTatoo == true) ) How many people understand the difference between that example and (person.hasTatoo == false) If i were to make a simple mistake like that in a scripting language, it wouldn't be too big of a deal. If I make that mistake with a rule engine, it could have horrible side effects. The first one (not (person.hasTatoo == true) ) means "there isn't any person with a tatoo". The second means "an individual doesn't have a tatoo." Now imagine I own a tatoo shop and i want to send a discount to all customers with less than 5 tatoos.
    Peter, Not to be critical, but I think the syntax leaves something to be desired. Your example tripped me up because I didn't realize that "person" was existentially quantified within the domain of Persons in the case of (not (person.hasTatoo == true)) and bound to a specific person in the second case. Or when you said "an individual doesn't have a tatoo" did you mean "there exists an individual who doesn't have a tatoo" (the English seems ambiguous, as English tends to be), in which case "person" is always existentially quantified. I don't know much about rule engines (so don't take offense if I'm wrong), but I suppose it makes sense for a rule engine because you're not asserting a fact, but rather quantifying a subset of the domain of Persons on which an action is going to be applied. -Erik
  25. JBossRules is a rule engine that supports First Order Logic and implements RETE algorithm. Although it looks similar to scripting languages it's quite different. Take this classic example. (not (person.hasTatoo == true) ) How many people understand the difference between that example and (person.hasTatoo == false) If i were to make a simple mistake like that in a scripting language, it wouldn't be too big of a deal. If I make that mistake with a rule engine, it could have horrible side effects. The first one (not (person.hasTatoo == true) ) means "there isn't any person with a tatoo". The second means "an individual doesn't have a tatoo." Now imagine I own a tatoo shop and i want to send a discount to all customers with less than 5 tatoos.
    Peter, Not to be critical, but I think the syntax leaves something to be desired. Your example tripped me up because I didn't realize that "person" was existentially quantified within the domain of Persons in the case of (not (person.hasTatoo == true)) and bound to a specific person in the second case. Or when you said "an individual doesn't have a tatoo" did you mean "there exists an individual who doesn't have a tatoo" (the English seems ambiguous, as English tends to be), in which case "person" is always existentially quantified. I don't know much about rule engines (so don't take offense if I'm wrong), but I suppose it makes sense for a rule engine because you're not asserting a fact, but rather quantifying a subset of the domain of Persons on which an action is going to be applied. -Erik
    Oops sorry about the LISPy syntax. It's a bad habit. In JBossrules, the same thing would look like this. not person : Person(hasTatoo == false) I'm not sure that's more readable. Most rule languages are derived from LISP, so the odd syntax takes a bit to get used to. Many people have hard time with s-expression languages and feel it's un-natural :) peter
  26. Oops sorry about the LISPy syntax. It's a bad habit. In JBossrules, the same thing would look like this. not person : Person(hasTatoo == false)
    It wasn't the LISPy syntax. I'd expect it to be written: (not (exists (Person p) (p.hasTatoo == false)) So the existential quantitfication is explicit and p is explicitly bound to the domain of persons.
  27. Oops sorry about the LISPy syntax. It's a bad habit. In JBossrules, the same thing would look like this. not person : Person(hasTatoo == false)
    It wasn't the LISPy syntax. I'd expect it to be written: (not (exists (Person p) (p.hasTatoo == false)) So the existential quantitfication is explicit and p is explicitly bound to the domain of persons.
    ok, I see the confusion. to clarify, in first order logic, there's negation and existential right. For example: (exists (person (hasTatoo "true") ) ) - clips syntax (not (person (hasTatoo "true") ) ) - clisp syntax The first example with "exists" tests to see if there is anyone with "tatoo == true". The second one tests to see if there isn't anyone with "tatoo == true". Exists can also be written this way. (not (not (person (hasTatoo "true") ) ) ) A nested negation means the same as existential. Many developers discover this difference by accident when their rules break and don't work as they expect. The danger of allowing any developer or business person write rules in a rule language is they will make these mistakes and cause serious issues. hope that clarifies it. peter
  28. (not (not (person (hasTatoo "true") ) ) ) A nested negation means the same as existential.
    Which is very confusing because in FOL (not (not A)) => A. In other words, you have to understand FOL in order to effectively use rule engines, but if you try to directly apply your knowledge of FOL sentences when reading rules for some rule engines you are likely to grossly misinterpret them.
  29. (not (not (person (hasTatoo "true") ) ) ) A nested negation means the same as existential.
    Which is very confusing because in FOL (not (not A)) => A. In other words, you have to understand FOL in order to effectively use rule engines, but if you try to directly apply your knowledge of FOL sentences when reading rules for some rule engines you are likely to grossly misinterpret them.
    LOL, yeah that's why I caution people. I'm bias towards a DSL approach. This way, you define a custom purpose language for the business users. The reality is that business users don't need to express "anything" which basically means everything. What they want to do is express very specific things. the job of the developer or rule consultant is to figure out what they really need to express and create a tool which provides just enough flexibility without providing a nuclear bomb. business users want to do their job just like everyone else. they don't want to crash the production system any more than the developers :) the trick is finding that balance which gives business users the power to write business rules and improves the lives of developers. peter
  30. Re: Rule Engine vs. Scripting[ Go to top ]

    James, in many cases you could just use a scripting engine, and it will do the job just fine. In fact, in the "old" version (old being a relative term) we had support for python and groovy as "semantic" languages in drools. We will probably bring that back shortly. However, with declarative rules, its generally discouraged to put great big chunks of code - ideally the rules will be simple declarative statments for example classification (like the example above) or simple calculations - any code is best left outside the rules. Of course this is a fuzzy "rule", and many people ignore it ;) but still, that is the preferred technique for using rules (ie don't put your whole application in rules, just cause you can !). JRuby, Jython, Groovy and Javascript are all good contenders for semantic modules, however with declarative rules, you rules would all pretty much look the same.
  31. Re: Rule Engine vs. Scripting[ Go to top ]

    Jython, Groovy and Javascript are all good contenders for semantic modules, however with declarative rules, you rules would all pretty much look the same.
    Thanks for the response. I'm afraid you lost me with this last sentence. If you don't mind, could you elaborate?
  32. Re: Rule Engine vs. Scripting[ Go to top ]

    Sure. Taking the simplest and most common things you would want to do with a rule in the action part: * setting a field on a bound fact, a variable etc. * calling a method on a fact (if its a bean/object - not true for all rule engines) * calling a function/utility method. In most languages, the above tends to look the same (or simimlar). Take the ruby style syntax for property access: loan.bracket = HIGH (would be the same for Javascript, JRuby, Jython or Groovy). When you want to/need to put chunks of code in the rules, yes the embedded language choice is more important of course, but ideally, rule actions are fairly constrained (keeping the imperative code outside the rules where possible, or at least in a function). Hopefully that makes sense, I am horribly jetlagged and not coping terribly well ;)
  33. Re: Rule Engine vs. Scripting[ Go to top ]

    My ulterior motive for asking these questions was that I recently hacked out a 'very' simple filtering syntax for maps. It only supports equals, and, or, xor and logical grouping. I'm happy with the results because it does exactly what I need but I'm not too happy with the parsing code because it's kind of inscrutable (even too me after a few weeks) because it relies heavily on regex. I was thinking that maybe a standard package of rules would be more supportable but I'm pretty sure it's too much for this simple need and figuring out the rules syntax will be more work than supporting this fairly small class.
  34. Re: Rule Engine vs. Scripting[ Go to top ]

    Hi James. A full blown inference engine could be overkill for that, but certainly it can do it. If you are concerned with heavy use of regex for parsing, I would suggest taking a look at Antlr3, and antlrworks. We use-used it heavily (early adopters) and its quite easy to use, even for "small" languages. Of course you can consider JavaCC and others as well, depending on your needs. They have a slight learning curve, but you can get good results once you get up to speed (yes, this has NOTHING to do with rule engines).
  35. Re: Rule Engine vs. Scripting[ Go to top ]

    Hi James. A full blown inference engine could be overkill for that, but certainly it can do it.

    If you are concerned with heavy use of regex for parsing, I would suggest taking a look at Antlr3, and antlrworks. We use-used it heavily (early adopters) and its quite easy to use, even for "small" languages. Of course you can consider JavaCC and others as well, depending on your needs. They have a slight learning curve, but you can get good results once you get up to speed (yes, this has NOTHING to do with rule engines).
    I have considered that and have wavered. Partly because I don't have any real experience with these tools and partly because I'm kind of the loose cannon where I work (and new) and if I come in and introduce Jython and DSLs and functional-style wrappers for common Java apis all in my first project, I think people are going to get really afraid of me. I'm having enough trouble because everyone on my team is more comfortable with COBOL than Java. I have some Class.forName() stuff in my code and they really don't know what to make of it. There's a fine line between coming across as smart and coming across as crazy. At this point I'm not sure if my coworkers are sure whether I'm full of crap or not. The team needs a jolt, but I have to ration it out. If I decide to expand the filter syntax, I might redo it with a JavaCC type tool but for now, I think I have a better chance slipping my regex stuff in. I probably just need better comments.
  36. Re: Rule Engine vs. Scripting[ Go to top ]

    Hi James. A full blown inference engine could be overkill for that, but certainly it can do it. If you are concerned with heavy use of regex for parsing, I would suggest taking a look at Antlr3, and antlrworks. We use-used it heavily (early adopters) and its quite easy to use, even for "small" languages. Of course you can consider JavaCC and others as well, depending on your needs. They have a slight learning curve, but you can get good results once you get up to speed (yes, this has NOTHING to do with rule engines).
    I have considered that and have wavered. Partly because I don't have any real experience with these tools and partly because I'm kind of the loose cannon where I work (and new) and if I come in and introduce Jython and DSLs and functional-style wrappers for common Java apis all in my first project, I think people are going to get really afraid of me. I'm having enough trouble because everyone on my team is more comfortable with COBOL than Java. I have some Class.forName() stuff in my code and they really don't know what to make of it. There's a fine line between coming across as smart and coming across as crazy. At this point I'm not sure if my coworkers are sure whether I'm full of crap or not. The team needs a jolt, but I have to ration it out. If I decide to expand the filter syntax, I might redo it with a JavaCC type tool but for now, I think I have a better chance slipping my regex stuff in. I probably just need better comments.
    I'm totally bias, so take this with a grain of salt. Writing a parser using JavaCC is straight forward. ANTLR shouldn't be that hard either. For my RETE rule engine, I use JavaCC for my LISP parser. Regexp is powerful, but it's not so good if you want to be able to give the user good error messages. of course, many cases you don't need a real parser and regexp is just fine. scaring your team members is probably a risky thing to do :) that reminds of the saying "lets choose the right solution." I've only been programming for 10 years, but the right solution is largely dependent on the members of the team. Technology X is never a solution in and of itself. I've seen cases where half the team didn't believe in rule engines and fought it. The end result is half the team goes one direction while the rest go another. In the end, the project self destructs because of it. My advice to people thinking about using rule engines is this. If you can't convince most of the team of the value, then don't use it. It doesn't matter how fast RETE algorithm is when most of the team is fighting it. I find explaining the value of a rule engine the hardest part of using a rule engine. peter
  37. Re: Rule Engine vs. Scripting[ Go to top ]

    I'm totally bias, so take this with a grain of salt. Writing a parser using JavaCC is straight forward. ANTLR shouldn't be that hard either. For my RETE rule engine, I use JavaCC for my LISP parser. Regexp is powerful, but it's not so good if you want to be able to give the user good error messages.
    Why do you always say that you are biased? You don't seem all that biased to me. Most people have some bias on any issue. Anyway, that's exactly right, the main problem is with the error message when the filter String can't be parsed properly. It gives a message like "unknown token: ')'". If I changed the code to initialize nodes before their children are created, I could probably give a better message and show the parse tree at the point of failure. The only reason I'm not too worried about it is that the syntax is so simple it shouldn't be hard to identify the issue, especially because I don't think there will be any very complex filters. The biggest problem I've had with it was with debugging the parsing code when it wasn't working properly. I actually might end up having to use JavaCC/Antlr/Sable for my COBOL copybook parsing OS project so perhaps something really simple like this is a good way to get acquainted with the tools.
  38. Re: Rule Engine vs. Scripting[ Go to top ]

    Why do you always say that you are biased?
    Well, from the perspective of someone who has hung out here a while - Peter is smart (at least in the technical arena - I don't know him personally). So what I think he is saying is that from his perspective - it is easy to do. So his smartness biases him. In the same vein, your level of experience/skill/ability biases you too towards your new coworkers. While I am no Peter/Cameron/Steve Z/... I've been there plenty of times. There are some things some normal and below normal developers can handle. I doubt what Peter is suggesting is something they can. Heck, I am doubtful about RegEx. So whatever you choose, I suggest abstracting it away so only those who really can handle it (now or in the future) really need to deal with it directly.
  39. Re: Rule Engine vs. Scripting[ Go to top ]

    Why do you always say that you are biased?
    Well, from the perspective of someone who has hung out here a while - Peter is smart (at least in the technical arena - I don't know him personally). So what I think he is saying is that from his perspective - it is easy to do. So his smartness biases him. In the same vein, your level of experience/skill/ability biases you too towards your new coworkers. While I am no Peter/Cameron/Steve Z/... I've been there plenty of times. There are some things some normal and below normal developers can handle. I doubt what Peter is suggesting is something they can. Heck, I am doubtful about RegEx. So whatever you choose, I suggest abstracting it away so only those who really can handle it (now or in the future) really need to deal with it directly.
    thanks for the compliment. any appearance of intelligence is purely coincidence. You're on the button about the "bias" comment by me. Not everyone likes JavaCC. I'm ok at regexp, but far far from an expert like some people I know. I have a few friends who are Perl regexp wizzes. I find it easier to write a parser than regexp. It's just how my brain works. Considering there's entire books dedicated to regexp, it is very powerful. I tend to think the right tool is largely dependent on the developer and what they are good at. It doesn't matter how good or cool a piece of technology is if a developer can't grep it :) peter
  40. Re: Rule Engine vs. Scripting[ Go to top ]

    In the same vein, your level of experience/skill/ability biases you too towards your new coworkers. While I am no Peter/Cameron/Steve Z/... I've been there plenty of times. There are some things some normal and below normal developers can handle.
    I didn't mean to give that impression. I don't think that I am smarter or more skilled than my co-workers. It's just that they are coming from a totally different world (COBOL and RPG) than me. I feel that if I try to throw too many different approaches at them right away, they will not be able to consider them with the proper amount of care. They will then either push-back (as I might in their position) or feel they are being railroaded by a cocky young dude and become resentful. They have enough experience to know that there are a lot of ideas that come and go. I have a lot of ideas that I want to bring up, I just have to build some trust in myself and some higher priority (to me) concepts like OO first.
  41. Re: Rule Engine vs. Scripting[ Go to top ]

    In the same vein, your level of experience/skill/ability biases you too towards your new coworkers. While I am no Peter/Cameron/Steve Z/... I've been there plenty of times. There are some things some normal and below normal developers can handle.


    I didn't mean to give that impression. I don't think that I am smarter or more skilled than my co-workers. It's just that they are coming from a totally different world (COBOL and RPG) than me. I feel that if I try to throw too many different approaches at them right away, they will not be able to consider them with the proper amount of care. They will then either push-back (as I might in their position) or feel they are being railroaded by a cocky young dude and become resentful. They have enough experience to know that there are a lot of ideas that come and go. I have a lot of ideas that I want to bring up, I just have to build some trust in myself and some higher priority (to me) concepts like OO first.
    I know what you mean. I guess i have the wrong impression. :) I was kinda talking about two things at once. Sorry. With your current co-workers I was talking about different experiences "biasing" your. But also the fact that some of them probably won't be able to bridge the gap between the COBOL/RPG world and the Java (OO, etc) world. They will continue to do, at best, JOBOL. I am speaking from experience. I came from the mainframe world. Granted, the first languages I learned were VB, VBA, C, C++ and Powerbuilder. But my first real experience and work was COBOL and IMS. And over the years I've worked with those who moved from the procedural world to the OO world. Or at least tried. For some, it was "like butter". Many did JOBOL. Others just quit or went back. Anyway, I think you are on the right track.
  42. Re: Rule Engine vs. Scripting[ Go to top ]

    When I look at the Drools code, it looks a lot like a script code (python for example.)

    What advantage, if any, is there to using a tool like Drools over using a Scripting language like Groovy, Jython or JRuby to define business rules? Is Drools another scripting language or something else?

    I have no experience with Drools so these are not rhetorical questions.
    If your business rules for an application are well understood and linear in nature (first do this, then this, then calculate that, then store it here, etc) then I'd say regular programming or scripting is the way to go. I think rules engines are good when the rule-set is unclear, shifts a lot, or is pretty huge. Rules engines are built to perform well under large rule sets or in cases where the source data is changing often. Others have gone into more detail on this thread so I'll leave it at that. They are also great when it is unknown if the business rules conflict with each other or if there is a fuzzy result. You can get more than one correct answer and have a weight associated with it. This works well in comapanies that need to figure out rating (insurance) or determine a price based on rules from several different sources: inventory, sales, marketing, etc. Rules engines are nice when you need to version rule-sets. There are cases where one rule-set is valid to a given date and then you want to switch to another dynamically. Typically there are ways to share common rules across rule sets.
  43. Re: Rule Engine vs. Scripting[ Go to top ]

    When I look at the Drools code, it looks a lot like a script code (python for example.) What advantage, if any, is there to using a tool like Drools over using a Scripting language like Groovy, Jython or JRuby to define business rules? Is Drools another scripting language or something else? I have no experience with Drools so these are not rhetorical questions.
    If your business rules for an application are well understood and linear in nature (first do this, then this, then calculate that, then store it here, etc) then I'd say regular programming or scripting is the way to go. I think rules engines are good when the rule-set is unclear, shifts a lot, or is pretty huge. Rules engines are built to perform well under large rule sets or in cases where the source data is changing often. Others have gone into more detail on this thread so I'll leave it at that. They are also great when it is unknown if the business rules conflict with each other or if there is a fuzzy result. You can get more than one correct answer and have a weight associated with it. This works well in comapanies that need to figure out rating (insurance) or determine a price based on rules from several different sources: inventory, sales, marketing, etc. Rules engines are nice when you need to version rule-sets. There are cases where one rule-set is valid to a given date and then you want to switch to another dynamically. Typically there are ways to share common rules across rule sets.
    I'm being nit-picky here, but the versioning of rulesets should be handled by the rule repository and rule execution server. The rule engine itself shouldn't really care too much as long as the rule metadata is present. I would caution against using rule engines to solve the problem of "unknown rule conflict". As the negation example shows, it's quite easy to royally screw up your production servers if you deploy a rule that "looks ok", but has logic flaws. I personally wouldn't use a rule engine if the ruleset is unclear. I would work towards clarifying the rules first. If i can't clarify the rules, or define sensible limits for the users, my take is to not use a rule engine. I think the BRMRS market has hyped the "business users can write rules" far too much. For specific scenarios, a BRE can improve things, but the biz users have to go through training and there should be sensible limits. peter
  44. Re: Rule Engine vs. Scripting[ Go to top ]

    First my bias: I work for ILOG, a rule engine (BRMS) vendor. I’ve developed many server-side and client-side applications over the years however and have a background in engineering and AI. I know what the “closed world assumption” is for example! ;-) BRMS is not a “silver bullet” but it does bring a very useful set of tools and methodologies to the table. The BRMS market is growing because companies are increasingly facing tough challenges where procedural code (including scripting) is failing them. For example:
    • The pace of change is increasing. It is not uncommon for application upgrades to roll out weekly or monthly. This is especially true for large online applications with many business rules, such as eBay (an ILOG customer).
    • Industry regulation is increasingly. For example, non technical people (rightly, in my opinion) believe that is not unreasonable to systematically store an audit log of how a transaction was processed.
    • All enterprises need a versioning strategy for services. Traditional procedural code is poor at maintaining multiple implementations and allowing clients to invoke each side-by-side.
    • Mergers and acquisitions are forcing companies to reconcile and merge disparate business models and implementations.
    • The push for Service Oriented Architecture is forcing companies to increase the level of communication between IT and business stakeholders. These two groups have different cultures and skill sets but we hope common objectives. Providing a tool set that allows each to focus on their skills and meaningfully collaborate is the key to successful SOA deployments.
    • Reusing services in different contexts demands a level of business transparency into service implementations
    Now an MDA tool vendor or a BPM vendor would probably cite many of the above points as well. This is telling because it shows that these challenges are very real, and there are several technologies that can meet some, or all, of these requirements. To meet these challenges however, and realize the associated benefits, demands an increase in rigor and formalism (no matter which approach is taken). The “old way” of hacking up an implementation in procedural code, intermingling display logic, persistence logic and burying business logic in code that is inscrutable to its stakeholders is drawing to a (long, painful and drawn out…) close. The biggest challenge (and power) of BRMS is that it can blur the boundaries between traditional IT and business stakeholders. When used well, the toolset allows IT people to concentrate on their core skills (scalability, performance, security, fault-tolerance, data access – what I like to call developing an “application container”) while others concentrate on service orchestration and yet others implement high-value business services using business rules -- rules that are accessible to their stakeholders. Accessible can mean many things depending on the level of maturity of the organization: being able to read an HTML report that describes the business rules behind the implementation, seeing a runtime report of the rules fired for a given transaction, modifying parameters in a look-up-table or decision table or taking full ownership of the definition of the business rules. A strong change management process and culture that can cope with changes coming in from different groups is important for successful deployments. If I had to summarize the BRMS approach in a sentence it would be that it allows the business to concentrate on the “what” rather than the “how” (to steal a phrase from CJ Date). Today the “what” is turning out to be much more important than in the past. The “how” changes frequently (Java or C# anyone?), but a business is expect to have a deep understanding of how it is processing transactions based on its business policy. Managing the “what” demands a tool set that goes well beyond a developer’s “traditional” tools such an IDE, source control and (maybe) UML. This formalism impacts the business side too of course, unfortunately many businesses today have lost track of their business policy and essentially “function as implemented”. Sincerely, Dan
  45. know all of the benefits that Drools Rule Engine provided,but I must face to one situation when I want to choose the Rule Engine Solution.As you know,in some interprise application environment,before you make a making desion using rule engine, you must get the data from other datasource(For example,database),so you must do some db access,this will be a performance issue.If we catch these data in memory,but usually these data is very large.So the result, sometimes we must give up the rule engine solution,and choose the store procedure solution in real world.How to deal with this solution?
  46. This seems to be a very old post but let me reply anyway in the hope that my research might help mankind in some way ;) From whatever little research I have done on Rule Engines, there are 2 types of engines (w.r.t. the deduction/inference algorithm): forward-chaining and backward-chaining. The latter is apparently more suitable for this particular purpose. An example is Mandarax. I am not an expert so please do trouble your favourite search engine. Tr gaurav