We're really doing a very good experience in handling rules engines . Through this project we had to face both the implementation of the rules and the implementation of a system that would allow to generate product configurators easier to use.
A rules engine is " technically " a nice toy . Seeing it run on thousands of conditions in a flash knock impresses IT addicted . And playing writing esoteric rules is a funny game .
In addition , it allows to approach old problems in entirely new ways and , indeed , very effective .
Let's say , however, that like all the " libraries " , deploy this approach at production level , make it accessible to an audience of humans not so enamored of development requires some features that the rules engine in itself does not provide .
And if the audience of users of the " result " of the rules engine covers extends , well, then we are part of a real production system.
WHAT TO DO TO PUT IN PRODUCTION SYSTEM AS Drools ?
The rules engine used ( Drools ) is a library that can connect to the system of rules defined with Guvnor , generate a Working Memory, take in a series of objects and "shoot " all the rules according to objects inserted .
The result is the creation or removal or modification of objects.
Objects must then be re-read and interpreted out from the working memory .
The main problems that we have identified and tried to overcome are the following
PROBLEM 1 : MANAGEMENT OF THE COMPLEXITY OF MANY "MODELS "
In a production environment, the complexity of the models can change over time and in particular the number of models can grow as you solve problems.
So in a production environment it is very important to be able to define "dependencies" between the models. Be able to reuse existing models in more complex models without going crazy with cataloging rules and definitions of abstruse priority.
The context that we experienced for our customer is so that models are defined to select the best product for the customer scanning through many different models and then to configure individual products .
PROBLEM 2: HARD TO LET THIRD PART SYSTEMS USE DROOLS "AS IS".
Talking with Drools, respecting the constraints of the system is not so trivial. Un hypothetical third system needs to call the model must be able to do it easily.
I'd say a nice REST layer is the answer.
PROBLEM 3: COMPLEX AND LIMITED DEBUG
Well, debugging provided by Guvnor is not the most immediate of the earth. It is based on creating TEST where you write by hand all object instances, you run the "Test Scenario" and you see the rules fired.
If the combinations of objects inserted are many, work is very huge.
PROBLEM 4: LACK OF SESSIONS PERSISTENCE
If a "remote" user gets an error during the use of a Drools session , you must replicate all the entry conditions. Unless there is some clever system that has saved the session and can recall it easily
PROBLEM 5: DIFFERENT RESULTS ON BOUNDARY CONDITIONS CHANGE
In a production environment, the rules are not black boxes detached from the rest of the systems. On the contrary they should change over time, perhaps based on external conditions such as data in a database. And this must be done without having to rewrite the rules.
WHAT HAVE WE DONE TO OVERCOME THE LIMITS?
We have developed an entire system software that can "embed" Drools and filter the use to simplify it.
FIRST PART: A complete SYSTEM for CONFIGURATION MODELS
A central system to manage a repository of models. Every repository contains a reference to a package in Guvnor and defines testing environments or production.