Wednesday, February 13, 2013

Dropping JSR94

We are thinking of dropping JSR94 support in the next release, especially as it doesn't align with our new approach to building rules - which is convention and configuration based, rather than api based.

If anyone has a good case for keeping JSR94, please leave a comment.

12 comments:

  1. You should keep JSR94 support because it offers interoperability between BRMS vendors.

    ReplyDelete
  2. I doubt dropping JSR94 will affect me but I suspect there are users not on the bleeding edge who will be unhappily surprised. I don't know how many systems embed Drools but a high google hit is: . I suppose if you want to hear from your downstream that dropping a feature they depend on is one way to do it! ;-)

    ReplyDelete
  3. Hmm, the link I was trying to post was to docs.wso2.org/wiki/display/BRS200/File-Based+Configuration

    ReplyDelete
  4. I would really appreciate if you could keep the support for JSR94.

    My project (RVPF at http://rvpf.org/) allows the embedding of rules engines for stateless computations and stateful event processing. This project is mostly configuration based and is used in some industrial and research environments.

    My clients favor stability and will keep a working version for quite a long time. This means that a given version of my framework must allow different versions of the rules engine: one of my clients is still using Drools 2.1!

    Thank you for your work on Drools!

    ReplyDelete
  5. Using JSR 94 restricts the rule engine to functions contained in the standard used by most rule engines.
    Going beyond that standard means breaking the restrictions of JSR 94.
    How about having rules that are tested for JSR 94 and are interchangeable and others that fail the test and are only useable with Drools?
    Drools should at least be able to process JSR 94 compliant rules even if it may be able to process more.

    ReplyDelete
  6. "Drools should at least be able to process JSR 94 compliant rules even if it may be able to process more."

    JSR94 is not related to rule language interoprability. It in no way allows you to write some rules that can run in multiple rule engines. All it does is provide an abstraction load rules and insert/update/delete facts.

    ReplyDelete
  7. Mark, I just ran across this comment and was wondering if you had any update about this decision? I am using JSR 94 and while I would love to see it improved and/or have the industry move toward a new specification altogether, for now it does serve a purpose for my organization.

    I was wondering, could you still offer a base set of features or some sort of continued support for JSR 94 (or alternative specification)? Obviously, I don't know the difficulties on your side considering what you are pursuing. Just letting you know there are people using the specification.

    Thanks for asking!

    ReplyDelete
  8. The committee behind JSR94 is no longer around, so nothing is changing or will be changed any time soon.

    We have no plans to further extend the JSR94 api.

    We will keep it around a little while longer. The reason for wanting to drop it, is we have limited resources. Every time we refactor or change, we have to fix tests in out JSR94 module.

    Sooner the world gets off JSR94, and I can kill it, the better.

    ReplyDelete
  9. This comment has been removed by the author.

    ReplyDelete
  10. Mark, I completely agree about killing it. I don't need most of the features, the administrator is beyond what my needs have ever been. As the industry moves forward, do you think an annotation standard should be considered? Has there been any talk of this or is it also considered unnecessary?

    If you end up dropping it, of course I can create my own glue to a Drools POJO. But it would still be nice to establish an industry standard way of having any Java application execute any Java rules engine, by simply changing the CLASSPATH and a couple URL's.

    Hey, maybe a major vendor dropping JSR 94 support will open this discussion? :-)

    Thanks,
    Alan

    ReplyDelete
  11. "Mark, I completely agree about killing it. I don't need most of the features, the administrator is beyond what my needs have ever been. As the industry moves forward, do you think an annotation standard should be considered? Has there been any talk of this or is it also considered unnecessary?"

    Getting vendors to establish singular agreed standards can be very difficult. But there is nothing to stop users from developing their own abstractions. In fact I would actually recommend this, by allowing multiple user driven efforts to establish "defacto" api wrappers, we'll get a lot more innovation, a lot quicker, than waiting for vendors to fight it out and drive things to the common denominator.

    In our 6.0 release, we have established something that is convention and configuration based and thus declarative. It has annotation support too (CDI), as well as support for OSGI Blueprints and Spring - working consistently across all environments. This is far superior to JSR94. See my 6.0 talk here:
    http://www.slideshare.net/MarkProctor/ireland-augam2013

    Anyone continuing to work with JSR94 is a masochist :)

    We have true implementation separation. We have a single user facing JAR, that exposes all our interfaces, using factories to provide our implementations - no implementations or factories are in this -api jar. You could take our -api jar framework and provide factories (implementing a subset of available interfaces) for other vendors products. This could easy be for for Jess or JRules. I would encourage any company needing vendor abstraction to try this approach. I'll offer direct support in those efforts, if they make those efforts available as OSS.


    ReplyDelete
    Replies
    1. Mark, thank you very much for the reply. I will definitely check out everything, I have not seen your talk yet. Yes, I have my own abstraction of JSR 94 to keep it away from my clients, but of course I hate it. :-) And I am pursuing OSGI compliance as well, so when I plug-in Drools this will be exactly what I need. Thank you for opening this discussion, it was actually perfect timing for me.

      Delete