1.2. Why use a Rule Engine - JBoss RULES 3.0.6 manual 英文版使用指南文档
Some questions often asked are
We will attempt to adderess these below.
Declarative Programming
Rule englines allow you to say "What to do" not "How to do it".
They key advantage of this point is that it can make it easy to express solutions to hard problems, and consequently have those solutions verified (rules are much easier to read then code).
Rule systems are capable of solving very very hard problems, yet providing a solution that is able to explain why a "decision" was made (not so easy with other types of AI systems like neural networks, or say, my brain - I have no idea why I scratched the side of the car).
Logic and Data Separation
Your data is in your domain objects, the logic is in the rules. This is fundamentally breaking the OO coupling of data and logic (this can be an advantage as well as a disadvantage depending on your point of view). The upshot is that the logic can be much easier to maintain as there are changes in the future, as the logic is all layed out in rules.
Speed and Scalability
The Rete algorithm, Leaps algorithm, and its descendents such as Drools' Reteoo (and Leaps), provide very efficient ways of matching rule patterns to your domain object data. These are especially efficient when you have datasets that do not change entirely (as the rule engine can remember past matches). These algorithms are battle proven.
Centralisation of Knowledge
By using rules, you are creating a repository of knowlegde (a knowledebase) which is executable. This means its a single point of truth, for business policy (for instance) - ideally rules are so readable, they also serve as the documentation.
Tool Integration
Tools such as eclipse (and in future, Web based UIs) provide ways to edit and manage rules and get immediate feedback, validation and content assistance. Auditing and debugging tools are also available.
Explanation facility
Rule systems effectively provide an "explanation facility" by being able to log the "decisions" made by the rule engine (and why the decisions were made).
Understandable rules (readable by domain experts)
By creating object models (and optionally Domain Specific Languages) that model your problem domain, rules can look very close to natural language. They lend themselves to logic that is understandable to domain experts who may be non technical (as all the program plumbing is in the usual code, hidden away).
The shortest answer to this is "when there is no satisfactory traditional programming approach to solve the problem.". Given that short answer, some more explanation is required. The reason why there is no "traditional" approach is possibly one of the following:
The problem is just too fiddly for traditional code.
The problem may not be complex, but you can't see a non fragile way of building it.
The problem is beyond any obvious algorithm based solution.
It is a complex problem to solve, there are no obvious traditional solutions or basically the problem isn't fully understood.
The logic changes often
The logic itself may be simple (but doesn't have to be) but the rules change just too often. In many organisations, software releases are few and far between, and rules can help provide the "agility" that is needed, and expected these days (in a reasonably safe way).
Domain experts (or business analysts) are readily available, but are non technical.
Non technical domain experts are often a wealth of knowledge about business rules. They typically are non technical, but can be very logical. Rules can allow them to express the logic in their own terms. Of course, they still have to think critically and be capable of logical thinking (many people in "soft" non technical positions are not, so be careful, as by codifying business knowledge in rules, you will often be exposing flaws in the way the business rules are at present).
Of course if rules are a new technology in your project teams experience, the overhead in getting going must be factored in. Its not a trivial technology, but we try to make it easier.
Typically in a modern OO application you would use a rule engine to contain key parts of your business logic (what that means of course depends on the application) - ESPECIALLY the REALLY MESSY parts !. This is an inversion of the OO concept of encapsulating all the logic inside your objects. This is not to say that you throw out OO practices, on the contrary in any real world application, business logic is just one part of the application. If you ever notice lots of "if" "else" "switch" and other messy logic in your code that just doesn't feel right (and you keep coming back to fix it - either because you got it wrong, or the logic/your understanding changes) - think about using rules. If you are faced with tough problems of which there are no algorithms or patterns for, consider rules.
Rules could be used embedded in your application, or perhaps as a service. Often rules work best as "stateful" component - hence they are often an integral part of an application. However, there have been successful cases of creating reusable rul eservices which are stateless.
In your organisation, it is important to think about the process you may want to/have to use for updating rules in systems that are in production (the options are many, but different organisations have different requirements - often they are out of the control of the application vendors/project teams).
To quote a Drools mailing list regular (Dave Hamu): "It seems to me that in the excitement of working with rules engines, that people forget that a rules engine is only one piece of a complex application or solution. Rules engines are not really intended to handle workflow or process executions nor are workflow engines or process management tools designed to do rules. Use the right tool for the job. Sure, a pair of pliers can be used as a hammering tool in a pinch, but that's not what it's designed for."
As rule engines are dynamic (dynamic in the sense that the rules can be stored and managed and updates as data), they are often looked at as a solution to the problem of deploying software (most IT departments seem to exist for the purpose of preventing software being rolled out). If this is the reason you wish to use a rule engine, be aware that rule engines work best when you are able to write declarative rules. As an alternative, you can consider data-driven designs (lookup tables), or script/process engines where the scripts are managed in a database, and able to be updated on the fly.
Hopefully the preceeding sections have explained when you may want to use a rule engine.
Alternatives are script-based engines that provide the dynamicness for "changes on the fly" (there are many solutions here).
Alternatively Process engines (also capable of workflow) such as jBPM allow you to graphically (or programmatically) describe steps in a process - those steps can also involve decision point which are in themselves a simple rule. Process engines and rules often can work nicely together, so its not an either-or proposition.
One key point to note with rule engines, is that some rule-engines are really scripting engines. The downside of scripting engines is that you are tightly coupling your application to the scripts (if they are rules, you are effectively calling rules directly) and this may cause more difficulty in future maintenance, as they tend to grow in complexity over time. The upside of scripting engines is they can be easier to implement at first, and you can get quick results (and conceptually simpler for imperative programmers !).
Many people have also implemented data-driven systems successfully in the past (where there are control tables that store meta-data that changes your applications behaviour) - these can work well when the control can remain very limited. However, they can quickly grow out of control if extended to much (such that only the original creators can change the applications behaviour), or, they cause the application to stagnate as they are too inflexible.
No doubt you have heard terms like "tight coupling" and "loose coupling" in systems design. Generally people assert that loose or "weak" coupling is preferable in design terms, due to the added flexibility. Similarly with rules, you can have "strongly coupled" and "weakly coupled" rules. Strongly coupled in this sense means that one rule "firing" will clearly result in another rule firing etc. in other words there is a clear (probably obvious) chain of logic. 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). This is not to say that strong or weak coupling is inherently bad, but its a point to keep in mind when considering a rule engine, and also in how you capture the rules. "Loosely" coupled rules should result in a system that allows rules to be changed, removed, added without requiring changes to other rules that are unrelated.