Discussions

News: javarules.org - The Java Business Rules Community

  1. We are pleased to announce a new web site for Java programmers building business rule applications or rule-based systems using the Java programming language.

    Our mission

    • Promote rule-based programming in Java in general.
    • Provide a vendor neutral portal for finding and sharing information.
    • Inform and educate implementors and users of the "Java Rule Engine API" (JSR-94).
    • Discuss future evolutions of the Java Rule Engine API.
    We have spent several weeks scouring the Internet for rules-related information and web sites. The results are available in the "Web Links" section of the site. Visit, comment, participate!

    We encourage vendors and end-users to post corrections, news, web links, comments or articles to the site and provide Java programmers with the definitive online reference for business rules.

    Checkout: http://www.javarules.org

    javarules.org
    Editorial Team

    Threaded Messages (19)

  2. Question for Daniel[ Go to top ]

    Seeing as you are an ILOG employee, I'm wondering if your employer is sponsering this web site? If so, how are you going to maintain independence from ILOG?
  3. Question for Daniel[ Go to top ]

    Robert,

    Good question, and one that I've been thinking about for a while.

    No, the site is not supported by ILOG, it is something that I work on in my precious spare time. I have neither the time not the inclination to micromanage the site, and it would be unprofessional to misrepresent the site as a community site and use it to push an ILOG agenda. The ILOG rule engines are more than capable of competing on their own merits, as they have for a number of years! :-)

    There are already four "editors", including one from YasuTech (an ILOG competitor), and we welcome anyone with time to spare and experience, or an interest in business rules, to get involved.

    As the JSR-94 specification lead for a while, I have some experience in working with other rule engine vendors in a collaborative way. I'm trying on getting more of them to sign up as editors.

    I strongly believe the Java community needs a site like javarules.org. I spent quite a while looking for something equivalent before reluctantly deciding to dive-in and create it.

    Want to make something of it?

    As they say in England... and product marketing! :-)
  4. Question for Daniel[ Go to top ]

    I can confirm what Daniel has said. The site is vendor neutral and will remain so. I work as the chief architect for a company based in the UK (http://joxo.co.uk) and we have no commercial affiliation to any of the vendors.

    On the site we do welcome input from the community including the right times to use a rules engine and the various definitions of a rules engine.

    Manoj. Editor (www.javarules.org)
  5. Question for Daniel[ Go to top ]

    Robert,Good question, and one that I've been thinking about for a while. No, the site is not supported by ILOG, it is something that I work on in my precious spare time.
    Daniel,

    Thanks for clearing that up. I hope you don't think me rude for asking.

    Best Regards
  6. Great start![ Go to top ]

    This is a great start. I hope a vendor-neutral community process will emerge that will standardize on rule languages. In my opinion standardization to one accepted rule language will give a great boost to the wider (and more standardized) use of sophisticated rule engines in enterprise business applications.

    Vijay Ganesan
  7. rules vs objects[ Go to top ]

    There's a question I've been mulling over for some time now:
    Does the use of rules imply not using the Domain Model pattern but using some tabular java objects like the Record Set pattern instead.
    (pattern names according to Patterns of Enterprise Architecture)

    The reasoning is of course that you go through the perils of O/R mapping because of the advantages of using object orientation on your business logic. If you implement all your business logic in rules there's no more need for O/R impedance mismatch.

    Another question with respect to rules vs object domain models is how to decide when to use one versus the other.

    Any thoughts on these two?

    groeten uit Nederland,

    Joost
  8. rules vs objects[ Go to top ]

    Domainn models are very powerful at abstracting concepts from the business domain and providing relationships between related concepts.

    Domain methods should be used to drive the execution of certain rule sets. For example, an Order class should have a method on it for validating the order. This should really delegate the validation to a rules execution set. Which rule execution set can be derived from business logic (i.e. if a book execute the book rule execution set) or from another set of rules.

    Rules themselves are first class objects. How are they stored is vendor-specific (some use a database, others XML etc.). But rules themselves are not domain objects. Rules can also be used for example to validate presentation logic.

    So rules and domain objects should be used together to provide reusable, flexiable business logic. Domain objects should drive rules. These rules may then invoke further domain objects.
  9. If you look at some of the largest enterprise business application software vendor products you will notice something very interesting in their architectures - they don't have an object view of relational data i.e. they don't have a domain object model that mirrors their relational database schemas! No entity beans, no JDO, no Hibernate or whatever. The relational data is manipulated directly through SQL or with some APIs to make the SQL manipulation easier.

    Why is this? Well, it's simple - performance. If you are building heavy duty transactional applications with stringent performance requirements AND you don't have very complex business logic, why do you need to incur the overhead of an object model layer in between? If I have a catalog management application, all I need is to pull data from my catalog tables and render it in a Web page and to provide basic manipulations like selecting a row, editing some fields, sorting, paging, adding to a shopping cart etc. - all of which can be done without a object model layer. In spite of all the marketing of EJBs by vested interests, many architects (including myself) are not sold to the idea of using a object model layer for transactional applications.

    But there is a very important factor here - "complex business logic". While there may not be very complex business logic involved in transactional applications compared to some strategic applications, there ARE a whole bunch of business rules. Business rules need to represented and applied at various levels in the application. Most of these rules are quite simple and there may not be a need for a sophisticated Rete algorithm based rules engine. Nevertheless, there is a lot of value in using some standardized way of rule representation and interfacing with rule engines (or simpler rule management systems).

    So the question is - what does a rule engine that does not depend on the presence of a domain object model look like? How would one go about implementing such an engine?

    Vijay
  10. So the question is - what does a rule engine that does not depend on the presence of a domain object model look like? How would one go about implementing such an engine? Vijay
    If we look back at history, there are several examples of this. The most obvious is to translate business process rules as sql stored procedures. The real catch is for large databases and distributed processes. In my biased thinking, if your business logic can be handled by summary tables and the application doesn't need to compare many objects, stored procs are probably sufficient. This obviously depends on the requirements.

    Where a rule engine comes in handy is when you have multiple database models, which are beyond your control. In those cases, you need a domain object model that covers the concepts across the different db models. Most people do not have these kinds of requirements, but those who do, often need to persist the data in a reliably way after the application has performed different business logic. The traditional approach is to write an application with hardcoded business logic. In cases where it is appropriate, encoding those rules in a Rete rule engine will be significantly faster.

    The easiest example I can think of is this. Say I have a distributed transaction that hits 4 different database, each with different models. Each database has validation rules and constraints the transaction has to satisfy. If I encode those rules in a procedural manner, each attribute of the object would be evaluated multiple times. Regardless of whether or not a given rule applies, it might evaluate it only to find out it doesn't apply. Using a Rete rule engine, each object would be evaluated once and only once. This is because Rete is simply an algorithm for building an index tree. Rule conditions are compiled to nodes. Each node maintains an index. When ever attributes of one object are compared to another object's attributes, a join node is used to link the conditions. I would suggest reading Forgy's paper from the 80's to get a good understanding of exactly what Rete does.

    If you want to get a good overview of Rete, Jess In Action provides a good introduction to rule technology. If I rephrase your original question "what does a rule engine that does not depend on the presence of a domain model look like?" I would say it's not possible. The only difference between a relational db model and domain object model to a rule engine is how the pattern matching occurs. In a db, you could write an embedded module to reason over the stream. But you could just as easily reason over an object as a stream using an embedded rete rule engine. I believe in the 90's IBM had a business rule product that converted business rules to sql/stored procedures. It never really took off, and was eventually dumped if memory serves me correctly.
  11. The traditional approach is to write an application with hardcoded business logic. In cases where it is appropriate, encoding those rules in a Rete rule engine will be significantly faster.The easiest example I can think of is this. Say I have a distributed transaction that hits 4 different database, each with different models. Each database has validation rules and constraints the transaction has to satisfy. If I encode those rules in a procedural manner, each attribute of the object would be evaluated multiple times. Regardless of whether or not a given rule applies, it might evaluate it only to find out it doesn't apply. Using a Rete rule engine, each object would be evaluated once and only once. This is because Rete is simply an algorithm for building an index tree. Rule conditions are compiled to nodes. Each node maintains an index. When ever attributes of one object are compared to another object's attributes, a join node is used to link the conditions.
    As I understand it, Rete algorithm based rule engine are useful only if you have the following conditions:
    - many domain objects
    - many rules
    - rule interedependence and chaining i.e. the firing of a rule affects the sta e of objects, which in turn requires the firing of some rules, which in turn affects the state of objects, which in turn... and so on. This results in complicated graphs that cannot be evaluated efficiently without a Rete like method.

    However, from my experience in this domain (perhaps limited), it seems to me that many customers buy and implement rule engines without really having a need for a sophisticated Rete algorithm based rule engine. A classic example of this is the application of rule engines in "shopping cart" type applications for commerce on the Web. There is no performance improvement in this scenario. In fact you may have more overhead. You can never come close to the performance stored procedures can give you. However, even in this case, I still see value in an enterprise standardizing on the way it defines rules, and in externalizing the rule definitions by separating it out from other business logic.

    Vijay
  12. A classic example of this is the application of rule engines in "shopping cart" type applications for commerce on the Web. There is no performance improvement in this scenario. In fact you may have more overhead. You can never come close to the performance stored procedures can give you. However, even in this case, I still see value in an enterprise standardizing on the way it defines rules, and in externalizing the rule definitions by separating it out from other business logic.Vijay
    hehe, I blame sales and marketing guys for that one. The funny thing is, people often use shopping carts examples during the sales pitch, because it is easy to understand. From a practical perspective, actual shopping carts are small objects that really operate by itself and doesn't need to be compared to other carts. A case where rule engine would be useful isn't for discounts, but for recommendation engine. Say you want to recommend other items or related items to a user as they shop. In that case, you would need to compare the contents of the shopping to the catalog and the user's purchase profile. In those situations, trying to achieve it with either stored procedures or a procedural rule engine would be considerably slower.
    But even then, you don't need a rule engine, if you tackle that problem in a overnight batch process using data mining techniques. The data mining approach in some cases may be impractical, or generate poor recommendations. Again, I tend to look at the requirements to figure out if it really is needed or beneficial. In the previous example of a complex distributed transaction with complex rules, handling that procedurally in stored procedures would be impractical, since triggering a stored procedure from one database to a remote database may not be feasible. I know of plenty of cases where the commit threshold depends on some fairly complex dependencies, so in those situations, it would be clear and more efficient to encode the rules using a Rete rule engine. Of course those kinds of cases are extreme and not common to the typical online retailer.
  13. Good Point Vijay!

    However, SQL or PL/SQL development is no place for "Business Rules"!

    Learn why, by reading this article:

    http://techrepublic.com.com/5208-6230-0.html?forumID=9&threadID=164296&messageID=1686053

    The bottom line is, as great as SQL is, it is not a general purpose development language! SQL is best used for persisting and retrieving data. When relied upon to perform business logic, or more specifically to try to emulate the functionality of a good inference rule engine, the results are always a whole lot of stored procedures and the use of temporary tables. This approach only leads to hugh software maintenance costs, year-after-year!

    In large enterprises, we all understand the issue and importance of performance. In the TechRepublic article above, the final result was an everyday insurance eligibility process written entirely in Oracle 9i stored procedures, being reduced from an average of 6 hours per day to an average of 10 minutes per day!

    The combination of POJO's, XML, and Oracle PL/SQL technologies accomplished this performance improvement.

    The significant added benefit was lower software maintenance. The Java Components were course-grain and non-specific and the Java inference rule engine was highly optimized. The specifics of the current business policies, industry regulations, data integrity and validations, process-related steps and workflow, were all persisted in XML rule-sets. Oracle PL/SQL did what it was designed to do best, retrieve and persist data very efficiently when directed by the XML business rule.

    It is a huge advantage in software development and software maintenance to use the proper technologies and disciplines appropriately, resulting in higher performance and lower costs. By using the above approach, the Oracle PL/SQL only needs changing if the data model changes. The POJO's involved almost never change, and the business logic and functionality specifics of any domain, are changed only in one or more rules or rule-set when a change is required.
  14. Details of Rule Engine solution[ Go to top ]

    Hi
    Would it be possible for you to share some details of your solution. I'd like to know how many rows did you process using your rule engine in the 10 min duration, how you managed the network cost of retrieving and persisting information from the database, and how many rules did you typically have to apply on each row.

    Thanks
  15. Details of Rule Engine solution[ Go to top ]

    HiWould it be possible for you to share some details of your solution. I'd like to know how many rows did you process using your rule engine in the 10 min duration, how you managed the network cost of retrieving and persisting information from the database, and how many rules did you typically have to apply on each row.

    Thanks

    I don't know about the case above, but I have seen cases where a database driven approach was 10x slower than using a general purpose rule engine like JESS. one of the issues limiting database driven business processing is handling it incrementally. Say you have a business process that collects several screens of data from a user, which trigger other business processes. In a simple case like processing loan applications, the user fills out the form, and submits the information.

    After that, the system may need to get the user's credit information, since the loan processing can't continue without that. After the information is retrieved, the user may need to verify it is accurate. If one did this using database, the steps might look like this.

    1. save user data
    2. db trigger runs stored proc
    3. stored proc inserts a row into GetCreditRating
    4. some external business process would need to constantly poll the database and see if there are entries in the table
    5. the process gets the user's credit rating and save it to the db
    6. another trigger checks to make sure rating meets the minimum and then categorizes the user
    7. a row is insert into another table
    8. yet another business process monitors the tables to see if it should send an email to the application and sends an email
    9. the user recieves the email and verifies it
    10. the system saves the verification and changes the state of the application
    11. another trigger sorts the application by category based on 2 dozen rules.
    12. the loan officer looks at the application and contacts the person

    A real loan processing application does much more than this, but it should provie a rough picture. The first thing about using a database for this type of application is it impacts the database and reduces it's ability to handle transactions. The second is you're making the database store a lot of temporary information which need to be update/deleted as the application goes through the process.

    Now, consider a business may need to process several hundred applications per day along with all the other normal database work. It makes sense to off load the business process to a rule engine. Then again, I'm bias :)

    if you look on ACMQueue, you'll see plenty of papers that go into detail why database driven rules generally do not scale as well as using a rule engine.

    peter
  16. rules vs objects[ Go to top ]

    Joost,

    This is a good question, and I think is similar to the "Rules in Large Enterprise Business Applications" question.

    What I often see is that people use a mixture of these two approaches. For attributes that are quite static (change less than once per year?) they will be encoded into the Object Model (OM) for easy access by programmers. For more dynamic data (data in a user profile perhaps) these will be coded using a Record Set approach using name/value pairs or something similar. This allows new data to be fed into the rules without making major code changes.

    In JRules, and other engines, you can drop a Business Object Model (BOM) on-top of the Java OM -- which acts as an abstraction layer over the Record Sets. This allows the business users to see these name/value pairs as "real attributes" on "real classes" when they are authoring rules.

    This mapping from the BOM to the eXecutable Object Model (XOM), as it is called in JRules, is a very powerful feature that insulates your business rules from XOM changes and allows you to make different modeling choices for authoring and execution.

    Sincerely,

    Dan
  17. rules vs objects[ Go to top ]

    Hi Joost,

    I think rules should be built upon the domain model. So both concepts are not mutually exclusive; on the contrary, they are complementary.

    Still, rules should not be directly attached to domain objects. The best way to organize them, in my opinion, is to group them into rule sets attached to "rule owners". Such rule owners can be seen as objects at a higher abstration level, objects that have an antropomorphic role associated with them, as well as a capability to act independently from each other.

    The actor programming model, developed by Carl Hewitt and his colleagues, is a good example of how those higher-level objects could be implemented. Please see, for instance:

    http://www.jot.fm/issues/issue_2004_07/column1

    My own article includes a concrete implementation:

    http://www.theserverside.com/articles/article.jsp?l=RuleBasedMDB

    Hope this helps,

    Cris
  18. Thank You[ Go to top ]

    Daniel,

    Thanks for creating the rules site!

    Here are some questions:

    1. Do you plan to provide educational and lessons-learned articles on the site? For example, given that you and Jason Howes built a commercial rule engine, I'd be interested in reading your thoughts on the merits and limitations of the RETE algorithm in a J2EE environment.

    2. Will you be providing or sponsoring head-to-head comparisons of Java rule engines?

    3. Will you be limiting the site's content to RETE-related topics or will you also include content for constraint enforcement algorithms and engines?

    4. Although your domain name includes the word "java", will you also be willing to include content regarding .NET implementations?

    5. Are you using rules in any way within the javarules.org site implementation? If so, how?

    6. Lastly, your site looks nice. Are you using a publicly-available framework? If so, what framework are you using?

    Thank you again for taking the time to build such a nice site.

    Doug Dew
  19. Thank You[ Go to top ]

    Hi Doug!

    1. Yes I hope to contribute some "integration architecture" articles within the next couple of months. The site is very much open however and I welcome everyone to come and share their experiences.

    2. Possibly. Rule engines are remarkably different (as we both discovered through JSR-94!) so first I think we all need to come to a better understanding of the types of rule engines and how they can be meaningfully compared.

    3. Constraints are not my speciality personally, but I'd be interested in learning more from the constraints community. In the general sense people talk about "constraint rules", and indeed many of the problems I see customers struggling with (using a forward-chaining engine) are often constraint or optimization problems in disguise.

    4. Sure, why not? Those guys need some help! ;-) Seriously, MS is doing some very interesting work with rule engines and domain vocabularies for business people.

    5. No, I don't believe so.

    6. It is more or less a vanilla install of PostNuke (an OpenSource PHP-based CMS)

    Drop me a line.

    Sincerely,

    Dan
  20. Thank You[ Go to top ]

    Daniel,

    Thanks for your answers.

    It seems to me that as an employee of ILOG you should be able to provide a broad and helpful perspective to javarules.org. For example, although you claim that constraints are not your "specialty", I suspect that you could leverage your ILOG environment to provide guidance to javarules.org readers who aren't sure whether they should be using rule engines or constraint engines to solve their problems.

    Anyway, I look forward to visiting javarules.org on a regular basis.

    I'm going to be out of Internet contact for a few days, but will drop you a line once I get back.

    Doug