[jboss-svn-commits] JBL Code SVN: r5907 - in labs/jbossrules/trunk/documentation/manual/en: Chapter-Install Chapter-Rule_Engine
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Wed Aug 16 07:38:12 EDT 2006
Author: michael.neale at jboss.com
Date: 2006-08-16 07:38:08 -0400 (Wed, 16 Aug 2006)
New Revision: 5907
Modified:
labs/jbossrules/trunk/documentation/manual/en/Chapter-Install/Section-Install.xml
labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-The_Drools_Rule_Engine.xml
Log:
added details on Initial Fact, plus corrected some typos.
Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Install/Section-Install.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Install/Section-Install.xml 2006-08-16 11:08:37 UTC (rev 5906)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Install/Section-Install.xml 2006-08-16 11:38:08 UTC (rev 5907)
@@ -82,6 +82,10 @@
come across classpath issues with "JDT", then you can switch to the janino
compiler. Set the system property "drools.compiler": For example:
-Ddrools.compiler=JANINO.</para>
+
+ <para>For up to date info on dependencies in a release, consult the
+ README_DEPENDENCIES.txt file, which can be found in the lib directory of
+ the download bundle, or in the root of the project directory.</para>
</section>
<section>
Modified: labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-The_Drools_Rule_Engine.xml
===================================================================
--- labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-The_Drools_Rule_Engine.xml 2006-08-16 11:08:37 UTC (rev 5906)
+++ labs/jbossrules/trunk/documentation/manual/en/Chapter-Rule_Engine/Section-The_Drools_Rule_Engine.xml 2006-08-16 11:38:08 UTC (rev 5907)
@@ -301,7 +301,7 @@
facts. WorkingMemory.assertObject(yourObject) for example. When you
assert a fact, it is examined for matches against the rules etc. This
means ALL of the work is done during assertion; however, no rules are
- executedl you call "fireAllRules()" after you have finished asserting
+ executed you call "fireAllRules()" after you have finished asserting
your facts. This is a common misunderstanding by people who think the
work happens when you call "fireAllRules()".</para>
@@ -453,6 +453,17 @@
</section>
<section>
+ <title>Initial Fact</title>
+ <para>
+ To support conditional elements like "not" (which will be covered later on), there is a need to "seed" the engine with something
+ known as the "Initial Fact". This fact is a special fact that is not intended to be seen by the user.
+
+ On the first working memory action (assert, fireAllRules) on a fresh working memory, the Initial Fact will be propagated through the RETE network. This allows rules that have no LHS, or perhaps do not use normal facts (such as rules that use "from"
+ to pull data from an external source). For instance, if a new working memory is created, and no facts are asserted, calling the fireAllRules will cause the Initial Fact to propagate, possibly activating rules (otherwise, nothing would happen as there area no other facts to start with).
+ </para>
+ </section>
+
+ <section>
<title>Stateless and Statefull Sessions</title>
<para>Rule engines that are based around algorithms like RETE are
@@ -582,42 +593,7 @@
specify an Agenda Group are placed there, it is also always the first
group on the Stack and given focus as default.</para>
- <section>
- <title>Example scenario</title>
- <para>An example may make things clearer. Imagine a credit card
- processing application, processing transactions for a given account
- (and we have a working memory accumulating knowledge about a single
- accounts transaction). The rule engine is doing its best to decide if
- transactions are possibly fraudulent or not. Imagine this rule base
- basically has rules that kick in when there is "reason to be
- suspicious" and when "everything is normal".</para>
-
- <para>Of course there are many rules that operate no matter what
- (performing standard calculations etc). Now there are possibly many
- reasons as to what could trigger a "reason to be suspicious": someone
- notifying the bank, a sequence of large transactions, transactions for
- geographically disparate transactions, or even reports of credit card
- theft. Rather then smattering all the little conditions in lots of
- rules, imagine there is a fact class called
- "SuspiciousAccount".</para>
-
- <para>Then there can be a series of rules whose job is to look for
- things that may raise suspicion, and if they fire, they simply assert
- a new SuspiciousAccount() instance. All the other rules just have
- conditions like "not SuspiciousAccount()" or "SuspiciousAccount()"
- depending on their needs. Note that this has the advantage of allowing
- there to be many rules around raising suspicion, without touching the
- other rules. When the facts causing the SuspiciousAccount() assertion
- are removed, the rule engine reverts back to the normal "mode" of
- operation (and for instance, a rule with "not SuspiciousAccount()" may
- kick in which flushes through any interrupted transactions).</para>
-
- <para>If you have followed this far, you will note that truth
- maintenance like logical assertions allows rules to behave a little
- like a human would, and can certainly make the rules more
- managable.</para>
- </section>
</section>
<section>
@@ -684,7 +660,7 @@
rule.For each logical assertion there can only be one equal object, each
subsequent equal logical assertion increases the justification counter for
this logical assertion. As each justification is removed when we have no
- more justifications the logical object is automatically retracted. </para>
+ more justifications the logical object is automatically retracted.</para>
<para>If we logically assert an object when there is an equal STATED
object it will fail and return null. If we STATE an object that has an
@@ -730,6 +706,44 @@
</imageobject>
</mediaobject>
</figure>
+
+ <section>
+ <title>Example scenario</title>
+
+ <para>An example may make things clearer. Imagine a credit card
+ processing application, processing transactions for a given account
+ (and we have a working memory accumulating knowledge about a single
+ accounts transaction). The rule engine is doing its best to decide if
+ transactions are possibly fraudulent or not. Imagine this rule base
+ basically has rules that kick in when there is "reason to be
+ suspicious" and when "everything is normal".</para>
+
+ <para>Of course there are many rules that operate no matter what
+ (performing standard calculations etc). Now there are possibly many
+ reasons as to what could trigger a "reason to be suspicious": someone
+ notifying the bank, a sequence of large transactions, transactions for
+ geographically disparate locations, or even reports of credit card
+ theft. Rather then smattering all the little conditions in lots of
+ rules, imagine there is a fact class called
+ "SuspiciousAccount".</para>
+
+ <para>Then there can be a series of rules whose job is to look for
+ things that may raise suspicion, and if they fire, they simply assert
+ a new SuspiciousAccount() instance. All the other rules just have
+ conditions like "not SuspiciousAccount()" or "SuspiciousAccount()"
+ depending on their needs. Note that this has the advantage of allowing
+ there to be many rules around raising suspicion, without touching the
+ other rules. When the facts causing the SuspiciousAccount() assertion
+ are removed, the rule engine reverts back to the normal "mode" of
+ operation (and for instance, a rule with "not SuspiciousAccount()" may
+ kick in which flushes through any interrupted transactions).</para>
+
+ <para>If you have followed this far, you will note that truth
+ maintenance like logical assertions allows rules to behave a little
+ like a human would, and can certainly make the rules more
+ managable.</para>
+ </section>
+
</section>
<section>
More information about the jboss-svn-commits
mailing list