I am exploring different ways to create a simple business rule engine in Java. I need to present the client with a simple webapp that lets him configure a bunch of rules. A
I would suggest using something like Drools. Creating your own custom solution would be an overkill because you would have to debug it, and still provide functionality certainly less than the one provided by a rule engine like Drools. I understand that Drools has a learning curve, but I would not compare it with creating a custom language, or a custom solution...
In my opinion, in order for a user to write rules, he/she would have to learn something. While I suppose you could provide for a language simpler than the drools rule language, you would never capture all of his/her needs. Drools rule language would be simple enough for simple rules. Plus, you could provide him/her with a well formed documentation. If you plan to control the rules created by the end user and applied on the system, then perhaps it would be wiser to create a gui that would form the rules applied on drools.
Hope I helped!
You're setting yourself up for failure for two major reasons:
Solving 1. is either going to push you into the fuzzy domain of NLP, for which you can use a tool like OpenNLP or something from that ecosystem. Because of the large amount of subtly different ways the user can write things down you will find your thinking skew towards a more formal grammar. Making this work will end you up in a DSL type solution, or you'll have to design your own programming language.
I've had reasonable results using Scala parser combinators to parse both natural language and more formalised grammars. The problems are the same, but the code you have to write to solve them is more readable.
Bottom line, even if you're thinking of a very simple rule language, you're going to find you underestimate the amount of scenario's you have to test for. NeilA is right to advice you to reduce the complexity by creating a proper UI for each type of rule. Don't try to be too generic, or it will blow up in your face.
Rather than build your own rules engine, you might want to consider the Open Source N-CUBE engine, an Open Source Java rules engine that uses Groovy as the Domain Specific Language (DSL).
It is a sequential rules engine as opposed to a non-sequential rules engine like a RETE-based rules engine. The benefit of a sequential rules engine is that it is much easy to debug the rules. Trying to decipher inferences from really large rule sets can be very difficult, but with a sequential rule engine like N-CUBE, tracing the rules is very similar to following sequential 'code logic'.
N-CUBE has built-in support for both Decision Tables and Decision Trees. The Decision Tables and Trees within N-CUBE allow data or code to execute within the cells, very much like a multi-dimensional Excel. The 'macro' language (DSL) is Groovy. When writing code within a cell, you do not need to define a package statement, imports, a class name, or function - all of this is added for you, making the DSL code snippets easy to read / write.
This rule engine is available on GitHub at https://github.com/jdereg/n-cube.