Key architectural features of the IDIOM Decision Suite runtime
- Passive – The Decision Engine only executes decisions when explicitly invoked by the calling application.
- Stateless – The runtime component does not store any state between activations. All dynamic data is input to the Decision Engine at invocation. The Decision Engine modifies the state of the input business objects and returns them in its output
- Decisions are compiled – all business decisions are compiled into the native programming language of the target platform (Java, C#, or C++). There is no runtime generation or interpretation.
- Deterministic – Decisions are executed in a well-defined order. For a given input and rule set, the path to derive the output is defined and testable.
- Simple static interface – The runtime interface to the IDIOM Decision Engine remains the same no matter what the rule set or input data. It does not change if the decisions are changed or re-generated. The application is isolated from the implementation of the decisions.
- Single point of integration – The Decision Engine does not (and cannot) access any external applications or data. All data required by the Decision Suite to execute a set of decisions is supplied in the call to the server.
- Decisions are written against a business object model defined by an XML Schema.
These characteristics of the IDIOM Decision Suite differ substantially from more traditional rules engines. In contrast to the IDIOM Decision Suite, traditional rules engines are “stateful”, active and non-deterministic. Traditional rules engines maintain an active knowledge base of facts and rules. They execute continuously, firing rules in response to changes in input conditions and the state of the knowledge base. These rules engines are non-deterministic. A rule that has previously been determined not to be executable may subsequently be fired as a consequence to a change in the state of the knowledge base.
With any reasonably complex set of rules it is very difficult, if not impossible, to statically determine the flow of execution of business rules. As a consequence of their active and stateful nature, traditional rules engines are difficult to integrate with applications. They tend to drive the architecture of the system. Because these rules engines become the centre of the architecture to which they belong, they also tend to become an application server. This results in the business rules language being used not just for implementing business rules, but also for non-business-oriented application logic.