All rules are implemented the unit tests, and we can write a validation service that our clients can access. It will define one method for validating a customer. This is the BankingValidationService interface:

/**
 * service for validating the banking domain
 */
public interface BankingValidationService {
  /**
   * validates given customer and returns validation report
   */
  ValidationReport validate(Customer customer);
}

Code listing 21: Banking validation service interface

The interface defines one method that validates a Customer object and returns the ValidationReport interface. Since, in our domain model, all objects are accessible (traversable) from the Customer object, it is sufficient to just pass this class as the method parameter. The implementation is more interesting:

public class BankingValidationServiceImpl implements
    BankingValidationService {

  private KnowledgeBase knowledgeBase;
  private ReportFactory reportFactory;
  private BankingInquiryService bankingInquiryService;
  
  /**
   * validates provided customer and returns validation report
   */
  public ValidationReport validate(Customer customer) {
    ValidationReport report = reportFactory
        .createValidationReport();
    StatelessKnowledgeSession session = knowledgeBase
        .newStatelessKnowledgeSession();
    session.setGlobal("validationReport", report);
    session.setGlobal("reportFactory", reportFactory);
    session
        .setGlobal("inquiryService", bankingInquiryService);
    session.execute(getFacts(customer));
    return report;
  }

  /**
  * @return facts that the rules will reason upon
   */
  private Collection<Object> getFacts(Customer customer) {
    ArrayList<Object> facts = new ArrayList<Object>();
    facts.add(customer);
    facts.add(customer.getAddress());
    facts.addAll(customer.getAccounts());
    return facts;
  }

Code listing 22: Section of banking validation service implementation

The implementation has the following dependencies: knowledgeBase, reportFactory, and bankingInquiryService. The setters for these properties are not shown; they are straightforward. The validation method creates a report that will be returned, creates a stateless rule session, sets three global objects, and finally calls the execute method with all facts grouped in one collection. Because a stateless session is used, all facts need to be passed in one go.

Note the different style of using a stateless session. In this case we set all three globals through the setGlobal method. By setting them this way, the global objects are scoped to the session, so we cannot reuse this session across multiple validate method invocations (across multiple threads). This is why the session variable is scoped to the validate method and not the class, as was the case with our unit tests. This is just to show you a different way of working with the session without using commands.