|
List Info
Thread: RE: Rules Engine always running
|
|
| RE: Rules Engine always running |
 
United States |
2007-03-28 10:12:04 |
|
|
I assume rules are dynamically added to the Rulebase and
that there is not a static set of rules associated with each application
release?
I believe new rules can be dynamically added to the
existing Rulebase - whether existing WM's inherit the new rules I don't know.
Agenda Groups could provide the control of which groups of rules
fire.
Also, if you retain FactHandles to all asserted Facts
depending upon the decision made by the component the legacy Facts can be
retracted before the new rule is activated.
I assume you'll also have some "Rule life-cycle" control in
place? Either removing rules from a Rulebase (I believe to be possible) or
destroying redundant WM's (as per your proposal).
Sorry, this doesn't add much more value ;- although
input from more experienced users is welcomed.
Cheers,
Mike
Mike,
Thanks for you rresponse, however I'm not sure based
on what we are wanting to do that we should use a single working memory. The
proposed approach is:
a rule has been added to the rule base, then a Fact
(object) comes along and we instantiate a working memory and fire all rules
relative to this working memory. The outcome from Drools is evaluated by
another sw component, and it is decided to try a different rule with a given
Fact.
So, a new rule, rule #2, comes along with slightly
different specifics on what it is supposed to match, so it is added to the
rule base. Then, Fact #2 comes down the pipeline. A new working
memory #2 is instantiated against the existing rulebase, Fact #2 is
asserted, and fireAllRules() called against the working memory
#2.
The desired behavior is that only rule #2 is actually
kicked into action (against Fact #2), since the first rule and fact is done
with. We don't want the previous rules/facts in the rule base operating any
longer.
Maybe I just don't know enough about the proper
application of rules when solving particular problems to ask the right
questions -- my task is to expose JBoss rules as a service so
I'm trying to understand a bit about ;it's
operation.
Thanks,
aj
--------------------------------------------
Alan R Jones
Boeing S&IS Mission
Systems
Denver
Engineering Center (BDEC)
303.307.3415
Hi Alan,
A working memory is in essence always availablerunning
whilst there is a reference to it; other than the "main" thread (on which your
public static void main executes) you don't need to use other threads (but
this obviously depends upon what exactly you're trying to achieve). The
Rulebase can contain all of your production rules (in fact this is probably
the recommended approach as, assuming some rules share ;a common
pattern, the resulting RETE network will be optimised); and you can feed
incoming objects (Facts in JBoss Rules terms) into one working memory created
from the one Rulebase. As objects are asserted patterns (LHS) defining the
rules are matched and, once fully matched, rules are activated for execution
(RHS). Unfortunately I don't have any experience of JBoss Rules in a
multi-threaded environment.
For
example /FONT>
public static void main(String
args[]) {
Rulebase rb =
loadRuleBase();
WorkingMemory wm
= rb.newWorkingMemory();
while (!exit())
{
Collection c =
getObjectsFromWherever();
assertObjectsIntoWorkingMemory(c,
wm);
wm.fireAllRules();
;
try {
;
Thread.sleep(1000);
;
}
;
catch(InterruptedException ie)
{
}
}
}
With kind regards,
Mike
Kind of new to JBoss Rules...I'm trying to fiigure
out from what i have read so far if the following scenario is
possible:
1. Start up an instance of a working memory (say,
with dummy rule?) and keep it running, feeding it data objects to operate on
from time to time.
2. As needed, kick off as many instance of working
memory within the single rule base (in a separate thread) and keep them
going as in step 1
The idea is to keep the rules engine running
constantly, but kick off separate working-memory threads for the injection
of various incoming rule sets and the objects those rule sets work on
as needed. Can anyone provide some insight to this? Pointers to examples,
perhaps?
Alan J. ;
|
| RE: Rules Engine always running |
United States |
2007-03-28 11:15:57 |
|
|
Yes, some of these things are being considered. Thanks for
your input , it has been helpful!
aj
I assume rules are dynamically added to the Rulebase and
that there is not a static set of rules associated with each application
release?
I believe new rules can be dynamically added to the
existing Rulebase - whether existing WM's inherit the new rules I don't know.
Agenda Groups could provide the control of which groups of rules
fire.
Also, if you retain FactHandles to all asserted Facts
depending upon the decision made by the component the legacy Facts can be
retracted before the new rule is activated.
I assume you'll also have some "Rule life-cycle" control in
place? Either removing rules from a Rulebase (I believe to be possible) or
destroying redundant WM's (as per your proposal).
Sorry, this doesn't add much more value ;- although
input from more experienced users is welcomed.
Cheers,
Mike
Mike,
Thanks for you rresponse, however I'm not sure based
on what we are wanting to do that we should use a single working memory. The
proposed approach is:
a rule has been added to the rule base, then a Fact
(object) comes along and we instantiate a working memory and fire all rules
relative to this working memory. The outcome from Drools is evaluated by
another sw component, and it is decided to try a different rule with a given
Fact.
So, a new rule, rule #2, comes along with slightly
different specifics on what it is supposed to match, so it is added to the
rule base. Then, Fact #2 comes down the pipeline. A new working
memory #2 is instantiated against the existing rulebase, Fact #2 is
asserted, and fireAllRules() called against the working memory
#2.
The desired behavior is that only rule #2 is actually
kicked into action (against Fact #2), since the first rule and fact is done
with. We don't want the previous rules/facts in the rule base operating any
longer.
Maybe I just don't know enough about the proper
application of rules when solving particular problems to ask the right
questions -- my task is to expose JBoss rules as a service so
I'm trying to understand a bit about ;it's
operation.
Thanks,
aj
--------------------------------------------
Alan R Jones
Boeing S&IS Mission
Systems
Denver
Engineering Center (BDEC)
303.307.3415
Hi Alan,
A working memory is in essence always availablerunning
whilst there is a reference to it; other than the "main" thread (on which your
public static void main executes) you don't need to use other threads (but
this obviously depends upon what exactly you're trying to achieve). The
Rulebase can contain all of your production rules (in fact this is probably
the recommended approach as, assuming some rules share ;a common
pattern, the resulting RETE network will be optimised); and you can feed
incoming objects (Facts in JBoss Rules terms) into one working memory created
from the one Rulebase. As objects are asserted patterns (LHS) defining the
rules are matched and, once fully matched, rules are activated for execution
(RHS). Unfortunately I don't have any experience of JBoss Rules in a
multi-threaded environment.
For
example/FONT>
public static void main(String
args[]) {
Rulebase rb =
loadRuleBase();
WorkingMemory wm
= rb.newWorkingMemory();
while (!exit())
{
Collection c =
getObjectsFromWherever();
assertObjectsIntoWorkingMemory(c,
wm);
wm.fireAllRules();
;
try {
;
Thread.sleep(1000);
;
}
;
catch(InterruptedException ie)
{
}
}
}
With kind regards,
Mike
Kind of new to JBoss Rules...I'm trying to fiigure
out from what i have read so far if the following scenario is
possible:
1. Start up an instance of a working memory (say,
with dummy rule?) and keep it running, feeding it data objects to operate on
from time to time.
2. As needed, kick off as many instance of working
memory within the single rule base (in a separate thread) and keep them
going as in step 1
The idea is to keep the rules engine running
constantly, but kick off separate working-memory threads for the injection
of various incoming rule sets and the objects those rule sets work on
as needed. Can anyone provide some insight to this? Pointers to examples,
perhaps?
Alan J. ;
|
[1-2]
|
|
lists.jbos