-
Language:
English
-
Language:
English
7.3. KnowledgeRuntime
7.3.1. The WorkingMemoryEntryPoint Method
The
WorkingMemoryEntryPoint
provides the methods around inserting, updating and retrieving facts. The term "entry point" is related to the fact that there are multiple partitions in a Working Memory and you can choose which one you are inserting into. Most rule based applications will work with the default entry point alone.
7.3.2. The KnowledgeRuntime Interface
The
KnowledgeRuntime
interface provides the main interaction with the engine. It is available in rule consequences and process actions. The KnowledgeRuntime
inherits methods from both the WorkingMemory
and the ProcessRuntime
, thereby providing a unified API to work with processes and rules. When working with rules, three interfaces form the KnowledgeRuntime
: WorkingMemoryEntryPoint
, WorkingMemory
and the KnowledgeRuntime
itself.
7.3.3. Fact Insertion
Insertion is the act of telling the
WorkingMemory
about a fact. You can do this by using ksession.insert(yourObject)
, for example. When you insert a fact, it is examined for matches against the rules. This means all of the work for deciding about firing or not firing a rule is done during insertion. However, no rule is executed until you call fireAllRules()
, which you call after you have finished inserting your facts.
7.3.4. The FactHandle Token
When an Object is inserted, it returns a
FactHandle
. This FactHandle
is the token used to represent your inserted object within the WorkingMemory
. It is also used for interactions with the WorkingMemory
when you wish to retract or modify an object. Below is an example of code implementing a FactHandle:
Job accountant = new Job("accountant"); FactHandle accountantHandle = ksession.insert( accountant );
7.3.5. Identity and Equality
These are the two assertation nodes used by the Working Memory:
- Identity
- This means that the Working Memory uses an
IdentityHashMap
to store all asserted objects. New instance assertions always result in the return of newFactHandle
, but if an instance is asserted again then it returns the original fact handle (that is, it ignores repeated insertions for the same object). - Equality
- This means that the Working Memory uses a
HashMap
to store all asserted objects. An object instance assertion will only return a newFactHandle
if the inserted object is not equal (according to itsequal
method) to an already existing fact.
Note
New instance assertions always result in the return of new
FactHandle
, but if an instance is asserted again then it returns the original fact handle (that is, it ignores repeated insertions for the same object).
7.3.6. Retraction
Retraction is the removal of a fact from Working Memory. This means that it will no longer track and match that fact, and any rules that are activated and dependent on that fact will be canceled. It is possible to have rules that depend on the nonexistence of a fact, in which case retracting a fact may cause a rule to activate. Retraction may be done using the
FactHandle
that was returned by the insert call. On the right hand side of a rule the retract
statement is used, which works with a simple object reference. Implemented below is example Retraction code:
Job accountant = new Job("accountant"); FactHandle accountantHandle = ksession.insert( accountant ); .... ksession.retract( accountantHandle );
7.3.7. The update() Method
The Rule Engine must be notified of modified facts so they can be reprocessed. The
update()
method can be used to notify the WorkingMemory
of changed objects for those objects that are not able to notify the WorkingMemory
themselves. The update()
method always takes the modified object as a second parameter, which allows you to specify new instances for immutable objects. The following is an update() example:
Job accountant = new Job("accountant"); FactHandle accountantHandle = workingMemory.insert( accountant ); ... accountant.setSalary( 45000 ); workingMemory.update( accountantHandle, accountant );
Note
On the right hand side of a rule the
modify
statement is recommended, as it makes the changes and notifies the engine in a single statement. Alternatively, after changing a fact object's field values through calls of setter methods you must invoke update
immediately, event before changing another fact, or you will cause problems with the indexing within the rule engine. The modify statement avoids this problem.