Trying to expand my comment above: I helped some coworkers in evolving and deploying a huge, ugly web application based on Struts2 / Spring and with tons of .drl files (133 files, from 500 to 3000 rows each one).
I can definitely say I'm now aware of how to NOT use Jboss Drools: presentation logic, workflow management, and so on.
Jboss Drools is not garbage. Jboss Drools is a great tool... if it's used for what it's designed: helping you with the LOGIC RULES of your application.
The problem is that often people choose which technologies need to be put into their stack basing on how these technologies seem cool, or have an high-sounding name, instead of the real need to use them, nor after some good (or at least, performed) scouting.
Drools it's not (so) quick to learn, (definitely) not quick to integrate, not (that) easy to mantain, and if it's used for the wrong purposes, it will devour weeks/months of work for results probably different (probably lower) than expected.
From the official Drools Expert documentation (there are others Drools, check them out), where you can find examples and all what you are asking in this question: http://docs.jboss.org/drools/release/5.2.0.Final/drools-expert-docs/html/ch01.html
1.2.2. When should you use a Rule Engine?
The shortest answer to this is "when there is no satisfactory
traditional programming approach to solve the problem.". Given that
short answer, some more explanation is required. The reason why there
is no "traditional" approach is possibly one of the following:
The problem is just too fiddle for traditional code.
The problem may not be complex, but you can't see a non-fragile way of building a solution for it.
The problem is beyond any obvious algorithmic solution.
It is a complex problem to solve, there are no obvious traditional solutions, or basically the problem isn't fully understood.
The logic changes often
The logic itself may even be simple but the rules change quite often. In many organizations software releases are few and far between
and pluggable rules can help provide the "agility" that is needed and
expected in a reasonably safe way.
Domain experts (or business analysts) are readily available, but are nontechnical.
Domain experts often possess a wealth of knowledge about business rules and processes. They typically are nontechnical, but can be very
logical. Rules can allow them to express the logic in their own terms.
Of course, they still have to think critically and be capable of
logical thinking. Many people in nontechnical positions do not have
training in formal logic, so be careful and work with them, as by
codifying business knowledge in rules, you will often expose holes in
the way the business rules and processes are currently understood.
The last sentence is as fake as a three dollar bill.
If you think that a Project Manager or a Secretary will change the rules without involving developers, because "they're simply rules, not Java files"... keep hoping :D
Rules need pretty good analytical skills, in addition to programming skills, and imho "Java" is pretty easier. Nontechnicals (as commonly meant by PM) generally can't master the knowledge needed to modify, nor understand a rule.
Instead, the bold point is the real value added.
If you are developing an application that handles, for example, mortgages, with mathematic rules that change every month (interest taxes, coefficients etc), then using Drools is good. You won't need to alter the logic of your application, you simply will alter the formulas and the magic will happen.
But if you are using Drools because you think it will prevent your webapp from being deployed anymore (read: to lower the costs of the release management), then you should think it twice.
I suggest at least a couple of weeks of scouting, before taking a decision; this is the kind of thing that may blow up in your hands automatically :/
From the same documentation linked above:
1.2.3. When not to use a Rule Engine
To quote a Drools mailing list regular:
It seems to me that in the excitement of working with rules engines, that people forget that a rules engine is only one piece of a complex
application or solution. Rules engines are not really intended to
handle workflow or process executions nor are workflow engines or
process management tools designed to do rules. Use the right tool for
the job. Sure, a pair of pliers can be used as a hammering tool in a
pinch, but that's not what it's designed for.
--Dave Hamu
As rule engines are dynamic (dynamic in the sense that the rules can be stored and managed and updated as data), they are often
looked at as a solution to the problem of deploying software. (Most
IT departments seem to exist for the purpose of preventing software
being rolled out.) If this is the reason you wish to use a rule
engine, be aware that rule engines work best when you are able to
write declarative rules. As an alternative, you can consider
data-driven designs (lookup tables), or script processing engines
where the scripts are managed in a database and are able to be updated
on the fly.
As a final thought, the requirements you described seem to me something pretty static, that can't evolve that much
1) User selects one object
2) User selects multiple objects
This will hardly become something different, I've never seen an application or a website handling a multiselection in a different manner between 2,3 or 10 elements. It is ==1, or it is >1.
And IF it will evolve, then you will need to change the code too;
if today you will perform one action for >1, and tomorrow you will perform two different actions for >1 && <=5 and for >5... then you will have to code those new actions too.
This is not what Drools is meant for, In My Humble, Humble Opinion.
