Future Directions For The Rule Engine Specification (July 2004)

The rule engine specification has been around for some months now with vendors gradually climbing on board to achieve compliance. The specification itself is a good first attempt to help define standard contracts for software that means many different things in the IT industry.

In this article I will discuss 18 features that I would like to see in the next version of the specification. All of these features are an attempt to help achieve the current goals of the JSR94 specification itself.

The list comes from my own recent experiences working with customers in the telecom, finance and retail industries. The projects had common themes of needing the ability to rapidly add new products or new criteria to a system and the desire of these real-time enterprises to respond rapidly to changing business environments.

Desirable Features For The New JSR94 Specification

The order below is not meant to be indicative of any priority:

1. The majority of customers want portable rules and rulesets. This means a standard rules language with standard semantics. Vendors should compete on features such as scalability, performance, tools etc. Customers should be able to switch between rule engines relatively easily with no changes to rules or the calling client code.

2. The ability to store rules in a persistent storage of the customer’s choosing. This may be a relational database, an LDAP server, an XML database, an object database, a file system or something completely different. The Service Data Objects specification is aimed at this exact same requirement and mandating the use of this object-based API would allow portable storage and administration of rules.

3. Under certain conditions, we do not want certain rules within a ruleset to fire. A rule firing may depend on the results of rules with a higher salience. One could argue that this logic should reside in the rule itself but this would then tie the individual rules together. This logic should remain as a separate orthogonal aspect. I’d also like to be able to execute a rule “instead of” another rule – similar to the way “instead of” triggers work in Oracle and SQL Server databases.

4. Monitoring and management hooks into the rule engine. There are no standardised APIs for obtaining performance and tracing information. In particular, for before and after rule execution and ruleset execution.

5. Greater management and monitoring of the rule engine environment. Instrumentation could be enhanced by making rules, rulesets and other JSR94 objects into MBeans. This would also allow for a standard administration console for rule engines, and a standard deployment mechanism for a rules environment including the registration of rule execution sets.

6. The ability to specify the type of rule engine (forward chaining, backward chaining etc.).

7. The ability to configure the rule engine to use different algorithms for evaluation. Not all rule-engine applications require a refiring of rules once a fact has changed.

8. Compile-time validity of rules should be standardised and mandatory. Some rule engines allows you to write Java expressions in the XML descriptor for a ruleset. This is evaluated at run-time by the rule engine rather than at compile time. This may cause compile-time errors to occur at run-time. An analogy here is the precompiliation of JSPs option that application server vendors provide. Something standardised and similar for rule descriptors would be welcome.

9. The fact that my client code has to know that it is a J2EE application or a J2SE application that is being called has a bad smell about it. I’d prefer if a client-side adapter could be loaded via an IoC pattern. The adapter would take care of the J2SE/J2EE specifics and provide a unified API.

10. The ability to specify JSR94 objects in UML. A UML profile for JSR94 defined objects would allow JSR94 objects to be modelled and documented in a standard fashion. Extensions to this include allowing rule logic to be specified in OCL and allowing relationships between objects and other UML artifacts to be constrained by JSR94 rules and rulesets.

11. Following on from the above point, products and criteria are often attached to rule execution sets. It would be useful to be able to model and generate rules and associate them with objects. UML is the current standard notation and a UML profile for rule engines would allow for rule engine objects to be defined in UML and then generated into code. This would increase productivity of rule development and maintenance and help achieve a good level of documentation. I have seen a number of projects where modelling rulesets and rules before implementing them has helped achieved a more flexible system closely aligned to the business needs. There is no reason why business rule development cannot be model driven.

12. Pluggable security model for ruleset execution and rule administration. Sometimes you want to execute and manage rulesets depending on the user’s role. JAAS was recently added to the 1.4 J2SDK and would be a good fit.

13. The use of a RuleContext object to allow vendor-specific and application-specific properties to be passed around the rule engine. The RuleContext should also allow access to the working memory of the current session.

14. Higher-level business rules. There is normally a many-to-one or a many-to-many mapping of rules within a rule engine to business rules, mapping rules or presentation rules. This is currently constrained by the fact that there is no standard way that rulesets can contain other rulesets or rules. One feature I’d like to see in the standardization of this is use of the composite pattern that would allow a better grouping where by a ruleset could contain rules and other rulesets. This would allow the definition of business-level groupings of logic.

15. Meta-data improvements. Think of the JDBC meta-data API and the power that it offers. JDBC, JDO, EJB, TopLink and Hibernate all make use of this API. Something similar for a rule engine would allow workflow engines, presentation frameworks, object-relational mapping frameworks etc. to build something similar on top of a rule engine.

16. The ability to execute a set of rules as if I was winding the clock back to a date in the past is a common business requirement as is the ability to report on what rules where executed for what products at a certain point in the past. This time-variance functionality is very useful particularly for industries that are heavily regulated or that need to back-date for example an order or a trade.

17. Testing a rule, a ruleset and a descriptor outside of the rule engine would increase developer productivity. The ability to use well-known mock objects to achieve this is desirable.

18. By their nature, rulesets and rules are read-mostly objects. A standard way to load-on-startup, refresh and lazily load these objects would help the run-time performance of a rule engine whilst ensuring portability.

Conclusion

As the Enterprise Java platform has matured, customers have started to demand higher-level services such as rule engines and workflow products be standardised around common API’s with common semantics.

The first version of JSR94 specification was an attempt to bring consensus and standardisation within the vendor community. This has been difficult in an environment where the term “rule engine” has many different meanings. The specification is now ready for its next-step and vendors will need to play-ball or be pushed to the side in order for the goals of the specification to be met.

The views I express in this article are my own vision of where I would like to see the JSR94 specification go to in its next release.

This is a copy of the seminal paper taken from the Java Rules website. Author:Manoj Kochhar