Friday, May 29, 2009

Drools Flow 5.1 Preview 1: Web console

Now that Drools 5 has been released, we're already working on the new features for the next release. I'll be adding some blog entries over the next few weeks about what we are planning to do for Drools Flow, and this is the first one.

Web-based management console for processes

Most of the work so far regarding Drools Flow has focused on creating a runtime for executing processes and the "hooks" to integrate that into your application. This involves APIs for starting processes, checking the status of running process instances, etc. Developers could use this API to retrieve the information they needed. There was however no easy way for non-technical people to access this information.

Heiko Braun has recently been working on a Business Process Management console which allows you to do just that ! And the console itself is completely pluggable, meaning that you can link in your own process engine implementation and extend the various views. So that is exactly what we did !

The console itself provides views for:
- viewing all processes that are part of your knowledge base
- starting and managing all running instances of a particular process
- showing the task list of the user
- reports summarizing of the execution history

The following screenshots show how this all looks like for a very simple employee performance evaluation process.

First you need to log in (role-based access control).

In the processes section you can get a overview of all the processes in your knowledge base, which is loaded from Guvnor. In this case, there's only one sample process called "com.sample.evaluation".

You can then get an overview of all the running process instances for that process. Since there are none, we quickly start a new one, after which we have one running instance, as shown below.

You can also get an overview of the current status of a specific process instance. In this case, our evaluation process is waiting for the user to perform a self-evaluation first (which is modeled using a human task node assigned to this user) before continuing, as shown by the icon in the top right corner of the node.

When switching to the task section, you can get an overview of all the tasks that a user can claim or that are assigned to him / her. In this case, there's only one task assigned to this user, which is the evaluation task created by starting our sample process as shown before.

The user can then execute his task. A task form linked to the task in question is then shown. These task forms can be created using freemarker templates and can ask specific input from the end user, which will then be returned to the process. This example shows a simple task form where the user has to fill in some evaluation questions and complete the form.

Finally, the report section allows you to view reports that show the history and/or current status of your processes. These reports are created using the Eclipse Business Intelligence and Reporting Tool (BIRT). This report for example shows the number of processes started (in the last few hours), the number of still active process instance and the average completion time per process. Users can define their own custom charts to monitor the key performance indicators of their business, based on the history data of the process engine and any other data sources available.


Drools Boot Camp : San Francisco 1-7 June 2009

I have just sent out a group email to those that registered for the San Francisco boot camp. If you are planning to attend and did not receive an email or would like to attend and have not yet registered, then please contact me asap - mproctor at redhat d0t com. We have a few spaces left, so if you want to attend, hurry.

Details of the boot camp can be found here:

And the registration page is here:

Drools T-Shirts now available at CafePress

Drools T-Shirts can now be bought from CafePress here.


Wednesday, May 27, 2009

Imperfect Evaluations #2

