I've taken a look at the sources Oleg found (Re: Re[2]: [jBoss-Dev] Rules
engine taker?, 2001.02.01 10:38:01 -0500) and thought a bit. I am not yet
an expert on any of this.
First of all, none of the implementations are transaction aware.
The RETE algorithm appears to involve caching all data relevant to rule
invocation, and responding only to changed information.
An EJB application presumably has more data than can be cached in memory,
transactions or no.
Therefore I think is necessary to supply the rule engine with all relevant
data separately for each transaction. This will presumably have acceptable
performance when the relevant data set is rather small. I am assuming at
this point that the rule engine will obtain data through home/remote EJB
references, and that the actions taken on rule matching will be calling EJB
home or remote methods, or rolling back the transaction.
How is the rule engine to be activated? The idea seems to be that the rule
engine responds to changes in the fact set. The most obvious such changes
to me are changes to entity beans. I think perhaps that we could also
regard someone calling a session bean method as a change in the fact set.
Session bean method calls can be, as I understand the interceptor
architecture, be intercepted by an interceptor; similarly create and remove
calls on entities can be intercepted. Modifications to entities through
remote interface methods can be detected in the same way, although I think
you would have to specify manually which are the mutators rather than
accessors. Another possibility for detecting changes to entities in the
CMP 2.0 (( or is it 1.3) model is to have the container generated
setAttribute methods notify the rule engine.
This model for rule engine connectivity does not involve the code in
session or entity EJBs knowing anything about the rule engine. The
connection is entirely declarative. If most of the application business
flow/rule logic is implemented in the rule engine, this could possibly
result in session beans all of whose method bodies were empty -- all action
taken by the rule engine as a result of the method call, dispatched by the
interceptors.
Setting up the connection between the rule engine and the EJBs would
involve specifying which home/ remote methods or CMP set accessor methods
would notify the rule engine, and what the content (type identity and
attributes) sent to the rule engine is to be. Also, assert actions need to
be mapped to creates, retract to remove, and modify to some appropriate EJB
method.
So, here's how I see it working:
1. Someone calls say a session remote method.
2. An interceptor notifies the rule engine of the transaction context and
the 'fact' that the method was called ( presumably with the arguments )
3. The rule engine asks for entity EJB remote references that it needs to
get the other facts for evaluating its rules, using the same transaction
context.
4. The rule engine comes to some conclusions about what actions to take,
and calls some EJB home or remote methods, again within the supplied
transaction context.
5. Control returns to the session bean.
6. State information is preserved in the rule engine until transaction
commits or rolls back. Thus further changes to facts relevant to this
transaction will use the already loaded RETE network. When transaction
ends, cached data in the RETE network is discarded. (???? I'm not at all
sure about this one, perhaps the 'state' is only in the EJBs and just
home/remote references kept. Maybe not even that)
Another aspect of this whole area is forward/ backward chaining. My
understanding is that forward chaining is usually appropriate when you have
rules with actions: changes in the facts are tested against the rules and
as a conclusion some actions are taken. The work here is to find the
needed actions. Backward chaining (e.g. Prolog) starts with a goal-- i.e.
a question to be answered-- what are all the things of this type-- and uses
more or less (less, unification is more complicated than this) recursive
query execution to find the answer. I don't see at this time how backward
chaining is useful for specifying actions as a result of fact changes. It
does seem like it might be useful in fancy finder methods.
At this point, i.e. before I know very much, it looks to me like JEOPS and
JESS are the possibilities technically. It is not clear to me that JESS is
available for free to individuals even for research purposes, despite their
download button. I will investigate. I think that the compilation needed
for JEOPS will be possible to automate during deployment: this is certainly
not ideal, but may be OK for at least experiments.
So, this are my first thoughts. Does this make sense? I could certainly
use some good references on this subject, especially some realistic
examples.
Is this the right place to discuss this? Or should I keep my mouth shut
till I have some kind of prototype?
All comments suggestions, and coworkers gratefully appreciated.
Thanks,
David Jencks
