In this article Manoj discusses features that he would like to see in the next version of the JSR-94 specification. He goes through a list of 18 enhancements, that come from experience on projects in the telco, finance, and retail industries.

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.

Read more: Future Directions For The Rule Engine Specification

What would you like to see in the future?

I agree with most of the issues raised. I recently developed a JSR94 compliant rule engine. The rule expressions are essentially wrtitten in terms of java object properties and methods. My experience was along the same line.

I particularly felt the need for a RuleContext object to control the run time behaviour of the Rule Engine. I created my own and passed it as the first object in the List passed to the rule engine. Through this I could control behaviour such as whether the RuleEngine should return after excetuion of each rule or after all rules, specify a pluggable conflict resolution class etc.

Pranab

Thanks for the comments Pranab.

Where are you placing the controller logic to decide whether the next rule should be executed ?

Number 18 is questionable to me.

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.

In a RETE rule engine, the rules are light weight and really do not take much memory. The scenario described by #16 is supported by the concept of a rule module in most of the current commercial engines.

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.

I like the idea of supporting some standard modeling language. Wether it is UML, Schema, DTD or RelaxNG will be a subject of debate. #3 can be implemented in a simple way and doesn't necessarily need to be part of a rule specification. I can see cases where each mode is desirable, but I would rather that be driven by the application development.

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

The reason i say this is if we look at how CLIPS implements salience, and conflict resolution, salience has a very specific meaning. Most likely I don't understand the goal of #3.

Peter,

This is dependant on the number of rules that you have in your application. If you have hundreds of rules or a mid-tier rules server I can see this being attractive.

Also, standardising on the module concept would help achieve the aims of the JSR as would standardising API hooks for controlling certain behaviours and as you point out a precise definition of salience.

Appreciate the comments.

BTW: What type of applications have you built using CLIPS ? Are they mostly AI-based ?

Peter,This is dependant on the number of rules that you have in your application. If you have hundreds of rules or a mid-tier rules server I can see this being attractive.Also, standardising on the module concept would help achieve the aims of the JSR as would standardising API hooks for controlling certain behaviours and as you point out a precise definition of salience.Appreciate the comments. BTW: What type of applications have you built using CLIPS ? Are they mostly AI-based ?

mostly inference and financial applications. when i say inference, i'm referring to reasoning over partial data, or situations where strong negation is not possible or reason expectation. I was guessing the comment was based on procedural rules and not RETE rule engine. Although procedural rule engines are useful, they do have draw backs as the number of rules increase. The other primary limitation of procedural evaluation is when multiple rules reason over the same objects, they end up doing more work than RETE engines. It isn't necessary to have numerous rules and numerous objects to get a performance gain with Rete engine. From experience, any situation where several rules reason over the same object within a single evaluation cycle, RETE will be faster.

when i say inference, i'm referring to reasoning over partial data, or situations where strong negation is not possible or reason expectation.

that should have been "reasonable expectation". to elaborate a bit more. I've worked JESS in mobile environments for user defined rules and privacy rules. In the case of privacy rules, the service provider would provide a base set of rules, which apply to everyone. Each individual then would write their own rules using some kind of simple rule editor. Both the system and individual rules use the same set of domain objects. In this specific type of situation, a reasoning/inference cycle applies multiple rules to the same set of objects.

one of the most frequent questions on the JESS mailing list is when to use a rule engine in a stateful or stateless manner. In a stateful mode, a Rete approach would only need to evaluate the new facts, whereas a procedural approach may have to re-evaluate from the beginning every single time.

I would prefer to see confluence with AOP from a methodoligical perpective rather than a growing features on top of 20 different rule scripting techniques. The business problem is clear. There is no standard syntax. Until that's fixed this JSR will flounder.

It would be nice to see frameworks like Jess evolve as components that aren't tied to the hip to an application server, that can be embedded as flyweight components on micro scale as well as a macro scale. I like Jess, but if Jess became an application server I would drop it.

I would prefer to see confluence with AOP from a methodoligical perpective rather than a growing features on top of 20 different rule scripting techniques. The business problem is clear. There is no standard syntax. Until that's fixed this JSR will flounder.It would be nice to see frameworks like Jess evolve as components that aren't tied to the hip to an application server, that can be embedded as flyweight components on micro scale as well as a macro scale. I like Jess, but if Jess became an application server I would drop it.

I don't believe Ernest has any plans of bloating JESS into an application server. I know he wants to support JSR94, but I think that is an optional thing and not a hard requirement. He may have to package JESS slightly different, so that you can use jess.jar without all the JSR94 stuff. The new screen shots of the rule IDE look pretty good so far, so JESS is growing. I find it doubtful that Ernest would go down the route of bloat, especially since he recently talked about the joy of removing redundant code and cleaning up JESS to make it cleaner.

I think there are differing demands from different projects and applications. Some application architectures would prefer for the rules engine to sit alongside MDBs etc. in a J2EE application server, other application architectures I agree do not this.

Without a standard syntax with defined semantics this JSR will struggle - I agree.