Join the DZone community and get the full member experience.
Join For FreeRules are statements that define business procedures and policies. Normally, every business application contains many embedded business rules that determine business process flow and execution. When we program these rules with static languages like Java, there is no problem at all.
However, the problem is that some business rules change over time very frequently. It is very expensive to fix these changing parts since it requires new versions and software development cycles; develop, deploy on a test server, test, package, deploy on a production server etc. Here “Dynamic Programming” comes to our rescue. Our program doesn’t have to necessarily be written with a dynamic language. We can use this advantage in Java with Rule Engine mechanism.
Rule Engines don’t serve only the dynamic programming. They evaluate rules and extract some inferences by using some algorithms like RETE. This inference mechanism is hardly possible with many “if-else” statements in normal program code. Rule Engines have generally 4 types of rules;
- Constraint Rule: We may need to define restriction or limits for some entities. “A customer sales order amount must be lower than 100 if the plant is over capacity ”
- Validation Rule: Some validation rules may change over time. “Production order can’t be accepted if current day is Sunday”
- Action Rule: Some actions may be triggered. “Send a notification e-mail if a purchase order is over $1000 to boss”.
- Computation Rule: Some formula may be executed. “Discount is 20% if customer is Mr. Anderson”
We can use Rule Engines on the market but even we can write our own Rule Engine to benefit the dynamic programming in Java. By using Java compilers, classloaders, it is not so much hard. My favorite rule definition format is Java source code instead of some natural languages or XML. This can also reduce the overall development cost of your custom rule engine. By writing Java rule definitions, we can also use the IDE debugger features without learning a new syntax. If we develop our own Rule Engine, we may skip the inference engine part since we only want dynamic programming feature for now. Best place for plugging rule execution is database access layer. Rules should work invisibly behind the database objects. In some cases, some rules might be invoked from static program codes.
The benefits that we have when using Rule Engine are:
- Dynamic programming with hotswapping feature that provides fix&run easiness.
- Minimal cost of business rule changes that occurs many times.
- Accumulation of business rules in one place that may result re-usability and code repetition prevention.
- Dynamic validations that may change over time.
- Constraints can be defines for default values, assertion checks etc.
- In any time rule may be turned off/on.
Some of the features of Rule Engine may remind us database constraints and triggers. Using database may hinder portability and require DBA involvement. I think Rule Engine is better for business rule definitions. These database features may be used for other purposes.
The critical question we should ask ourselves is which part of business rules should be taken into Rule Engine from the programs. The answer is “frequently changing” rules. Some changing parts can be defined within parameter tables (processing options) but we can’t define computation or many if-else statements in these tables. But we should prefer parameter table if it is enough for the problem.
Links:
Topics:
Published at DZone with permission of Adam Brown. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments