N. Alex Rupp has started a new column, Ruling Out
, on rule engine technology. In this first introductory article he discusses why we have rules engines, the standards behind them, developing with them, and a declarative programming example.Ruling Out: Rule Engines and Declarative Programming Come to JavaThere seems to be a lot more movement in the rules engine world on the Java space, which is great to see
the article provides a good introduction to rule engine technology. for me, one of the best examples of how "imperative" programming fails to scale well is the classic chess game example. If a person had to code a chess game procedurally, the game would be very easy to beat. Once you figure out which paths in the logic tree the game doesn't understand, beating it is trivial. Although AI has gotten a bad reputation from the 80's, the technology is mature and used in numerous financial and insurance systems. A real world example would be changing SEC regulations. Many companies cannot handle the rapid changes in SEC regulations, because their rule engines were designed to process rules procedurally. Rule engines like JESS, iLog JRules, Blaze Advisor and Drools take advantage of RETE algorithm to make rule evaluation efficient and flexible.
I was just curious how the Prolog language fits into this. Perhaps using standard rule APIs in the JSR (if they exist) you can plug in a Prolog compiler and write all your logic in prolog with some extra methods to get some data from the existing object data structures?
There may be a few prolog programmers still out there than can do all the expert system development for the problem domain and separate them from the actual java development itself.
Assuming Prolog processing is fast as they say RETE is.
Prolog (a language) is based on backward chaining while Rete (an algorithm) is based on forward chaining concept. This means that Rete will tell you which rules fired given the facts while Prolog will tell which facts were required to fire a given rule.
Jess - a Rete implementation - provides a backward chaining facility but its not as fast as its normal execution (forward chaining).
Actually there is a Prolog derivative called Prova that can do what you are asking about. It is based on the open source mandarax rules engine (and now part of it).
I agree that this article is a really good introduction to
I was trying to apply the declarative approach to one problem in the knowledge representation area, and the problem I ran into was unsuitable semantics of today's frameworks. At first sight the semantics of rule systems seems straightforward, but in reality it is not, especially when you start to consider negation and concepts such as overriding default behavior or priorities. Many theoretical approaches have been described, but not all are simple and intuitive enough, and very few are actually implemented. My hope is also that using a declarative approach for my problem could actually improve the performance of the solution (which is now handled imperatively), and that's even harder to satisfy, given the reputation of declarative implementations, which are often much slower than imperative languages. I ended up implementing my own rule engine, but I am not really satisfied with it. So I am still looking for suitable semantics of the framework and efficient implementation algorithms.
Just an ide . I may be easy to define rules in a XML file. Rule engine can read XML file and the act accordingly .
I have used JESS in the past, and was really happy with it. I started out implementing with JSR-94, but found it to be limiting, and honestly questioned its value. It removed me too much from the power of the underlying JESS rules engine. I felt it dumbed down my API too much, so I used the native rule API instead.
(About JESS... The author of the software has a great book that will get you started. JESS is not free for commercial use. I have not had a chance to try out drools, but am looking forward to it.)
The goal of JSR-94 is the ability to plug rules engines. But the reality is if you change rules engines, 90% of your effort will be in recoding your rule base. Changing the interface to you application is the least of your concerns. So there really is not much advantage there.
I would highly recommend people try a rules engine, if just to learn the interesting logic they use. JSR-94 is fine, but done be afraid to chuck it as I did. Results matter, not standards. ;)
There is a discussion here about the future evolutions of JSR-94:http://www.javarules.org/modules.php?op=modload&name=News&file=article&sid=16
I'd encourage anyone with ideas to contribute to the debate. We will shortly be open up the Expert Group and defining the charter for the next version of the specification.
(JSR-94 spec. lead)
If I remember correctly, the JSR was originally initiated by BEA and the RuleML group. It stalled for over a year when the lead at BEA left and someone else took the lead on JSR-94. I also remember that BEA used to use iLog JRules.
When JSR-94 first started up, there was a proposal to include a standard rule markup, but it was rejected. There was also a suggestion to standardize on Rete engines, but no agree could be reached. Therefore, the current JSR-94 looks pretty useless and borrows heavily from EJB concepts. In my mind, there needs to be a light weight rule api that describes the process of loading the necessary objects, facts and rulebases. The administration of the rule engine can remain separate and should. Regardless of the rule engine, there are common operations which are needed. Loading object definitions, loading base data, creating modules/components, loading rules and executing rules.
in my mind, it is feasible to define a generic rule deployment API that is more useful than the current spec, but still lets each company implement it their way.
Disclaimer: these comments are mine and are not approved by BEA or any of the other JCP members.
I used to be a staff engineer and later a program manager for BEA, but left BEA in 2003. While employeed as a staff engineer, I authored and submitted the JSR-94 proposal to the JCP and I was the original spec lead for the JSR-94 EG. As such, any stalling or lack of progress during the initial months of the JSR effort was my fault.
Here are some facts and some opinions related to the items that you mentioned:
0. In an early version of BEA's Portal product, BEA embedded ILog's JRules engine. I was the person who wrote most of the embedding code. I advocated for JRules over alternative rule engine embedding solutions, as did my boss prior to the embedding effort. I advocated for JRules largely due to the high quality of JRules, the unique usefulness of JRules' embedding APIs and most importantly, the incredibly good support that I received from the JRules engineers and the JRules product manager during my evaluation of the rule engine alternatives.
1. For reasons that it is not my privilege to discuss, after shipping a version of the Portal product with JRules embedded, BEA decided to replace JRules with its own, homegrown rule engine in the next version of the portal product. For the most part, Daniel Selman and Jason Howes built that rule engine. Anyway, at the same time that BEA decided to build and embed its own rule engine, BEA also decided that it would be best to enable customers to embed rule engines of their choosing.
2. I concluded that the best way to enable customers to embed rule engines was to standardize a rule engine plug-in model, a rule engine usage model and a rule engine language. Of course, I wasn't the only person that had reached such a conclusion. I was new to the rule engine domain and there were genuine rule engine experts who had thought of the standardization idea long before I had. For example, the RuleML group that you mentioned had given consideration to the idea long before I had.
3. I convinced my bosses (sometimes, lots of bosses get involved in a JSR decision) that BEA should submit a rule engine JSR. So, on behalf of BEA, I submitted JSR-94 for approval. This was BEA's first-ever JSR submission. And JSR-94 was my first-ever JSR submission. I mention this not to brag, but to give me an opportunity to point out that I was a JCP novice, and that by being a novice, I was not the best possible lead for the JSR-94 EG. However, as I learned, sometimes the strength of the lead is not as important as the strength of the lead's sponsoring employer.
4. I learned a bit about the JCP during the discussions that lead to the approval vote for JSR-94. Among the things that I learned was that some powerful JCP members had widely divergent visions of the JCP. In particular, I learned that some powerful JCP members did not believe that the JCP should be used as a basis for innovating, but should instead be used merely as a basis for capturing mature technologies in specifications. I mention this because originally I had proposed in the JSR to create and standardize the rule engine language that you mentioned. During the pre-approval discussions, more than one powerful JCP member made it clear that they would vote against the JSR not only because they thought that the *Java* Community Process was an inappropriate forum for creating *languages*, but also because they believed that the JCP should only be used to harvest mature technologies, not create new ones. In order to gain the approval votes of those members, I removed the rule language from the scope of the JSR. At the time, I was upset about the vision of those JCP members. But over time, I've thought about their vision a lot, and have actually come to the conclusion that I agree with them. In other words, I believe that they were right and that I was wrong about the scope and best use of the JCP.
5. The EJB-ness of JSR-94, at least initially, was due to a few factors. Other members of the expert group might have different opinions, but I believe that the EJB-ness of the initial JSR-94 thinking was due in part to technical considerations, and was also due to business considerations. EJB-oriented vendors were heavily represented in the original expert group membership and I'm sure that you can guess how such orientation might influence the thinking of an expert group. I should add, however, that at least one member protested that the rule engine API should be a lightweight API that could be used outside of the context of a J2EE appserver, which seems to be consistent with your opinion.
6. The question of how rule base loading should be supported or not supported was, in my opinion, the biggest initial source of disagreement among the expert group members. I can't speak for the other members, but I can say that I totally agree with you that JSR-94 should have said more about rule base loading. When I had embedded JRules in the early Portal product, I implemented an on-demand model for loading rule bases that I borrowed from the JSP on-demand loading model. I advocated for a similar model within the expert group, as well as even more aggressive loading models (e.g. file-based rules embedded within J2EE apps and rules embedded within in-flight document messages). However, as I learned during the initial JSR-94 effort, most traditional rule engine folks thought of rule bases as distinct, stand-alone databases that were loaded and un-loaded without regard to J2EE application lifetimes. In other words, some of the other JSR-94 EG members seemed to think that my ideas were naive or just plain wacked. Perhaps they were. As I said, I was new to the rule engine domain and so lacked the years of experience that some of the other EG members had. But, I was never very comfortable with the model of rulebases as a sort of stand-alone brain. That model always reminded me of that episode of Star Trek where Spock's brain is removed from his body and placed in a glowing orb ;-). Comedy aside, I had already learned the usefulness of on-demand loading from my embedding efforts, and I didn't want to reduce the functionality of the BEA Portal product simply to support another EG member's view of how rulebases should or should not be loaded. Such reduction-in-functionality issues are probably typical for EG members attempting to standardize features of shipping products. Anyway, I forfeited the right to advocate for loading/un-loading functionality in JSR-94 because...
7. Shortly after initiating the JSR-94 effort, I changed jobs within BEA and was no longer working on rule engine stuff as part of my day job. As a result, I neglected to pay sufficient attention to the JSR-94 effort. For several months, the JSR-94 effort languished and I'm reasonably sure that some of the EG members concluded that the JSR-94 effort was a waste of time as it was not going to go anywhere as long as I was the spec lead. If so, they were justified in their thinking as I really did let the EG down. Fortunately, Daniel Selman eventually bailed me out and took over leadership of the EG to get things back on track. However, during the time that JSR-94 was languishing we lost some of the interest and participation of some of the EG members. Who knows, JSR-94 might have been different if it had not been allowed to languish for those early months.
8. Daniel Selman can provide you with a lot more information about the "why" and "why nots" of the JSR-94 spec that finally shipped than I can. I recommend that you ask him any detailed history questions that you might have.
thanks for providing more details into the history of JSR-94. Since I am not a member of JCP, please excuse the inaccuracies of my earlier post. I'm definitely biased, but even if someone wants to plug a procedural rule engine into a servlet or ejb container, the same deployment concepts should apply.
I'm optimistic the rule engine API can improve and make developing/deploying rule technologies consistent. It may not be easy, but it can be easier and consistent.
Thanks for the background info. A few points:
One of the ideas we have is to establish a strong meta-data api (similiar in concept to that provided by JDBC). This would allow products such as Portal Servers to embed different rule engines with a simple adapter. Of course, a standard rule language with standard semantics would also have to exist for this vision to be achieved.
A rules engine sitting outside of a J2EE app server does make alot of sense. Also, a calling client application should not care if the application is within a J2EE server or a Spring container or its own JVM. However, I am not sure how much lighter it would be.
Within the JSR community we did learn lessons from EJBQL etc. about inventing new languages. But, for this JSR to meet its goals, a standard language with standard semantics is needed. You cannot have portable rules without this.
Doug,Thanks for the background info. A few points:One of the ideas we have is to establish a strong meta-data api (similiar in concept to that provided by JDBC). This would allow products such as Portal Servers to embed different rule engines with a simple adapter. Of course, a standard rule language with standard semantics would also have to exist for this vision to be achieved.A rules engine sitting outside of a J2EE app server does make alot of sense. Also, a calling client application should not care if the application is within a J2EE server or a Spring container or its own JVM. However, I am not sure how much lighter it would be.Within the JSR community we did learn lessons from EJBQL etc. about inventing new languages. But, for this JSR to meet its goals, a standard language with standard semantics is needed. You cannot have portable rules without this.Regards,Manoj.
I would agree 100% a standard markup language is needed. Hopefully either the W3C can come to an agreement or one of the other standard bodies like OMG or Oasis can tackle the challenge. Whether the JCP should be the place for it isn't totally clear in my mind. I would hope it would include other platforms and be inclusive.
I don't know that this is any fault of JSR-94 itself. I found the spec to be rather sensible. The challenge in this space is similar to what you find in lots of the JSRs. The more complex the problem becomes, the more varied the products that offer them, the more "irrelevant" a standard becomes - even a very good standard.
JSR-94 is no EJB, it is a sensible spec.
JSR-94 a good job at sending Java objects in and out of the rule working memory. I drew from this model to create my own wrapper around JESS, using a HiveMind
service to create a rule session.
Its a real judgement call. I have found that the power of the native apis is much greater, and the benefit of "pluggablity" with JSR-94 is dubious. I don't know that it is a fault of the spec itself, as much as the weakness of a having a spec for a complex problem. It is not an easy task.
I agree, for example Rulesharp has a back door that is far much better then jsr-94. One line of code, can't beat that.
Also I think rulesharp is better because jess , jrules , blaze , haley , etc are not that easy to use and integrate and do much more then just rules overlapping with other coding.
check it out for yourself at: www.rulesharp.com
Has anybody used Mandarax in production? http://mandarax.sourceforge.net/
It's been around a while, and looked pretty good when I looked at it briefly about a year ago, so I'm interested in any comments from people who've actually used it for a real app.
For people familiar with Rule Engines, Rule engines sually come as libraries or components, I had the chance to implement rule engine systems on top of JavaSpaces as the run-time and container for the rule engine, as well as communication, subscription and delivery platform. The rule engine I implemented is XML based, using XPath queries and XPath based subscription. The result is realy good in terms of performance, scalability and flexibility.
I will be more than happy to provide the XML rule engine sample and information to people interested in this.
Avi, Sound very interesting. Could you email me on dselman [at] javarules.org with the details -- or write a little article and post it on www.javarules.org?
I would be very interested in receiving a sample of your XML-based rules engine. If possible, please email to: dshah at sloan dot mit dot edu. Thanks.
Can you send me information on your XML based rules engine to austin at poeticdata dot com. Thanks.
I am currently interested to try out your rules engine. Could you please send me the rules engine implementation to abhilashk dot cse at gmail dot com.
I would be very interested in checking out your XML rule engine code. The concept could be very helpful on a project I'm currently working on. Could you please send to rizzo dot m at comcast dot net ?
I am by no means an expert on rule engines, but I have seen them used in powerful ways, in particular in financial applications. However, in "vanilla" Java development, I'd be a bit more careful about using them. First of all, you are very likely to be tied in with a particular vendor/supplier of your rule engine quite quickly.
Because such tools usually depend on some basic libraries, say for logging, persistance etc. you will very easily get some serious version dependencies into your code - as is of course the case with any "large" third party library, so not much of a surprise here. Then of course rule engines will usually require the design of a domain specific language. On its own this is of course not bad at all - in fact it is one of the nice things of declarative programming - but again I believe in keeping the number of languages as low as I possibly can in any system. Then rule engines have sort of a "problem", that is people, a lot of people, especially those doing occasional maintenance do not really understand how they work or in other words, can't guess the outcome of a certain set of rules. And finally I am not really convinced of rule engines that I have seen delivered as part of various ecommerce products.
The basic demonstration of showing the "gold campaign content" to the "gold customer" is nice, but is this something that can be easily generalized to any business case? I rather doubt it. But maybe it is just because the right "domain specific language" has not yet been defined.
For example there are some excellent examples where I like rule engines, in particular where they augment something, that people are somewhat used to do with rules. For example advanced access control is something that I can readily endorse. So maybe it is just that may way of thinking has not opened up enough to appreciate the principle in other areas as well...
If you are interested in experimenting with Rule engines, there are a several of them that are implemented for the Java platform. You can find this list here:http://www.manageability.org/blog/stuff/rule_engines
I once spent three or four months on Rule language programming. My job was well done. The disappointment was that my ruleset never reached the goal of well maintainence and extension as we declared. I could sense the power of rule language, but don't how to manipulate the power.
For the rules I use XPath, it is very easy, intuitive and standard, For the actions, I use plain Java or JMS destinations that activate MDB's on J2EE servers.
I wonder if anyone who has experience with the new JSR-96,
or older 94 spec has used JESS? http://herzberg.ca.sandia.gov/jess/
It is essentially a java wrapper CLIPS.http://www.ghg.net/clips/CLIPS.html
I used this briefly at a bio-informatics company, but it experienced limited production time.
I agree with the person whom posted that it seems very powerful, but difficult to manage.
I wonder if anyone who has experience with the new JSR-96, or older 94 spec has used JESS? http://herzberg.ca.sandia.gov/jess/It is essentially a java wrapper CLIPS.http://www.ghg.net/clips/CLIPS.htmlI used this briefly at a bio-informatics company, but it experienced limited production time. I agree with the person whom posted that it seems very powerful, but difficult to manage.
a slight correction. JESS is not a wrapper for C CLIPS. it is a pure Java implementation and is on par with iLog JRules and Blaze. the next release will include a rule IDE plugin for eclipse. some people don't like LISP syntax, but I am not bothered by it. managing rulebases is an old problem and most people tend to go with a rule database of some sort.
Is anyone aware of any efforts to standardize on a rule definition language through JCP?
Maybe we need a separate JSR for that.
Unless there is an accepted standardization of the rule language with the ability to use a rule engine vendor of choice (and with the ability to swap one vendor's engine out and replace with another easily), you are not going to see wide-spread adoption of rules technologies in enterprise applications.
Please see item #4 of my earlier post about the "history of JSR-94."
I agree with you that a standard rule language is a prerequisite for widespread adoption of rule engines. However, I don't believe that there's much of chance that anybody would be able to get JCP approval for a JSR that includes a non-Java-based rule language within the JSR's scope.
Although I haven't given much consideration to this idea, perhaps there's some way to leverage the new features of the Java language to express rules. For example, perhaps annotations could be used to indicate that a method is a rule. Perhaps annotations could also be used to express the declarative conditions of the "If" portion of the rule. Then, the method body could be used to express the imperative actions of the "Then" portion of the rule. That probably sounds like a hack (it is), and until thirty seconds ago, I hadn't given the idea any thought at all. So, if you say that the idea sucks, you certainly won't hurt my feelings. The reason that I mention such an idea is to point out that if your goal is to include a rule language within the scope of a JSR, then you're probably going to have to do some sort of a Java-based hack. That's just the nature of the *Java* Community Process.
I see your point about not being able to get "JCP approval for a JSR that includes a non-Java-based rule language". Maybe a different body/process needs to come up with the specification. This could just be a group of interested developers and vendors without any relation to JCP and JSRs.
I can envision a "Java-like" rule language that uses Java syntax as far as possible with some other non-Java extensions. This would basically be a new language that looks a lot like Java (and therefore easy to learn for most users).
If anyone is interested in bouncing some ideas around this concept, ping me at vijay at mindspring dot com
In my (personal) opinion the root problem is not that there is not a standard rule language, it is the lack of a standard execution semantic for rule engines.
Once a standard execution semantic is defined, any number of rule languages can be easily created. We can create XML-based languages for interchange, Java-like languages for programmers, natural-language like formats for business people etc. etc.
The enabling technology required for all language standardization is a "virtual machine specification" for rule engines. This would be the foundation upon which standard languages would sit and would ensure that an "if xxx then yyy" on one engine would execute the same way on another engine. This is the point of a standard language in my view.
This is obviously a very ambitious goal but without such an effort I cannot see how else we can tackle this hard problem. Java has the JVM specification (and indeed multiple languages run on the JVM), .NET has the ECMA/ISO-standards, C/C++ has ANSI etc (500+ pages for C).