MRules: A Simple, Powerful Java Rules Engine for Business Apps
Easy Rules too simple? Drools too much? MRules is a new kid on the block that hopes to take a middle ground while including externalized configurations.
Join the DZone community and get the full member experience.
Join For FreeSay you're working on an app that has to implement lots of business rules. You might have explored Drools or Jess and thought it's too much for your needs. And Easy Rules or RuleBook might be great, but they might be too light and, moreover, you can't externalize configuration. Then your friend Google tells you about MRules...
MRules Genesis
Some time ago, I worked on a project in which we needed to implement business rules in several use cases. We had some strict constraints:
- Rules had to be configured by an administrator, with a GUI.
- Execution had to be fast.
- Code had to be reusable.
- Rules could be complex, and not only [if X == Y then Z = "value";].
- Rules had to be ordered and a rule output could be the input of a following one.
We checked out Drools and it quickly appeared complex. VERY complex. We didn't need all these inference things, and it was difficult to build a GUI to configure it.
Same conclusion for Jess. OpenRules is a Formula 1 car used to drive through town. No, we needed something simple. Easy Rules? Well not that simple... and with external rules configuration, please!
Hard coded rules? Too expensive. And adding a new rule implied development.
So, MRules was born. We built a lightweight, extensible and simple rules engine dedicated to business apps and to business logic, which is often made by sequentially operating a bunch of rules.
It evolved with the time, and it's now a full-featured rule engine, offering a wide range of possibilities which will cover, out of the box, most current (and less current) business cases.
How It Works
MRules is based on a really simple concept. You provide data under the form of one or more Java beans. Fields of these beans are read, other are written.
When you enter a little more into the details, a rules engine will have four steps in its lifecycle:
- Building: From a Java API or from an external configuration using Factories. For the moment, only XML format is supported, but others will be added soon. And it's easy to build its own Factory.
- Compiling: In order to check rules validity, to pre-compute data for performance issues (mainly related to data types).
- Optimizing: Performing some rework on some rule patterns in order to improve performance.
- Executing: The most interesting part, which can be safely executed multiple times and in a multi-threaded system!
MRules Features
Lots of features are provided, including but not limited to:
- Support for functions in rules configuration.
- Extremely efficient data access framework.
- Powerful data conversion system, automatically detecting necessary transformations.
- Internal cache system to improve data reads.
- Java 8 Date Time support.
- Modular design, making it easy to extend. Creating extensions and add-ons is simple.
- Easy-to-learn APIs and many demo projects.
- Centralized builder (the use of which is not mandatory) allowing us to detect changes in configuration and automatically recompile the rules engine.
- Simple integration with Spring or in a J2EE environment.
- Integrated log system, adapting itself to the main log interfaces (JUL, SLF4J, JCL).
Getting Started
Adding MRules to your project is as simple as a Maven dependency:
<dependencies>
<!-- Adding dependency -->
<dependency>
<groupId>com.massa.mrules</groupId>
<artifactId>MRules</artifactId>
<version>1.9.0</version>
</dependency>
</dependencies>
<profiles>
<!-- Declaring remote Maven repository -->
<profile>
<id>mrprof</id>
<activation><activeByDefault>true</activeByDefault></activation>
<repositories>
<repository>
<id>mrules</id>
<name>mrules</name>
<url>http://mrules.xyz/pubrepo</url>
</repository>
</repositories>
</profile>
</profiles>
Then, write you first rule:
<?xml version="1.0" encoding="UTF-8"?>
<rules implem="RULEEXECUTIONSET" name="Hello" contextFactory="CONTEXT:example.dzone.User">
<executable implem="PRINTF" message="Hello {{first}} {{last}}, how are you today ?" first=":firstName" last=":lastName" />
</rules>
This rule means you have a data model represented by the User class, with the fields firstName and lastName:
package example.dzone;
public class User {
private String firstName;
private String lastName;
public User(String firstName, String lastName) {
this.firstName = firstName;
this.lastName = lastName;
}
public String getFirstName() {
return firstName;
}
public void setFirstName(String firstName) {
this.firstName = firstName;
}
public String getLastName() {
return lastName;
}
public void setLastName(String lastName) {
this.lastName = lastName;
}
}
Just launch, and it will print "Hello John Doe, how are you today ?" in the console:
package example.dzone;
import com.massa.mrules.context.execute.IExecutionContext;
import com.massa.mrules.context.execute.MExecutionContext;
import com.massa.mrules.factory.xml.RichXMLFactory;
import com.massa.mrules.set.IMruleExecutionSet;
public class Hello {
public static void main(String[] args) throws Exception {
final RichXMLFactory factory = new RichXMLFactory();
final IMruleExecutionSet set = factory.read(ClassLoader.getSystemResourceAsStream("hello.xml"));
final IExecutionContext context = new MExecutionContext < User > (set, new User("John", "Doe"));
context.execute();
}
}
Road Map
We have lots of ideas to improve MRules and add new features. Some of the main ones:
- Creating new configuration formats, like Excel and JSON (for data exchange), but mainly, we are currently working on writing rules via natural language. It will be similar to the Gherkin language, but with different objectives.
- Creating a generic configuration GUI. It's a very vast and time-consuming project and might take time to be released.
- Adding new rules formats, operators, and micro-features that simplify rules writing.
Why Isn't It Open Source and Free to Use?
MRules is a part-time activity for its main developers, it's not our main income source. The license is very cheap compared to the cost of making your own dedicated rule engine.
It only allows the users to participate in the costs induced by the project (hardware, web hosting, etc ...).
Also, you can try it absolutely free before buying the license. And if you feel you can't afford the license, just tell us and we'll find something that works.
Opinions expressed by DZone contributors are their own.
Trending
-
Competing Consumers With Spring Boot and Hazelcast
-
What Is React? A Complete Guide
-
4 Expert Tips for High Availability and Disaster Recovery of Your Cloud Deployment
-
Using OpenAI Embeddings Search With SingleStoreDB
Comments