NFJS: Drooling

[More of my first No Fluff, Just Stuff experience]

The second day of the "No Fluff, Just Stuff" symposium started off with a session called Drooling with Groovy and Rules presented by the indefatigable Venkat Subramaniam. I was really looking forward to this session, and I wasn't disappointed.

Venkat started the session talking about rules-based programming. Now, I've programmed rules engines before, but it had been a while and this refresher was very informative. He contrasted declarative programming (you say what you want, not how to do it) with procedural programming (a series of sequential instructions). Rules-based programming is declarative because you are describing the behavior you want not creating an algorithm with instructions to follow. You can program a rules engine in a procedural manner, but the if-else logic becomes unmanageable.

We then moved on to the anatomy of the Rules Engine. There are four basic parts to a rules engine: the rule base, the working memory or fact base, the inference engine, and the action list. I won't go into detail about each of these, but what basically happens is, given a set of facts that are in working memory, the inference engine determines which rules (in the rule base) will be fired. The result is a set of actions. What I just described was the forward chaining method. The other method of reasoning is called backward chaining which starts with a set of goals and works backwards to find supporting data.

After talking a little bit about computational complexity and the RETE (ree-tee) algorithm, we moved on to Drools. Drools is an open source rules engine that is JSR 94 compliant. You can express the rules in XML with Java or Groovy, Python, a Domain Specific Language, or the new JBoss Rules. Venkat demonstrated Drools with XML and Groovy which was great because I finally got to see Groovy in an enterprise type environment. Here's a look

<rule name="Big Time Buyer accepts Big Time seller" salience="1">
<parameter identifier="buyer">
 <class>com.agiledeveloper.Collector</class>
</parameter>
<parameter identifier="seller">
 <class>com.agiledeveloper.Collector</class>
</parameter>
<parameter identifier="theExchange">
 <class>com.agiledeveloper.Exchange</class>
</parameter>
<groovy:condition>theExchange.seller == seller</groovy:condition>
<groovy:condition>theExchange.buyer == buyer</groovy:condition>
<groovy:condition>buyer.bigTimeOperator</groovy:condition>
<groovy:condition>seller.bigTimeOperator</groovy:condition>
<groovy:consequence>
 println('Big Time Buyer accepts Big Time seller')
 theExchange.okToTrade = true
</groovy:consequence>
</rule>

He also showed a little of the JBoss Rules syntax which follows more of the typical rules-based language format. Apparently, JBoss has no immediate plans to support Groovy in the JBoss Rules format (I'm a sad Panda).

Anyway, this was a great session because, like I said above, I got to see Groovy in a real enterprise environment. Okay, that maybe a little strong, but finally seeing the potential was great. Also, programming a rules engine forces you to think in a different manner and can introduce some interesting challenges. There are several opportunities at my current job for this type of programming, so this session was extremely beneficial.

Next up: Domain Specific Languages