Madura Software

Madura Objects

Imagine Business Objects looking like ordinary Java Objects. They have setters and getters and your code calls those to do obvious things.

Now imagine these objects are self-aware of their validation requirements. They know they need a valid email address in that field, they know an amount cannot be less than 100 and so on. The calling code doesn't know about any of this, but it gets a runtime exception when the data is not valid.

Let's go a little further: You have an Order object with several Item objects attached. Each of those has an amount, the price of the item, and those need to be summed to a total in the Order. The Order knows this. When the calling code adds items or changes the amounts in the items it recalculates the total. It also does it if items are deleted, and it applies the freight and various discounts as well. Your calling code knows nothing of this. It just sees the amount changing.

The obvious way to do this is to code the business rules into the objects. We don't do that. In fact we don't directly code our business objects. We generate them with JAXB and we like to use the HyperJAB3 plugin to add persistence annotations, making them JPA compatible. And we also get JAXB to add the Madura hooks too.

We leave the rest up to Madura which uses the generated hooks to implement the business rules, and we interpret the term 'business rules' quite broadly. Here are some more examples of things we use them for. We do all these from the XSD file:

  • The order reference field can have up to 30 characters, no more.
  • The label for the order reference field is 'order.reference', a key to be looked up in the language resource before rendering.
  • Only a user with SUPERVISOR permission can update the item amount field. Render it disabled for the others.
  • Only a user with PAYROLL permission can see the wages amount field. Do not render it for the others.
  • The Customer name field is required. Mark it on the UI somehow and disable the submit button until it is filled in.
  • Also disable the submit button if any fields are in error, required or otherwise.
  • Render the amount as a 2 decimal, with punctuation according to the user's current locale.
  • The Customer status field can only have values from an enum list. It has a default value of 'retail'.
  • These are all implemented in Madura Objects and, for the UI, Madura Vaadin which uses Vaadin for its UI technology. You probably need a diagram around now:

    The business objects, generated from the XSD, look like anemic objects, and they are in the sense that they don't contain the business rules, just a few hooks and annotations. The validation engine (part of Madura Objects) uses those to enforce the rules. So we call this a delegating anemic model. The important point is that the business rules are below the application code which is unaware of them. Clearly you can have multiple applications, perhaps using different technologies, using these objects, each of which has no knowledge or interest in implementing the rules.

    But there is more in the diagram: the RulesPlugin. This is Madura Rules. So far almost everything has involved just one field at a time. You can specify a field length etc for each field. But what if the business rules involves multiple fields?

    Madura Rules

    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.

    Projects

    The Madura suite consists of the following modules:

    Documentation

    Every project has a PDF posted to Maven central along with Javadocs, binaries etc. So for more detailed information you should go there next. The Git repositories hold all the source, and they all build with Maven.

    Licensing

    All of the modules are available as open source. All except Madura Rules carry an Apache 2.0 license which means you can use them anywhere you like without charge. Madura Rules carries an APGL license which means you can use it in any non commercial application without charge, but not in commercial applications. A commercially licensed copy of Madura Rules is available for a negotiable fee.

    If you want to use the other Madura products commercially without Madura Rules there is no fee. You are also free to write your own rules (or other) plugin for Madura Objects.

    Environment.

    All of these projects are written in Java. We use Eclipse as our development environment so they are all Eclipse projects as well as maven projects. The binaries, source and detailed docs are all uploaded to the Maven Central repository.

    The image in the header is the ceiling of a church in southern France.
    The name 'Madura' was chosen because it is an island near Java.
    Madura was developed by Prometheus Consulting, a New Zealand based software consultancy.