Rule Engine API (JSR-94), What Next?

Discussions

News: Rule Engine API (JSR-94), What Next?

  1. Rule Engine API (JSR-94), What Next? (12 messages)

    Daniel Selman (the new specification lead for JSR-94) has posted some thoughts on enhancements for Java rule engine support.

    Amongst other things, Daniel proposes creating a "Virtual Rule Engine Specification" to standardize the execution semantics of rule engines.

    The full article: JSR-94, What Next?

    What do you think of these ideas? Does Java even need a rule engine API? How do you think rule engine support should relate to J2EE?

    Threaded Messages (12)

  2. Wrote my own[ Go to top ]

    I looked at rules engines recently. I tried looking at the websites. I tried to find examples in the variuos OSS projects. But I couldn't find anything that really did what I thought a rules engine should.

    In particular, the projects are, like AOP, very focussed on the internals of their technology (rete algorithm/forward chaining/backward chaining/...) I don't understand these things, nor do I want to.

    All I wanted was a GUI interface that allowed me to define rules that queried a java bean object model. A way to define in configuration something like:
    <test>if (journey.isDepart("AMS"))</test>

    Fustrated, I wrote my own non-OSS basic system, minus GUI, using Javassist.

    My message is that rules engines, like AOP, are still too hard to grasp for full mainstream adoption IMHO.
  3. Have a look at Drools[ Go to top ]

    While not quite a production release, I found that the Drools project (http://www.drools.org) had the best documentation compared to some of the others. For example, the Mandrax project sounded better at first. However, after reading through thier docs, they didn't really get into how the heck you'd actually use it in your application. Drools sold me when I took a look at the FishMonger example which I found in the CVS repo. But yes, I'll agree that many of these engines focus on the internals rather than presenting a strong case as to why a rules engine is a good idea. And the examples on the drools site also DO NOT give a compelling reason to use Drools. "Bob likes Cheese" doesn't make me think that a rule engine will help my project any. Also, the fact there isn't a nicely packaged distribution doesn't help either. However, if you spend the time I think you'll find Drools is very nice and easy to use. The Drools Rule syntax is much easier to use than say JESS. I also prefered the Drools API over teh Java Rules API.
  4. Wrote my own[ Go to top ]

    (rete algorithm/forward chaining/backward chaining/...) I don't understand these things, nor do I want to.
    ...
    All I wanted was a GUI interface that allowed me to define rules that queried a java bean object model. A way to define in configuration something like:<test>if (journey.isDepart("AMS"))</test>Fustrated
    ...
    My message is that rules engines, like AOP, are still too hard to grasp for full mainstream adoption IMHO.
    Generally I agree, rules engines are complex but the task in hand is also complex, a simple test (as above) is fine but implementing something more complex without getting bogged down in rules and rule relationships is orders of magnitude harder, GUIs are also limited, some rules just get too complex. Versioning can be messy in GUIs and you'll find the majority of B.A.s define their rules with something as primitive as Excel, this doesn't translate well into a GUI.

    The ideal situation is perhaps a GUI for most of rules with the ability to use Java when it gets too complex. There are several enterprise vendors that offer this already but few have interesting technology behind them or any respect for standards.

    Banks spend millions on rules and workflow engines, it's big business. There are quite a few vendores in the space, products include work-flow, CRM (part of it), pure rules, BPM, BAM, process-orchestration etc. Personally I would like to see a good distributed engine (enter pi-calculus). JavaSpaces is the ideal technology for this, add RuleML, good Rete/ECA Policy-based rules and you've got a winner.

    Most of you have probably read these but they cover the same subject...
    Rule Engines and Declarative Programming Come to Java
    TSS Article: The State of Workflow

    -John Davies-
  5. Wrote my own[ Go to top ]

    I looked at rules engines recently. I tried looking at the websites. I tried to find examples in the variuos OSS projects. But I couldn't find anything that really did what I thought a rules engine should.In particular, the projects are, like AOP, very focussed on the internals of their technology (rete algorithm/forward chaining/backward chaining/...) I don't understand these things, nor do I want to.All I wanted was a GUI interface that allowed me to define rules that queried a java bean object model. A way to define in configuration something like:<test>if (journey.isDepart("AMS"))</test>Fustrated, I wrote my own non-OSS basic system, minus GUI, using Javassist.My message is that rules engines, like AOP, are still too hard to grasp for full mainstream adoption IMHO.
    Writing a basic rule engine isn't all that hard honestly. Anyone with compiler experience can write one fairly quickly. The real challenge here is writing a rule engine that can scale to handle large amounts of data, or very dynamic environments where there are numerous rules reasoning over a set of objects. One limitation of writing procedural rule engines is the concept of "truth maintenance."
    The basic principle is that during the evaluation process, the facts should not change, because a change could mean potentially all the results calculated so far are inaccurate. This is one of the reasons "production systems" went with the concept of a "in-memory" database or what Forgy calls "working memory." Some rule engines refer to this as shadow facts. In a real world application, some data is needed to evaluate the rules, but they are relatively static. Other data, will change during the evaluation process. In order for the rule engine to reach a valid set of results, the facts must be evaluated as a closed system. What that means is a change to any one value, must be re-evaluated in all associated rules.
    Forgy's algorithm is rather simple and isn't all that hard to understand. Evaluate every object once for every rule. In a procedural rule engine, every rule will take it's turn evaluating a set of conditions for that rule. What Rete algorithm does is it converts the conditions of a rule into a node. This way, when an object is evaluated, it first enters the node defining that object. In clips, it's called "deftemplate". From there, it links to one or more nodes which may join an attribute of a given object with an attribute of another object. For example, order.discountID == daily.discountID. Rete defines how rules should be converted into nodes to form a network, which optimizes how objects are evaluated.
    Obviously, implementing a rule engine is a bit harder than understanding the high level concept. Writing a good Rule IDE is also a fairly complex task, which still needs to mature a bit more before it is really easy for non-experts. If you want to learn more about it, I would recommend Jess In Action by Ernest. It is a solid book and provides a much better explanation than I can provide in a post.
  6. Subset[ Go to top ]

    Another way of looking at this is that my needs were just a subset of what a rules engine is supposed to provide.

    Nested if statements, defined in a configuration file, against a java beans.

    It seems that this level of limited rule evalutaion is almost a separate concept from a 'rules engine'. But its probably useful to a lot of people. And a great alternative to complex XML structure in configuration ;-)
  7. Subset[ Go to top ]

    Another way of looking at this is that my needs were just a subset of what a rules engine is supposed to provide.Nested if statements, defined in a configuration file, against a java beans.It seems that this level of limited rule evalutaion is almost a separate concept from a 'rules engine'. But its probably useful to a lot of people. And a great alternative to complex XML structure in configuration ;-)
    yeah, if all you really need is very simplistic rules, than a simple approach is most likely the best option. Since I work with RETE, I'm obviously biased. In a more dynamic environment where privacy rules may use some sort of declarative rules that must co-exist with a standard set of privacy rules on the server side, using a procedural approach would most likely hit a ceiling quickly.

    On the topic of what is next for the rule API, my bias is towards a standard rule language. From first hand experience, the execution part of it is easier for newbies to understand. The ease of teaching new programmers declarative rule programming is probably one of the hardest parts of building an effective application with Rete rule engines. The concept of pattern matching is probably one of the hardest concepts for new users to grasp. Other people may have different experience, but if you look at jess mailing list, you'll that is the most common problem.
  8. Another rules engine ...[ Go to top ]

    Hi, It may be a bit too late responding to this discussion.
       I did have a look at the existing rules engine and found that the rules language is more close to the programming constructs.Its similar to having ur data written in a cryptic manner in a properties file,which could be manipulated for configuring the application settings.
       I decided to pursue writing my own rules engine with the following goals :-
    1.A UI to create rules
    2.Current data objects can be input in the rules engine,or be used in the action fields for manipulation in the working memory.
    3.JSR 000094 compliant - the rules engine JSR

    These may seem hefty goals for now,but thats the aim.
    I am currently in the designing phase and am implementing a forward chaining rules engine using the rete algorithm.

    I could be reached at amythical at yahoo dot com for further comments and discussions.
    Would be glad to receive comments and suggestions.
    Regards,
    Amit
  9. Another rules engine ...[ Go to top ]

    Hi, It may be a bit too late responding to this discussion.&nbsp;&nbsp;&nbsp;I did have a look at the existing rules engine and found that the rules language is more close to the programming constructs.Its similar to having ur data written in a cryptic manner in a properties file,which could be manipulated for configuring the application settings.&nbsp;&nbsp;&nbsp;I decided to pursue writing my own rules engine with the following goals :-

    1.A UI to create rules

    2.Current data objects can be input in the rules engine,or be used in the action fields for manipulation in the working memory.

    3.JSR 000094 compliant - the rules engine JSRThese may seem hefty goals for now,but thats the aim.I am currently in the designing phase and am implementing a forward chaining rules engine using the rete algorithm.I could be reached at amythical at yahoo dot com for further comments and discussions.

    Would be glad to receive comments and suggestions.

    Regards,
    Amit

    having worked on rule engines, rule compilers and rule editors, if your goal is to make it easier to write rules for non-programmers, it would be better to focus on the IDE. I say this because any declarative rule language should be easy to map to any other rule language. Take drools for example. It provides semantic modules so that users can write their own rule language, without having to write their own rule engine. I've been working on a full RETE implementation for Drools the last 8 months, and that in itself will take us another 12-14 months to support all the advanced features of a full blown first class RETE implementation. For the short term, we're hoping the rewrite of the alpha node, beta node and memories will ship later this year. After that, we're planning on supporting things like logicals, Just-In-Time optimization and logic rewriting in the rule compiler.

    writing a rule engine is a great learning experience, but it really does take a long time. the learning curve is rather steep. good luck.

    peter
  10. Limitations of JSR 94[ Go to top ]

    Hi

    Following are the limitations that one observes when planning to device a generic connector for the BRE implementations:

    1. The JSR94 specification does not address the structure of rules and rule execution set, as there are considerable differences between vendors, and differences often relate to the requirements of different types of rule engines and execution algorithms. For the purposes of this specification, a rule merely exposes basic metadata, such as a name and a description. This limits the information that can be shown to a user to select the rule execution set for execution.

    2. Inclusion of the custom packages. The sample provided with final release makes use of custom classes to be supplied as input to the rule engine. Unlike JDBC JSR 94 does not specify data types that can be sent as input to the engine.

    3. Most implementations support the JSR 94 spec. but the implementation is meant for the J2SE environment. The javax.rules.admin API provides the methods for registering the rule sets with the engine that later can be retrieved by the client javax.rules API and accessed through the URI. These implementations maintain the URI at the client level in a Map. Such implementation would fail in clustered environment.

    As the specification it self suggests:
    “The binding mechanism used to associate a binary RuleExecutionSet instance with a String URI is not prescribed by the specification.”

    The implementations are free to establish the associations.

    Can anyone comment on this?

    Rinesh Kumar Agnihotri.
  11. Rules are made to be broken[ Go to top ]

    I've worked with JESS, ILog and Blaze and let me tell you the real value of a rule engine is in an interface where the Business users can manage theit own busines rules(There has to be a policy structure and/or workflow in place to managing rule changes).

    Having developers implement all business rules is "the same soup warmed over".

    IMHO, ILog offers the best toolset around their core rule engine but by no means is it the silver bullet in rules development.


    My .02 cents,
    Travis M. Gibson
    http://www.travismgibson.com

    P.S.
    Implementing a true Rete algorthim in no easy undertaking. Determining 'Rule Salience' in the context of Rete network can be tough.
  12. Rule Representation[ Go to top ]

    Hi, with all talk on rule engine, I'd like to focus on Rule Representation. If you cant maintain your rules, you are better off having them as simple logical code. Simple! It's all very well to get carried away by the cool technology behind it, but esure people can use what you make or else you;d be admiring your own image. If you decide Rule Engines are for you THEN Decision tables in the form of EXCEL are 'arguably' the easiest form of representation for BA's to represent their logic and surprisingly engineers to also follow up on. Context: Few years back I had written a UI in java/java script to define Business Objects, compile expressions and write rules from a Browser [For Drools XML rules set] (Was trying to emulate what a popular commercial rules engine had 'At that Time' and I was successful. I was very pleased with the output as a research project, but technical people forget its not the greatness of what you write that is important but the fact how easy it is to use and how much other people use it. (I'm not a Microsoft fan but I respect it for this reason). Today after a lot of interacting with business users and non-technical clients, I understand that that approach is restrictive. Whats the Bottom Line? So whats the best format? I'll try not to be diplomatic by saying ".. Well it depends on what you want!" On an individual rule level, its easier to write a DRL or DSL file. And for this you can make you life uselessly fullfilling by writing a UI but this is full of risks and also when the rules become a lot, it is a pain to look at. The question is answered by, "What is easier to maintain and Read!" Decision tables are a good choice, arguably the best! They also have other advantages that I dont want to kill this thread with. Also, you dont waste time with "When..Then" Just What are my conditions and what is the Action and if required the prioriy. Do I need a UI to maintain decision tables? Hell NO!!! The world uses Excel, use Excel or anything, a database for all you want (Although thats spinning the wheel in a way to confuse people in differentiating between Meta data and the rule itself --> So try and avoid it :) ; theres a book on this also, its good reading but I'd resist converting my DB into a rules engine. As for version control; if the decision table is in a file Q.E.D :) -- version COntrol! If you want to monitor rule level changes, well figure it out! ;)
  13. ... Just like to add; Decision tables can be compiled into DRL's. So yo uare anyway safe. The reverse I doubt is successful or currently available.