Hi there, I'm back.
Some of the advatanges of using a Rule Engine against plain java code are:
- Declarative definition of your business rules, that can be expressed using a domain specific language that business analysist can validate and understand. In other words you can define what to do and not how to do it.
- You keep the business logic decoupled from your application, letting you change it without recompiling your entire application.
- You need to understand that having rules is not the same of having multiple IF/ELSE statements. The analysis of true statements are not done sequencially, allowing you to analyze multiple conditions much faster.
- Using rules you don't burry the business logic inside your application code
Among other advantages
Are you referring to using rules in general (like Mauricio has answered excellently ), or the more specific case of using Java code constraints vs. rule constraints inside your processes?
In fact, in the source code of krisv-jbpm, I find the test code about Java constraint and MVEL(rule) constraint in jbpm-flow-build/src/test/java/org/jbpm/integrationtests/processSplitTest.java, in this file, there is no difference between MVEL constraint and java constraint, see
public void testSplitWithMVELContextConstraint() and
public void testSplitWithJavaContextConstraint()
the two kinds of constraints are the same:
in the first function:
<constraint toNodeId="6" toType="DROOLS_DEFAULT" priority="1" type="code" dialect="mvel" >return context.getVariable("name") != null && ((String) context.getVariable("name")).length() > 0;</constraint>
in the second function:
<constraint toNodeId="6" toType="DROOLS_DEFAULT" priority="1" type="code" dialect="java" >return context.getVariable("name") != null && ((String) context.getVariable("name")).length() > 0;</constraint>
I don't know why?
By the way, in this test case file, there is also the comparison between context and kcontext, I don't know their difference and in the testcase file, their only difference is their name. Can you explain it?
MVEL is a scripting language, but it is a superset of Java, so any Java expression is also an MVEL expression. Though you can do more with MVEL, e.g.
myVariable = myPerson.name
(which would be equivalent to myVariable = myPerson.getName())
You can check out the MVEL documentation for all details:
Regarding context or kcontext, they resolve to the same object, context was the old name we used first, we later switched to kcontext (which is now the preferred) as it is similar to ksession and kbase etc.