I had an interesting discussion today, and one of the topics was operator usability: even if the 4 steps described in the previous blog ( allow to define a custom evaluator quickly, will a user have to repeat them for every custom operator/evaluator they want to use? The answer is no...

  • Many Operators, One Definition, Many Evaluators
A user may want to define different, but correlated evaluators. Just to make an example, consider an Operator ("white") and its negated (e.g. "black"). Or think of the fuzzy sets that could be used to define a domain (e.g. "very young", "young", "adult", "old", "very old" for ages). One still needs different Evaluators, but can use just one Definition class. So, the steps become:
  1. Attach the Operators to the same Definition:
    org.drools.evaluator.[eval1] = [MyMultipleEvaluatorDefinition]
    Notice (thanks Edson) that this needs to be done only once.

  2. [MyMultipleEvaluatorDefinition] must register the different Operators. Also take care that getEvaluatorIds() returns all the ids.

  3. The method
    getEvaluator(..., String operatorId, ...) 
    must return the appropriate Evaluator according to the value of operatorId. Maybe a
    could be useful...

  4. Of course, the individual Evaluators have to be defined independently

  • Many Operators, One Definition, One Evaluator
A user could otherwise have an object capable of evaluating different properties. Suppose, for example, you have a Neural Network trained for Optical Character Recognition.
For the unfamiliar readers, such a NN is a classifier which processes a bitmap image and returns the character which most resembles - in the sense of probability or similarity - the shape in the image.
Whatever the case, the Evaluator, e.g. the network, has more than one imperfect outputs, each one with a different symbolic label.
A way to use it could be to define an Operator, e.g., "resembles" and attach the network to it, writing rules such as:

Bitmap( this ~resembles 'A' )

But imagine that one wants to define different Operators:

Bitmap( this ~isA )
Bitmap( this ~isZ )

To do this, one would have to behave exactly as in the previous case, but now the Evaluators would be different Adapters wrapping the single "real" Evaluator, such as:

public class NNAdapter extends BaseImperfectEvaluator {
private char target;

private static NeuralNetwork classifier;

Notice that this, independently on the chosen solution, is an option for the easy creation of hybrid intelligent systems, mapping a connectionist module such as a Neural Network onto a symbolic structure such as "resembles" or "isX". This is not trivial.
  • Dynamic Evaluators
Surely there exist more patterns, so let me introduce more. The Evaluators defined so far are static, since they are to be known at compile-time. To use a custom Evaluator at run-time, two dynamic (meta) Evaluators have been defined:

  1. Seems

Person( $a : age ~seems old )

The meta-evaluator SeemsEvaluator, associated to the Operator "seems", extracts an object from the left field and an unary Evaluator from the right expression, according to the pattern:

Type( $f : field ~seems eval )

To return a degree, SeemsEvaluator invokes the right Evaluator on the left field.
Having to return an Evaluator, the right argument is typically a variable or an expression, but can't be a literal constant. However, there is an exception: it can be a String, but in that case the field's value is required to be an object implementing an interface, IDynamicEvaluable, with the single method:
getEvaluator(String args)
This is a callback to the evaluand, which provides the appropriate Evaluator itself.

(A final remark: I know, you would have expected the SeemsEvaluator to be attached to the Operator "is". But "seems", imho, recalls more its imperfect nature. If you don't like it, just attach the Evaluator to a different Operator.)

2. Evaluates

"Seems" has a dual Operator/Evaluator: "Evaluates". It allows to write rules using the pattern:
   Type( $f : evaluator ~evaluates value  )
which includes
   Evaluator( this ~evaluates value  )

The (unary) Evaluator must be the pattern object itself, or can be stored in a field.
Again, "evaluates" feeds the result of the right expression to the left Evaluator and returns the result.

-- thanks to Edson Tirelli for some precious advice on how to improve this post!


Tuesday, May 26, 2009

Imperfect Evaluations

This is my first technical dive into Drools Chance and is a follow up to my posting "Take your Chance".

The first step in adding imperfection to a rule is to give up its "boolean" nature. Consider again the example:
$r : Room ( $temp : temperature > 25 )  //r1 

The (literal) restriction on the field temperature wraps an Evaluator, '>' in this case, which is responsible for comparing the actual value $temp to the literal value 25. Of course, assuming that the bean $r models a known Room with a precise thermal sensor...

1) Imperfect Data
In a more realistic scenario, all you have is an imprecise and unreliable sensor: a simple real number is hardly adequate to model the measured value. One could take a measurement error into account, or maybe a "reliability" value if sensors tend to fail and return inconsistent values. To store all the information, one could define a simple bean:

declare UnreliableTemperatureMeasure
mean : float [-20..60]
error : float [0..10]
reliability : Percentage [0..1]

Now the field temperature returns an instance of UnreliableTemperatureMeasure, which has to be compared with a threshold:

$r : Room ( $temp : temperature > $thold )  

The threshold itself could be an instance of the same class, UnreliableTemperatureMeasure, created at some earlier point in the code:

thold = new UnreliableTemperatureMeasure();

The value stored in $thold now represents a reliable, but slightly relaxed "25 +/- 1.5"

Imperfect Evaluators
The main drawback of using UnreliableTemperatureMeasures instead of Numbers (or any other custom class, in any ohter context) is that the standard evaluator '>' is no longer adequate.
Drools, however, allows the definition of custom evaluators:

$r : Room ( $temp : temperature ~above[ params... ] $tHold )  //r3

A custom evaluator is (an instance of) a class holding a piece of business logic. It computes whether - and in which degree - the left operand has a certain property with respect to the optional right operand and some additional initialization parameters.

The full APIs are quite powerful and flexible, but not yet stable. However, one often just needs to define a simple imperfect custom evaluator quickly and get it to work. This can be done in a few steps:

  1. Set the RuleBaseConfiguration property "org.drools.evaluator.[CustomEval]" to the name of a class extending

  2. Such class, e.g. [CustomEvalDefinition], must register an Operator:

    public static final Operator CUSTOM = Operator.addOperatorToRegistry( "custom", false );

    public String[] getEvaluatorIds() {
    return new String[] {"custom"};

  3. ... and define the method getEvaluator, which returns the instance of the Evaluator proper:
    public Evaluator getEvaluator(ValueType type, String operatorId,
    boolean isNegated, String parameterText,
    Target leftTarget, Target rightTarget) {
    return new CustomEval();

  4. The class [CustomEval] extends
    and overrides the method:
    protected abstract IDegree eval(Object left, Object right, IDegreeFactory factory);

Notice that the EvaluatorDefinition creates a decoupling between the Operator - e.g. "above" - and the actual Evaluator. This also means that the same instance of Evaluator could be used to define different operators.

3) Imperfect Degrees

Back to the original problem... Suppose that the probe returns a slightly unreliable (24.3 +/- 2): it's not possible to say whether such value is certainly greater than (25 +/- 1.5).

Given the values, it could seem not very probable: likely it will never be but much greater, but it is possible nevertheless. How to evaluate this is the task of the CustomEvaluator associated to the Operator "above".

Which information to return and how to do it, instead, is yet another degree of freedom. Drools Chance provides an interface, IDegree, which should be implemented by any class modelling the degree of truth/probability/certainty/possibility/... at which a constraint is satisfied.

An IDegree should at least model the concepts of "true", "false" and, possibly, "unknown". So, it is possible to cast an IDegree to boolean and vice versa.

The simplest, and most widely used, type of IDegree is a real number in [0,1], and has been used to model confidence, certainty, fuzzy degrees of truth, simple probabilities, ...

IDegrees are not built directly, but using a concrete object implementing the interface IDegreeFactory. The factory, which can be set using a RuleBase configuration property, ensures that the degrees used in the computation are coherent.

More importantly, using custom pluggable evaluators together with custom pluggable degrees allows to change the behaviour of a rule without changing the abstract idea behind them. For example, the concept of "temperature above threshold" expresses an abstract concept which can be specialized according to different interpretations.

Monday, May 25, 2009

Drools vs jBPM personal experience

This comment was published in The Server Side web page ( in response of some comments asking about the differences and the overlap between two projects from JBoss: jBPM and Drools low. The Drools team saw my comments on the site and invited me to publish them here. It's my experience and the reason why I have chosen Drools over jBPM to work with every day and contribute as a community member.

Here is the link to the comment and the article.

I hope that gives to all you guys a simple and not biased developer perspective.

Here is my comment:

Hi guys,

Regarding the Drools vs jBPM discussion, I can share my recent experiences making the shift from jBPM to Drools. I started with jBPM about a year and a half ago, at the beginning it seemed to be a decent framework, very process centric and developer oriented. When I started to play with rules and delegating the business decisions to the inference engine, I started to notice that I needed to learn another set of very different of API, and that these two frameworks didn't integrate very well.

When I decided to get involved with the Drools project, about 8 months ago, I realized that the integration proposed for version 5.0 was what I, as a developer, was looking for years. A whole environment that allows me to model different business situations with an unified set of APIs and merging three of the hot topic today: BPM, Business Rules and Complex Event Processing, all in one! And since it's not easy to define all my business logic using only one of those, it's promising to see I'm now allowed to combine (and integrate!) them whenever necessary.

The other thing that really attracts me is the fact that the tooling created by the Drools team is great, very extensible and easy to use, with a lot of extra features compared with the jBPM tooling. In my opinion, the most useful features are:
1) A powerful set of nodes to model your business processes
2) An easy way to create your domain-specific processes. I created a lot of new domain-specific nodes in a very short period of time. And these can be used inside the graphical tooling immediately.
3) Nice debugging tools, you can follow your process (and rules) step by step, simulating your execution.
4) The real possibility to support and plug in new languages. I have participated in the OSWorkflow migration tool, and I see that is very easy to create support for different languages. This is so cool that it would also allow you to run jBPM3 defined processes with RuleFlow.
5) A lot more extra features like a human task management component based on WS-HumanTask, reporting, etc.

