Skip to main content

New tool for writing Domain Specific Languages in Drools

Posted by n_alex on July 11, 2005 at 12:18 PM PDT

When I started working on Drools in January of 2004, my goal was to eventually be able to embed Drools in a web-framework-turned-action-sequencer I was working on, called Shocks. Two weeks ago, to my complete astonishment, I realized I'd implemented the complete inverse of my original idea--and much more.

This May, after a winter-long recovery from post-mercenarial burnout, I began reapproaching the problem of Domain Specific Languages in Drools. I began working with the Drools semantic module framework (drools-smf), trying to figure out how to write DSLs. There's no real documentation on the subject, and I committed myself to writing those docs, just as soon as I could figure out how it all worked. I decided to write a simple example DSL called "Expresso" (sic), to illustrate the concerns of a very specific problem domain--the sacred and immortal rules that guide the behavior of coffee shop patrons. The name of the language was intended to underscore the hilarity of the problem domain. Armed with this irony, I set about coding.

My work came to a head last week when I finished implementing an inversion of my original idea for Shocks. Instead of embedding Drools and a custom Domain Specific Language inside of an action sequencer, I implemented the action sequencer as a domain specific rule language in Drools. Ultimately, I found myself standing on the other side of a mirror I first looked through about two years ago. Only this way actually kills several other birds as well, such as the problem of building extensible and natural sounding rule languages that business analysts can understand.

I love a good surprise.

What I learned over the course of the last month of feverish programming, was that the drools-smf library is so expansive in what it permits, that anyone with solid knowledge of XML and Java (i.e., has written their own XSDs and parsers, eats DTDs for breakfast, etc.) should be able to create just about anything they can imagine in the way of XML-based rule languages.

However, the price of this permissiveness is complexity--Drools' semantic module framework requires that language designers learn about the way the underlying rule engine works. They'll find themselves working with tuples, the working memory, fact handles, declarations and underlying logic closer to the RETE-OO core of Drools than they might care to travel. The more I worked with it, the more I felt it encroaching on what I was trying to do. I became convinced that