Should I be using JBoss Rules, jBPM, SQL or just plain Java?
JBoss Rules is not a magic bullet - there I've said it.
What I mean by that is that JBoss Rules is a sexy, interesting new technology with many applications and it is natural to look at ways in which such new addition to the JEMS product suite can be applied to customer problems.
However, JBoss Rules also has considerable overlap and some confusion (regarding its applications) in people's minds with jBPM. It may also remain more appropriate to use plain Java or SQL for a particular solution (or certainly to consider these technologies as alternatives). This Wiki page aims to give an overview of when it is likely to be most appropriate to use JBoss Rules in contrast to one of the other options.
JBoss Rules as an Expert System
It is important to briefly put JBoss Rules in context with the entire field of Artifical Intelligence (AI), in which it belongs, before looking at how JBoss Rules relates to other technologies which might be appropriate tools to solve a business problem.
AI is a very broad research area that aims to allow "computers to think like people" - i.e. to mimic "natural intelligence" within a computer system. AI includes disciplines such as Neural Networks, Genetic Algorithms, Decision Trees, Frame Systems and Expert Systems.
Knowledge Representation is an area of AI that is concerned with how knowledge is represented and manipulated. Application of knowledge is a key part of natural intelligence and hence a key aspect that needs to be emulated in AI.
Expert Systems use Knowledge Representation to make it easier to capture knowledge into a knowledge base which a computer can then use to reason about observed data and to infer conclusions based on a combination of the knowledge and the data.
A Rules Engine is a specific type of Expert System which represents knowledge as a set of rules (think if...then... statements) defined with respect to and modifying observed data (called facts in this context). JBoss Rules is an implementation of a Rules Engine.
Even more precisely, JBoss Rules is classified as a Production Rules Engine. This means that it is "Turing complete" - i.e. it can be formally demonstrated that one can solve any computational problem using JBoss Rules.
However, this does not mean it is necessarily the best way to solve a given computation problem (or even an appropriate way to solve a given problem)...bringing us nicely on to the bulk of this page, when might it be most appropriate to consider JBoss Rules and when might another approach be more likely to provide a better result...
JBoss Rules vs. plain Java
There are a couple of key differences it is important to understand between "standard" Java programming and a rules-based approach:
Java is an object-oriented language which means that data (variables) and behaviour (methods) are combined into Java classes. JBoss Rules starkly seperates data (facts) and behvaiour (rules). Neither approach is "better" but they do contrast in this way.
Java is an imperative (also called procedural) language where you specify both what you wish to have to happen (as code statements) and how you wish it to happen (using control structures including if...then... and while constructs). JBoss Rules is a declarative language where you specify what you wish to happen - the goal (in the form of a series of rules) but do not define how it will happen - the method. Instead you leave the rules engine to apply the rules.
These differences are not the whole story, but coupled with the expert systems discussion they lead to the reasons why one would consider using JBoss Rules rather than using Java. I have divided these into two categories.
Primary Reasons for Using JBoss Rules rather than Java
The first category are those areas where JBoss Rules allows you to do something that it would be prohibitively expensive or even impossible to obtain the same goal using straight Java coding. Here JBoss Rules is playing to its strength and being applied as an expert system. Most people would agree to this list as good applications for a rules engine.
if you need to search a large solution space efficiently to find an answer to complex problem and exhaustively looking over the entire space is prohibitively costly an expert system's based solution such as Monte Carlo, Genetic Algorithm or rules engine is likely to be a good fit
if you can capture the logic behind the appropriate solution as a set of relatively small and discrete logical statements that must be satisfied that have relatively few interactions, a rules-based approach is likely to be an expressive and appropriate way to define the required solution
if you need to be able to explain why you reached the solution that you reached, a rules engine is likely to be able to do a better job of this (by auditing which rules were fired during the evaluation process) than the alternate expert system approaches
if the rules for the system change infrequently and the system has many facts but only a relatively few of the facts change at any given time or the facts evolve slowly then the caching characteristics of the Rete algorithm (which underlies JBoss Rules) are well suited to making efficient decisions
Secondary Reasons for Using JBoss Rules rather than Java
The second category are those areas where JBoss Rules allows an alternate approach to doing something it would be possible in Java. It becomes more of a matter of opinion, personal taste and down to the specifics of the problem domain whether one or more of these reasons would lead to a JBoss Rules solution being appropriate.
as business logic is externalized from code, a developer is not required when it changes, making the logic more agile
as business logic is externalized from code, frequently changing logic can be more readily updated by changes to the external DRL file rather than code
business logic can be expressed in a more concise language, closer to the language a business expert will understand, fostering communication and understanding of the IT systems in which rules are used
business logic and business data can be kept seperate (can be seen as a benefit or as breaking a desired OO approach)
business analysts can own changes by editing a DRL file as opposed to developers owning changes by editing Java source files
An experienced developer will be likely to see that many of these potential benefits can be realised using Java programming and a suitable external configuration file, or other techniques such as jBPM (see below).
Reasons for Using Java instead of JBoss Rules
To complete this section, let us briefly consider why you might wish to avoid the use of a JBoss Rules system
if none of the above reasons to use a JBoss Rules system then the learning curve for a new technology is unlikely to be justified
the Rete algorithm behind JBoss Rules is very efficient at inferring behaviour from rules but it does a large amount of up front optimisation. This can require relatively large amounts of memory and can have a performance impact, especially if you set up a whole set of facts and data, evaluate the rules and then throw it all away and start again!
JBoss Rules vs. jBPM
Some rules of thumb and questions to ask if you are wondering if JBoss Rules or jBPM are likely to be a better fit to solve your business problem:
if it is possible to draw up a well-defined flowchart of steps to follow that lead from a starting point to one or more endpoints - jBPM is likely to be more appropriate than JBoss Rules (jBPM is designed to support such a workflow, JBoss Rules may have to be forced to behave in this way)
if you need more than one actor to collaborate in order to execute a decision making process - jBPM is likely to be more appropriate than JBoss Rules (jBPM has explicit built-in support for multiple actors, JBoss Rules does not)
if the execution of a decision making process or workflow is likely to take minutes, days or hours rather than seconds - jBPM is likely to be more appropriate than JBoss Rules (jBPM is designed to support long-running process instances like this with pauses in execution while steps are executed by human actors, JBoss Rules is designed to execute in a single call to fireAllRules())
if the execution of a decision making process requires many interactions with external systems during process steps - jBPM is likely to be more appropriate than JBoss Rules (jBPM includes a built in framework to support interactions with external systems, JBoss Rules is more introspective with all required facts typically asserted in advance)
JBoss Rules vs. SQL
Each rule in a rules engine approach will map directly to a potential SQL statement (another declarative language) where the data objects from the rules engine are replaced by the rows in a set of database tables.
This means that some applications of a JBoss Rules engine can be addressed by using SQL queries on a database.
In general the rule of thumb here is relatively simple:
if it is possible to construct one or more SQL queries that can be executed in a defined sequence on a database to produce an an answer, you should definately strongly consider using a query-based approach directly on a suitably optimised database rather than using JBoss Rules - it is likely to perform better
if it is hard, impossible or prohibitively messy to specify one or more SQL queries than can define the entire solution one is looking to achieve but natural to specify a set of smaller, more independent SQL queries than define characteristics of the solution that must be met a JBoss Rules approach should be considered over a query-based approach on a database
i.e. when your SQL gets messy and convoluted as you try to find a solution, applying JBoss Rules may be a good option
Comments