I'm in the process of doing something akin to what you want to do.
Since these business rules would be very often by the business, I would want the business to make necessary changes to the rules via GUI.
WARNING WARNING WARNING!!! It's a common misconception that as long as there's a GUI, non-programmers can use it. That's... not the conclusion I've come to. It helps, but the hard part of programming isn't writing code, it's coming up with good solutions to the right problems. I'm certain some of the more intelligent and technically inclined business folks can do stuff with Guvnor, but don't expect it to be some kind of yellow brick road to the Land of Magical Bliss. You still have to provide the business people with a sane data model and API which lets them do what they need but which prevents them from doing by accident what they don't want to do.
1. Does Drools support a lightweight GUI for editing the rules?
2. Is Drools Guvnor a lightweight GUI, or is there are a way to step it down?
Well, "lightweight" is subject for discussion, but Guvnor works fairly well and doesn't require more than a browser, so I think it's OK.
3. How easy to integrate an application to Guvnor to read the rules?
Well, once you've got Guvnor up and running, wiring up your application to use a KnowledgeAgent to connect to Guvnor and listen for new rule updates isn't particularly hard.
Unfortunately, Drools in general and Guvnor in particular has a bunch of quirks which you may have to work around (for instance, you have to explode the Guvnor WAR file and edit files in WEB-INF/beans.xml to set up a non-default configuration...). But once you've got that straightened out, I think it works pretty well.
As for documentation, the Javadocs can be a bit sparse at times, but the web site has some pretty good stuff, and including several books.
All in all, Drools and Guvnor are powerful tools, but it's not trivial to get them working. If you really need what they have to offer, they're worth it, but it might also be worth considering if a simpler scripting solution will suffice.
Now, if you find yourself actually needing Drools, here's my top piece of advice - keep separate data models for your database and your rules. It does mean there's a lot of boring conversion code to write, but it's well worth it.
The app I'm working on uses JPA for database matters, and it wouldn't have been very pleasant to use that data model in our rules. Several reasons:
What's fits your data layer doesn't necessarily fit Drools, and vice versa.
We have a tree structure, which in JPA naturally is a @OneToMany relation with the children in a list in the parent node. Working with lists in Drools was rather painful, so we flattened it to a structure where we insert one ParentNode object, and a bunch of ChildNode objects, which was far easier to work with.
Dare to refactor.
The rule's data model needs to live inside of Guvnor, too - and that means you could break all rules if you rename an entity class or something like that. A separate data model for rules means you can refactor your database stuff without worries.
Show them what they need to see.
Databases can grow fairly complex, but the rules normally don't need to care about many of these complexities. Exposing these complexities to the people editing rules can cause a lot of unnecessary confusion. For example, we've found that for our scenarios, there's absolutely no need to expose rule writers to many-to-many relationships (which proved very complicated to handle in Drools) - so we make them look like one-to-many instead, and everything becomes more natural.
Protection.
We've designed most our rules to work like this pseudo-code:
rule "Say hello to user"
when
user : User
then
insert(new ShowMessageCommand("Hello " + user.getName() + "!"))
end
... and so, for each rule package, it's clearly defined which response commands you can insert, and what they do. After we've run the rules in our app, we pick out the objects inserted into the session by the rules and act upon them (the visitor pattern has proven very useful to avoid long if instanceof/else if instanceof/else chains).
I'm very happy we did it this way, instead of letting the rule writers do whatever they think they want to do with our JPA objects.
Anyway, hope this helps.
