Yoni Mazar wrote:
We are at the begining of a new clinical decision-support project.
We plan using drools (using Eclipse) in order to manage and execute our
As part of our research, we also evaluated JRules which has a feature that
is very important to us and we could not find in Drools.
I've reference the ilog manual on in/out parameters if anyone doesn't
know what they are:
I don't see the difference between a global and an IN_OUT parameter, and
I don't see the value of specifically saying which parameters are IN and
which are OUT. It doesn't seem that parameters are facts, they are not
asserted into the engine and propagated through the working memory -
atleaast I don't think they are, the manual doesn't say clearly enough,
it just says they can be referenced from any ruleset component, which
seems to be akin to how we do globals.
Unless we missed it out, we will probably try and add this
In JRules, one can define a ruleset (corresponds to a package) with
parameters. Each parameter has a datatype (a class), a direction
(in/out/inout), and an alias.
Then, within the rules, the user can refer to the parameter alias. For
example, a user can define a ruleset with the following parameters:
*class=LabResult, direction=in, alias=hemoglobin
*class=LabResult, direction=in, alias=creatinin
Then, within a rule, one can write:
when hemoglobin.value<10 and creatinin.value>34
We can do the same with globals, but what that actually means is you
have a rule that doesn't use any working memory objects, and you put the
constraints into one big eval - no pattern matching, so you are turning
the rule engine into a scripting engine rather than a production rule
If they are indeed facts that allow for pattern matching, then it seems
that they constraint by the variable name rather than by object type.
I've never liked this, again why not just use mvel directly as a
scripting engine. But I have thought of how this would be possible,
somethign I call Named Facts - where asserted facts can be given a
unique string identifier and a pattern can be told to not only
constraint against that object type, but also against that variable
name. However this is something that users can emulate themselves now,
by just putting an "identifier" field on their facts and constraining on
it in the pattern. If someone comes up with a clean way for supporting
named facts and provides a patch we will consider including it, but it's
not one of our priorities at the moment.
Now, the application retrieves the patient data accordingly
creatinine data separetly - even though they are of the same type) and sets
the ruleset parameters:
It is important that the definition of the aliases will be done outside of
the rule (and not by defining in-rule variables)
This approach simplifies the rules since some of the filtering is being
applied externally (not in the rule itself)
sounds like it simplifies it, by turning it into a scripting engine
where all facts are variables with identifiers.
Does someone has an idea how to bridge this gap using Drools?
Are there any workarounds that can be used in order to avoid changes in
Hopefully my main paragraph above shows you how to emulate this.
And here we can use your help:
We are new to Drools (and still have to dive into the big ocean of code that
The following features
1) defining parameters (in the package level...something like import)
2) adding in/out modifiers (can be used in LHS, RHS, or both)
3) allowing assignment of aliases to parameters
4) adding such functionality to the rule editor (auto-complete ,type safety)
Where should we start?
Do you have any ideas that can help start this process (e.g. relevant
We would appreciate any help regarding any of the items in the list above.
Any hints, suggestions, directions, referals and so on.
IF IN_OUT params are nothign more than globals and big fat evails, then
you have nothing to do.
If they are named facts, it won't be easy, but you could try the
1) update drools to support named facts, as described previously, this
will involve a special type of ObjectType I imagine, and you'll have to
change how it matches ObjectTypes so that it also has access to the
possible variable name.
2) figure out a sane syntax, that is not ambigious, to allow pattern
matching on named facts, and update our Antlr files to support this.
4) I don't konw if in/out parameters are useful for a stateful session,
or only stateless. Either way you will probably want to create some
Context object that contains these parameters and then you "insert" them
using smething like insertWithParameters( myParams ). With stateless
it'll execute and return results directly, with stateful you'll have to
figure out how that'll work with possible incremental inserts and
fireallrules being called separately.
4) Write lots of tests ot make sure it doesn't break anything
Thanks a lot.