David Bolton Strikes Again

I plan on writing some more structured details on implementing a DSL with Drools when I get a chance, but for the moment, this is an email I sent to the Drools user list in response to a query about how Drools DSL works:

A ConditionFactory and ConsequenceFactory are used to create Condition
and Consequence objects. These objects have access to the
Configuration object, which is in concept an XML wrapper. So the XML
you see inside the tag is essentially the
configuration for the action.

Your custom Consquence object can inspect the Configuration (i.e. the
content of the action elements) and perform any arbitrary process on
it. In the house example, there is code that interprets that XML, and
programmatically sets the heating to be off in the room object
representing the lounge. How you do this is up to you, but the
natural implementation would be a Map of Room objects with a Heating
property. The Consequence does the programmatic work to translate the
XML to the object model.

Condition objects operate in the same way.

So the DSL is not necessarily the text of the elements but encompasses
the whole XML structure. There needn’t be any element text at all if
you wish, the elements and their attributes themselves could provide
everything you need to perform rule processing.

Obviously then, there is a certain amount of work in implementing a
DSL. And creating a DSL is not very well documented (I might add some
of my experiences now that I’ve actually created a non-trivial DSL).
But the benefit once the Condition, Consequence, and Factory objects
have been coded is that a relatively complex process can be translated
to rules using a rule structure of your choosing.

Drools seems to be getting more and more interest every day. I’m just new to it myself, but its easy to see how its extremely useful in the right scenario. Right now, it appears theres a lot of people trying to figure out if their uses for rules engines are valid.