Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Method and procedure for the persistence of a stateful rule engine on a grid, preserving the rule execution and optimizing the performance and size

IP.com Disclosure Number: IPCOM000238900D
Publication Date: 2014-Sep-24
Document File: 4 page(s) / 38K

Publishing Venue

The IP.com Prior Art Database

Abstract

This publication presents a method and algorithm to save the state of a RETE rule engine on a grid, which infers on the objects on a grid with weak identity. The RETE rule engine respects the refraction principle by remembering the rule instances that have been fired, and it optimizes the saving time and size. A robust serialization format is used, so that the saved states can be read under other configurations or using new versions of the products.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 27% of the total text.

Page 01 of 4

Method and procedure for the persistence of a stateful rule engine on a grid, preserving the rule execution and optimizing the performance and size

A rule based system works on a system of objects in a non-intrusive way. On one side, the objects are designed and exist; and on the other side, rule engines are used to control the behavior of the objects. In the today's computing environment, the objects are distributed across a grid and are made available transparently to various computation algorithms and engines.

    As an inference algorithm, a rule engine refers to the objects, track relationships between them, and execute the rules if the conditions are satisfied. As the objects are on a grid, they do not have strong identities and are identified by an identifier (a string). Some objects are local to a rule engine and are allowed to not have an ID, these objects implement a comparison algorithm.

    This is an example of rule:
set 'cust' to a Customer where the account number of this customer starts with "060"

    set 'card' to a credit card in the credit cards of 'cust'
if the category of 'cust' is GOLD and
the expiration date of 'card' is April 2014
then emit a credit card renewal notification for 'cust', with the last 4 digits of 'card'.

    This rule will be executed on a customer who has a credit card expiring in April 2014. If the customer has several credit cards, the rule could possibly be executed several times, one time per expiring credit card.

    For the customer "John Doe" and a credit card ending with "6523" that expires in April 2014, the execution causes a notification to be sent, with the 4 last digits of the credit card. If the same customer has another credit card (say ending with "3398") that is not expiring, it will not be executed. The preservation of the rule execution is the notice that rules have been executed on some objects, and they will not be executed again unless there is a change in the logical state.

If the rule engine is passivated and reactivated, the customer "John Doe" still has the credit card ending with "6523", so a rule instance is fireable again. If the rule engine executes the same rule instance (the same rule on the same objects), the notification will be sent again, this causes several notifications. The present invention remembers the executed rule instances and avoids the rules to be re-executed on the same objects after passivation.


 The performance and size concern. The passivation and activation is to be performed relatively often, and the size of the persisted data should be small with an efficient algorithm.


 The frequency of the passivation and activation is typical. Statistically the passivation is performed much more often than the activation. This is to be exploited to implement an algorithm that is optimal for the speed.


 During the passivation, which could last for some time, the engine could change its version (its code). We want to be able to restore the saved states of the engine....