Share this page to your:

Madura Rules is an optional plugin to Madura Objects. It handles more complex rules than what you can say in XSD syntax. The rules are specified in a RUL file and look a lot like Java code, deliberately so that Java programmers can write them easily. Here are some examples of what they can do:

• The Order total is always the sum of the amounts of the items under it.
• If the Customer type is ‘credit watch’ enable the credit check button.
• If the Pizza size is ‘small’ activate the ‘extra sauce’ check box and set the amount to 10.
• Calculate the bmi using: bmi = weight / (height * height).
• The sum of the items on the order can never be more than 1000 unless the Customer status is ‘wholesale’

Expression in the rules can be arbitrarily complex so the rules can get much more complicated than these. They implement various predefines functions to turn fields to required if they weren’t already (or back to not-required) etc. There are also list processing functions to sum and count items in lists of objects (like the list of order items) attached to an object. You can add your of functions if you want to.

‘Truth’ is always maintained by the rules engine, so if you set a value which causes the rules to derive another value, and then change the original value back, then the derived value will be unwound automatically.

Decision Tables

Using Madura Objects we mentioned using enums to generate a list of valid values for a dropdown field. Madura rules implements decision tables. These can be loaded with all valid combinations for several multi-choice fields. For example say you are specifying a pizza with a base, a topping and a size (small, medium, large). In a real pizza shop you would likely be able to order any combination of those. But what if some technical reason (or marketing reason) meant that the shop did not want to sell large seafood topping pizzas. Maybe they went through the topping too fast, or maybe they found the gluten-free base really tasted nasty with the seafood topping.

Wouldn’t it be nice if when the customer picked seafood topping in their online ordering system the gluten-free base disappeared from the choices on the base field and the only choice on the size was small? Or if they pick one of the other fields first and it is not compatible with seafood that choice goes away. That way every pizza that gets through the order process is a valid pizza. The shop doesn’t have to call back and explain that seafood and gluten-free taste bad etc. Madura Rules’ decision tables handles this situation easily. It can load decision tables from various sources including XML documents, database queries or something you build yourself.

Directed Questioning

Using the power of the rules alone you can implement directed questioning. Say you have a formula: bmi = weight / (height * height) and you want to find the value for the bmi. The formula is implemented as a rule and all the fields are on the same object (to keep it simple). You can launch a directed questioning operation which is effectively asking for the bmi value. The rules engine knows that it needs to find a value for weight. Now it may already have a value, this might not be the first thing this user did and it may have been entered or pulled from a database. But it if does not have a value it will be prompted for. Same with height. But it is more interesting than that. The formula needs those values in metric and people don’t always know their metric measures. So we might have other rules that deliver height converted from feet and inches, and weight converted from pounds. When the user is asked for metric height he can say ‘don’t know’ and the rules will try and find the height by conversion, which will result in another prompt, actually two: one for feet and one for inches. Eventually it will have enough data to figure the bmi.

Notice what happened here:

• We did not have to write ‘special’ rules for this. Just rules to derive the result from the data. The engine figured out what to prompt for.
• The engine did not prompt for things it already had.
• Expert users automatically answered fewer questions.

Advantages

The advantages of all this should be obvious but let’s spell them out:

• The business rules end up below the domain objects rather than implemented above them, which means you do not get them creeping into DAOs and UI layers, and that means for example, when you need to implement a different UI technology you don’t find the old UI is riddled with business rules that need to be re-implemented.
• Objects are defined outside of Java, in an XSD file. This means they get generated and they cannot be messed about with by people adding code to them when they shouldn’t.
• Simple objects means simple DAOs and simple UI code.
• There is almost no API to learn, so this is easy stuff for a fluent Java programmer to use. Most of the time you are just operating simple Java objects.
• The simple validation rules, the ones in the XSD file, are declarative and very obvious to get right.
• The Madura Rules RUL files are easy to understand (from a Java background) but powerful in that they implement full truth maintenance and contain an extensive (and extensible) function library.

In addition we support configuring the application with Spring XML, Spring annotations and CDI.

More Detail

Madura Rules is licensed with an AGPL which means you are free to use it in non-commercial applications and for commercial applications a commercial licence must be purchased. See the contact form to get in touch.

Source