Is there a rules engine that can handle constantly changing rules? The scope of the rules is well defined, but users have the ability to change parameters of rules within that scope whenever they choose to. I don't expect to have more than a couple thousand rules, but they will likely experience numerous changes each time a user joins the system. Should I scrap the Rules Engine idea altogether here or does something exist that meets these demands? I wasn't able to find anything online except an IEEE paper.
Any business rule engine is nominally designed to handle this use case. However, you will find that they all have different takes on what is important and the technology stacks will be different. The above answers for InRule and CodeEffects seem good for environments where .Net is required.
Based on statements in your question, it seems that you are going to have a lot of churn in the rules. I think it is important for you to consider then who will be making these changes and what the governance of the changes will be. These considerations may be more important to you than the technology platform (.net / java / hosted) or the initial implementation effort, actually. Most rule projects should be considered with the on-going maintenance in mind more than the initial development.
Related
What are the benefits of the "Convention over Configuration" paradigm in web development? And are there cases where sticking with it don't make sense?
Thanks
Convention states that 90% of the time it will be a certain way. When you deviate from that convention then you can make changes...versus forcing each and every user to understand each and every configuration parameter. The idea is that if you need it to differ you will search it out at that point in time versus trying to wrap your head around all the configuration parameters when it often times has no real value.
IMHO it always makes sense. Making convention the priority over explicit configuration is ideal. Again if someone has a concern, they will force themselves to investigate the need.
I think the benefit is simple: No configuration necessary. You don't need to define locations for this-or-that type of resource, for example, for the app/framework to find them itself.
As for cases where it does not make sense: any situation where it will be fairly frequent that alternative configurations would be required, or where it makes sense that a developer/admin would need to 'opt-in' to some behavior explicitly (for example, to prevent unintended and unexpected side-effects that could have security implications).
The benefit of convention over configuration paradigm in web development the productivity since you won't be required to configured to set all the rules and there are less decision that a programmer has to make. This is evident when using the .NET Framework.
The most obvious benefit is that you will have to write lesser code. Let's take case of Java Persistence API. When you define a POJO having attributes and corresponding setters/getters, it's a simple class. But the moment you annotate it with #javax.persistence.Entity it becomes an entity object (table) which can get persisted in DB. Now this was achieved by just a simple annotation, no other config file.
Another plus point is, all your logic is at one place and in one language (i.e. you get rid of separate xml).
I think this wikipedia article has explained it very well:
Convention over configuration (also known as coding by convention) is
a software design paradigm used by software frameworks that attempts
to decrease the number of decisions that a developer using the
framework is required to make without necessarily losing flexibility.
The concept was introduced by David Heinemeier Hansson to describe the
philosophy of the Ruby on Rails web framework, but is related to
earlier ideas like the concept of "sensible defaults" and the
principle of least astonishment in user interface design.
The phrase essentially means a developer only needs to specify
unconventional aspects of the application. For example, if there is a
class Sales in the model, the corresponding table in the database is
called "sales" by default. It is only if one deviates from this
convention, such as the table "product sales", that one needs to write
code regarding these names.
When the convention implemented by the tool matches the desired
behavior, it behaves as expected without having to write configuration
files. Only when the desired behavior deviates from the implemented
convention is explicit configuration required.
In our project we have to implement business logic regarding mapping of certain objects to some actions. We will have a series of conditions for specific types of objects to be verified before a certain action finally gets resolved. In other words for 7 types of objects we can have a series of actions ( from out of almost 45 actions).
We were thinking of using Drools to write down the aforementioned rules. Does anyone have some positive / negative experience with using Drools as far as its efficiency is concerned? There is also the jBPM framework that can be used (if I am not mistaken Drools are used there) – anyone is familiar with that framework? Perhaps you have some other ideas of how to solve the problem?
With regards efficiency, you should have no issues at all with Drools. That sounds like a pretty tiny set of facts and rules to me. The Rete engine on which it is based is almost certainly faster at making decisions than any pile of if-then-else statements you code up yourself. And a particular benefit that I noticed is that response times are extremely predictable.
Obviously all fact models and rules differe, but as an example, the application I'm currently building has hundreds of facts in working memory at any time, and more than 1000 rules. It's able to make decisions about incoming requests in about 20 milliseconds.
The full jBPM framework doesn't sound necessary for what you describe. However, it is good at what it does. For instance there is a process modelling GUI if you're looking to design workflows, and Guvnor can be usable for non-technical rules authors if the technical team puts in some up-front effort on writing DSLs and building decision tables.
For completeness, the main competitors are probably FICO Blaze Adviser or IBM ILog JRules. Generally when it comes to benchmarks those tend to be slightly ahead of Drools, but they are expensive. Admittedly, if you decide to pay for JBoss/RedHat service contracts then it's not much different, but if you're happy to take community support on Drools, then it's free!
My only concern about Drools is that there is no decent GUI for it that a non-IT business people could really use. Lots of products claim that they do provide such UI but it always turns out to be not really true. So, you have to accept the fact that your development team will end up creating and testing all those rules based on decision tables or some other formats.
Other than that, Drools is a great BRE used by governments, banks and large companies.
Drools is very efficient and fast. But as with any technology & framework it will need an investment to integrate into your project and it is not a magic bullet. You need to consider:
How many rules will you have? I would not recommend any rule engine if there is less than 20 rules. It might not justify the effort you will spend for the compexity of adding a rule engine just for 7 objects and 45 actions...
Will you need DSL (Domain Specific Language) capabilities? Ie. will non-technical people write rules? IMHO this is not very usable in Drools in comparison to eg. Oracle OPA. But again I have not seen a non-technical person safely tinkering with a rule system yet. Apart from changing values in a decision table.
How often will your rules change? If you need a centralised system to manage, version, package, test your rules then Drools Guvnor is a very capable product.
jBPM is not a rule engine, it's a workflow engine. Drools is a rule engine. So Drools is what you're looking for.
Drools and jBPM are companion projects: they integrate really nicely if you need workflows with rules.
Drools is good well JBPM is bit complex as compared to other BPMN engines. I would suggest go for Activiti because it is bit easier and integration of anything say Spring, LDAP etc.; with Activiti is easier. Also you can integrate Drools with Activiti.. so go for Activiti as aworkflow engine and Drools for a rules engine.
Rules Engines are often sold under the premise of making it possible for business people to modify some very dynamic parts of the application directly, without any involvement or programming done by the developers.
In my opinion, putting into production any code that is not covered by automated tests represents a grave risk. I know that many rules engines are actually a rules management environments, including versioning, promotion between environments etc.but what support they offer to BA for writing tests? I have seen some documents where it seems frameworks like JUnit are integrated into the engine and this is certainly not the type or programming that non-programmer would do.
BA can easily change the rule with business engine, but how easy is for him to write a test that can cover it without the help of a programmer? How is the problem of rules test coverage resolved in practice?
"making it possible for business people to modify some very dynamic parts of the application directly, without any involvement or programming done by the developers."
We have been using a commercial rules engine for over 6 years now. We build template applications that are customized as per the customer's (like banks etc) requirements. The customization's are in the form of decisioning rules which are written in business vocabulary. Below are some of the observations that I've made over 6 years
I've never seen any rules customized on the fly in production by any customer. They all go through proper testing in the UAT environment before they are pushed to production. The whole app is not re-deployed, only the business rules are pushed.
Rules are written by the BA's but most of the time they still need to go through the developers for performance tuning purposes because of the execution model that these rules engine use.
I doesn't know about many open source rules engines but for the one we use, we wrote custom eclipse plugins so that that BA's can generate the test cases in the form JUnits
I think most of the rules engines will provide some sort of a API that tells which rules were fired in the form of audit report for a given request. But the challenge for us was to find the test data that can fire a particular rule. We call it as rule relevant data.
Recently, I am reading about the rule engines in JBOSS Drools Manual [ref - 2.2.5. Strong and Loose Coupling]. Below is the excerpt from it 'If your rules are all strongly coupled, the chances are that the rules will have future inflexibility, and more significantly, that perhaps a rule engine is overkill (as the logic is a clear chain of rules - and can be hard coded. [A Decision Tree may be in order]). This is not to say that strong or weak coupling is inherently bad, but it is a point to keep in mind when considering a rule engine and in how you capture the rules. "Loosely" coupled rules should result in a system that allows rules to be changed, removed and added without requiring changes to other rules that are unrelated.'
Does that mean, the rule engine is not suitable option to implement complex business logic [tightly coupled rules or chain of rules].
In my current project, we have chain of rules i.e. outcome of 1 rule decides the outcome of another rule and so on. The application has many internal variables to chain the rules. I thought rules engine might help to handle the complexity with the added advantage of declarative rules and dynamic business logic.
Discussion in this regard will be helpful ...
Some logic just isn't all that easy to get right even if you exactly know the order and nature of the tests you need to perform, and the actions that should result. Examples are Corporate Audits, Means testing for Assistance programs, Insurance regulations, etc.
Most Rules Engines today are beginning to include a Decision Table feature, which in all reality introduces some "limited strong coupling" (I don't know if that is really a term, but it is how I understand the effect in systems such as ILog, Drools, etc.). This is helpful because some tests are just related to other tests and decision tables are far better for structuring these tests than IF THEN ELSE structures.
Corticon (a proprietary Rules Engine) and DTRules (an open source Rules Engine) just toss the whole loosely coupled rules approach, and just build decision tables. The idea is that giving a nice structure for the construction of your decisions (which amount to decision trees underneath everything) is easier for many applications.
"Avoiding strong coupling" has nothing to do with "avoiding complexity".
What the documentation advocates is that you should not call one rule from another, instead, each rule should produce an outcome, and the outcome itself should trigger the next rule in chain. This way rules do not concern with what happens next, and instead they deal with facts (aha!). And if - instead of writing rules for facts - you focus on writing an ordinary flow of procedural logic, you do not really need the added complexity of a rules engine.
The difference is subtle, but not more subtle than rules like "don't put your business logic in view" or "don't put your database access code in your business logic".
In IBM ILOG Jrules there are many ways you can represent your rules.
In plain english like language , if else kind of syntax.
decision table - for a set of value
decision tree - multiple outcomes , branching out.
so you can decide on which way you can use the above three ways which fits to crack your complex rules into a more simpler form.
you can use rule flow orchestration with conditional flow to tackle " outcome of 1 rule will be the input of another rule "
I think it all depends on UI, not on actual logic that the rule(s) contain(s). Remember that most of today's engines are decision-table-mentality-based. And all that "Strong and Loose Coupling" is nothing more than buzz words used as an excuse for a bad UI or lack of it. Normal engine can handle execution of a rule of any complexity. Note that this is my personal opinion, lots of folks out there would completely disagree. So, please don't rush to downgrade my answer, I'm just trying to help :)
The typical notion is that the rule with complex logic would look really "messed up" or even impossible to implement in a decision table. Normally, guys try to combat that by dividing complex rules into smaller simple rules and stack them up into rule sets based on execution priorities.
There are new engines that have decision-table-less UIs by implementing parentheses instead of priorities. Parentheses also help with complexity.
When is a Business Rules Engine used?
What is the difference between Business Rules Engines and scripting/configuration/customization
A business rules engine, or a business rules management system, should be used when you are trying to implement a decision in your code. But not just any decision. A decision that:
Involves lots of rules
Has rules that change often
Has rules that are complex or interact in complex ways (think lots of nested IFs otherwise)
Has rules that only someone with domain knowledge can understand/verify
Is one that the business people REALLY want to be able to change without your help
Involves using predictive analytics / scores as part of the decision making
These are the kinds of decisions that pay off the use of a business rules management system. Don't start with the rules, start with the DECISIONS.
Business rules are verbose (so business people find them easier to read), declarative not procedural and atomic (so they can be stored, managed and reused like data in a database).
More on why to use business rules here in this piece on why I believe in business rules.
Business rules engines are typically used to provide customizable "IF some-condidtion THEN do-something" sorts of logic to applications. These types of business rules can trigger certain workflows to execute or bubble up event knowledge to higher level rules, causing them to be evaluated.
Using a rule engine also allows for easier separation of concerns by removing the business logic from your code. Rules engines today typically also offer a front-end where users can add new rules without having to modify scripts inside the application.
Rules engines implement algorithms such as Rete (speaking from Drools experience) that make the task of evaluating the rules quicker. The rule engine also provides forward chaining, backward chaining, hybrid chaining, etc. of rules. However, these could be implemented in a scripting language as well. You can achieve some of the same sorts of things with both approaches, but I believe that it depends on the complexity and number of rules as to which avenue you should choose.
Take a look at this link from the Jess project: http://www.jessrules.com/guidelines.shtml
It provides a step-by-step walk through of questions to ask yourself in order to determine if a rules engine meets your needs, or is overkill.
Rules engines can do forward and backward chaining as well as inferencing. Check out Fair Isaac Blaze, Drools or iLog for implementations.