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 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).
Equality
This means that the Working Memory uses a HashMap to store all asserted objects. An object instance assertion will only return a new FactHandle if the inserted object is not equal (according to its equal 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.