The Java Rule Engine API (JSR-94) specification has just been released for public review.
The API prescribes a set of fundamental rule engine operations. The set of operations is based upon the assumption that most clients will need to be able to execute a basic multi-step rule engine cycle, which consists of parsing rules, adding objects to an engine, firing rules and getting resultant objects from the engine. The set of operations also supports variations of the basic cycle, particularly variations that would occur in J2EE server deployments.
Read the Java Rule Engine API Specification Final Review Draft
Check out JSR 94: Java Rule Engine API Specification
argh,.... bad reqeust!
Is there any reason why you think this is a bad request?
I meant that the page was down and sending a bad request.
Bea/Sun had server issues.
No this is a good thing! Not sure I like a non free reference implementation though....
actually, from at least what I have been working on (trading systems in financials) this is very welcome.
Is this JSR just a way to get official approval for the Rules Engine implementation in BEA's WebLogic Personlization Server ?
Sounds like building the application and then describing the API :)
Yes, that sounds really likely, and of course IBM, Oracle, Unisys, and Fujitsu are all too happy to play along with BEA´s little scam? =)
Br - Johan
I've now read the API javadocs and the specification. It's sad to see a JSR deviate so far from J2EE's philosophy of vendor substitution. JSR 94 well defines object lifecycles, but makes no attempt to define a framework that might allow rules to run on alternate rules engines.
For example the JSR vaguely prescribes two rule formats, both of which are intentionally left as vendor-specific grammars: XML and binary abstract syntax tree. Merely promoting the existing RuleML dialect as a standard would have helped immensely.
There's no official way to programaticly construct a rule. Nor is there an official means of subclassing a rule, so associating custom behavior with a rule is impossible or unportable.
Thus even with JSR 94, rules are still entirely subject to vendor lock-in. This oversight is the equivalent of expecting J2EE deployment descriptors to be expressed in a proprietary fashion (perhaps even in a opaque binary format as JSR 94 suggests). Without vendor portability, JSR 94 might as well not exist, and customers might as well continue to code directly to their supplier's proprietary API. JSR 94 needs significant revisting before release.
As you pointed out, the specification does not cover the creation or management of rules. It really only covers the invocation of Rule Execution Sets (to use the terminology of the specification) without specifying how Rule Execution Sets are created. While this does indeed not address the “rules portability”, it does provide a solution to the “code portability” issue of how a rule engine can be invoked. While some vendors have APIs for programmatically creating rules, such APIs are rarely used, because if you write more than a dozen or so rules you are going to use the vendor’s rule language and/or their rule-creation IDE. It is not uncommon for companies to write thousands or tens of thousands of rules for a single project – they are able to do this because of rule languages that have been developed to tackle such real world business problems. Once a company writes the rules using the vendor’s rule language, they could deploy the rules as a Rule Execution Set using the JSR 94 API – in this way they could end up writing fully portable and vendor neutral Java code, since there is no “coding” is involved in the rule writing process.
From what I have seen, RuleML is yet a standard, it has little if any vendor support yet, and most importantly the companies who have adopted rule management systems and/or rule engines are not writing their rules in RuleML. Perhaps RuleML could soon be used as a common grammar to ease conversions from one vendor’s rule language to another, but I’m guessing that both standardization and large-scale adoption are a long way off.
>...if you write more than a dozen or so rules you are
>going to use the vendor’s rule language and/or their
Perhaps the best reason for a developer to choose J2EE is skills portability, which is something I don't see in JSR 94.
>Once a company writes the rules using the vendor’s rule
>language, they could deploy the rules as a Rule Execution
>Set using the JSR 94 API...
You mention deployment, and one way I view JSR 94 is as a container contract, not unlike J2EE. So I expect portability. I doubt I'd need JSR 94 if my main concern were rules capture and refinement, which still have a proprietary format.
>Perhaps the best reason for a developer to choose J2EE is >skills portability, which is something I don't see in JSR >94.
Well it is a very limited API, and since it doesn't specify either a rule language format or rule engine semantics you are not going to learn everything about rules by learning JSR 94. It is similar to JDBC -- you are not going to learn everything about how to interact with a database from Java unless you also know SQL. Of course there is no standardized rule language yet, but once you learn one vendor's rule product it is definately easier to learn that of another vendor.
>You mention deployment, and one way I view JSR 94 is as a >container contract, not unlike J2EE. So I expect >portability.
No - JSR 94 is not a container contract. It is a service invocation API. As the spec states it is an open question exactly how JSR 94 and J2EE are related. There is a JSR 94 - JCA example but that is just one approach.
>I doubt I'd need JSR 94 if my main concern were rules >capture and refinement, which still have a proprietary >format.
There are (at least) two phases of rule development:
1. Rule capture and refinement.
2. Rule deployment.
JSR 94 covers certain aspects of phase 2. If you are not interested in the first phase, then I don't know that you are going to be satified with any of the rule engine vendors since their products are all focused on both phases, and because they all aim to ease rule capture and refinement they each have their own rule language. Perhaps you could explain exactly what you are doing or hope to do using rules and rule engines?