The fundamental problem is, of course, that if there's data in a database, somehow, the rule engine has to know about it. There are a couple of ways that people have tackled this.
First, Jess has PropertyChangeEvent support built-in. If the database is the persistence layer for EJBs, say, and the rule engine is reasoning about the EJBs, then if you make the EJBs send PropertyChangeEvents, everything is kept in sync automatically. Even without the events, you can manually tell Jess to update a single object.
Now, of course, this doesn't deal with the question of how the objects get into the rule engine in the first place. Jess is primarily a forward-chaining engine, but it's got some backward chaining machinery in it which can be used to good effect. One of the "User Contributions" on the Jess web site is the "Fact Storage Provider Framework (FSPF), " which can be used as is, or used as an example. The basic idea here is that you write forward-chaining rules about arbitrary data, and Jess's backward-chaining machinery is told to try to find the data these rules want to match. The FSPF is triggered by this and makes
JDBC calls to fetch the objects you need to reason about. These objects can be flushed when you're done with them, or the change-event mechanism could be used to keep them up to date. So this is basically the Mandarax approach you described, except in a forward-chaining engine.
A third, more radical alternative is to do away with the RDBMS altogether, and use a OODBMS or something like Prevayler to store the objects, which then basically live in Jess's working memory. This is more practical than you'd imagine, especially on architectures where the
Java heap can be a full 4GB.
There's no magic bullet; none of this stuff is completely transparent. But people have done a good job of successfully addressing the problem in many different ways using Jess. The Jess user community is a smart bunch of people.
