Thomas,
I'm curious to know about the system you developed. How complex it is and the
approximate performance of that system?
Approximately how many facts/rules are there? What type of computing boxes are
you using? How many rules are applied against how many facts at any given
time? How often do the facts change? What kind of performance figures can you
describe?
I only ask because your system is a real, working one and it might help me
understand whether we should use an expert system for our needs.
-Chuck.
[EMAIL PROTECTED] on 06/05/2000 02:51:59 PM
Please respond to [EMAIL PROTECTED]
To: Chuck V. Sterbis/DDI@Timeweb
cc: [EMAIL PROTECTED]
Subject: Re: JESS: Questions on when to use Rule Based System
Hi!
>So I'd like to use an RBS, but can it handle it? I can't imagine
>keeping all that data in memory. So how efficient would the
>engine be at reading/representing this information in an SQL
>table? I've seen Thomas Barkenow's RDBS extension. It basically
>is wrapper for creating individual SELECT statements for each rule
>to find it's facts. But I can't imagine that is very efficient.
>It gets the job done, but it would be murder for a large system.
Note that any number of records can be retrieved using that extension. You
don't need to fetch records individually. The number of facts actually
created by the framework depends on the condition implicitly stated by the
(need-schema-table) goal fact asserted during backward chaining. You could
thus define some intelligent prefetch strategies. Note that, as long as a
fact exists in the Rete network, it won't be read again from the database,
i.e., backward chaining won't occur.
The classes you've seen are a simplified excerpt from a considerably more
powerful and feature-rich framework that I've developed for system
integration and process control purposes. One important part is an observer
component that monitors database modifications (inserts, updates, deletes)
in order to infer state changes of business objects persistently stored in
that database. The first part of the problem, i.e., detecting insertions,
updates, and deletes, is done by automatically generated database triggers
that create change notifications (XML strings, to be specific). These
notifications (instances of UML SignalEvents) are automatically converted
to Jess "event" facts. Thus, you wouldn't need to pull each fact from the
database. They could also be pushed to you, if that simplifies matters.
Only "state" facts would be read from the database, e.g., in order to check
conditions of Jess ECA rules. This mode of operation can also be mixed with
a prefetch strategy.
>I can see a case where it would use two SELECT statements instead of
>using a JOIN.
Do you think that's good or bad? I've had situations where performing joins
externally was a lot faster than letting the RDBMS do it.
There doesn't need to be a one-to-one mapping from facts to tables (base
relations). You can also define database views and corresponding
deftemplates/facts.
Greetings
Thomas
________________________________
Dipl.-Inform. Thomas Barnekow
Fraunhofer IAO, Competence Center Software Technology
mail: Nobelstra
�e 12, D-70569 Stuttgart,
Germany
phone: +49 (0) 711 / 970 - 2346
fax: +49 (0) 711 / 970 - 2300
mobile: +49 (0) 172 / 7126018
email: [EMAIL PROTECTED]
web: http://www.swt.iao.fhg.de
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
