Does easy-rules support a stateful rule-engine like Drools?
I would like to re-execute other rules if the fact is updated by one of the rule.
Please let me know if this is supported by easy-rules.
No, it's not stateful.
You could implement statefulness yourself by storing state in a static structure and run rules over the state by treating it as facts whenever state changes.
Related
By walking through a tree structure I have to check at each tree-level whether some nodes at that level fulfill certain criterials and then do some related action. Without easyrules, this can be implemented in a recursive call where nodes at each level during an iteration can be checked by if-else. How can this kind of behavior be implemented by using rule?
You can try to use an InferenceRulesEngine for that. You need to add facts for each level and register the required rules to trigger actions when a given level meets the criteria.
The inference engine will continuously select candidate rules and apply them until no more rules are applicable. So you need to make sure there is a certain fact that acts as a stop condition in your rules.
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.
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.
I need to design a application registry S/W component using C++. Basically, this needs to support addition and deletion of key/values. Dynamic updates need to be supported (for example, when a new application get installed).
Is there a design pattern which closely matches the given problem?
Though I have formulated a rough sketch of the APIs this component needs to support, it would be helpful to have a look at alternative (perhaps better) ways of design.
If there are some typical problems associated with registry design (may be some thread issues which I might have overlooked), I want to make sure I have circumvented those.
Is there a design pattern which closely matches the given problem?
You are probably looking at more than one: A proxy for the entire registry, iterator etc. comes to mind.
If there are some typical problems associated with registry design
You will probably need transactional semantics. Rollback too!
Do you need to save snapshots from time to time? Then you will need an archiving module.
Synchronization: Multiple writes to the registry need to be taken care of.
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.