How does the use of a rules engine impact the design, implementation, and performance of an application?

Question

I'm interested in the ability of rules engines to:

• launch and iterate over business driven logic
• have "business users" perform the actual modification of those rules rather than developers
• comprehend the business rules in general

Also, does using a rules engine impact the quality of an application?

Does the use of a rules engine change if you were deploying to a 1-machine setup vs. your architecture vs. a multi-tier cloud-based distributed architecture using thousands of machines? How would it be different?

Answer 1

The decision as to whether to expose an interface for non-technical personnel to modify business rules largely depends on several factors, including the goals of the project, cost of the project, lifetime of the project, and the ratio of knowns to unknowns in the project.

For instance, if I believed that no one would use the rules interface, then I would probably opt out of implementing it. However, if I had reason to believe that changes would be frequent and that different end-users would expect different rules to be in place, then I would consider working on building such functionality.

I chose to do this on a project, and it took years before the feature was ever widely used. I suspected that we would eventually have end-users who would want to customize things themselves, so we implemented this functionality in pieces.

It started out as something that only certain people, like developers or admins could use. The interface was clunky, but usable if you knew what you were doing. But by the time the product was nearing completion, the rules engine backend logic came in handy, and our design team gave it a beautiful, customer-facing user interface.

If I were to do it different, I might choose a different database architecture just because the learning curve is high. But in short, building it early on led to many customer facing features later on without the headaches of having to go back in the code and refactor it to include all of the dynamic rules.

Answer 2

If I were to do this I would create a Domain Specific Language to express the rules, and maybe give the biz types a UI to modify it if requested. Then use a functional language (like Haskell, Lisp or Erlang) to evaluate the rules.

If massive parallelism was required I would go with Erlang which does concurrency very well. Using Erlang would scale well from 1 node to 100 or more.

If you think of the rules as an Algebra that will be applied to a dataset it becomes much easier to logic out what is need in your code, and to prove to yourself (or your managers) that it is correct. This is one of those places where a functional language will work in your favor.

Answer 3

I have had a less than perfect experience connecting from Java code to an Oracle rules engine. Some of this may be due to inexperience on the part of rules authors, but this is what I faced.

• We implemented our rules engine as a stateless device. The caller had to gather all the parameters and pass them to the engine for evaluation. This meant that if the rule needed another data field, all clients needed to be updated, This negated the touted advantage of being able to update the rules independently from their consumers.
• The engine published a SOAP WSDL, but it was auto-generated from the rule set. Minor changes to the rules would break the contract with the consumers.
• The engine was good at evaluating the rules, but terrible at telling us why the evaluation failed. It was difficult to feed informative error messages back to the user.
• The WSDL was not fit for general consumption. The simplest rule set had a 14 page WSDL, that exposed the internals of the rules base. We had to put a SOA translation layer in front to present a business-friendly facade. So instead of calling a 100% reliable local library, there were two extra servers in the loop. That does not add to reliability in the least. Plus any change to the rule signature involved three disparate teams updating code. Not my definition of agile!
• Any time the rule set needed additions, the WSDL would have to be updated, which meant clients no longer understood it. This lead to adding new SOAP endpoints for v2, v3.. which had knock-on effects of needing firewall rules to be updated.
• The rules were expressed in "structured english" which was readily understandable for simple rules, but near to opaque for complex rules.
• We could never find contractors that knew the rules authoring language.
• The rules language did not implement arrays, recursion or object orientation. In one case, the only way to implement a rule was via a callout to an Excel spreadsheet, where the rule was implemented in VB. Why bother?

I don't think the choice of using a rules engine (or not) is clear-cut. I suggest you prototype any engine you intend to use, then make an informed decision. They are certainly not a silver bullet...

Answer 4

I wrote an application based on WF (windows workflow foundation). My boss (a DBA) was convinced that WF could perform multi-threading without the need to plan for concurrency. Memory was divided thoroughly, but there were so many problems I can't explain it in just a few paragraphs and it's only slightly related to your question...so I continue.

Ability to iterate BL:
WF does this well.
allow nontechies to "build an app":
WF does this well IF the architecture works AND nontechies understand technical limitations... Ours did not.
Ability to comprehend business rules in general:
There are some add-ins that can do some basic stuff much like sharepoint can automate workflows. I did not get into these items.
Quality of software realeases:
Mediocre. WF did not perform well for our purposes, but the system was badly designed and my hands were tied.
Speed of applications:
Slow. The learning curve is pretty steep for developers and end users alike. The way WF seperated memory (app-domains If I recall) made cross thread communication, mutexes and other threading concepts kludgy or simply not work whatsoever.

Ultimately, I wrote a prototype to prove WF fails in the way it was implemented. I replaced it with common multi-threading. Performance and code readability went up. Take this with a grain of salt as this was my first professional WF application.

Nontechs can come to believe practically anything is possible with no programmer required, a potentially large negative to the whole "dummy down" of BL; sociological problems related to this killed the project.

If I could go back and do it my way: use traditional threading and the BL molding achieved via Decorator Pattern. I wrote a proof of concept that used these technologies and it worked well. AND the BL mapping should be wrapped in a SIMPLE UI.
Update
I found an old post I wrote when working through concurrency problems. The code shows how printing "hello world" in parallel workflows doesn't work without an understanding of what goes on underneath the covers (which defeats the whole purpose of the WF abstraction). The MSDN moderator explains a high level overview of how parallel activities are really sequential. He concludes with basically "you need to read the whole manual" to do something this basic. http://social.msdn.microsoft.com/Forums/en/windowsworkflowfoundation/thread/8a1fa165-ad5c-4cd2-b489-7ea5fc31fed8

Good luck.