One of the interesting attributes of rule-based systems (whether in complex event processing, decision services, or whatever) is the ability for end-users to maintain the rules separately from the IT development cycle. Rule-based development tools (TIBCO BusinessEvents included) typically allow for the hot-deployment of these changes – usually where process instances are updated with the new application logic in between transactions or events. This update process is both inevitable and a requirement when the underlying ontology or Business Object Model changes.
There is however a class of update that is less obtrusive, and can be managed simply by a rule update event. This is where the rule design pattern (or template) does not change, but the change is a create / update / delete operation on such a pattern instance, stored as an object or concept. Alternatively the update could simply be to rule instance metadata (for example, champion-challenger status, or active status, or effective date). In an Event-Driven Decision system, such update events are simply a new type of event to be processed, and would typically be created by some suitable Business User Interface (or automatically generated by some analytics system). Of course, rule maintenance events themselves should be validated by the rule engine prior to deployment, and other controls such as security and authentication may be required.
Of course, with event-driven rule maintenance one has to decide where the *record* of the current rule instances is to be stored – either in running rule system (for example, exploiting the distributed cache), or local to the user interface. Alternatively one can resort to tradition, treat the rule instances as data in a database, and update them via a simple 2-tier UI using database-imported concepts in the rule-based system…
