Q: What's a no-problem?
A: A problem which never occurs in practice but is defined to be one by some committee.
---
Q: What's JSR 94?
A: An initiative to define a Java runtime API for rule engines by providing a simple API to access a rule engine from Java. In theory, rule engines can be seamlessly interchanged if they comply to JSR 94.
---
Q: Why is JSR 94 solving a no-problem?
A: IMHO there at least two reasons:
1. JSR 94 covers only the rule engine API, but NOT the rule language (which might, one day, be covered by RuleML).
+ This API describes how a rule engine should be invoked from Java. That's (simple) infrastructure code - you need a couple of classes and interfaces for it.
+ If you change your rule-engine, just rewrite those few classes and you're set... at least with the infrastructure.
+ You'd have to rewrite (and re-test) ALL your business rules to change the engine - and rule languages are by no means similar to each other...
2. Who wants to change the database? In more than 20 years I have not seen a single customer migrating a productive system from one database to another - although database independency long seemed a crucial issue.
+ I've experienced cases where we used MySQL for development and Oracle for production - but they behaved differently, even with powerful OR-Mappers we could not resolve those issues.
+ Don't tell me anybody wants to try this with their business rules... nobody wants them in two different rule-languages.
---
Q: What do the rule-engine vendors say about it?
A: I don't care. SQL-vendors blubbered about interoperability for ages. But they always found ways around it.
---
Q: What shall I do if I care about rule engines?
A: Choose the best one for your purpose. And be prepared to stick to it for a long time.
