i,
Thanks for your great comments!
I'd like to clarify and amplify and think out loud a bit more.
On 2001.02.02 18:07:24 -0500 Mariusz Nowostawski wrote:
> Hi,
>
> > First of all, none of the implementations are transaction aware.
> Correct. There is no concept of transactions in a "normal" rule engine
> world. And, the problem is not trivial. As rolling back some
> "external" actions is easy to implement, proceeding with the rule
> inference and remembering all the involved steps requires creation of a
> local cached copy of all the changes (one changed single bean attribute,
> which triggered some rules firing, which changed other beans attrutes,
> which in term triggered other rules to fire, etc - simply, you have a
> chain reaction, with changes to rete internal state (facts) and with
> external actions changing the external data).
>
> > The RETE algorithm appears to involve caching all data relevant to rule
> > invocation, and responding only to changed information.
> Correct. Once run, inference engine evaluates all the rules, performes
> all necessary matching and action execution, and then triggers matching
> only on fact/rule changes.,
>
> > An EJB application presumably has more data than can be cached in
> memory,
> > transactions or no.
> Yes and no. It depends how you are performing pattern matching. Normally,
> RETE implementations create a (shadow) copy of all the facts as a rete
> network, and operates on such constructed representation. This is fast,
> but memory usage is really high. One could (possibly) extract and fetch
> data when needed, kind of lazy evaluation, which would be much slower,
> but
> one does not need to create a shadow copy of all the data. "Data" is
> probably more or less equivalent of "facts" in the rule engine
> terminology.
>
I am assuming that shadowing all the data, in all its differing states for
the different transactions, is too hard and memory consuming. As you point
out, lazy fetching may be slow and may require more finder methods to
retrieve just the necessary data. On the other hand... for CMP entities it
might be possible to construct the necessary finder methods/ queries from
the rule set. I haven't worked through enough examples yet to understand
how to be sure we have all the relevant data for a rule set.
> > [...]
> > 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.
> > [...]
> I think this direction is the most intuitive, and I am for trying it
> out. One question we still need to answer, is, whether session beans are
> the only persistent data (facts) the engine operates on. If yes, and if
> rule engine rules cannot create any intermediate, internal state, that
> would simplify a lot transaction management. It would mean, that we could
> have engine instance per transaction, and rollback/commit is fully based
> on J2EE transaction support. I need to think on that a little more.
This is what I was planning on. On the other hand, with JTA architecture
it ought to be possible to at least send other persistent data to a
different resource-- the message service comes to mind.
>
> > [...]
> > 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.
>
> Exactly. This is probably what we would try to achieve - a complete
> transparent for beans implementation, and declarative
> architecture. However, I suspect this will require building 'dynamic
> rete'
> matching module.
>
It seems to me that the hard part here may be figuring out how to
(automatically) load all the relevant facts. I think this boils down to
constructing a query (/finder method specification). This seems plausible
if the rule conditions can be mapped straightforwardly to SQL where
conditions. However one of the things that seems kind of nice about JEOPS
is that the conditions are arbitrary java boolean expressions. If we want
to have something like this we might need to specify which facts (might)
need to be considered using conditions that can be translated to SQL, and
thus can be converted to finder methods, and other conditions that are
applied only to facts already fetched.
> > 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.
>
> I need more thinking here. It may be better to 'declare' which actual
> beans should be used, instead of just declaring the types (the rule
> engine
> has to fetch the data from somewhere when needed, etc.)
>
I think I wasn't clear about what I was thinking. type = home interface,
identity = remote interface, attributes I'm not quite so sure about, either
specific entity methods or the CMP 2 (1.3??) container implemented get/set
methods.
> >[...]
> >
> > Another aspect of this whole area is forward/ backward chaining. My
> > understanding is that forward chaining is usually appropriate when you
> have
> >[...]
>
> Jess implements backward chaining by a special design pattern on the
> rules
> via forward chaining. As said, forward chaining is more suitable in some
> cases, and backward chaning in another. Forward chaning requires all the
> intermediate facts to be stored in the fact set - this, for some types of
> problems is unacceptable, as it leads to explosion of facts.
> Backward chaining disposes all intermediate states just after unification
> is completed. So, if you will need your intermediate states later, and
> you
> do not care about memory, and wants high performance, forward will be
> best, if you want a small memory usage, and you do many operations on
> very different domains, backward would be the way to go.
>
> I know Jess, but do not know much about JEOPS. Hower, due to a special
> properties of entity beans (can mapped to thousends of facts) I suspect
> one will need to make more dynamic implementation - implementation which
> fetches the facts when needed.
>
> > So, this are my first thoughts. Does this make sense? I could
> certainly
> > use some good references on this subject, especially some realistic
> > examples.
>
> Example: lets say we have two entity beans, one representing books
> written
> by some authors, with one of the properties specifying how many copies
> of this book got already sold, and second representing authors. Lets say
> one of the properties of an author is, whether author is popular or not
> (a
> boolean property). Lets say now, that we have a business rule, declared
> in
> our rule engine, that
> "if the latest book by the given author was sold in more than 50k copies,
> the author is popular"
>
> We have to think it over:
> *) books and authors may exceed the memory limit for statically created
> RETE network, what we do about it?
> *) how we should process "latest" (there are several ways, for example,
> one could split the rule above into several rules, some of which would
> look for latest book by particular author - however this is the internal
> state of the rule engine, which I think we should avoid; another would be
> to delegate the job of finding the latest book by a given author to the
> business method on Author bean for example, it would be the most
> efficient
> way, but then, not that much declarative anymore, etc)
Latest book could be finder method on book home--
findLatestByAuthor(Author). This, being essentially a query, could be
constructed at deployment time-- just as queries for other finder methods
are.
>
>
> > Is this the right place to discuss this? Or should I keep my mouth shut
> > till I have some kind of prototype?
>
> Don't know. We can discuss it here, or we may create a seperate
> discussion
> group for the rule engine API and implementation bits, and discuss here
> only the issues for jBoss integration.
>
> > All comments suggestions, and coworkers gratefully appreciated.
>
> Count me in. I will try to find some time to do some thinking and
> experimenting on this.
>
> best regards
> Mariusz
Thanks again,
David Jencks
>
>
>
>
