CODEWITHSUNDEEP
javadroolsjava-ee-6rule-engineredhat-brms
Spear A1
Spear A1

Reputation: 585

Why rules engine instead of easily comprehensible one line property?

I am a newbie with the rules engine, so bear with me if this question is very basic. All the tutorials for rules engines have been saying that you can move your business logic outside your code and get it updated by BAs/ end users instead of putting it inside Java code.

I have the following questions

  1. But why can't we write our code to read values from property files and do the same thing?

  2. Also, the rules files seem to have a syntax which is not simply one-liners, compared to .properties files.

  3. Does putting these rules in Rule engine make the code/app work without requiring an app server restart?

    3a. If it does NOT, then how can we achieve it?

Upvotes: 2

Views: 3045

Answers (5)

john k
john k

Reputation: 6615

Rules engines are just algorithms for organizing many rules. See the Rete Algorithm.

Basically, it all comes down to complexity. If you have a few simple rules, of course you can use a .properties file. But imagine if some of your rules are 'chained' - one rule affects some other property, which triggers some other rule, which changes another property... you'd have to scan every rule, every change. For thousands of rules, it would take forever. Hence a 'rules engine'.

There are many articles on why you should or shouldn't use a rule engine. Here is one good example. https://martinfowler.com/bliki/RulesEngine.html

Upvotes: 1

darkKnight
darkKnight

Reputation: 46

  1. If there's a change in logic, you'll change the properties file and deploy the whole project again. Whereas, if you maintain it using BRMS, you can change & test individually on the BRMS only without needing to deploy the whole project again. Once the testing is done and you finally want to deploy the new rule in place, then also, no need to deploy the whole project in production. If you've exposed your rule as API using KIE Server, redeploying just the KIE server would do.
  2. One can write decision tables in such a way that all the logic is contained in the top rows. Then the developer can lock & hide those top rows and then give it to BA. Now BA doesn't see any logic but knows how to maintain the file. Also, not all logics should be written as decision tables.
  3. As I mentioned above, one can deploy each and every rule as a separate rest API and hence is deployable independent of the rest.

In the end, I'd say the main reason we use Redhat BRMS is, as they mention in their documentation,:

  1. Agility: No need to involve developers for a change request. BA's themselves can change the logic.
  2. Visibility: What you see (in the excel) is what you get.
  3. Consistency: Rules are evaluated the same way every time.

Upvotes: 1

Spear A1
Spear A1

Reputation: 585

Had been doing some reading the last few days and I think (it is IMHO), the capacity for allowing business rules to be updated using simple spreadsheets, gives Rules Engines the edge over property files. I can make property files as highly configurable as possible using multiple properties and instructions for modifying rules as comments under each property.

But in a scenario where the business user is able to directly configure the application to apply values based on a "decision table" in a spreadsheet, then that solution will be more desirable.

If any other (budding) developer looking for justification on the for the need of Rule Engines is convinced with this answer, please leave a thumbs up!

Upvotes: 1

mjs
mjs

Reputation: 149

  1. Rules engine comes into picture when business users of company want to set certain rules and drive application based on execution results / outcome decisions of rules set. One of examples of such company could be a Law firm or Insurance company where lawyers set rules to drive the quotes calculation for a insurance & rules are subjected to change over period of time. Property file is developer area where business user may not be proficient to make changes. Having separate rules engine tracks the rules and make a business user and a developer work together automating the business seamlessly which could be difficult with properties file.
  2. Rule files syntax is way to convert business rules (verbal) to coding instructions which are executable. Thats where the syntax comes into picture. That way rules engine provide data abstraction to business entities and their relationships.
  3. Integration with rules engine may be done with some broker or a web service or whatever, based on that, server app need rules client jars to make call against. So its matter of deployment and how server picks up changes / hot deploys if rules client jar is updated.

Upvotes: 0

Steve11235
Steve11235

Reputation: 2923

Rules engines are not always the answer. However, they provide, in theory, the advantage that the engine can perform complex processing on a simple rule expression and return a result. Other advantages are visibility to the rules and less code.

Answers to your questions.

  1. You can. In simple cases,using property files makes sense.

  2. Rules need to sufficiently complex to cover the business issues they validate. A good rules engine uses a syntax that is readable, even if it is complicated.

  3. In theory, the rules server could run independently of the app server. In large companies, that is normal. The rules server could allow updates without a restart, or it could be restarted (rippled, if there are multiple instances,) without affecting the app server.

Upvotes: 0

Related Questions