|
ReteEngine 1.0
A rules engine and builder
|
| NReteCore | |
| CActivation | The Activation class represents a pending rule activation in a Rete-based rule engine. It encapsulates the information needed to execute a rule when its conditions are met, including the name of the rule, the action to perform, the token that triggered the activation, and the salience (priority) of the activation. Activations are typically created by terminal nodes in the Rete network and added to an agenda for later execution. When an activation is fired, it executes its associated action using the token that caused it to be activated. The salience value allows for prioritizing activations when multiple rules are activated simultaneously, with higher salience values being executed first |
| CAgenda | The Agenda class manages pending rule activations in a Rete-based rule engine. It maintains a list of activations that have been triggered but not yet executed |
| CAlphaConditionNode< T > | The AlphaConditionNode class represents a node in a Rete network that applies a simple condition (predicate) to incoming facts |
| CAlphaMemory | The AlphaMemory class represents a node in a Rete network that stores individual facts and propagates them to successor nodes. It maintains a collection of facts that have been asserted and provides methods for asserting, retracting, and refreshing facts. When a fact is asserted, it is added to the collection and propagated to all successor nodes. When a fact is retracted, it is removed from the collection and successors are notified of the retraction. The Refresh method allows for updating the state of a fact without changing its presence in the memory. This class is a fundamental component of the Rete algorithm, enabling efficient pattern matching and rule evaluation in a rule engine |
| CBetaMemory | The BetaMemory class represents a node in a Rete network that stores partial matches (tokens) of facts and propagates them to successor nodes. It implements the IReteNode interface, allowing it to participate in the Rete network, and the ILatentMemory interface, indicating that it can hold tokens that may not yet be fully matched. The BetaMemory is responsible for managing the collection of tokens, handling assertions, retractions, and refreshes of facts, and ensuring that successor nodes are updated accordingly when changes occur. It serves as a crucial component in the Rete algorithm, enabling efficient pattern matching and rule evaluation by maintaining the state of partial matches and facilitating the flow of information through the network |
| CCompositeBetaMemory | The CompositeBetaMemory class represents a node in a Rete network that combines multiple branches of tokens (partial matches) using an OR logic |
| CExistsNode | The ExistsNode class represents a node in a Rete network that implements the "exists" condition. It tracks partial matches from the left (beta) side and facts from the right (alpha) side, ensuring that a token is only propagated to successors if at least one matching fact exists on the right. The node maintains a count of how many right facts currently block each left token, allowing it to efficiently determine when to assert or retract tokens based on changes in the right memory. This node is essential for implementing rules that require the existence of certain conditions without needing to specify all possible combinations of facts. <Remark> As a side note, in a rete network, the ExistsNode and the NotNode are very similar in structure and logic, with the main difference being that the ExistsNode propagates tokens when at least one match exists, while the NotNode propagates tokens only when no matches exist. This means that the ExistsNode will assert tokens when the count of blocking facts is greater than zero, whereas the NotNode will assert tokens when the count is zero. Both nodes must carefully manage their internal state to ensure correct propagation of tokens based on changes in the right memory.</Remark> |
| CILatentMemory | An interface representing a latent memory in a Rete network, which holds tokens that are not yet fully processed or activated |
| CIndexedExistsNode | The IndexedExistsNode class represents a node in a Rete network that efficiently implements the "exists" condition by maintaining indexed collections of tokens and facts. The left side of the node (tokens) is indexed by a key extracted from the tokens, while the right side (facts) is indexed by a key extracted from the facts |
| CIReteNode | An interface representing a node in a Rete network, which is responsible for processing facts and propagating them through the network |
| CJoinNode | Represents a join node in a RETE network that combines partial matches from the left input with facts from the right input based on a specified condition |
| CNotNode | This class represents a NOT node in a Rete network, which implements the logical negation. It tracks partial matches from the left (Beta side) and facts from the right (Alpha side) to determine when the NOT condition is satisfied. When a new left token is asserted, it checks against all right facts to see if any block it. If none block it, the token is propagated downstream. When a new right fact is asserted, it checks if it blocks any existing left tokens and updates their state accordingly. The node also supportsretractions and refreshes to maintain correct state as facts and tokens change over time. <Remark> As a side note, in a rete network, the NotNode and the ExistsNode are very similar in structure and logic, with the main difference being that the ExistsNode propagates tokens when at least one match exists, while the NotNode propagates tokens only when no matches exist. This means that the ExistsNode will assert tokens when the count of blocking facts is greater than zero, whereas the NotNode will assert tokens when the count is zero. Both nodes must carefully manage their internal state to ensure correct propagation of tokens based on changes in the right memory.</Remark> |
| COrNode | Represents a node in a Rete network that forwards facts to multiple successor nodes, effectively implementing a logical OR branch |
| CTerminalNode | Represents a terminal node in a Rete network that schedules rule activations when matching facts are asserted |
| CToken | Represents a chain of named facts used to track the state and ancestry of rule evaluation in a rule engine |
| CCell | Represents a data cell with an identifier and a value, supporting property change notification |
| CIFact | An interface representing a fact in the Rete network. This interface allows for abstraction and flexibility in handling facts of various types within the Rete engine, enabling the implementation of different fact representations while maintaining a consistent interface for interaction with the rest of the system |
| CFact< T > | The container for any types of data. This class implements INotifyPropertyChanged to allow observers to be notified when the underlying fact changes. It also includes a unique identifier (Id) to ensure that each Fact instance can be uniquely identified |
| NReteEngine | |
| CReteEngine | |
| NReteProgram | |
| CJoinKeyExtractor | This class is responsible for analyzing a join expression provided by the user and extracting the key selector functions for both sides of the join. The Extract method takes a lambda expression representing the join condition (e.g., (token, fact) => token.Property == fact.Property) and processes it to identify which part of the expression corresponds to the Token and which part corresponds to the Fact. It then compiles these parts into Func delegates that can be used to extract the join keys at runtime when processing tokens and facts in the Rete network. This allows for efficient indexing and matching of facts based on the specified join condition |
| CReteEngine | |
| CTraceNode | |
| CRuleBuilder< TInitial > | Provides a fluent interface for constructing and configuring rules in a Rete-based rule engine |
| CAlphaToBetaAdapter | Adapts an Alpha Memory output (single fact) to a Beta Memory input (Token). This allows the first JoinNode in a chain to receive a Token on its left |
| CSystemStatus | |
| CSensor | |
| CCriticalCell |