Hi, comments interspersed below
On 2001.04.25 09:06:08 -0400 Micheal J wrote:
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of
> David
> > Jencks
> > Sent: 25 April 2001 04:20
> > To: [EMAIL PROTECTED]
> > Subject: RE: [JBoss-dev] Rule Engine Improvements
> >
> >
> > Hi,
> >
> > Jeops _is_ a freely available RETE based rule engine. It is unusual in
> > that it operates on java objects rather than data tuples.
>
> Isn't JEOPS a kind of codegen/compiler that build an inference engine for
> a
> specified set of rules as opposed to an engine that can be given a set of
> rules in a text file for example?
Yes, JEOPS generates java code and compiles to java classes.
It starts with a source file in its own text format (original version) or
an xml document (my version). How is this different in principle from
rules in a text file used by an interpreted rule engine?
> - How does this affect the modification of rules in a system?
I'm not familiar with how interpreted rule engines deal with this. I think
with any RETE framework, you have to throw out everything you know and
start over. I also think in a transactional environment the facts need to
be reloaded inside each transaction. With JEOPS, the java code needs to be
regenerated and recompiled. In my integration, the generated rule engine
classes need to be reloaded. I don't think this will be terribly
difficult, but I haven't implemented it yet. See below.
> - Will anything break when rules change and the engine is regenerated
> and,
> how can this be automated for use by non-programmers?
I thnk the situation is more complicated than this. Many people seem to
talk about how great it is to be able to change rules at the drop of a hat,
etc, while everything is running,.... Is this really plausible from a
business viewpoint? It seems likely to me that a business would want to be
able to specify exactly which transactions get treated under which set of
rules. I also think any business would have a test system in which they
would try to find out if the proposed new rules did what they expected. So
for a real production system I think some kind of changeover scheduler is
needed... " at 12:00 am ruleset xxx change from version 2.1.3.4 to 2.1.3.5"
After it is implemented, redeploy would be kind of automatic-- mostly I
think it needs a scheduler.
> - How does such an architecture affect the resource requirements for the
> [all the] inference engine instances? By this I mean that since we can
> expect a number of rulesets that deal with "areas" of functionality
> (perhaps
> on a high-level usecase basis), how does the fact that JEOPS creates
> essentially independent, hardcoded, unreusable engine instances affect
> the
> resources used compared to say JESS where one could keep a pool of
> instances
> and (re)load different rulesets from a text file as needed?
The classes generated by JEOPS implement only the rules: they extend base
classes that have the RETE engine functionality. Essentially they are
compiled versions of what an interpreter is going to have to do.
Right now my implementation does not reuse instances of these classes
between transactions, but it is pretty easy to pool and reuse them.
However as noted above I think all the facts need to be reloaded in each
transaction. If there is a way around this that quarantees transactional
semamtics I would like to know about it.
>
> You are saying that the generated inference engine(s) are based on the
> Rete
> algorithm?
Yes. As noted above, there are base classes implementing the RETE
algorithm, and the generated classes contain only compiled versions of the
rules themselves. It could probably be made slightly more efficient, I
think it was perhaps developed with jdk1.1x as it uses Vectors instead of
ArrayLists, but it does work.
Another issue that you perhaps didn't directly ask about is the rule
language. The community process for rule engines mentions an effort to
develop a standard xml based rule language, but I have been able to find
out nothing about it. JEOPS uses what is essentially java code snippets,
which has the advantages of being unambiguous and general. Any rule
language is going to have to be semantically translatable to this if is to
be executed in java (well thats a pretty big claim, argue if you
like)...the question is what rule language do we start from. I plan to
address this I have some useful examples for the rule engine and the
desired language becomes clearer.
>
> > I would really like some information about what the community
> > process group
> > is thinking of in terms of rule engine activation. I like what I came
> up
> > with, which is essentially before and after triggers on ejb method
> > invocations. If they have a really different idea I'd like to know
> about
> > it.
>
> Anyone have any idea what's cooking in the community process?
>
> Micheal
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
