Rules Engine behavior takes one of two forms:
•Blocking behavior, also referred to as restrictive action. •Transforming behavior, also referred to as corrective action. Strictly, Rules Engine action is limited to responding to data manipulation requests rather than data query requests. We expect of a Rules Engine that it makes sure no unwanted data manipulation takes place, and wanted automatic manipulation always takes place.
In practice, a USoft Rules Engine also has a role to play in handling data query requests. It offers rich query possibilities that are logically related to the rules it implements. The best way to think of the Rules Engine as a query handler is by imagining that if offers views on the business data in a way similar to database views offered by RDBMS products.
The Rules Engine's blocking (or restrictive) action occurs in response to INSERT, UPDATE or DELETE requests. If the result of a requested data manipulation would go against what the rules allow, the Rules Engine does not send the request to the database, but instead sends a message back to the caller. This message typically formulates the violated business rule.
The picture below visualises how requests are blocked that come directly from the client (initial requests). In reality, the Rules Engine also potentially blocks the result of corrective actions that it attempts to perform itself as an indirect result of the initial request. See the next section for an explanation.
|
The Rules Engine's transforming (or corrective) action occurs in response to INSERT, UPDATE or DELETE requests. In order to comply with business rules, the Rules Engine may decide to transform the initial request and do something else, or something additional, in the RDBMS. Like the initial request, this indirect action takes itself the form of INSERT, UPDATE, or DELETE commands that are themselves subject to the same rules and the same blocking action as the initial request.
The term 'corrective' is slightly misleading because it seems to imply that the initial request is somehow erroneous: that it must be 'corrected'. This is not the intended meaning: the initial request is typically valid and legal. Rather, the intended meaning is that rules tell the Rules Engine to do something else, or someting more in the RDBMS than what the initial request says.
The picture below visualises transforming (corrective) action. It also visualises that the Rules Engine is an interface not only for data manipulation requests, but also for all data query requests. These requests take the form of SELECT statements.
|
|