Book Image

Drools JBoss Rules 5.X Developer's Guide

By : Michal Bali
Book Image

Drools JBoss Rules 5.X Developer's Guide

By: Michal Bali

Overview of this book

<p>Writing business rules has always been a challenging task. Business rules tend to change often leading to a maintenance nightmare. This book shows you various ways to code your business rules using Drools, the open source Business Rules Management System.<br /><br />Drools JBoss Rules 5.X Developer's Guide shows various features of the Drools platform by walking the reader through several real-world examples. Each chapter elaborates on different aspects of the Drools platform. The reader will also learn about the inner workings of Drools and its implementation of the Rete algorithm.<br /><br />The book starts with explaining rule basics, then builds on this information by going through various areas like human readable rules, rules for validation, and stateful rules, using examples from the banking domain. A loan approval process example shows the use of the jBPM module. Parts of a banking fraud detection system are implemented with the Drools Fusion module which is the complex event processing part of Drools. Finally, more technical details are shown detailing the inner workings of Drools, the implementation of the ReteOO algorithm, indexing, node sharing, and partitioning.</p>
Table of Contents (22 chapters)
Drools JBoss Rules 5.X Developer's Guide
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
Setting Up the Development Environment
Creating Custom Operators
Dependencies of Sample Application
Index

Problems with traditional approaches


There is no well-defined way to represent the business logic in Java or C#. What usually happens is that every application represents business logic differently.

For example, consider this code that does some checking on customer level, customer accounts, and account balance:

if (customer.getLevel() == Level.Gold) {
  // do something for Gold customer
} else if (customer.getLevel() == Level.Silver) {
  if (customer.getAccounts() == null) {
    // do something else for Silver customer with no accounts
  } else {
    for (Account account : customer.getAccounts()) {
      if (account.getBalance < 0) {
        // do something for Silver Customer that has                        // account with negative balance
      }
    }
  }
}

Code listing 1: Code written in standard Java (or any imperative-style language)

First, the code checks if the customer's level is Gold and does something, then it checks if the customer's level is Silver, and if so, it checks if this customer has no accounts and does something in this case. If the customer has accounts, the code performs some logic for each account that has a negative balance.

The point of this Java "spaghetti code" is to give you an idea about what we are trying to prevent. You may think that it doesn't look that bad; however, after a couple of changes in requirements and developers who are maintaining the code, it can get much worse. It is usually the case that if you fix one bug, you are more likely to introduce several new bugs. Lots of requirements are literally packed into few lines of code. This code is hard to maintain or change to accommodate new requirements.

It is not only difficult to represent business logic in an imperative programming style language, but it is also hard to differentiate between code that represents the business logic and the infrastructure code that supports it.

For developers, it is hard to change the business logic. For the domain experts, it is impossible to verify the business logic and even harder to change it.

There is a need for a different paradigm for representing the business logic.