Discussions

News: ILog Releases Business Rule Studio for Eclipse

  1. ILOG has released Business Rule Studio, a complete business rule authoring, testing and debugging environment for Eclipse. Business Rule Studio allows you to use the rules paradigm to develop business logic separate from but deployed into Java code.

    Download BR Studio at brstudio.ilog.com.

    BR Studio is part of ILOG's complete line of Business Rule Management solutions and requires the JRules runtime license for deployment. For more information visit ILOG's Website.

    Threaded Messages (12)

  2. First AOSD Workshop on Aspects (http://www.st.informatik.tu-darmstadt.de/staff/Ostermann/aosd2002/ACP4IS.pdf) hinted that Aspects implementations were simpler than ILog rules. Has anyone one done a recent real world comparison of the expressiveness or limitation of say AspectJ and ILog Rules?

    Gus.
  3. I think the two are not comparable - each has a different place in software development.

    The primary argument for rule technology is to decouple the details of business logic from the architectural logic. In a rules application, one constrains java development to infrastructure, and the truly fixed semantics of the business object model. All detailed business rules (validation, computation, etc.) are implemented as rules that can be changed without touching the java code. In an advanced rule application, this permits business logic changes to be made independently of the software development cycle, and facilitates implementing differing business logic for differerent domains (customers, jurisdictions, products, dates, etc.).

    Aspects, on the the other hand, are inherently tied to the java code base, because they act to modify that code base. They are useful for infrastructure issues (transactions, persistence, logging, etc.) and for fixed semantics in an object model. So, whereas the whole point of Aspects is to implement coarse-grained concerns that cut across large elements of the problem space, the point of rules is at least partly to permit flexibility in details that are too fine-grained to be efficiently managed as java code.
  4. I think that a good rule engine is faster and smarter than anything else because of the rete algorithm which they implement.

    Rules are more dynamical than other hard coded stuff. As far as I know, changing rules can be done without recompling and without deployment of components.

    Business Rules can be written by non-programmers some rule engine vendors claim.

    Take a look at Jess. It is very dynamical and you can easily implement artificial intelligence with it if you want. It implements AOP features by the way.

    I think that a rule engine cannot be compared with AOP.

    The really bad thing about rule engines is that the good ones are very expensive. And there is no standard rules language yet.
  5. Rete is proven[ Go to top ]

    I think that a good rule engine is faster and smarter than anything else because of the rete algorithm which they implement.Rules are more dynamical than other hard coded stuff. As far as I know, changing rules can be done without recompling and without deployment of components.Business Rules can be written by non-programmers some rule engine vendors claim.Take a look at Jess. It is very dynamical and you can easily implement artificial intelligence with it if you want. It implements AOP features by the way.I think that a rule engine cannot be compared with AOP.The really bad thing about rule engines is that the good ones are very expensive. And there is no standard rules language yet.
    Forgy's Rete algorithm has been proven to be the best and most scalable. In JESS, ilog JRules and Blaze, rules can be deployed/undeployed dynamically. the real benefit of Rete is the performance is not affected by the number of rules deployed. If one were to code the business logic rules in C/C++/Java, it would not perform as well as the number of rules or dataset increases. Rete gets around this by matching each data instance once for all rules. The basic principle of Rete is to take a set of conditions and convert them to nodes. Rules that match on the same exact condition reuse existing nodes in the Rete network. The nodes are then joined to other conditions. At the end of the conditions is a terminal node. for a detailed explanation, i would recommend reading Jess In Action.
  6. Rete is proven[ Go to top ]

    How about the problem of contradictory rules?

    What about rule priorities? I mean what if two rules have the same priority, which rule is evaluated first?

    Is it possible to create a infinite loop of rule evaluations? I mean a rule can change the data so that another rule is fired which changes data too. So this can result in infinite rule evaluations.
  7. How about the problem of contradictory rules?What about rule priorities? I mean what if two rules have the same priority, which rule is evaluated first?Is it possible to create a infinite loop of rule evaluations? I mean a rule can change the data so that another rule is fired which changes data too. So this can result in infinite rule evaluations.
    that is absolutely true and I've done that before while prototyping an application. The debate over how to handle those situations is still hotly debated. Some prefer to theorom, other provers. Rule engines aren't magic bullets, but they can make business rules more portable. I believe most of the popular engines have a "fire once" mode to prevent these types of infinite loop. I know the next release of Jess will have that feature.
  8. I am a newbie to the world if AOP and Rete Algorithm. However, I have worked/developed applications that perform Rules Engine task (evaluate bill -invoice data for determining direct auto payment).

    From the implementation and maintainance point of view, wouldn't it help that rules are kept simple (i.e. break complex rules into subset of standalone single rules) and let the rules engine run these singlets (single simplet rule) at a time and promote the object (item to be evaluated) to the next stage of processing, wherein the Engine and load the next applicable rule set.

    Such kind of system will make evaluation faster. (If there are failure during stage n, you can generate the object upto stage n-1 and run it through stage n, instead of starting it all over.
  9. that is correct[ Go to top ]

    I am a newbie to the world if AOP and Rete Algorithm. However, I have worked/developed applications that perform Rules Engine task (evaluate bill -invoice data for determining direct auto payment). From the implementation and maintainance point of view, wouldn't it help that rules are kept simple (i.e. break complex rules into subset of standalone single rules) and let the rules engine run these singlets (single simplet rule) at a time and promote the object (item to be evaluated) to the next stage of processing, wherein the Engine and load the next applicable rule set.Such kind of system will make evaluation faster. (If there are failure during stage n, you can generate the object upto stage n-1 and run it through stage n, instead of starting it all over.

    Those familiar with Rete engines and have a good amount of experience usually take that approach. Those without experience will have a hard at first, but once they do it a few times, it gets easier.

    Perhaps one of the harder things with Rete engines is teaching developers how to use and to change one's thinking from procedural to patterns.
  10. Rulesharp also benefits from RETE[ Go to top ]

    Rulesharp uses database in addition to RETE to increase performance and scalability. just thought that rulesharp could be mentioned next to jrules , blaze and jess since I think it outperforms them in java systems and is much simpler. randy
  11. I´m with you.
  12. I don't think AOP and rules are quite serving the same interests, particularly when it comes to dealing with complex business policy that must be managed by non-programmers.

    I believe they could be usefully used together (see the "AspectJ in Action" Manning book for an example). As an application architect you may choose to weave in a call to a rule engine: a authorization aspect delegating to a rule engine for rule-based authorization, where the rules are being maintained outside the application code by system administrators.

    Sincerely,

    Daniel Selman
    (ILOG)
  13. My wish-list for rule support in a programming/modeling system:


    a) AspectJ as underlying implementation technology, following documented patterns for tracing declarative rules to aspects

    b) embedded in Java, i.e. methods can participate in expressions, as in JEOPS
    http://www.cin.ufpe.br/~jeops/

    c) the docs explain in which thread and in which transaction context the rules execute ... at least that was the idea in http://www.eas.asu.edu/~irules ( overview at http://page.mi.fu-berlin.de/~hinze/caise02_DC/cameraready/jin.pdf )

    d) there are different kinds of rules, it's amazing how much one can go by just using sharp terminology:
    http://tmitwww.tm.tue.nl/staff/gwagner/myRuleML/What_is_a_rule.html


    Having a graphical editor and debugger would be nice too.


    Miguel