So far I only mentioned the technical advantages that we discovered making the switch from jBPM to Drools, but there is another mayor thing that pushed me towards Drools, and that is the fact that the group of core developers are really open to new ideas (that is very cool, in not every project you can find that) and let the community members share their personal experiences and contribute with them on an every day basis.

It is also important to mention that the Drools project seems to be be evolving at a much faster rate than jBPM, which seems to have been frozen for about 3 years now. From what I've seen, they are working in version 4 of their framework, without adding new functionality compared to version 3.

I hope that my experience helps you to choose the right tool for your situation, I have already chosen, and that is why I try to contribute every day to this nice framework and promote it to succeed, because it makes the life of the developer easier. And that is all we want !!


Drools on Twitter & San Francisco

This is for those who are either on twitter, or coming to the San Francisco boot camp (or both !).

I have been on twitter for some time (as michaelneale, markproctor is also there..), and find it both fun and useful. One of the things that sucked me into it was in San Francisco for java one last year - keeping track of what was going on and where people were etc... This can be done via web interfaces, a million phone and desktop apps, or even SMS itself...

So I have created a DroolsRules twitter account: for drools things - follow this to be notified of what is happening, specifically to do with the boot camp if you are coming (or are just curious).

Now, one other nice thing, is if you follow it, I can follow you back: send a "direct message" to DroolsRules and it will be echoed to other followers.

