13 July 2007

Why JSR 94 is a futile attempt to solve a no-problem

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.

1 comment:

Mark Proctor said...

JSR94 is also very basic and vendors are pressured to make their enhancements available to JSR94, typically this is done via the properties file. The ludicrousness of this situation is users have insisted on a standard api and then insisted that it be made proprietary encumbered and thus no longer portable.

Mark
http://markproctor.blogspot.com