TSS Article: An Introduction to the Drools Project

Discussions

News: TSS Article: An Introduction to the Drools Project

  1. In this article, Alex Rupp discusses how Rules Engines can improve the agility of your business by helping you isolate the "logic of the bottom line" from the technical logic of your software applications. He introduces the JSR-94 Rules Engine API and an open source product called Drools, an implementation of this up-and-coming technology.

    Read The Logic of the Bottom Line - An Introduction to the Drools Project

    Threaded Messages (41)

  2. some time ago I got some interest about it, but it's poor&fragmental doc failed me. I have to turned to JESS recently
  3. Very good article. One thing not mentioned is the extent of a Rule Engine approach applicable in a project. It appears on first reading that these just allow conditional logic to be made declaritive.

    However, in the 'old' large IT corporate industry, a Business Rule system is much more then that (see for example, the book "Business Rules Applied"). Do the Rule Engine's mentioned, like Drools, allow use for "Business Rule" use? According to the Drools document, Drools is not intended for Business Rules that use a 'higher-level' form, that do not use the if-then format, see the drools-manual-2.0-beta-13, section 3.4.

    Or is this just a notational issue, and transforms are applicable?

    --- J. Betancourt
  4. The JSR and Drools allows for the use of logical rules (if-else conditions). These are lower-level than business rules. Business rules can be written as a combination of these logical rules along with a mapping exercise.

    To create a business rule you need a ruleset. But currently a ruleset cannot contain a another ruleset which is a problem. There are vendor-dependant ways to work around this.
  5. second article[ Go to top ]

    Alex, when are you planning to release a follow up article?
  6. O'Reilly Articles on Drools ...[ Go to top ]

    ... Not Officially a second article , but it does pick up where this these articles left off

    http://www.onjava.com/pub/a/onjava/2005/08/03/drools.html
  7. How does it compete with JESS[ Go to top ]

    Same here, I went through the drools website but could not find enough docs. to get me started. Eventually I had to turn to JESS. Also because its more mature and there's a book "JESS in action" available.

    /t
  8. Another mature project is Manadarax:
      http://mandarax.sourceforge.net/

    There is also a pretty nice rules editor available for it:
      http://www.jbdietrich.de/

    Regards,
    Colin
  9. about mandarax..[ Go to top ]

    Hey Colin,

    Thanks for your post.
    Have been looking for a rule engine which regards _retrieving the proof_
    as worthy enough to be in the docs and API !
    Haven't really tried it yet but looks nice.

    Some might view yours as a 'shameless plug', but drools seemingly not moving
    anywhere these days(?) -docs or otherwise-, other good OS rule engines certainly
    deserve as much attention as d(ead?)rools
  10. about drools..[ Go to top ]

    To the good folks at drools:
    Just read in the article "Drools is approaching its 2.0-beta-14 release"
    ..so isn't dead at all, also has JSR-API support, which is good.

    I apologize for my hasty judgement on drools.
    But still I am missing in drools: _getting the proof_ , good docs
  11. RETE vs. PROLOG[ Go to top ]

    Be careful to compare apples to apples (or oranges to oranges if you want).

    You may find that the PROLOG based backward-chaining rules engines are not performant enough for your needs...
  12. No shame in plugging[ Go to top ]

    Some might view yours as a 'shameless plug', but drools seemingly not moving anywhere these days(?) -docs or otherwise-, other good OS rule engines certainly deserve as much attention as d(ead?)rools
    There's no shame in plugging other projects or in criticizing our documentation, but please let's keep things clean and fair around here. I think Drools is a great product, and with a little more momentum, it could be a fantastic Open Source project.

    When I started working with Drools, I was attracted to the JSR-94 interface layer, because I could use it to get started with Rules engines, without much fear of vendor lock-in (even from an Open Source project--it's the principle of the thing that matters).

    What I found was that the JSR-94 module for Drools had been shut down, the tests turned off and the code left unfinished. Also, there wasn't very great documentation for it. But I didn't gripe about it. It's an Open Source project, and the guys who wrote it are busy working on other stuff. I downloaded the code from CVS, hopped on the project IRC channel at irc.codehaus.org/#drools, asked a few questions and took some initiative. In a couple of weeks I'd finished the JSR-94 module, got the tests running, and added a top-level maven build. Now I'm working on documentation and articles to help others get started with Drools, and doing whatever I can to promote what I consider a very good project. That is how Open Source projects get written.

    I don't think the Jess or Mandarax guys have anything to be ashamed of by letting other people know about their projects. If their PR guys or user evangelists want to ride on my coattails and plug their projects, so be it (nothing like a good-natured inflammatory comment to stir up the crowd ;)

    But I'll have you know--this project is not dead. I know the documentation sucks--I had to figure out how it all worked by digging around in the code. Now I'm working on more and better documenation, example code, and the like, and I'd encourage anyone who wants to participate to come hang out with the rest of the developers in IRC.

    Besides, anything beats paying $25k per processor per year for a license to the BizTalk rule engine, right?
  13. No shame in plugging[ Go to top ]

    Besides, anything beats paying $25k per processor per year for a license to the BizTalk rule engine, right?
    Yep. Because it doesn't stop there because of all the other things you will need or have to use because of the platform choice.
  14. No shame in plugging[ Go to top ]

    I appreciate these open-sources guys' work.And I also know clearly about the hardness of rolling the ball.
    If u can't afford the time for a comprehensively docs, may I suggest you to supple a sample program for ppl to get started, it's easy and very helpful.
  15. No shame in plugging[ Go to top ]

    Me too. I was refering to Biztalk + Sharepoint + Exchange ...
  16. No shame in plugging[ Go to top ]

    Good article Alex.

    I'd like to see the JSR improved to allow the back-end be pluggable - perhaps using Service Data Objects. This would allow me to store my rule configuration in a relational database, an xml database, a DRL file or something else. I'd also prefer to see a rules description language as a standard - it helps with portability and reduces the learning curve. As with EJB3.0 I guess some of this could be meta-data driven.

    Other items amongst my wish list - the ability to intercept the execution of a rule (for logging for example rather than stopping execution) - similiar to the servlet filters concept, the use of a composite pattern to allow rulesets to contain other rulesets, standardisation of concepts (perhaps alignment with the OMG spec.).

    I also think that DROOLS has potential but as a user its frustrating to work with.
  17. Vendor-specific AST objects[ Go to top ]

    Good article Alex.
    : )
    I'd like to see the JSR improved to allow the back-end be pluggable - perhaps using Service Data Objects. This would allow me to store my rule configuration in a relational database, an xml database, a DRL file or something else.
    While the moniker "AST" might not be fitting, the API does allow for the creation of RuleExecutionSet objects from vendor-specific objects. So, presumably, you could write an implementation that supports everything you've mentioned above. I'll have a talk with Bob about it and see what we can do--I've thought the same myself.
    I'd also prefer to see a rules description language as a standard - it helps with portability and reduces the learning curve.
    Actually, rather than standardizing the rule description language, it might be better to standardize something similar to Drools' semantics module framework. Then application developers could customize their own Domain Specific Languages and write a quick-and-dirty compatibility layer to hook it into the SMF. If you look at how the Java semantics library hooks into the SMF in Drools, you'll see how simple this is. My next article is going to explore this concept in depth.
    As with EJB3.0 I guess some of this could be meta-data driven.Other items amongst my wish list - the ability to intercept the execution of a rule (for logging for example rather than stopping execution)
    We actually have an experimental AOP branch that does exactly this. We use AspectJ to monitor events in the WorkingMemory. It's very useful for debugging and performance monitoring. You can probably expect to see it in the beta-14 release.
    similiar to the servlet filters concept, the use of a composite pattern to allow rulesets to contain other rulesets,
    I've been kicking around some ideas in my head for how to better organize Rule Execution Sets for doing composite patterns. If there were a distinction in the JSR API between RuleExecutionSets and RuleSets, we'd be able to cobble together RESs. Bob and I have asked about this a couple of times. We're also looking into ways to execute Rule subsets, but I don't know how quickly these features will make it into a release.
    standardisation of concepts (perhaps alignment with the OMG spec)
    That gives me the willies. I'd rather write a Business Rule Language semantics module to plug into the Drools SMF than to drag the OMG stuff into the JSR. Just Say No.
    I also think that DROOLS has potential but as a user its frustrating to work with.
    Hey, man, I sympathize and take your feedback seriously. I consider myself a user as well, and it can get tough. It helps for people to be able to tell us that in a forum where we have to listen (this was a major part of my impetus for writing the article). The test now is whether or not the project's members and developers respond. But there's a lot of room for new users and developers to get involved as well. The cool thing about the project is that it's wide open for enterprising users to get involved as developers and contributors. I'm working on the documentation, and on getting the drools.org site migrated to the Confluence docs section of Codehaus (http://docs.codehaus.org/display/DROOLS/Home).

    Thanks for the feedback, man--I appreciate it.
    --
    Alex
  18. Already exists in Jess and ILog[ Go to top ]

    If there were a distinction in the JSR API between RuleExecutionSets and RuleSets, we'd be able to cobble together RESs. Bob and I have asked about this a couple of times. We're also looking into ways to execute Rule subsets, but I don't know how quickly these features will make it into a release.
    I believe both Jess and ILog have the concept of modules, which basically achieves the same results as executionsets. Modules in Jess are very power and allow you to manage execution of rulesets into separate modules. If I'm not mistaken, quite a bit of research in this topic occurred in the 80's and early 90's. The concept isn't new and the major Rete engines already have it. Also, JSR94 uses jess for the reference implementation. There have been several papers in the past using the concept of modules to categorize large rulesets. The resulting modules could then run within the same rule engine, or be distributed across multiple machines. ACMQueue has some of these old papers, so look there and you'll see some useful information.
  19. Example applications[ Go to top ]

    ... If u can't afford the time for a comprehensively docs, may I suggest you to supple a sample program for ppl to get started, it's easy and very helpful.
    We've got a module in CVS with three example applications. We also have a lot of unit tests. The tests in the JSR-94 package do a great job of showing how to use the Java semantics. In addition, I'm working on a tutorial with it's own "dirt-simple" example, so beginners can get started. Things are coming along :)
  20. Besides, anything beats paying $25k per processor per year for a license to the BizTalk rule engine, right?
    Yep. Because it doesn't stop there because of all the other things you will need or have to use because of the platform choice.
    If I'm not mistaken, BPML is converted to SQL in Biztalk. Strictly speaking BizTalk is not a rule engine and doesn't provide any chaining capabilities. It is strictly procedural. This approach has been tried numerous times in the past to great failures. A backward or forward chaining rule engine is much more powerful, since rules are compiled into a network of nodes.
  21. Vendor lock-in[ Go to top ]

    I could use it to get started with Rules engines, without much fear of vendor lock-in
    All you are gaining via the JSR is no code changes to move to a different vendor. You would still have to convert your rules into the language/syntax of the vendor you are trying to port to, which, for a decent sized application could be a major effort. I wish that there was more standardization in the JSR/JCP regarding the rule definition language. That would be true vendor independence.
  22. I could use it to get started with Rules engines, without much fear of vendor lock-in
    All you are gaining via the JSR is no code changes to move to a different vendor.
    Believe me, that's a great start! God I love open standards :)
    You would still have to convert your rules into the language/syntax of the vendor you are trying to port to, which, for a decent sized application could be a major effort.
    One of the huge attractions for Drools is that I can write my own Domain Specific Language. As long as other vendors have some sort of semantic module framework like Drools has, I should be able to write a compability layer for other engines (which would probably end up being easier than porting all the rules). At least the client code has a common interface. I know it isn't perfect independence, but then again it turned out that I became a developer in the project, which I wasn't really expecting. That's almost as good as competely avoiding vendor-lock in.
    I wish that there was more standardization in the JSR/JCP regarding the rule definition language. That would be true vendor independence.
    Or, perhaps the next JSR could address the requirements for building a Drools-style semantics language framework. The SMF and IO modules in Drools are very simple, straightforward, and they allow an incredible degree of language independence.

    Very good points, though :)
  23. Help required in drools[ Go to top ]

    Can someone please send me a sample drl file which has java functions in it? My requirement is as follows: I have a set of rules in a xml file. I need to read the xml and store the values in a HashMap.How do i do this in a drl file?
  24. Mandarax is based on backward reasoning
    So it is not exactly the same as an original (Drool) system

    Dmitry Namiot
    http://www.servletsuite.com/
  25. License for JESS[ Go to top ]

    Same here, I went through the drools website but could not find enough docs. to get me started. Eventually I had to turn to JESS. Also because its more mature and there's a book "JESS in action" available./t
    I have read that the license is $10.000 (Google: jess + license).
    Is that true ?

    Best regards,

        Andres
  26. Is there any evaluation report on the open source products of rules engine? What's the common features of rules engine? What's the advantage and disadvantage of the specific product? Which one is popular one and widely adopted?
  27. drools is alive![ Go to top ]

    drools is alive! its just not very active :)

    yes, more documentation is needed and articles such as this help address that deficiency. things are looking good!
  28. That example is scary. The "rules" embedded in XML are integers, strings, and floating points. You might as well give the "executive" pre-build SQL queries and tell him to go to town on the database. The only increase in security your "XML rules" have over raw SQL is that there are more failure points (thanks to the complexity of XML parsing) so the likelihood that he breaks something important on accident with a typo or accidentally malicious query is reduced directly proportional to to probabilility your system will fail due to invalid data.
  29. An XML language is not ideal by any standard, but its a start - the goal is to definitely move away to a more user oriented langauge. To leverage what we have in a usefull way I instead create "rule building" screens for specific problem domains, in this case absence tracking. A business user can define how things like service, age grade affect the base entitlement or how warnings and resets happen on carryovers - this is all country specific and doing it programmatically is not desirable.

    The rule builder screens store their information in a DB which I dump to XML I then have XSLT transfer them into drools DRL files - this works great, it means I have a generic framework to allow users to build rules within a given/known problem domain. The only work I do is in building/tailoring the rule building screens and in the XSLT files to map the various options to a a resulting DRL. So I can concentate of programming a framework, not on business rules, and business concentrate on building the rules. If we change vendor I only need to update the XSLT files to output the rules to a different format.

    As each rule builder screen is tailored to the problem domain it presents the relevant facts, conditions and consequencs that make sense to the current context so little training is needed.
  30. Domain Specific Languages[ Go to top ]

    An XML language is not ideal by any standard, but its a start - the goal is to definitely move away to a more user oriented langauge.
    Mark's right here, and there's been some talk about it in the IRC channel. I wrote a Java.net blog on Domain Specific Languages (http://weblogs.java.net/pub/wlg/1359).

    It's tough to talk about DSLs without having pictures, but high level and narrowly-scoped languages captured in innovative UIs and tool sets are definitely the future of this. DSLs can more easily be translated to code or XML, which is where the Drools SMF comes in. Being able to support any type of XML you want makes Drools an incredibly powerful competitor as far as Rule Engines go.

    I've only just begun to explore the possibilities of that myself, and I'll cover the topic in greater depth in future articles.
  31. Domain Specific Languages[ Go to top ]

    Would it be possible to generate the DSL from your Domain Model? So when you're "MDA-ing" your code you also spit out the DSL?

    Just wondering...
  32. Technical support or development should be the only people able to edit the configuration of rules manually. Otherwise - as you say it ends up being a complete nightmare. For example, DROOLS allows the adding of Java expressions in its ruleset configuration files. These expressions are only evaluated at run-time.

    BTW. this does not exclude the use of a user interface with validation constraints that subsequently regenerates the ruleset files.
  33. Yeah, the example is pretty scary. Obviously, you'd want to write a Domain Specific Language for working with the rules and give the executives a GUI editing tool. That's just common sense, but I couldn't hack out a complete DSL and toolset for this article--I'll work toward that in future articles, though :)

    Thanks for the feedback. I appreciate it :)

    --
    Alex
  34. www.javarules.org/[ Go to top ]

    More general information on rule-based programming in Java:
    http://www.javarules.org/

    If you would like to discuss ideas for future evolutions of the Java Rule Engine API please subscribe to the mailing list on the site.

    All contributions welcome.

    Sincerely,

    Daniel Selman
  35. the challenge with declarative rules[ Go to top ]

    I've been using Rete Rule engines since 2K and often the hardest part of implementing rules is the learning curve. It takes time and patience to really think in a declarative mode to optimize pattern matching. If you look at the questions on Jess mailing list and countless other mailing lists for Expert Systems, you'll see people try to wedge procedural logic into rules. For those who are interested in Rule engines and more specifically Rete algorithm, I would recommend Earnest's Jess In Action from manning. Drools is a backward chaining engine that implements a modified version of Rete. Mandarax on the other hand is a query based rule engine and doesn't implement Rete. It fits well into query centric applications, but it is difficult to scale to large datasets. Query based rule engies are better suited to applications that use small amounts of data, which means the queries should ideally return atomic facts and not thousands of rows of data. Backward chaining rule engines are often used in ECA (event condition action) systems. In practice, you don't need a backward chaining rule engine to implement ECA. Forward chaining rule engines can achieve the same result. Most of the modern Java Rule engines can achieve 30-80K rule activations per second on a 1.4ghz CPU with Jdk1.4.x.
  36. Differences between engines[ Go to top ]

    Correct me if I'm wrong on the difference between a Rete style system and a Backward Chaining (BC) system.

    Using the example of "What is the discount for customer X".

    My understanding is that for a Rete system, all of the factors related to, in this case, pricing are presented to the rule set, and as those factors are interpreted and distributed through the system, eventually the "discount" bucket will be populated correctly.

    So, in essence, you provide the "facts" of the example to the system, and then you'll simply pull out the result (in this case the discount).

    With a BC system, instead you present it with the base query and the engine then determines from its rule what facts it actually needs to come up with a correct result.

    Consider that perhaps the three criteria necessary to determine discount are Customer Type, Customer Volume, and, Customer History to calculate a Loyatly Bonus.

    In a Rete system, we must "know" that we have to provide Type, Volume, and History to the system in order to determine Discount, whereas in a backward chaining system, the system will inevitably ASK for those pieces of data.

    As a corollary though, it seems that Rete systems are better designed to be reactive, whereas BC are more informative.

    Simple example, if you want to send an email to the Account Manager when a Customers outstanding balance is approaching some credit limit, in a Rete system, you'd simply add a rule "If creditBalance - outstandingBalance < margin then email manager", and that would "automatically" be fired when either the creditBalance or outstandingBalance were changed. In a BC system, wouldn't you need to have a nightly process "asking" if an email needed to be sent? Rete systems figure things out as the data comes in, where as BC system figure things out as the questions are asked. Is that a good distinction between the two?

    I'm in a quandry with our system, on which we have a hacked, very coarse rule system.

    On the one hand, the Rete system makes a lot of sense, as most of our things are event based "if this changes then do that". But, we have hundreds of variables for each case, as well as the entire history of those variables. So, it seems execessive to have to load the entire data set to manage the changing of a single variable. On the other hand, a BC system would fetch the data as required (which is what our generic java code does anyway), but how does it "know" which rules to fire? Currently we coordinate this stuff by hand "when variable X changes, do rules A, B, C". A better rule system would make those associations automatically.

    Perhaps I'm completely missing the boat, and the two systems are essentially identical with only subtle difference at the fringes of the bell curve.

    Finally, does anyone have a good online reference to the Rete algorithm? Everything I've seen points to an AI magazine article from, like, 1982, and I've never seen it discussed in any real detail online.
  37. Rete[ Go to top ]

    The "Jess in Action" contains a good overview of the Rete algorithm. Also, check out the Rete section on Ernest Friedman-Hill's Jess page at:

    http://herzberg.ca.sandia.gov/jess/docs/61/rete.html
  38. Rete reference[ Go to top ]

    The "Jess in Action" contains a good overview of the Rete algorithm. Also, check out the Rete section on Ernest Friedman-Hill's Jess page at:http://herzberg.ca.sandia.gov/jess/docs/61/rete.html
    As does the ILOG JRules documentation! See the "Rule Engine User's Manual" for example. ;-)

    Also note that JRules (as well as other commercial rule engines) also support multiple execution algorithms for when the stateful nature of RETE is not required.

    Go download an eval (http://www.ilog.com/products/jrules/) and you will see that much of the value of business rules comes from the tool support that enables business users to author/edit rules in a controlled way with minimal interaction with IT. This includes using higher-level authoring constructs like decision tables or decision trees.

    JRules 4.6.x includes a rule-enabled version of Petstore (what else!) that runs out of the box (on Tomcat+JOnAS+HSQLDB) for you to tinker with.

    Sincerely,

    Daniel Selman

    Product Manager
    ILOG JRules
  39. ILOG[ Go to top ]

    I know this is supposed to be a Drools plug, but I must say, ILOG is definitely a very good product. The only product I could find (sometime back when I was evaluating) that allows a non-IT person to create business rules in a natural-english language via a web browser (not forced to use the rule builder GUI). It's got a nice, intuitive web interface for rule building. For most other products, you would have to build your own high level, natural language to low level,vendor-specific translation. The demo is definitely worth checking out.
  40. It can be, but not necessarily[ Go to top ]

    Correct me if I'm wrong on the difference between a Rete style system and a Backward Chaining (BC) system.Using the example of "What is the discount for customer X".My understanding is that for a Rete system, all of the factors related to, in this case, pricing are presented to the rule set, and as those factors are interpreted and distributed through the system, eventually the "discount" bucket will be populated correctly.So, in essence, you provide the "facts" of the example to the system, and then you'll simply pull out the result (in this case the discount).With a BC system, instead you present it with the base query and the engine then determines from its rule what facts it actually needs to come up with a correct result.Consider that perhaps the three criteria necessary to determine discount are Customer Type, Customer Volume, and, Customer History to calculate a Loyatly Bonus.In a Rete system, we must "know" that we have to provide Type, Volume, and History to the system in order to determine Discount, whereas in a backward chaining system, the system will inevitably ASK for those pieces of data.As a corollary though, it seems that Rete systems are better designed to be reactive, whereas BC are more informative.Simple example, if you want to send an email to the Account Manager when a Customers outstanding balance is approaching some credit limit, in a Rete system, you'd simply add a rule "If creditBalance - outstandingBalance < margin then email manager", and that would "automatically" be fired when either the creditBalance or outstandingBalance were changed. In a BC system, wouldn't you need to have a nightly process "asking" if an email needed to be sent? Rete systems figure things out as the data comes in, where as BC system figure things out as the questions are asked. Is that a good distinction between the two?I'm in a quandry with our system, on which we have a hacked, very coarse rule system.On the one hand, the Rete system makes a lot of sense, as most of our things are event based "if this changes then do that". But, we have hundreds of variables for each case, as well as the entire history of those variables. So, it seems execessive to have to load the entire data set to manage the changing of a single variable. On the other hand, a BC system would fetch the data as required (which is what our generic java code does anyway), but how does it "know" which rules to fire? Currently we coordinate this stuff by hand "when variable X changes, do rules A, B, C". A better rule system would make those associations automatically.Perhaps I'm completely missing the boat, and the two systems are essentially identical with only subtle difference at the fringes of the bell curve.Finally, does anyone have a good online reference to the Rete algorithm? Everything I've seen points to an AI magazine article from, like, 1982, and I've never seen it discussed in any real detail online.
    I'm most familiar with Jess, so I'll use it as an example. Jess can work in both forward and backward chaining. The normal mode of operation with Jess is you add an object to the rule engine using definstance method. The rule engine converts the object to unordered facts and asserts them to the working memory of RETE. when that happens, the facts begin at the root node of the object and traverse through the RETE network.
    Say you have this rule, "if the balance is less than 100.00 and there's no pending deposit, send an email notice to the customer." If I add the a withdraw transaction to the rule engine, it will perform the pattern matching for the first condition. If my account data isn't in the working memory, the rule won't fire. If my account information is already in the rule engine, the rule engine will fire if I have no pending deposits. If we run this same scenario in BC mode, the rule engine would match on the withdraw transaction and update the join node to the next condition. Assuming the app is setup to query the database, it would fetch the data and assert it to the working memory. If both conditions are satisfied, the engine would fire the rule.
    For me, BC is a powerful tool for figuring out "what conditions do I need to satisfy a rule." I'm definitely biased on this topic, so take this with a grain of salt. Running an engine in BC mode and letting it query automatically can lead to undesirable results, like loading a ton of data unnecessarily. To avoid that, you have to code the rules and queries such that you get the smallest piece of data from the database. I prefer to separate the logic of what data is needed with the actual reasoning in two components. This way, the reasoning process happens very quickly and the process of getting data doesn't block the rule engine. Forward chaining can achieve the same query like process, but that's a complex topic.
  41. Who's actually going to use it ?[ Go to top ]

    From a techie point of view rules engines are great. But realistically who's going to be using them. In the article there was mention of techno savy managers or whatever who're going to write the rules in xml. Come on guys, business people DON'T want to know about anything technical, that's what the techies are for. For those old timers out there, remember the days when case tools which could automatically generate "business logic" code were in vogue, where are they now ? We've been down a variant of this path before. Rule Engines are great for non-business type industries, where the main users are technical in nature e.g. biotech, .... But they'll never gather enough momentum in the business world to take off.
  42. Announcing RulesWorld.com[ Go to top ]

    Please join www.rulesworld.com today. This is an open business rules modeling and collaborative community designed to educate the market about the value of rules. RulesWorld also provides to community members, at no cost, Corticon's flagship Business Rules Modeling Studio (a $5K per seat value). This is not a crippled version of the product. It’s full featured and is meant to give the user a complete rule modeling experience. We believe that until users are hands-on, they can’t fully appreciate the value of business rules and to know what to look for in a BRMS. We therefore have lowered the barrier to entry and allow community members to use rules without having to invest any money upfront. Users can: • capture their business policies as rule models • analyze rule models to: o ensure completeness of their policies o identify/resolve policy conflicts and loopholes o remove policy redundancies • scenario test rule models to see them in action • put together POCs to demonstrate to end users the value and agility of rules All this can be done in without the need for programming. Think of it as the Microsoft Excel for business rules modeling. Of course once they have gotten this far, then they can make an educated decision as to whether a BRMS purchase and rules automation make sense for them. Should they choose Corticon BRMS, then their rule models are directly deployable as Decision Services. Should they choose another BRMS, at least they have made an informed and educated buy decision. We hope that RulesWorld helps promote the business rules domain overall. This site is also meant to allow business rules experts to do self-promotion and in the process help educate the community about the value of business rules. Look forward to seeing you there.