If this is all wierd jargon to you, don't sweat, its simpler then it sounds !

See some of you soon in SF !


Friday, May 22, 2009

Drools 5 Released

Drools Guvnor

The Drools team are pleased to announce the release of Drools 5.0 Final. Everyone's favourite Java Rule Engine with the delivery of version 5.0 gives genesis to the Business Logic integration Platform, which provides a unified and integrated platform for Rules, Workflow and Event Processing. It's been designed from the ground up so that each aspect is a first class citizen, with no compromises.

Drools 5.0 is now split into 4 modules, the links below provide more information and screenshots for each module:

Drools Guvnor
Drools Expert
Drools Fusion
Drools Flow.

Guvnor is our web based governance system, traditionally referred to in the rules world as a BRMS. We decided to move away from the term BRMS to something based on governance, as our long term emphasis is no longer rules specific. Expert is the traditional rules engine. Fusion is the event processing side, it's a play on data/sensor fusion terminology. Finally there is Flow which is our workflow module.

The Drools 5.0 Release Notes

Home Page


Drools Boot Camp - San Francisco 1-7 of June


Monday, May 18, 2009

Dell online help support fails the Turing Test

It's official Eliza is more intelligent than Dell help agents.

Had a sadly hilarious online chat with Dell support today, it reminded me of the old Eliza program. I expected any minute for it to ask me how I felt about the fan.

Here is the conversation I had, it's the abridged version as I removed a lot of other peripheral stuff:
Initial Question/Comment: Fan is loose and making a loud ricketting noise.
agent: Have you done any diagnostic tests or trouble shooting steps to help identify the issue?
me: did you read my questions? how do I diagnose a ricketting fan, am I speaking to a person here, or a bot?
agent: I am a human.
me: just wanted to be sure, didn't want to go round and round being asked the same Qs, via an automated agent.
agent: What have you tried so far to fix this?
me: um to fix a fan I'd have to open up my laptop, this voids my warranty, want me to do this now?
agent: Did you already tried to update your BIOS for your fan issue?
system: The session has ended!

Thursday, May 14, 2009

Live Models Using JBoss Drools and EMF

C├ędric Brun has blogged his investigations into getting Drools to work with Eclipse EMF, so I thought I'd plug his latest entries, with a choice quote and images below:

Live Models Using JBoss Drools and EMF
The 20 minute Graphical Modeler based on Eclipse

"You bet I picked the Rules Engine, so that I can get my hands dirty with those strange beasts you (most of the time) never ever want to meet again after you graduated. I picked JBoss Drools which seemd just nice, powerfull, and based on an implementation of a Rete-like algorithm - which make it fast - and I have to admit I liked their logo is really cool.

EMF and Drools are going along really nicely. Drools considers your Java instances as facts and is then really easy to integrate with EMF. EMF provides the generic notification mechanism which make it really easy to integrate with drools so that drools know that something changed and that he might have some work to do."


Wednesday, May 13, 2009

Take your Chance

