Given that you’re using Spring MVC, this might be a reasonable example: https://github.com/gratiartis/sctrcd-payment-validation-web It has examples of doing this for a simple validation, with a stateless session. i.e. Request goes to Spring MVC controller. Controller invokes a service bean, which wraps a knowledge base. Rule based validator inserts a fact and executes rules. Rules may or may not set an ‘isValid’ flag on the request. They may (or may not) also annotate that request fact to indicate which rules are rejecting it and why. The rule based validator returns a result object to the service. The service returns a result object to the controller. The controller returns a JSON object to the client. Hopefully it’s not too difficult to find your way around the project. To try it out: git clone https://github.com/gratiartis/sctrcd-payment-validation-web cd sctrcd-payment-validation-web mvn clean install tomcat7:run curl http://localhost:9090/iban/validate/GB29NWBK60161331926819 Change a couple of characters in the IBAN on another curl to see a rejection. btw - If anybody else fancies taking a look at it, please feel free to send criticism back to me. Either directly or to discuss on the mailing list. There’s so little out there in the way of documented good practice for using Drools, that I get the impression that everyone just finds their own way. So I would be happy to hear what others feel could be done to improve my little Spring MVC/Drools demo project. Steve On 9 Nov 2013, at 09:24, forsakendoll <forsakendoll(a)hotmail.com&gt; wrote:

That’s a balancing act I’m struggling with. I’m trying to make it a reasonably full-featued web application, but at the same time, I’m trying to keep it simple enough to use for demonstrating things. Unfortunately, those aims often feel mutually exclusive. But I certainly need to add more explanatory comments. There are some areas of the application where I haven’t done much commenting. This is the controller class with the @Controller and @RequestMapping annotations in it: https://github.com/gratiartis/sctrcd-payment-validation-web/blob/master/s... You should see in there that there is a mapping for an IBAN validation request: @Override @RequestMapping(value = "/iban/validate/{iban}", method = RequestMethod.GET, produces = "application/json") public @ResponseBody IbanValidationResult validateIban(@PathVariable String iban) { IbanValidationResult result = ibanValidator.validateIban(iban); log.debug("Validated IBAN: " + result.toString()); return result; } That invokes an IbanValidator, which in this case has been injected with the “ruleBasedIbanValidator”: https://github.com/gratiartis/sctrcd-payment-validation-web/blob/master/s... That particular validator is a Spring @Service. It constructs a knowledge base in its constructor, because Spring will instantiate it on start-up, and ensure that there is only one instance. The validateIban(iban) method in the RuleBasedIbanValidator creates a new stateless session for the knowledge base. It creates an IbanValidationRequest fact, which it inserts into the session and causes rules to fire. As you might see in the constructor for the IBAN validator, the rules are in here: https://github.com/gratiartis/sctrcd-payment-validation-web/blob/master/s... That contains rules such as this: rule "IBAN failed the Mod-97 checksum test." salience 100 when $req: IbanValidationRequest($iban:iban) not PaymentValidationAnnotation( attribute == PaymentAttribute.iban, level == AnnotationLevel.REJECT, ruleName == "IBAN failed the Mod-97 checksum test." ) eval(!IbanMod97Check.isValid($iban)) then insert( new PaymentValidationAnnotation( drools.getRule().getName(), AnnotationLevel.REJECT, "The IBAN is not valid.", PaymentAttribute.iban ) ); end That rule will activate if the IBAN is not valid according to a standard "Mod-97" check. In the case of it activating, it will insert a PaymentValidationAnnotation fact. This is a simple object to note that the request has been rejected, and indicates why. Whenever an annotation is inserted, the “Derive most severe IBAN annotation” rule might fire. This will update the “mostSevereAnnotation” property of the original IbanValidationRequest. Similarly, the “RejectIBAN request if there is an IBAN rejection annotation” rule will set the “isValid” property to false if the request has has a rejection raised against it. Going back to the RuleBasedIbanValidator, once the rules have executed, all I do is look at the IbanValdiationRequest that was inserted into the session. I use the contents of that to create an IbanValidationResult which just has a flag to indicate whether it is valid and contains a list of annotations. That gets returned to the controller. Finally the controller, returns the IbanValidationResult. Because it has a @ResponseBody annotation and the project includes a dependency on Jackson, that result will be converted to JSON automatically. Hence, firing a valid IBAN at the service, I’ll get: {"annotations":[],"iban":"GB29NWBK60161331926819","valid":true} … and firing an invalid IBAN gives me: {"annotations":[],"iban":"GB29NWBK6016133192681","valid”:false} … which shows that it’s not working right! It’s working out that the IBAN is incorrect, but the response is not including the annotations. Time for me to do a little bit of debugging. :) Anyway, I hope that’s a useful walkthrough. Feel free to fire more questions at me. Steve On 9 Nov 2013, at 11:28, forsakendoll <forsakendoll(a)hotmail.com&gt; wrote: