Jboss Drools in a Web Application
We have huge web application and we are adding new functionality to it. As it's web application, it's using Struts2, Spring frameworks.
I have googled a lot, couldn't find any tutorial of Jboss Drools usage in Web Application.
Can any one please show me working Drools Tutotial based on Web Application/Project.
Is it possible to configure Drools such that if user selects few options in JSP, based on selected options, can I fire Drools engine? By firing, I should be able to change view dynamically.
Let's say there are three products in Cart [View page]. If user selects A product, I should show him more options, If User selects both A and B, disable selecting 3rd product etc... [view controlling from Drools]
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.
链接地址: http://www.djcxy.com/p/45354.html上一篇: 电子商务网站的REST