IDIOM News
From Business Rules Journal
The IDIOM Decision Suite System Architecture
For application developers IDIOM simplifies life by removing the necessity to program rules. Instead, applications access business rules by calling on the IDIOM Decision Service. The Decision Service is IDIOM’s runtime component: it consists of a shell (the Decision Engine) that acts as a container for the organisation’s business rules in the form of generated code. Calls on the Decision Service always follow the same simple pattern. The application sends the decision server a request containing all the business data required as input to the decisions to be made. The server executes the appropriate business rules, stores their results in the request and returns the request to the application.
Figure 1: IDIOM System Architecture
The Rule Builder’s Role
The goal of IDIOM is to allow business people to build and manage the business rules. Rules builders are charged with managing decisions and formulas and need have no knowledge of the technical architecture or environment. The rules they develop are technology agnostic: it makes no difference which programming language is generated or how the generated code is integrated into the application. The organisation’s rules are maintained in just one place and can be deployed to multiple applications using whatever languages and technologies are necessary.
Rule builders use the IDIOM decision Suite to create repositories of business rules. They work independently of the application developers, having agreed at the outset on a "contract" defined by a series of XML schemas describing the objects contained in the decision requests that pass between the application and the IDIOM Decision Service at execution time. The business rules that they develop take the form of decisions and formulas closely integrated with the schemas.
Developing Schemas
The schemas are the starting point for building an IDIOM rules repository. They emerge from a conventional analysis and design process in which some additional focus has been placed on decisions. For example, use case writers recognise that the application modules which will implement the use cases will at runtime delegate decision making to the IDIOM Decision Service, and specifically identify decisions in the use cases accordingly. Typically the decisions are factored out into a separate "decision inventory" where they can be analysed, managed and reused more effectively. More detailed analysis of the decisions leads to the definition of the input and output data for each decision request, and a final formal specification using XML schemas. This is a technical design task for the system’s architects, who must also consider the integration of the decision requests into the software architecture.
| Next: "Preparing the IDIOM Decision Suite Business Rules Repository" |
 
 
|
| Return to News Archive ... |