We spent a long time analysing other rule engines - including jess,
clips, jrules and oracle business rules. We also contemplated
continueing something on the lines of Drools 2.0. BTW the Oracle
Business Rules language truly sucks. They spent some time trying to
implement their own rule engine and failed. They have sinced licensed
Jess and removed all the power and wrapped in a "Java Like" langauge
that I just couldn't warm too. I guess proprietary vendors have to
"differentiate" themselves and at no time can they pay hommage to the
inspiration from other vendors; where as we have no such vanity or
marketting constraints and are comfortable to cherry pick the best ideas
while tipping our hate to the origins of inspiration. Drools 3.0 owes
much to Jess/Clips/JRules, all of which are great systems and provide
the bar that I continual strive to meet.
After much deliberation I honestly believe the JRules approach to be
best for a declarative rule system.
Drools core remains to be language independant engine further to this
we have an intermediate AST called "descrs". This means that anyone who
is handy with parser can build their own rule language parser building
the descr AST. We welcome parsers for other languages like Jess or
JRules, or your own custom languge, as you described.
At no point is Drools 3.0 a dynamic language, everything is still 100%
type safe. You don't have to declare the type of a variable to be type
safe, there is no reason why the type of a variable cannot be determined
at compile time - this is exactly what we do - it is also something that
.Net/C# 3 will offer. This reduces the verbosity of the Rule. The entire
language is aimed at being as less verbose as possible while still
retaining clarity. We might loose Java purity, but I believe we gain
something much more.
ClassA( objA == "xyz" )
I believe this is to far clearer than spreading the logic over multiple
lines. In the syntax above I can see in a single glance the Class and
the field and the value I am constraining on. As we constrain on more
fields this becomes even clearer.
ClassA( fieldA == "xyz",
fieldB > 12,
fieldC == false )
This to me is much easier to grok than
a = ClassA();
a.getFieldA().equals("xyz") &&
a.getFieldB() > 12 &&
a.getfieldC() == false;
What do we gain from the inclusion on the "get" part of the field. This
might facilitate JavaBeans and introspection, but it does not make for
clearer and easier read rules. The more character you include the more
you have to read and the less clear a rule is.
Give it some time, it takes a while to get use to, newer syntax do. The
syntax is actually simpler and after a few hours of use I'm sure most
users will grow to like it. Not convinced? Then please write another
parser, competition is good and only through the rules of dynamic
evolution and competition can we improve. The Drools team will do
everything they can to support community members R&D efforts - we don't
have all the answers.
Yes there will be some bugs and caveats, but with the help and input of
community members we will solve each of these in turn. Michael and Bob
already have plans on how to make this more robust.
Mark
Hamu, Dave wrote:
Dmitry,
I have to concur with you, the syntax that has been implemented for the
Java Semantics is really whacky! I'm not sure what hole this semantics
was dug out of, but it kinda sucks.
Better would be:
(objA : ClassA.getStringAttr()) == "xyz"
I understand what is being done here is to take some of the effort out
of the process so that the developer does not need to write a rule to
populate scalar attributes, but at what cost???
Why not provide a declaration section above the when/then clauses so
that the developer could write the rule as:
rule "Better First Rule"
declare
objA = ClassA.getStringAttr()
objB = ClassB.getIntAttr()
when
(objA == "xyz")
(objB > 50)
then
// do some java code
end
Even then, there are some issues because of the fact that Java is a
typed language. Who's job is it to ensure that the comparisons and the
"do some java code" are type-safe? Wouldn't it be better if we stick
with type declarations as they existed in Drools 2.0? I have to admit
that while there are some cool things going on in Drools 3.0, some of
the decisions that have been made wrt Java semantics are puzzling. The
beauty of Drools for a Java developer was the purity and the seamless
integration of the Drools Java Semantics and JAVA! Why sacrifice that
purity???
Just MHO.
- Dave
-----Original Message-----
From: Dmitry Goldenberg [mailto:[EMAIL PROTECTED]
Sent: Friday, April 14, 2006 9:01 AM
To: [email protected]
Subject: RE: [drools-user] The DRL notation vs. jbossrules Rule Language
- ?
rule "First Rule"
when
ClassA( stringAttr == "xyz" )
ClassB( intAttr > 50 )
then
// do some java code
end
In this example, where is the call made to the getStringAttr() and
getIntAttr() methods on instances of ClassA and ClassB ??
rule "First Rule"
when
objA : ClassA( stringAttr == "xyz" )
objB : ClassB( intAttr > 50 )
then
// do some java code
System.out.println(objA);
System.out.println(objB);
end
Here, are objA and objB Boolean ?
________________________________
From: Edson Tirelli [mailto:[EMAIL PROTECTED]
Sent: Thu 4/13/2006 3:47 PM
To: [email protected]
Subject: Re: [drools-user] The DRL notation vs. jbossrules Rule Language
- ?
All,
Find in the following link, the documentation that is being built
for drools 3.
http://labs.jboss.com/portal/jbossrules/docs
On a quick explanation, the new syntax would be:
------------
rule "name"
ATTRIBUTES
when
LHS
then
RHS
end
------------
ATTRIBUTES: those are rule attributes like salience, duration, etc, in a
similar way Drools 2.x uses.
LHS: this is the left hand side of the rule. This is the previous
"parameter" + "condition" statements. (see bellow)
RHS: this is the right hand side of the rule. This is the consequence,
the same way in drools 2.
I think the simple way to explain LHS is to make a conversion
example:
<rule name="First Rule">
<parameter identifier="objA">
<class>ClassA</class>
</parameter>
<parameter identifier="objB">
<class>ClassB</class>
</parameter>
<java:condition> objA.getStringAttr().equals("xyz") </java:condition>
<java:condition> objB.getIntAttr() > 50 </java:condition>
<java:consequence>
// some java code
</java:consequence>
</rule>
The above rule when converted to Drools 3 would became:
rule "First Rule"
when
ClassA( stringAttr == "xyz" )
ClassB( intAttr > 50 )
then
// do some java code
end
If you need a reference to the actual object matched in each "column"
(more or less what Drools 2 call parameter), you can bind it in the
following way:
rule "First Rule"
when
objA : ClassA( stringAttr == "xyz" )
objB : ClassB( intAttr > 50 )
then
// do some java code
System.out.println(objA);
System.out.println(objB);
end
In the documentation you will find syntax diagrams that can help you
understand all possible syntaxes and all the new operators/features
drools 3 has.
[]s
Edson
Ronald van Kuijk wrote:
AINAE, but it could be as simple as 'replacing' condition with when and
consequence with then, but I'll let the experts tell me.
Ronald
2006/4/13, Dmitry Goldenberg <[EMAIL PROTECTED]>:
I don't understand the relationship between the XML-based DRL notation
and this new lingo with "when" / "then".
With the DRL notation, my understanding is that you write an XML
structure like the one I'm including below. How does this change with
the when/then notation? Thanks.
<?xml version="1.0"?>
<rule-set name="SamplePolicyRuleSet"
xmlns="http://drools.org/rules";
xmlns:java="http://drools.org/semantics/java";
xmlns:xs="http://www.w3.org/2001/XMLSchema-instance";
xs:schemaLocation="http://drools.org/rules rules.xsd
http://drools.org/semantics/java java.xsd">
<!-- Imports -->
<java:import>java.lang.Object</java:import>
<java:import>java.lang.String</java:import>
<!-- Utility functions -->
<java:functions>
public boolean
f1(com.weblayers.platform.rule.PolicyExecContextcontext)
{
return ...;
}
public boolean
f2(com.weblayers.platform.rule.PolicyExecContextcontext)
{
return ...;
}
</java:functions>
<!-First Rule: IF (P1 AND P2) THEN RETURN OK -->
<rule name="First Rule">
<!-- Rule parameters -->
<parameter identifier="context">
<class>MyContext</class>
</parameter>
<!-- Rule Conditions -->
<java:condition>
f1() && f2()
</java:condition>
<!-- Rule Consequences -->
<java:consequence>
context.setReturn(Constants.OK);
</java:consequence>
</rule>
<!-Second Rule: IF (!(P1 AND P2)) THEN RETURN FAILURE -->
<rule name="Second Rule">
<!-- Rule parameters -->
<parameter identifier="context">
<class>MyContext</class>
</parameter>
<!-- Rule Conditions -->
<java:condition>
!(f1() && f2())
</java:condition>
<!-- Rule Consequences -->
<java:consequence>
context.setVerdict(Constants.FAIL);
</java:consequence>
</rule>
</rule-set>
--
---
Edson Tirelli
Auster Solutions do Brasil
@ www.auster.com.br
+55 11 5096-2277 / +55 11 9218-4151
