Content Copyright © 2006 Bloor. All Rights Reserved.
You can tell a technology has matured when announcements of new versions major on phrases such as ‘enterprise ready’, ‘scalability’, ‘operations management’ and ‘audit trail’ and say little about any new base functions. That is an emphasis on operations rather than development.
On this basis ILOG JRules 6.0 can be considered the release that JRules has come of age. The history of JRules since 1997 has been a continuing move in this direction but the March 2006 release puts JRules firmly in the enterprise operational category.
This is a natural progression but has undoubtedly been accelerated by the customer requirements from major clients such as eBay and Visa and partners including IBM. Business rules have historically been used to implement complex, high value but relatively low volume decision processes. eBay and Visa on the other hand have recognised that they can be more flexible and responsive by building rules base processing into the heart of their transaction processing. When many of their on-line business transactions include JRules processing the operational strength and enterprise reliability of JRules becomes as critical as the application servers themselves.
The first imperative for operational strength solutions is that the promotion of rules to production should be controlled, audited and secure. This is to ensure that the compliance officers and auditors can be told reliably the status of the rules now and at any past point in time. They also need to be convinced that the rules have not been circumvented or altered to allow rogue transactions through.
This process is more complicated for rules than for normal programming as there are two separate development communities. There are the standard Java-type programmers who need to use the same source control solutions as they use for Java to apply to rules. On the other hand there are business analysts who will develop business rules but have no wish to understand a Java development environment or the standard promotion processes that surround them.
JRules 6.0 provides a clear separation between the two groups with a clear and automated synchronisation process between them. Rule Studio, an Eclipse-based development environment, is for the Java programmer and works with standard Source Code Control (SCC) repositories. Rule Team Server is for the business analyst and has a browser-based front end and a database repository for the rules generated. Both these servers can deploy onto the operational Rule Execution Server. The repositories not only keep the current versions of the rules but historic versions and critically future releases that are either being developed or waiting to be deployed.
The Rule Execution Server can report on the current and historical state of the rules therefore the business management, compliance officers and auditors can find out the current state of the rules and the state of the rules at any point in the past. Without this ability it is really not possible to have mass deployment of operational rules.
Having ensured the veracity of the rules in production it is then essential to ensure that they run effectively. This includes:
- The ability to distribute the rules to multiple geographically dispersed Rule Execution Servers.
- The scalability of the Rule Execution Server to support large and increasing volumes of transactions and rules.
- Support for fail-over of a Rule Execution Server to a back up.
- Monitoring of the running rules must be integrated with the monitoring and operations of the total operational set-up.
- The rules engine itself should perform fast.
ILOG JRules 6.0 has addressed all these areas, as well as making it easier to learn and providing support for more complex rule sets, and therefore can be seen to have become a mature product.