If you read a paper, or a journal, or an article, or a note recommending NOT to use a Production Rule System, you will find that one of their strongest point is that Rule Systems are too... logical. In fact, a Rule Base must be built with complete and correct Knowledge of its domain, and it is expected to evaluate exact data, to yield new exact information. No need to say that domain knowledge can hardly ever be defined complete and correct - and even then, when can the input data be defined exact?

Actually, there are many applications for which these conditions ARE true, but what happens when they are not - e.g. medicine, finance, forecasts, .... A RBS is an all-or-nothing solution: either the knowledge and the inputs are precisely defined, or no information will ever be entailed. Yet there is another option: letting the engine become imperfect, so that it can deal with the imperfection in its inputs. Is it ironic for an engine to become more powerful by being less perfect? If it seems so, consider the simple example:

Room ( temperature > 25 , $f : fan )

This rule, "turn the fan on, if the room is hot (and you have one)", is perfectly acceptable, but could easily become inadequate under a few circumstances:

  • Imagine the temperature fluctuates with imprecision around 25°, say from 24.9° to 25.1°: should you activate the fan or not? Such action could have a cost, and with the energy prices rising...

  • Imagine you have a sensor measuring 30°, but it is placed in a sunny spot just under the window: the value it returns may not be the real one. Or the sensor could be broken and, from time to time, yield random, unreliable values. Is your confidence strong enough to justify the activation of the fan?

  • Imagine you don't have a temperature sensor: you know that the room is hot, for sure more than 20°, but not the exact value of the temperature. Should the fan be turned on even in presence of such a vague estimate?

  • Imagine you are getting back home from work, and can activate the fan using a SMS. You know your room IS hot, unless someone opened the window earlier in the afternoon. There is some probability that you need to turn on the fan, but some that you need not

  • In any case, is turning on the fan always the right decision? Maybe there are exceptions to be considered...

  • and so on...

The target of the new sub-project, Drools:Chance, is to make our favorite rule engine capable of dealing with any - possibly even more than one - type of imperfect information natively. This means that the degrees of imperfection will not have to be processed explicitly in the rules, as the engine will take care of it behind the scenes. Moreover it will be possible to configure the behavior of the engine to reason with different types of imperfection without changing the rules: like different flavors, a user will be able to pick his favorite one.

I have been working on a prototype for some time, and have implemented several new features, which I will show in this blog. However, there is still much to do: from implementation, to optimization, to documentation, to testing, to providing advice. So any help, even a simple but constructive comment, will be appreciated.

Davide "sotty" Sottara
-- No Laws, just Rules.

coming soon: Custom Degrees, Evaluators and much more...

Sunday, May 10, 2009

Definition of Hell for an Englishman

"There have been many definitions of hell, but for the English the best definition is that it is the place where the Germans are the police, the Swedish are the comedians, the Italians are the defense force, Frenchmen dig the roads, the Belgians are the pop singers, the Spanish run the railways, the Turks cook the food, the Irish are the waiters, the Greeks run the government, and the common language is Dutch."

David Frost and Anthony Jay

Monday, May 04, 2009

Michael speaking JAOO 2009 (Sydney, Brisbane)

Michael is speaking at JAOO 2009 (Sydney and Brisbane conferences).
(Sydney, this Friday, at 1pm, specifically).

Not entirely rules related, but if there, say hi (I will probably be loitering around the Red Hat stand as well).

Sunday, May 03, 2009

Miss Manners 2009: yet another drools-solver example

A couple of weeks ago James Owen proposed a larger Miss Manners benchmark for rule engines on his blog.
Last weekend he posted the first dataset, so this weekend I took it upon myself to implement this "Manners 2009" as an example in drools-solver.

In Manners 2009, miss Manners is throwing a party again.
  • This time she invited 144 guests and prepared 12 round tables with 12 seats each.
  • Every guest should sit next to someone (left and right) of the opposite gender.
  • And that neighbour should have at least one hobby in common with the guest.
  • Also, this time there should be 2 politicians, 2 doctors, 2 socialites, 2 sports stars, 2 teachers and 2 programmers at each table.
  • And the 2 politicians, 2 doctors, 2 sports stars and 2 programmers shouldn't be the same kind.

Drools-solver solves this planning problem.
Here's a screenshot of a result of a table in drools-solver:

As you can see, all constraints are met. I estimate I've implemented this example in roughly 14 working hours (including the GUI work). So, with drools-solver, planning problems are easy!